Ситуация. Некоторые менеджеры, только узнавшие об Agility, с энтузиазмом набрасываются на концепцию скорости команды: ого, цифры, мы сможем их посчитать, контролировать, ставить планки, можем сравнивать команды и людей и т. д.
Последствия. Все уже перечислено выше. Скорость команды используется для давления на команду.
Бывает даже, что под контроль ставится индивидуальная скорость, что является полнейшей чепухой.
Скорость команды подразумевает всех участников, а не отдельных лиц.
Как сделать лучше? Поразмышлять, для чего необходимо измерение скорости команды и какие решения могут быть приняты на ее основе.
Ситуация. Команде кажется, что она слишком много времени тратит на оценку.
Последствия. У команды остается меньше времени на разработку, что обидно: ведь это важнее оценки.
Как сделать лучше? Поговорить об этом во время ретроспективы и предложить более простые способы оценки. Научиться разбивать работу на маленькие части (см. паттерн
Ситуация. В погоне за прозрачностью команда публикует подробный план, включающий мельчайшие истории предстоящих спринтов. Заинтересованные стороны теряются в этом плане: истории для них слишком детальные.
Последствия. В плане нет смысла.
Как сделать лучше? Заинтересованные стороны лучше разбираются в функциональностях, чем в историях. С ними стоит общаться именно на уровне функциональностей.
Чтобы идти дальше
Книги
‣ Майк Кон, «Agile. Оценка и планирование проектов», Альпина Паблишер, 2021
‣ Vasco Duarte, NoEstimates, How to measure project progress without estimating, Oiko Sofy, 2014
Во Франции совершенно точно существует такая тенденция: сначала выбор информационно-технических средств, затем уже определение и овладение методом. На этот счет мне вспоминается одна большая компания в области аэронавтики, где целые армии разработчиков тратили время на оснащение метода инструментами – а сам метод еще не был освоен.
В этом плане Agile-методы – все же за здравый смысл: сначала приобщение к ценностям и практикам, а затем уже выбор инструмента.
Некоторые могут пойти еще дальше и интерпретировать первую строку из Agile-манифеста –
Люди важны в первую очередь. Но очевидно, что для разработки пригодятся инструменты. Они необходимы, например, для непрерывной интеграции и тестирования.
Что касается Scrum-инструментов, все зависит от контекста. К примеру, если вся команда находится в одном рабочем пространстве, она не так сильно нуждается в электронном ведении бэклога, как команда, чьи участники разбросаны по разным континентам.
Самое интересное, что Agile-методы пересматривают понятие инструментов. Ведь речь не только об электронных инструментах. Информационно-технические средства – это одно решение, обладающее множеством функций. Но (и именно этому учит
Цель этой главы – познакомить вас с инструментами, которые могут стать эффективными помощниками для Scrum-команды. Мы поговорим о компьютерных приложениях, а также играх, досках и, конечно, Post-it®.
О том, что в компании применяется Scrum, зачастую можно судить по цветным стикерам на стенах.
До появления Post-it® мы использовали обычные блоки для записей, это было обычным делом на ранних этапах работы над пользовательскими историями. Рон Джеффрис в посвященной этому статье вывел формулу
Я использовал карточки для своих первых бэклогов. Это практично, их можно менять местами в зависимости от приоритетов, если ты Владелец продукта, и на обороте можно фиксировать основные моменты с собраний. Вот только ими сложно делиться с другими – разве что крепить на пробковую доску или приклеивать к стене.
Можно, например, использовать карточки с клейким краем, чтобы свободно их перемещать.
Когда в команде есть открытое рабочее пространство, да или просто стена – это наиболее эффективный инструмент для плодотворного общения между всеми участниками.
Их использование особенно рекомендуется для мониторинга спринта. Scrum-доска – это идеальное место для проведения ежедневных схваток.