Как владельцы продукта, scrum-мастера и члены команды могут лучше играть роль «свиней»

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

К сожалению, многие компании ожидают от членов команды действий, характерных для «кур», а не для «свиней». Программисты нередко обнаруживают, что их попытки принять участие в планировании заканчиваются ничем, потому что планирование и принятие решений – это привилегия менеджеров. («Уж не возомнил ли ты себя менеджером? Отправляйся на свое рабочее место, жалкий программист!») Если такое видение характерно для команды, то ей трудно эффективно применять Scrum.

Scrum-мастеру непросто поощрять команду «кур» в их стремлении стать владельцами или «хранителями» плана. Командно-административному менеджеру, стремящемуся стать scrum-мастером, трудно ломать стереотипы. Это не помогает успешным менеджерам проектов, привыкшим единолично разрабатывать план. А высшему руководству гораздо удобнее, когда за все отвечает один человек. (Некоторые любят рассуждать о нем как о «единственном, кому должны свернуть шею».) Он чувствует свою значимость, потому что создал порядок из хаоса.

Планирование необходимо. Но им нужно заниматься вместе с командой. Когда scrum-мастер разбивает работу на спринты, самостоятельно получает оценки у команды, распределяет между ее членами задачи и проверяет их выполнение, он ведет себя как «хранитель» плана. И одновременно поощряет «кур» вместо «свиней».

Scrum-мастеру приходится устранять одно из основных препятствий на пути внедрения Scrum в команде – менталитет «курицы». Часто команда голосует за командно-административного менеджера проекта, потому что он берет на себя всю ответственность. Но гораздо важнее сделать проект быстро и хорошо, потому что команды разработчиков, применяющие близорукий подход, создают плохо спроектированные системы. Когда команда выбирает кратчайший путь и срезает углы, она может получить продукт, который на первый взгляд выглядит работоспособным, но на самом деле очень хрупок и труден для поддержания.

Рис. 4.3. Когда командно-административный менеджер проекта выступает в качестве «хранителя» плана, он вынуждает команду быть «курицами»

Scrum-мастер может стимулировать членов команды стать «свиньями» в рассмотрении оценок как еще не раскрытых фактов, а не обязательств, выбитых из команды. Оценка длительности выполнения задачи – это уже факт, потому что команда будет тратить совершенно конкретное время на выполнение работы. Точные расчеты – это реальная попытка спрогнозировать будущее, а не многообещающие предположения, которые используют, чтобы успокоить менеджера или поскорее закончить совещание.

Хороший план – это как история, которая еще не написана. В конце спринта команда сможет оглянуться назад и точно указать, что именно сделано и сколько времени потрачено на каждую задачу.

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

Это настоящее изменение в мышлении многих команд. Члены команды, использующие разработку плана как способ постановки оптимистических целей, часто не могут их достичь. А ведь одного чрезмерно оптимистичного члена или менеджера команды достаточно, чтобы разрушить планы каждого (в том числе и на следующие четыре выходных), даже если он думает, что таким образом помогает. Но если команда рассматривает план как наиболее реалистичный вариант спрогнозировать события в течение ближайших 30 дней, то у них гораздо меньше шансов «взвалить на себя больше, чем могут унести», есть возможность достичь цели вовремя, не срезая углов и не создавая хрупкий код.

Для многих менеджеров проекта это совершенно новый способ планирования. Традиционные руководители проектов воспринимают план как способ мотивировать команду и фиксировать сроки выполнения работ. Они убеждены, что план заставляет команду работать, а без него сотрудники будут бездельничать. Менеджер проекта, требующий от команды чересчур оптимистичных оценок объема работ и «утверждающий» их в начале спринта, будет чувствовать себя комфортно, используя этот план для дальнейшего третирования команды. Вот почему такое отношение к «плану работ, рабочему плану» может привести к разладу между руководителем проекта и командой.

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

Члены команды чувствуют себя полностью вовлеченными в проект, когда участвуют в распределении задач во время планирования спринта, а не в ходе выполнения задания. Если сотрудники действительно испытывают чувство ответственности, то в начале спринта нет необходимости распределять задания между ними. В эффективных scrum-командах персонал сам распределяет задачи на основании имеющихся навыков и опыта. Это один из ключей к пониманию того, как работают самоорганизующиеся команды.

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

В успешных scrum-командах сотрудники не ограничиваются простым выполнением задач. Каждый из них – настоящий энтузиаст своего дела и старается поставлять пользователям и стейкхолдерам наиболее ценное программное обеспечение. Когда все члены команды разделяют это чувство и обязуются поставлять работающее ПО в конце каждого спринта, мы говорим о

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Как владельцы продукта, scrum-мастера и члены команды могут лучше играть роль «свиней»:

  1. Рис. 16. 13-дневный экспоненциальный показатель среднего движения курса Когда ЕМА растёт, это значит, что тренд идёт вверх и на рынке нужно играть на повышение. Покупать лучше тогда, когда цены возвращаются к ЕМА, а не тогда, когда они высоко над ним, потому что у вас будет лучше соотношение между прибылью и риском. Когда ЕМА падает, это говорит о нисходящем тренде и о том, что играть нужно на понижение. Продавать лучше тогда, когда цены поднимаются назад к ЕМА. Когда ЕМА идёт ровно, как в декаб
  2. Другие члены команды
  3. Члены группы могут ухватить несколько трендов, но они погибают, когда рынок меняется на противоположный. Когда вы присоединяетесь к группе, вы действуете как ребёнок, следующий за родителями. Рынок не заботится о вашем благополучии. Успешные игроки – всегда независимые мыслители. Зачем присоединяться к толпе?
  4. Рис. 22. Сигналы системы направлений Линии направления определяют тренд. Когда +DI сверху, стоит играть на повышение. Когда сверху – DI, лучше играть на понижение. Лучшее время для использования указателей тренда наступает тогда, когда ADX поднимается и проходит выше нижней линии направления. Это два признака динамичного тренда
  5. Джефф Сазерленд. Scrum. Революционный метод управления проектами, 2015
  6. Инструментальная роль распределения в соответствии с произведенным продуктом
  7. Роль финансов и разработки новых продуктов
  8. Как я начал играть на бирже
  9. Как я начал играть на бирже
  10. 8. Все дело в том, КАК играть
  11. 8. ВСЁ ДЕЛО В ТОМ КАК ИГРАТЬ
  12. Анархономика бросает вызов и подтачивает сегодняшнюю бизнес-модель Мы увидим, как вместо этого возникнут новые бизнес-модели Компании могут стать конкурентоспособными, используя открытые исходники и т. п. Вы можете раздавать продукт, зарабатывая на обслуживании, рекламе и т. д. Freemium — часто используемая IT-компаниями бизнес-модель Нам нужен тщательный пересмотр экономического мышления, который бы включал и анархономику
  13. Ваша команда как целое