Скрам-паттерны для предсказуемости команд

В сфере разработки программного обеспечения команды сталкиваются с высокой неопределенностью. В Спринтах, несмотря на лучшие стремления команды, все может пойти не так, оценки “плывут”, а результаты часто непредсказуемы. Давайте разбираться почему так происходит, и как улучшить ситуацию с помощью Скрам-паттернов.

Разработчики непрофессионалы или…?

Когда я работал программистом, то был фрустрирован тем, что постоянно не попадал в оценки. Не покидало ощущение, что я ненадежный работник и на меня нельзя положиться. С такими же проблемами сталкивались мои коллеги. 

“Злые” проблемы

Инновационная работа отличается от серийного производства. У рабочего на заводе есть конкретные стандарты качества и приемки продукции. Подшипник готов, когда он соответствует разработанной спецификации. Каждая новая фича в Бэклоге Продукта представляет собой новую проблему и по своему уникальна, а технологии и окружение постоянно меняются. Разработчик начинает лучше понимать проблему, когда появляется первоначальное решение. 

Хорст Риттель и Мелвин Уэббер определили «злую» проблему как проблему, которая может быть четко определена только путем ее решения или решения ее части. Этот парадокс подразумевает, по сути, что вы должны «решить» проблему один раз, чтобы четко определить ее, а затем решить ее снова, чтобы создать работающее решение. (Стив Макконнелл)

Читать далее «Скрам-паттерны для предсказуемости команд»

Правильное ведение хозяйства

или ежедневный чистый продукт

https://sites.google.com/a/scrumplop.org/published-patterns/_/rsrc/1555448727626/value-stream/good-housekeeping/GoodHousekeeping_Head.jpg?height=317&width=320

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

Команда разработки двигается к Цели Спринта.

✥ ✥ ✥

Если вокруг беспорядок, вы тратите время и силы на поиск того, с чего нужно начать.

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

Слишком большой объем информации на Доске информации путает сотрудников и мешает отделить главное от второстепенного. Это отнимает время.

Если команда откладывает наведение порядка на конец Спринта, это тормозит прогресс. Команда может вообще не навести порядок в рабочей среде, так как к концу Спринта появляется много «срочной работы». Беспорядок в ходе Спринта существенно снижает производительность (см. Заметки о производительности) и качество продукта.

Пустая трата времени возникает из-за работы в условиях неясного прогресса.

Поэтому:

Каждый день продукт (код) и рабочее пространство должны быть абсолютно чистыми.

Читать далее «Правильное ведение хозяйства»

Illegitimus Non Interruptus (без стука не входить)

Скрам-команда обслуживает многих стейкхолдеров, и все они борются за внимание команды. Команда получает запросы и требования от стейкхолдеров, от каждого клиента, от отделов продаж и маркетинга. Кроме того, в ходе работы появляются баги и это тоже требует внимания. Частота и важность этих запросов меняется. Иногда их объем и срочность просто чрезмерны.

✥ ✥ ✥

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

Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.

Часто неудачные решения Владельца Продукта ведет к тому, что к Скрам-команде начинают обращаться с конфликтующими запросами. Некоторым командам приходится даже работать над фичами, которых нет в Бэклоге Продукта.

Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-команда не будет обращать внимание на скрытые дефекты.

Это, а также другие причины постоянно мешают работе Скрам-команды.





 Читать далее «Illegitimus Non Interruptus (без стука не входить)»