Как стать автором
Обновить

Как мы разбили разработку на команды (и забыли про бесконечные спринты и бесполезные стендапы)

Время на прочтение 6 мин
Количество просмотров 15K
Всего голосов 42: ↑29 и ↓13 +16
Комментарии 42

Комментарии 42

уберите пожалуйста тег, из agile у вас здесь только терминология. и, может, управление процессами разработки это не ваше?..
НЛО прилетело и опубликовало эту надпись здесь
забавно говорить о agile, забывая как минимум прочесть scrumguide и хоть что-то о канбан-методе. безусловно agile об экспериментах, но вся статья сквозит непониманием базовых принципов

Зачем читать scrumguide если намерения внедрять скрам нет? Был консультант, который пособирал информацию и сказал, что скрам не взлетит.

Может Вы можете подсказать, какой agile является правильным? :)
тот, в котором организация, ее структура и процессы в целом осознано оптимизируются на доставке бизнес ценности отталкиваясь от принципов и ценностей agile. концепцию shu ha ri слыхали? сначала делаем, как канонически предписано, потом адаптируем под себя, потом уже создаем свои правила.

зачастую нельзя поправить ситуацию использовав «кусочек» 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 минутах, если бы захотели экономить — вообще отменили бы стендапы. Это больше вопрос синхронизации команды и озвучивания проблем. Иногда проблемы вскрываются там, где их вроде-бы не было (Пр: по разному поняли задачу; ждут кого-то, но не сказали об этом, либо сказали, но их не услышали).
НЛО прилетело и опубликовало эту надпись здесь
Говорить про ТЗ в agile-процессах как-то странно. Нормальный скрам не предполагает ТЗ, так как ТЗ это классический waterfall со своими всем известными проблемами.
НЛО прилетело и опубликовало эту надпись здесь

На вопрос "а если вы сделаете говно?" апологеты аджайл отвечают что-то вроде "мы вместе составляем ТЗ на 2 недели и мы по нему работаем, через 2 недели вместе смотрим результат и составляем ТЗ на следующие 2 недели".

НЛО прилетело и опубликовало эту надпись здесь
В теории это идеальная схема для получения заказчиком в и тоге, того что ему в итоге нужно, а не того, что он думал, что нужно три года назад.

Приёмка ведётся каждые две недели по ТЗ на эти две недели. Если скорость продвижения заказчика не устраивает, то он меняет подрядчика. Опять же рисков меньше чем выдать ТЗ на три года с этапами по полгода.

Без всяких "в теории". Достаточно попытаться поднять хотя бы один сколько-нибудь новаторский в рамках конкретной компании проект, и сразу станет понятно, что "работа по утвержденному ТЗ" === "работа в стол". Пока такого опыта нет — можно с апломбом делать утверждения любого масштаба.

Сильно зависит от процессов компании, её масштабности и отношения проекта к этим масштабам. Где-то хорошо зайдёт, где-то только ненужный оверхед внесёт.
Чисто ради информации, как сказать редеплой по русски?
«переразвёртывание», «повторное развёртывание»
Спасибо.
Не слышал ни разу.
ИМХО долго и неудобно, причем режет слух гораздо больше, чем редеплой. ИТ термины пришли с английского языка и не всегда стоит им искать замену.

Я подозреваю, что русский язык заимствовал большУю часть слов из других языков: тюркских, финнского, французского, немецкого. Вы же не говорите лошадиное молоко, а кратко и употребляете более подходящее кумыс.
Заимствования делают язык богаче.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо, вы не говорите кисломолочный напиток из кобыльего молока.
Может пример не очень удачный, но суть в том, что любой язык непрерывно развивается и заимствует слова. И в случае с ИТ терминологией для русского языка это не несет негативных последствий.
В статье не хватает чисел «было»/«стало», а без этого нельзя наверняка понять стало ли лучше.

Пока получается, что у вас были «какие-то процессы», вы «что-то сделали», и у вас стали «какие-то другие процессы». Это здоровое, но…
Блин, тоже хочется «поворчать», но влом-)
Наверное хабр пора делить на хабр-next и хабр-старпёр -))
Сотрудники как относятся ко всем этим экспериментам? Вы их спрашивали, как по их мнению наладить эффективную работу?
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Прошу уточнить — а кто такой в вашем понимании «тимлид»?
Сотрудники относятся с пониманием :) Часто инициативы для изменений приходят с ретро либо с one-2-one. Не все, что хочется можно внедрить и не все приживается, но сотрудников точно слушают и слышат.
НЛО прилетело и опубликовало эту надпись здесь
Спринт из 20-30 задач задерживался и ждал решения одной задачи. В результате — один человек фиксит проблему, остальные «придумывают» себе работу.
Т.к. продукт работает 24/7, а code-freeze делаем только в случае выкатки критического функционала — чем дольше спринт ждет — тем больше риск конфликтов и необходимости повторной прогонки регрессии(а то и не одной).
+ бизнес нервничает, куа нервничают, все нервничают, а нервные клетки не восстанавливаются :)
НЛО прилетело и опубликовало эту надпись здесь

Что-то мне кажется в самом начале было как то неправильно. Спринт в скрам не предлагает релиза в конце спринта, может быть релтз раз в год, а может каждая закрытая задача релтз. И спринт не может быть задержан. Прошёл срок и подводим итог успешный спринт или нет. Ждать никого не надо, надо начинать новый спринт, в который не выполненные задачи из неуспешного переносятся, если не появились более приоритетные.

Релтз=релиз

Зарегистрируйтесь на Хабре , чтобы оставить комментарий