scrum - Лофт Миколи Сарри

scrum

A collection of 11 posts

От провала проекта гибкие методологии не спасут

– У нас не получится уложиться в сроки! – Примените Agile! – Без достаточного количества людей он нам не поможет! – Тогда придумайте другое умное слово! Многие люди связывают провал проекта с выбором методологии разработки, вот выбрали бы Scrum/Agile/DevOps то все было бы хорошо. Скажу честно – такие люди ничего не понимают в

Scrum в древнем Египте и сейчас

История Agile берет свое начало в ферале 2001 года, когда был опубликован документ под названием Agile Manifesto. Текст документа состоит из очевидных философских формул (простота – искусство не делать лишнюю работу) и ряда спорных утверждений (лучшие технические требования, дизайн, архитектура получаются у самоорганизованных команд). Документ является странным не только содержанием, но

Проблемы при внедрении SCRUM

В этой статье я хочу рассказать как избежать самых болезненных неприятностей при внедрении чего-то нового в компании на примере фреймворка SCRUM. Также рассмотрим какие средства могут помочь в борьбе и как избегать подобных неприятностей. Некоторые сотрудники против изменений Фреймворк SCRUM как правило внедряют чтобы уменьшить TTM (time to market)

Почему Scrum вам не поможет

Вы видите как конкуренты и партнеры внедряют у себя скрам и показывают результаты выше чем у вас. Конечно же вы тоже решаетесь внедрить его у себя. Для вас есть плохая новость – при неправильном внедрении он принесет больше вреда, чем пользы. Предлагаю ознакомиться с перечнем ситуаций в которых скрам помешает вашей

Правильный Scrum: Эпизод 3 - Scrum Master

Продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору. Есть культура, у которой есть свой культ, свои обряды, есть служители

Правильный Scrum: Эпизод 2 - Команда

В первом эпизоде мы рассмотрели признаки правильного scrum со стороны роли Product Owner и симптомы неправильности с вариантами исправления. В этом эпизоде мы рассмотрим ситуацию со стороны команды. Одна из мантр scrum – команда должна быть самоорганизованной и кросс-функциональной, что выглядит как самая простая часть scrum: берем людей с нужными

Правильный Scrum: Эпизод 1 - Product Owner

Я больше 6 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами. [sendpulse-form id=”278″] Начну с метафоры, так как иногда приходилось видеть внедрение

Синхронизация команды в SCRUM

Как мне кажется, одна их самых больших проблем в работе команды не только в скрам — рассинхрон между людьми в команде. Стабильного и универсального решения этой проблемы к сожалению нет. Есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры, но их использование помогает

15 минут, без которых не видать релиза

Большинство IT-компаний привыкли к ежедневным внутренним митингам, статусным собраниям или коротким stand up, которые призваны оптимизировать процессы и синхронизировать работу всех членов команды. Оптимально, если такие встречи не превышают 15 минут. В Agile-разработке без митингов никуда. Однако рабочие собрания у команд Scrum, Kanban или XP отличаются и имеют

Scrum или Kanban?

Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban. [sendpulse-form id=”278″] Две популярные Agile-методологии Scrum и Kanban — итеративные методологии. Перед тем, как разобраться в разнице между

Коротко о Scrum, Kanban, XP

Разработка программного обесечения требует своевременного принятия правильных решений. Но все принимаемые решения нужно синхронизировать. Один из резидентов Hacker News написал о том, как наблюдал за экспериментом, когда в одной крупной компании пяти сотням разработчиков разрешили принимать решения в “отрыве” от команды. Он пишет, что был хаос. Хотя команды начали работать