Среди сотен различных Agile-практик разработки программного обеспечения есть несколько совершенно бесполезных, но, как ни странно, они все еще очень популярны среди многих организаций и Scrum-команд.
Вот мой список 5-ти лучших Agile-практик, на которые уходит много времени и которые бесполезны:
1. Оценка пользовательских историй в Story Points по конечным результатам.
Единственная причина оценки в Story Points - проверить, есть ли у команды одинаковое понимание того, что и как нужно сделать для завершения User Story. Оценка любой работы методом от обратного контрпродуктивна и не приносит никакой пользы: Какой смысл проверять, одинаково ли мы понимаем то, что уже сделано? Кроме того, это подрывает правильное использование Story Points на сессиях планирования.
2. Фокус внимания во время Ежедневного Scrum на ответах на знаменитые три вопроса: 'Что вы сделали? Что вы будете делать? Есть ли какие трудности?"
Проведение ежедневных Scrum должно помочь вашей команде синхронизировать свои действия с тем, что происходит в данный момент в спринте и с тем, как мы можем перепланировать нашу деятельность, чтобы увеличить шансы на достижение цели спринта. Знаменитые 3 вопроса ежедневного стенд-апа перенаправляют фокус с цели спринта и командного взаимодействия на индивидуальную работу и личный вклад. Во время ежедневного Scrum мы должны сосредоточиться на реорганизации своей деятельности наилучшим образом для достижения целей спринта.
3. Использование критерия Team Velocity (производительность/скорость команды) в качестве основного способа измерения успеха команды и прогнозирования будущих результатов.
Story Points - это просто абстрактный способ помочь членам команды лучше понять требования. Их использование для долгосрочного планирования - это пустая трата времени и создание ложной уверенности в том, что все под контролем. Существует множество прогностических научно обоснованных моделей и инструментов (например, метод Монте-Карло), которые могут помочь в прогнозировании возможных будущих результатов, но velocity (скорость) не является одним из них - это просто случайное угадывание.
4. Внедрение определения Ready (готовности) в качестве stage gate в вашем процессе.
Установление правильного баланса между работой над наиболее важными пунктами в спринте и недопущением хаоса в работе команды (из-за часто меняющихся приоритетов) является ключевой деятельностью каждой Scrum-команды. К сожалению, часто команды выстраивают свой фокус на процессе по принципу stage gate и вводят формальное определение Ready (готовности) с множеством сложных условий. Каждый процесс, основанный на этапах, снижает вероятность работы над самыми важными пунктами и лишает наибольших преимуществ Agility - гибкости, которая заключается в быстрой реакции на изменения.
5. Использование самоорганизации в качестве объяснения беспорядка, недостатка управления и отсутствия индивидуальной ответственности.
Самоорганизация - один из самых сложных способов управления командами и людьми. Она требует много времени, знаний и коммуникативных навыков, чтобы помочь группе незнакомых людей начать работать вместе как команда без необходимости дополнительного контроля со стороны внешнего наблюдателя. Самоорганизованная команда не может быть оправданием для невыполнения целей или отсутствия индивидуальной ответственности за работу - все действия команды, такие как распределение ролей, разделение ответственности, оценка результатов или способы контроля работы членов команды, должны быть закреплены в самоорганизованных командах.
Неправильно применяя вышеперечисленные практики, вы не только тратите время своей команды, но и препятствуете правильному использованию Agile подходов. Неверное использование Story Points, DoR (Done to Ready - определение готовности) или концепций самоорганизации постепенно приведет к потере доверия и демотивации ваших коллег к применению других методов и практик Agile.
И вместо заключения приглашаю всех на бесплатный вебинар, в рамках которого рассмотрим несколько вопросов:
Обучение в онлайне – как сделать это действительно эффективно?
Принятие решений Agile-командой – как меняется подход?
Гигиенические правила онлайна – проверь себя сам
Tips & Tricks при работе в онлайне – что помогает делать полезные встречи (и почему так) рассмотрим несколько способов. Коснёмся классического инструмента critical path.
Комментарии (16)
AlexSpaizNet
08.10.2022 07:02+3Так все таки сами практики бессмысленные или все таки неправильное использование практик является проблемой?
DirectoriX
09.10.2022 08:14+1Каждая конкретная практика может (не) работать в каждом конкретном случае, а также может (не) требовать подстройки под конкретные условия.
Подобные практики — не более чем инструменты со своей областью применения, но некоторые команды упорно подметают пол отвёртками, а потом жалуются, что отвёртки только вредят.
ryo_oh_ki
09.10.2022 10:23+1Story Points - это просто абстрактный способ помочь членам команды лучше понять требования.
Нет, они не для этого. Такое же отсутствие понимания Agile во всех остальных пунктах. Не статья, а одни манипуляции... ????
mclander
09.10.2022 12:10Практики - это отправная точка, имхо. Если они работают как в учебнике, прекрасно. Если нет (при их соблюдении), то нужно либо адаптировать практики либо перекраивать команду. Иногда и то и другое.
Я участвовал в нескольких скрамоподобных процессах и большая часть из них нормально работала. Для данного проекта и данной команды, хотя от феншуя они были если не далеки, то уж точно не близки.
lxsmkv
08.10.2022 15:43+4Обьясните мне как вот это (типичное усредненное высказывание из любого дейли)
Вчера я работал над двенадцать сорок два, сегодня я продолжу работать над двенадцать сорок два, но в час мне нужно к дантисту. Так что посмотрим как далеко я продвинусь.
помогает другим участникам спринта принимать решения? Какая информация содержится в таком высказывании для других? Никто ведь по правде не знает уже, что там за 1242.
Единственное, что из этого можно предположить, это что результат мы узнаем вероятно только завтра. И ведь в данном примере человек мог бы ничего не говорить и результат мы бы узнали тоже завтра.Или вот другое типичное высказывание из дейли:
Вчера я закончил работать над двенадцать восемнадцать, мне нужно ревью на пулл реквест.
Пулл реквесты и так все видны в системе управления кодом. Почему поиск партнера на ревью нужно сообщать всем? Найди себе подходящего партнера закрепи за ним ревью и все.
И вот мой вопрос, как поменять содержание сообщенийк так, чтобы они стали полезнее для самого человека и для окружающих.
Вы понимаете, содержание типичных высказываний в дейли настолько шаблонны, что давно появились боты для этого.
Не знаю, может я просто слишком рацинально мыслю поэтому мне неэффективная коммуникация очень бросается в глаза. Все-таки не только айтишники пользуются аджайлом и скрамом.
auddu_k
08.10.2022 21:29+1Так команда и должна работать над эффективностью коммуникации и это самое важное.
В статье как раз и говорится про синхронизацию: первый пример как раз является контрпримером синхронизации, а вот второй вполне себе хорош, если отсутствие ревью стало или может стать проблемой.mclander
09.10.2022 12:16+1Нет. Первый пример отличный пример синхронизации, если кто-то до этого выступал по 1242, то есть команда в курсе. И текущий спикер просто уточнил позицию. Хотя если бы он сказал, что продолжит сегодня, но скорее всего результат будет завтра к обеду (в том числе по причине дантиста)
Вторая причина оправдания упоминания дантиста в том, что 1242 работают несколько человек и спикер имеет лучшую экспертизу, то есть он намекает, что вопросы надо задать до часу или после 15-16.
За второй согласен иногда ревью превращается в реальный ботлнек.
K_Chicago
09.10.2022 10:26+7у меня одного ощущение что энтузиасты Agile - это что-то вроде свидетелей Иеговы или саентологов (только вредоноснее)?
mclander
09.10.2022 12:17Именно энтузиасты, плавно превращающиеся в инквизиторов или просто те, кто аджайл используют всуе? ))
Paskin
09.10.2022 12:28+2В Agile есть несколько хороших идей - но когда компания/отдел начинают его внедрять силой, да еще и с помощью нанятого "тренера", как правило с хорошо подвешенным языком и нулевым пониманием специфики работы - тогда пиши пропало...
Особенно доставляет, когда начальство всеми силами старается препятствовать проведению ретроспектив - "как бы чего не вышло". Или наоборот - на ретроспективах люди кидаются друг в друга какашками, забывая о том что сначала надо добиться соответствия планов и реальности, и только потом начинать улучшать velocity.K_Chicago
10.10.2022 05:20В Agile есть несколько хороших идей - но когда компания/отдел начинают его внедрять силой, да еще и с помощью нанятого "тренера", как правило с хорошо подвешенным языком и нулевым пониманием специфики работы - тогда пиши пропало...
То же можно сказать и про коммунизм(а также фашизм). Задумано-то было из лучших побуждений (и как я понимаю, по обкурке, а что же еще могут сделать 17 программистов собравшись в Юте?), а получилось как обычно...
Лично меня больше всего бесит их новояз. Как я понял, любой новояз в любой области - это попытка откровенное говнище обмазать шоколадом.
Я работал в Wells Fargo и там спустили приказ - во всех подразделения весь девелопмент исполнять только и исключительно методом Agile. Буквально.
Это примерно как на заводе распространить директиву - все работы во всех цехах делать только гаечным ключом 8x12, иначе расстрел.
Когда я на "стэнд-апе" для смеха процитировал из первоисточника 4 основых принципа, на меня написали донос что я своими высказываниями наношу вред командному сотрудничеству.
AxCoder
09.10.2022 22:32+3И вот мой вопрос, как поменять содержание сообщений так, чтобы они стали полезнее для самого человека и для окружающих.
Разбиваете задачу на подзадачи и перечисляете то, что сделали за день.
Программист 1: "Вчера я доделал уведомления для списка TODO, сегодня собираюсь сделать экспорт их списка в Excel. Были проблемы с тем, что сервис уведомлений брейкнули API"
Варианты реакции:
Программист 2: "Ой мне тоже надо сделать уведомления, кинь в меня примером"
Программист 3: "Я недавно поменял общую либу для экспорта, когда замерджу, скажу, чтобы ты сразу поюзал удобняшки"
Тестер: "Ага значит уведомления скоро передадут в тестирование"
Тим лид: "Что-то они часто брейкают, уже вторая жалоба, надо с ними выяснить этот вопрос"lxsmkv
10.10.2022 01:43В Вашем примере подразумевается, что результаты работы разработчиков взаимосвязаны.
Это работает, потому что спринт наполнен взаимосвязаными задачами, которые вместе добавляют новую функцию в приложение. Тогда работа может быть поделена например на фронт, апи и бекенд и естественным образом этим трем участникам нужно синхронизироваться.
То с чем доводилось сталкиваться мне, это когда в спринт берутся несколько функций плюс багов между собой не связаных, а просто выделеных по приоритету и уместившихся по сумме строипоинтов в емкость команды. Например: баг с подвисанием приложения, баг когда прогресс бар не отображается, возможность маркировки и комментирования данных в сводной таблице, функцию восстановления последнего открытого проекта после перезапуска приложения.
Т.е. достаточно разные области приложения, практически никак друг с другом не связаные.Может такой подход к планированию спринта уже есть ошибка?
amphasis
Ох, сколько же я помню user story, которые, в результате уговоров продакта, были взяты в спринт с несоблюдением пары пунктов DoR, и неизменно заканчивались sprint fail. Интересно, что каждый новый продакт упорно наступал на эти грабли, несмотря на предупреждения...
mclander
Грамотные продакты понимают, что при этом надо чем-то жертвовать. И вполне нормально относятся к сносу или упрощению менее горячих целей. Правда что-бы так работать, продакту обычно нужно пару лет непрекращающихся факапов и внезапно пришедшее понимание, что это не только из-за косоруких разрабов.
amphasis
Да тут даже не в жертвах дело. От того, что в одной команде все приоритеты перенаправят на конкретную юзер стори, пункты DoR для нее не начнут вдруг магическим образом выполняться. Не пропадут зависимости от других команд, если они были, не появится дизайн UX/UI если он еще не был проработан, и т. п.