Home

Автор: Вячеслав Дукальский

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

По мере усложнения проекта, конечно же, усложняется и его управление. Хорошо, если задачи всем понятны, или же есть уже опыт выполнения подобных проектов. В этом случае применение определенных (теоретических) моделей разработки может оказаться успешным. Но что делать, если задача слишком сложна и не до конца всеми понята? Очень часто центральное планирование в этих случаях начинает давать сбои, либо вообще приходит в негодность. К примеру, вы едете на автомобиле, и начальство дало вам карту с указанием маршрута и указав время прибытия на каждом перекрестке. Вы выдерживаете график, но вдруг перед вами произошло ДТП и образовалась большая пробка. Вы, не можете объехать этот участок по другому маршруту, потому, что у вас есть карта и маршрут, по которому вам предписали следовать. Вы, возможно, позвоните начальству с просьбой составить новый маршрут и вам его составят, утвердят и вышлют. Но это может занять много времени и возможно, пробка к этому времени уже рассосется и вам будет удобней следовать по старому маршруту. Маршрут, который вам предоставили, был верный, но не учел непредвиденные обстоятельства — большая пробка в результате ДТП. Бывают случаи, когда и маршрут сам по себе неправильный, например, вам нужно свернуть, но дорожный знак запрещает вам это сделать. Вам снова необходимо звонить начальству и утверждать новый маршрут. Гораздо более эффективно было бы предоставить вам большую свободу и право самому выбирать наиболее удобный и быстрый маршрут, указав только конечную точку. Важно также предоставляя свободу, очерчивать границы этой свободы, поскольку есть опасность скатиться к анархии и сделать проект неуправляемым. Решить все эти проблемы вам поможет Scrum.

Что такое Scrum?

В основе лежат короткие ежедневные встречи — Scrum и циклические 30-дневные встречи, называемые Sprint. Во время ежедневного Scrum'a каждому члену команды задаются только 3 вопроса:

• Что было сделано с последнего Scrum'a?
• Что вы будете делать между этой и следующий встречей Scrum?
• Что мешает вам выполнять работу?

Главные принципы Scrum

• Индивидуализм и взаимодействие важнее строгих процессов и методов
• Работающее ПО важнее сложной документации
• Взаимодействие с заказчиками важнее контрактных договоренностей
• Готовность изменить важнее следованию плану

Scrum, как и другие способы быстрой разработки ПО лежит вне того представления, что главной задачей является делать все возможное для следования плану. Scrum — это искусство возможного.

Девизом Scrum'a можно считать следование здравому смыслу. Качество ПО не определяется лишь простым соответствием ТЗ. В моей практике был случай, когда GUI команда по каким-то своим причинам поместила один дополнительный чекбокс, которого не было в изначальных требованиях к ПО. Этот чекбокс должен был выполнять определенную абсолютно простую, прозрачную и понятную из подписи к нему функцию, взаимодейтствуя со службой Windows. Он, однако, никакой функции не выполнял и являлся просто заглушкой. Я как QE создал кейс по этому поводу, но команда разработчиков службы заявила, что это не баг, потому что у них не было подобных требований. Багом, по их мнению, являлось наличие этого чекбокса на GUI. В результате, после долгой переписки, эта функциональность все-таки была добавлена.

Построение команды

Команда, которая будет участвовать в ежедневных Scrum'ах должна состоять из 7 плюс-минус 2 человека. Большее число не рекомендуется, лучше разделить на несколько команд. Scrum Master (или, более понятно – Project manager) ведет эту встречу. Члены команды называются «свиньями» и только они имеют право говорить. На встречах могут присутствовать молчаливые посетители — «курицы», которые такого права лишены. Scrum встречи должны быть короткими, опоздания не приветствуются. Кен Швабер (Ken Schwaber, автор книги «Agile Project Management with Scrum») на своих тренингах предлагал вводить практику наказания «рублем», когда каждый опоздавший платит по доллару или евро, собранные деньги впоследствии он отдавал бездомным на улице.

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

Scrum Master и управление проектом

Поскольку в основе Scrum'a лежат ежедневные встречи и 30-дневные циклические встречи, называемые Sprint, все возникающие организационные и технические проблемы всем хорошо видны.

SCRUM — структура

В конце каждого Sprint'a команда должна демонстрировать заказчику готовый запускаемый файл. Требования на функциональность должны были быть определены в начале этого Sprint'a месяц назад и не должны были меняться в течение этого времени. Эти требования отображаются в бэклоге — отдельной таблице с указанием того, что нужно сделать и сколько этой займет времени.

Успех Scrum'a зависит во многом до деятельности Scrum Master'a. В числе его главных задач и особенностей деятельности:

• Удалять барьеры между заказчиком и разработчиками, так чтобы заказчик напрямую управлял разработкой
• Доверять своей команде, делать все возможное чтобы раскрыть креативность каждого ее члена
• Увеличивать продуктивность команды любыми возможными способами
• Мертвый Scrum Master — бесполезный Scrum Master
• Плохой опыт будет заметен сразу, хороший — незаметен
• Разрешение конфликтов

Ссылки

• http://www.controlchaos.com
• http://www.agilealliance.org
  Ken Shwaber. Agile Project Management with Scrum. Microsoft, 2004
• Книга: Agile Software Development with SCRUM (Ken Schwaber, Mike Beedle)