Комментарии 42
зачастую нельзя поправить ситуацию использовав «кусочек» agile, проблемы оказываются системными. вы же в Москве, идите в scrumtrek.ru, определенно помогут поставить «правильный» agile
Беклоги мы тоже поделили. У каждого модуля системы свой беклог. Т.к. задач очень много — так намного удобней формировать задачи для спринта.
Пленинг покер используем, но носит он больше информативный характер. Для синхронизации команды в понимании задачи.
Sprint != Большая задача. Это один из худших антипаттернов.
Sprint это timebox. Когда время вышло, спринт закончен. То же самое и со всеми остальными церемониями.
Из статьи создаётся ощущение, как верно сказали выше, что у команды нет четкого понимания того как работает scrum и зачем. А самое важное — нет scrum master — человека который отвечает головой за оптимизацию процесса и рост velocity (не инфляцию velocity, а именно рост).
Мне кажется что у вас очень серьезные проблемы с декомпозицией на Story, а учитывая "рекомендательный характер" оценки, команда еще не очень хорошо понимает как эта самая оценка работает. Возможно, в силу размера техдолга, неправильной разбивки задач, отсутствия необходимых скиллов в команде.
Что же касается Kanban, то это очень строгая методология. Я не видел ни одной успешной канбан-команды, у которой были бы проблемы со scrum. Т.е. всего того что описали вы.
Все это, в целом, очень знакомо, и связано, в частности, с недостатком знаний и информации по теме.
К счастью, это легко исправить.
Я очень рекомендую почитать вот этих ребят:
https://www.scrum.org/resources/scrum-guide
Jeff Sutherland — один из создателей Scurm. Scrum.org — это его компания.
Удачи вам в становлении ваших процессов.
но вот по канбану… это не методология, это метод управления работой. формально нет ролей, нет митингов — есть принципы. тоесть в целом канбан менее предписуем по сравнению со скрамом. Девид Андерсон выделяет 7 уровней зрелости канбан системы, но, в целом, даже просто визуализация работы в виде стикеров на стене, то это тоже будет канбан. www.kanbanmaturitymodel.com
Согласен, что формально это будет Kanban-ish, но даже стабильный lead time без эффективно выстроенных процессов, инфраструктуры и умения правильно декомпозировать задачи — фактически недостежим, а значит и планирование будет неэффективным.
Вы верно сказали выше, любое внедрение должно начинаться со строгого следования правилам. А все остальное это kai-zen.
Спасибо что обратили на это внимание. Это — суть agile. Фрэймворк это вторично.
Увидел негативные комментарии и захотел сказать что мне понравилась статья. Я сам встречался с сетапом когда скрам не очень работает, так что на мой взгляд не стоит догматично за него держаться.
Дело не в 10 минутах, если бы захотели экономить — вообще отменили бы стендапы. Это больше вопрос синхронизации команды и озвучивания проблем. Иногда проблемы вскрываются там, где их вроде-бы не было (Пр: по разному поняли задачу; ждут кого-то, но не сказали об этом, либо сказали, но их не услышали).
На вопрос "а если вы сделаете говно?" апологеты аджайл отвечают что-то вроде "мы вместе составляем ТЗ на 2 недели и мы по нему работаем, через 2 недели вместе смотрим результат и составляем ТЗ на следующие 2 недели".
Приёмка ведётся каждые две недели по ТЗ на эти две недели. Если скорость продвижения заказчика не устраивает, то он меняет подрядчика. Опять же рисков меньше чем выдать ТЗ на три года с этапами по полгода.
Не слышал ни разу.
ИМХО долго и неудобно, причем режет слух гораздо больше, чем редеплой. ИТ термины пришли с английского языка и не всегда стоит им искать замену.
Я подозреваю, что русский язык заимствовал большУю часть слов из других языков: тюркских, финнского, французского, немецкого. Вы же не говорите лошадиное молоко, а кратко и употребляете более подходящее кумыс.
Заимствования делают язык богаче.
Пока получается, что у вас были «какие-то процессы», вы «что-то сделали», и у вас стали «какие-то другие процессы». Это здоровое, но…
Наверное хабр пора делить на хабр-next и хабр-старпёр -))
Т.к. продукт работает 24/7, а code-freeze делаем только в случае выкатки критического функционала — чем дольше спринт ждет — тем больше риск конфликтов и необходимости повторной прогонки регрессии(а то и не одной).
+ бизнес нервничает, куа нервничают, все нервничают, а нервные клетки не восстанавливаются :)
Что-то мне кажется в самом начале было как то неправильно. Спринт в скрам не предлагает релиза в конце спринта, может быть релтз раз в год, а может каждая закрытая задача релтз. И спринт не может быть задержан. Прошёл срок и подводим итог успешный спринт или нет. Ждать никого не надо, надо начинать новый спринт, в который не выполненные задачи из неуспешного переносятся, если не появились более приоритетные.
Как мы разбили разработку на команды (и забыли про бесконечные спринты и бесполезные стендапы)