Pull to refresh

Панацея ли Scrum — 2!

Project management *
Этот топик, есть продолжение вот этого топика: habrahabr.ru/blogs/pm/39308

Итак. Продолжим повествование на тему Скрама.

Перед тем, как описать саму методологию, чуть коснёмся классификации. Часто приходится слышать: у нас XP методология, а у нас Скрам, а у нас Agile девелопмент. Всё это имеет право на жизнь. Но, на мой взгляд, желательно правильно соотносить эти понятия.

XP — это набор принципов и подходов, меняющих традиционное отношение к разработке современного программного продукта.

Agile – это общее название группы гибких и достаточно успешных методик организации ведения проектов. Методик, которые, как правило, опираются на принципы XP и предполагают быструю итеративную разработку, тесное общение с заказчиком и, за счёт тесного общения членов команды, минимизацию создания дополнительных сущностей (артефактов/документов), которые традиционно создавались в процессе работы над проектом. Минимизацию всего того, что создаётся помимо самого программного кода.

Scrum – это одна из конкретных Agile-методик. То есть чёткий шаблон (каркас) организации управления проектом. Со своими терминами и понятиями. Если вы близко следуете именно этому шаблону, то можно сказать, что вы ведёте разработку по Скрам.

Я часто сталкиваюсь с другой классификацией, когда XP называют Agile методологией. Сложно сказать… На мой взгляд, XP — постулирует основополагающие прнципы. В один ряд с XP становятся другие концептуальные подходы к разработке: Водопад, Спираль, RUP… А Agile это уже конкретный набор методик, так или иначе описывающих технологические моменты управления проектом. Хотя… это уже терминологические нюансы. Но иметь в виду нужно — термины эти употребляются с разной степенью обобщения, что порой способно вызвать некоторую словесную путаницу.

А сейчас непосредственно о Scrum.

Для начала организации проекта по Скраму, в команду вводится две важные персоны. Это Product Owner и Scrum Master.

Product Owner – человек, который чётко знает, что в конечном итоге нужно заказчику от программного продукта. В идеале, это представитель заказчика. Причём не той части заказчика, которая платит деньги, а той, которая будет непосредственно этим продуктом пользоваться. В реале достичь этого не всегда возможно, поэтому данную роль может выполнять сотрудник компании, который отвечает за контакт с заказчиком. Звонит, ездит, говорит по скайпу и уточняет, выясняет, выдавливает…

В любом случае – именно и только от этого человека исходят все пожелания (требования) к будущему программному продукту. Его слово тут основополагающее и по сути единственное. Это закон.

Scrum Master – очень особенный человек. В его задачу входит сделать так, что бы разработке постоянно сопутствовал дух вовлечённости/участия всех членов команды, и при этом не были упущены важные детали, которые должны быть прояснены на скрам-митингах. Скрам миттинг является главным местом где принимаются решения по организации проекта.

И что важно – этот человек не является формальным начальником для команды. Но именно он должен правильно организовать обсуждение деталей проекта, “навязав” встречам соответствующий дух, что бы они НЕ проходили в виде – а теперь пусть отчитается начальник транспортного цеха! Но вся информация должна быть донесена и цели выполнены. Я бы сказал, что этого человека можно назвать тамадой проекта. :-) Очень непростая роль.

А вот теперь, перейдём к тому, как строится непосредственно сам процесс разработки. А точнее процесс управления.

Как мы помним, в XP, на принципы которого и опирается Скрам, разработка должна строится таким образом, что бы идти к цели итеративными витками, на каждом из которых проект приобретает всё более и более законченный вид, и уже с первого витка начинает дышать. Пусть и виде одной только заставки.

В Скраме, такой единичный временнОй забег (итерация) называется спринт (Sprint). В последний день (и час) каждого спринта мы должны иметь работающую версию проекта, в которой уже есть на что глянуть. С каждым новым спринтом, мы имеем всё более и более обрастающий мясом (функциональностью) проект. И так, спринт за спринтом, забег за забегом, на выходе получаем готовое изделие. Учитывая, что после каждого забега проект как-то уже работает и, стало быть, мы имеем что показать, то тем самым мы имеем и возможность оперативно получить обратную связь от будущих пользователей и, соответственно, оперативно учесть их замечания. Чуть точнее подстроив будущее изделие под нужды заказчика. Причём эта обратная связь опирается не на представления будущего пользователя о том, как это будет выглядеть в конце, а на том, что он уже смог посмотреть. Что крайне важно в любом проекте. Поскольку увы, представления разных людей могут отличаться очень и очень сильно.

Тут очевиден вопрос – а какой должна быть длительность спринта? Хороший вопрос. Чем меньше – тем лучше. Но – вы должны иметь работающий проект (с новой функциональностью!) после каждого спринта. Подобрать длительность спринта это опыт и искусство. Но, Скрам говорит – эта длительность должна быть не более нескольких недель. Иначе это уже будет не XP, а водопад. :-) Одна, две, три, в крайнем случае — четыре недели. Больший интервал расслабляет заказчика. Маленький интервал? Так вы сделать ничего заметного не успеете. Или не сможете собрать. Такие вот грустные дела.

А теперь — перейдём к механике процесса. Попутно, введём ещё несколько новых понятий.
Начинается всё с создания Product Backlog. Я намеренно вначале употребляю англоязычные термины, что бы не запутать читателей, читающих тексты о скрам в английском варианте. По ходу, ненавязчиво, использую разумный перевод на русский.

Итак, Product Backlog – это полный список пожеланий (stories) заказчика, который формирует и ведёт Product Owner (менеджер продукта). Линейный список. Дополняется постоянно. Он может быть создан в excel. Там сконцентрировано всё то, что заказчик хочет видеть в конечном продукте. И все замечания, которые он вносит по ходу работы. А-абсолютно все. Дабы ничего не забыть. Верно, иногда это напоминает: 1. Ремонт сарая (приоритет — 20). 2. Построение коммунизма (приоритет — 6). Но вот так. Скрам не настаивает на том, что бы список был иерархическим, учитывал зависимость пунктов… и так далее. Нет. Не спрашивайте меня почему, но нет! Хотя, по уму. Может быть и да.

Канонически, каждый пункт, должен состоять из нескольких колонок: Номер, Название, ПРИОРИТЕТ, приблизительная оценка срока выполнения, пояснения к пункту и столбец — КАК ПРОДЕМОНСТРИРОВАТЬ РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ. Как вы поняли – приоритет выставляет менеджер продукта. Остальное решает команда.

И теперь – движение.

В начале каждого спринта, собирается собрание. Там вся команда (с продуктовым манагером и скрам-мастером внутри). Грубо и привычно говоря – митинг. Производственное совещание. Долгий такой митинг. Часа на три. И на нём решается, какие пункты (stories) попадут в реализацию на текущий забег. И формируется второй список – Sprint backlog. То, что попадёт в реализацию на текущий забег из Product backlog. Понятно, что это подмножество Product backlog. Но этого мало. Главное – фиксируется цель забега. Что и как мы сможем показать представителю заказчика на финише данного спринта. И, что самое интересное, делается оценка сроков разработки. Публично и весело. Давая понять манагеру продуктов, что действИтельно удастся сделать на данном забеге. А что, действительно не удастся. А дальше?

А дальше — хлопок стартового пистолета и забег. Как вы поняли, это спринтерский забег, а не стайерский. И уж тем более не марафонский. В легкоатлетическом марафоне всё просто – там хотя-бы понятно куда бежать. В разработке софта, траектория забега будет постоянно корректироваться. И даже конечная точка может поменяться.

А что бы всем было понятно, что мы ещё бежим, и, что важно, бежим вместе и в нужном направлении, каждый день проводятся небольшие митинги. Под чутким руководством Скрам мастера. Живые такие производственные совещания на полчаса, где каждый с энтузиазмом рассказывает сколько он пробежал и где споткнулся. Они, как раз, и называются схватками. Что в переводе на английский означает Scrum. Как мужики в регби, в борьбе за мячик. Или, как мужики в американском футболе. В борьбе за тот же мячик. Что, порой, более впечатлительно, хотя и туповато. И не важно, что человек делает в проекте. Локоть товарища он должен чувствовать всегда! В идеале, все локти всех товарищей. Эти схватки лучше утром проводить. Это не сборище уставших в конце дня людей. Это ведь тусовка энергичных спринтеров, остановившихся на двадцатом метре полосы, что бы хлебнуть добротного кофе в хорошей компании.

В конце дистанции каждого спринта– показ. Показ результатов спринта. Всегда. В идеале — прямо заказчику. Ну какой смысл показывать самим себе то, что уже сто раз видели в забеге? Нет. Именно показ кому-то. Ну, на крайняк, руководителю компании. Или начальнику отдела кадров. И обсуждение личных достижений.

А дальше? А всё!

Рывок – результат! Рывок – результат! Осязаемый результат. Осязаемый для тех кто смотрит, а не для самих разработчиков.

Что имеем в сухом остатке? А вот:
1. Формируем Product Backlog
2. Оцениваем сложность проекта и длительность спринта
3. Компонуем Sprint Backlog на забег.
4. Непосредсно забег! (с обсуждениями каждый день)
5. Показ!
6. Дополняем Product Backlog.
7. Компонуем Sprint Backlog на забег.
8. Непосредсно забег! (с обсуждениями каждый день)
9. Показ!
10. Дополняем Product Backlog.
11. Компонуем Sprint Backlog на забег.
12. Непосредсно забег! (с обсуждениями каждый день)
13. Показ!
14. Дополняем Product Backlog.
15. …
16. …
17.… Ну вы поняли…
18. Получаем производственную премию за успешно сделанный проект.
19. Отлёт в отпуск (или поиск нового места работы).

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

Методология Скрам предлагает разные техники для успешного результата. Это и приятное помещение для миттингов. Большое. Светлое. С мягкими креслами. И с комнатными растениями. Это и использование большого количество бумаги для стикеров, что бы визуально показать на доске, как и куда мы двигаемся. Предварительно разлинеев доску на лево и право. На менее важное и более важное. Это и тонкие психологические методики оценки времени (planning poker). Команда должна работать крайне напряжённо, но с комфортом и поддержкой друг-друга.

И ещё, Скрам очень аккуратно и внятно настаивает на использовании концептуальных принципов XP. Особенно на test-driving development. Невозможно вести интесивную разработку и не писать тестов. Да, это трата времяи В первый раз. Затем – экономия времени. Особенно после рефакторинга. Это очень важный принцип. Не стоит его недооценивать!

Думаете закончилось пиво? Нифига! Просто решил пока закончить.

Теперь, в русле тактичных и умных комментариев, будем смотреть как бы это правильнеЕй поднять критическую часть обсуждения в третьей части эпопеи. :-)

Если ей конечно суждено будет быть.
Tags: scrumeXtreme programming
Hubs: Project management
Total votes 69: ↑63 and ↓6 +57
Comments 25
Comments Comments 25

Popular right now