Читаем Скрам полностью

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

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

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

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

Перед вторым днем запуска команды я плохо спал: переживал, что следующий день станет катастрофой, а тренинг в целом может провалиться. Наконец я решил, что у меня достаточно информации для формирования гипотетического проекта. Мне сказали, что видение проекта заключается в поддержании национальной безопасности посредством слияния и анализа данных. Каждый гражданин США был знаком с критикой в адрес правительства относительно сбора и использования разведданных перед 11 сентября. Я знал, что одни участники команды являлись ведущими экспертами страны по данным, другие – отвечающими за разработку алгоритмов математиками, а третьи – специалистами по поиску в интернете. Понимая, однако, что могу ошибаться в деталях, я ощущал уверенность, что смогу создать адекватный гипотетический бэклог продукта, чтобы помочь команде разработки объединиться.

Следующее утро я начал с рассмотрения концепций бэклога продукта и сашими[14], а затем представил команде гипотетический бэклог продукта, составленный мной прошлой ночью. Я попросил команду разработки в ходе следующих двух часов выбрать задачи для первого спринта и рассказать мне, из каких элементов состоит бэклог, который они превратят в полноценный, демонстрируемый и готовый к поставке инкремент продукта. Другими словами, что они могли бы сделать за один спринт? Я надеялся, что мой гипотетический бэклог продукта окажется достаточно близким к их реальному проекту.

Бэклог продукта состоял из одного функционального требования и ряда поддерживающих его нефункциональных требований. В частности, продукт должен был выполнять следующие функции:

■ выявить людей, которые посещали летную школу в течение последних трех месяцев и соответствуют профилю кандидата к совершению террористического акта против Соединенных Штатов;

■ отображать информацию графически, чтобы облегчить операции объединения и детализации, сворачивания и развертывания данных;

■ объединить информацию из нескольких источников на основании запроса или введенных критериев;

■ декомпозировать результаты запроса;

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

Объединяя требования для демонстрации только одной функциональности в конце спринта, скрам приучает команду разработки концентрировать свое внимание на самом важном. Я сказал участникам, что в рамках этого учебного задания являюсь их владельцем продукта и готов ответить на любые вопросы об элементах бэклога и проекте.

Перейти на страницу:

Похожие книги

Охота за идеями. Как оторваться от конкурентов, нарушая все правила
Охота за идеями. Как оторваться от конкурентов, нарушая все правила

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

Роберт Саттон

Деловая литература