Книги

Постигая Agile

22
18
20
22
24
26
28
30
Ключевые моменты

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

Чтобы «осознать» Scrum, члены команды должны выйти за рамки простого внедрения практик и четко осознать, что означают самоорганизация и коллективная ответственность.

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

Чтобы стать успешными scrum-командами, необходимо глубоко усвоить scrum-ценности: приверженность, уважение, сосредоточенность, открытость и мужество.

Описание: команда, разрабатывающая приложение для мобильного телефона в небольшой компании

Роджер – руководитель команды, пытающийся использовать Agile

Ави – владелец продукта

Эрик – scrum-мастер в другой команде

Акт II. Обновления статуса – это только для социальных сетей!

Вернемся к команде Lolleaderz.com. Роджеру и Ави требовалась помощь. Они знали, что в Hover Puppy существует еще одна команда, имеющая большой опыт работы со Scrum. Роджер попытался поговорить с представителями этой команды, чтобы разобраться в непонятных вещах, но запутался еще больше. Казалось, у них все точно так же, как и в его команде: спринты, ежедневные scrum-совещания, ретроспективы, бэклог, владелец продукта и scrum-мастер. На первый взгляд, обе команды делали одно и то же, но в одной получались отличные результаты, а другая медленно чахла. Роджер и Ави встретились с Эриком – scrum-мастером другой команды. Он достиг больших успехов в Scrum и был рад помочь товарищам найти причину их неудач.

Первым делом Эрик спросил: «Есть ли у вас коуч?» Роджер не сразу его понял. «Это наставник, – объяснил Эрик. – Человек, помогающий правильно внедрять Scrum. Лучшего способа не существует. Если бы не он, моя команда ничего бы не добилась». И здесь Роджер впервые смог оценить Ави как продавца, потому что к концу дискуссии тот убедил Эрика стать коучем в команде Lolleaderz.com.

В следующий понедельник во время scrum-митинга Роджер и Ави хотели представить Эрика команде. Но Эрик попросил, чтобы все шло как обычно – а он будет наблюдать за командой, а затем попытается придумать и сделать ей несколько небольших предложений. Хорошо, что он так сказал, потому что только половина команды успела к началу совещания – все знали, что ведущий разработчик всегда выступал первым и подробно рассказывал об обновлениях, – остальная же часть команды подошла в середине его доклада.

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

На следующий день Эрик наблюдал за другим scrum-митингом, который проходил по тому же сценарию. Он заметил, что один из членов команды сообщил о выполнении задания на 95 %, и вспомнил, что этот сотрудник ранее уже называл ту же цифру. Эрик сказал об этом Роджеру. «Да, похоже, он опаздывает. Не волнуйся, я контролирую ситуацию и уже обновил задание. Он постоянно затягивает сроки, поэтому я заранее учел непредвиденные обстоятельства. Если он чересчур забуксует, то я уверен, что об этом узнают Ави и генеральный директор».

В тот же день Эрик встретился с Роджером и Ави. Он начал с главного. «Роджер, ты используешь scrum-митинги для управления своим планом проекта. Что происходит, если член команды запаздывает? Ты обновляешь свой график, и получается, что работа сделана, не так ли? За исключением того, что само по себе обновление диаграммы Ганта не уменьшает сдвиг окончания проекта на более поздний срок».

Роджеру неприятно было это услышать. Ави тоже, потому что он использовал этот график для корректировки деятельности остальных участников проекта. Эрик продолжал объяснять Роджеру, что тот использует ежедневные совещания для получения информации о задачах, выполненных командой. Ситуация накалялась. «Конечно, я использую их для получения обновлений! Ведь так и должно быть!» Роджер начал жалеть, что привлек Эрика в качестве коуча.

Вы можете объяснить, почему у Эрика возникли проблемы с Роджером и Ави, которые на ежедневных scrum-митингах получали обновленные статусы команды или вносили изменения в расписание? Если ежедневные митинги нужны не для этого, то для чего же?

Вся команда принимает участие в scrum-митингах

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

Обратная связь и цикл «обзор-контроль-адаптация»

Многие новички в Agile привыкли считать, что мир вращается вокруг программирования. Эти разработчики проходят в офис, чтобы сделать то, для чего их наняли, и, выполнив задание, уходят домой. Это очень удобно, потому что дает возможность сосредоточиться в основном на решении технических проблем.

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