Доклад - Практика внедрения Scrum: трудности и пути их преодоления

Подождите немного. Документ загружается.

итерации и т.д. Для обсуждения подобных проблем и задач есть ретроспектива. Команда

сама должна решить, что ей нужно предпринять, чтобы демонстрации были максимально

четкими и проходили гладко.

Ну и наконец, ситуация «делали-делали, а недоделали или вообще не то сделали». Чтобы

этого не было, обязательно следует придерживаться следующих правил:

• в Product Backlog-е для каждой задачи (item-а) должно быть краткое, но

содержательное описание «Как демонстрировать»;

• во время спринта каждый реализованный пункт Product Backlog-а в обязательном

порядке должен проходить фазу верификации (тестирования), на которой нужно не

забыть сопоставить то, что получилось, с тем, что описано в «Как

демонстрировать».

Правда и этого бывает недостаточно. Очень часто во время планирования по задаче

выясняются нюансы, дополнительные детали, формируется картина как это должно быть

сделано. Оценка трудоемкости дается именно исходя из этого, а когда дело доходит до

реализации, часть этого понимания и знания, как правило, уже забывается. Чтобы

справиться с этим, часть команд у нас рисует «vision» задачи во время планирования: на

листе A4, от руки, очень кратко и тезисно (просто, чтобы сработал ассоциативный ряд).

Этот «vision» просматривается перед тем, как непосредственно приступить к работе над

задачей (чтобы освежить в памяти результаты обсуждения этой задачи во время

планирования), а также используется на этапе QA, т.е. проверки.

Time-boxing

Во многом, эта ахиллесова пята всех Agile-методологий: трудно объяснить менеджменту

преимущества гибких методологий, если даже краткосрочные планы не выполняются.

При этом важно, чтобы команда сама искренне стремилась к максимально четкому

соблюдению жесткого time-boxing-а, так как Agile работу «из-под палки» не предполагает.

Части команд это присуще как-то само по себе, с такими командами в этом плане проблем

почти нет. Но есть и другая часть – проблемная.

Так что же делать, если у команды не хватает (само)мотивации на соблюдение жесткого

time-boxing-а, т.е. команда не борется за выполнение взятых на себя обязательств в

полном объеме?

Есть мнение, что такая ситуация, как правило, возникает в командах, в которых нет

сильного яркого лидера, т.е. своего рода «мотора». Но это достаточно тонкий и скользкий

вопрос. И даже если допустить, что это действительно всецело так, то всё равно такого

лидера найти ой как не просто, его адаптация к команде (и команды к нему) в любом

случае займет немало времени, а проблему соблюдения планов нужно решать здесь и

сейчас.

И здесь на выручку может придти следующий нехитрый совет: чем выше и активней

интерес к проекту «со стороны» (т.е. извне команды), тем выше (само)мотивация внутри

команды. Таким образом, очень важно, чтобы проектом интересовались, причем делали

это активно, открыто и доброжелательно:

• присутствие представителя заказчика на сессии планирования поможет точнее и

качественнее сформировать объем (scope) работ на итерацию;

• здорово, когда хотя бы на нескольких Scrum-митингах за итерацию присутствуют

Product Owner, руководитель проекта, может даже представитель HR-отдела –

команда чувствует, что ходом работ интересуются, т.е. многим вокруг важно, что и

(с) Заказные ИнформСистемы, 2008 год

как они делают (только помните, что эти «гости» не должны вмешиваться в ход

Scrum-митинга, а могут только молча наблюдать);

• крайне важно, чтобы на демонстрации были сторонние зрители, а иначе всё это

рискует выродиться в скучный показ для самих себя. Если удается обеспечить

присутствие представителей заказчика, то вообще здорово! Но даже и без этого

можно хорошо оживить демонстрацию, позвав коллег-экпертов из других команд,

главного архитектора, представителей руководящего звена.

Кстати, интересно отметить еще следующий момент, связанный с выполнением полного

объема работ: если команда полностью успевает сделать все запланированные задачи, то в

последние день-два возникает «простой» отдельных сотрудников (кто-то дожимает

оставшиеся задачи, а другим вроде как получается нечего делать). Это не очень здорово,

поэтому рекомендуется иметь на итерацию пару «бонусных» задачек, к которым можно

приступать, если остальные задачи уже все сделаны или вот-вот будут доделаны. Также

можно планировать с небольшим перебором объема работ (например, за счет небольшого

завышения Focus-factor-а) и считать, что если команда немного не успела, то это

абсолютно нормально.

Еще опытный факт: даже у самой хорошей и мотивированной команды примерно раз в 4-5

итераций случаются проблемы с выполнением полного объема работ. Как правило, это

связано с одним (или сразу несколькими) факторами:

• большое количество незапланированных срочных работ (либо всплеск поддержки,

либо какие-то особые обстоятельства у заказчика);

• серьезная недооценка целого ряда задач (новый вид работ, не учли серьезные

нюансы, освоение нового инструментария);

• технические трудности (серьезные баги в базовых библиотеках, падение сервера и

т.п.);

• эпидемия гриппа.

Трагедии из этого делать не надо. Это нормально. Главное, чтобы это не случалось

слишком часто.

Nokia-тест

В процессе работы по методологии Scrum, благодаря ретроспективам и гибкости,

заложенной в сам процесс, команда может достаточно далеко уйти от канонического

понимания Scrum-а. И здесь возникают неизбежные вопросы:

• каковы рамки адаптации процесса?

• каковы критерии, что это всё еще Scrum?

У нас уже возникали такие споры. И пока мы не нашли лучше ответа, нежели интервью с

одним из прародителей Scrum-а – Jeff-ом Sutherland-ом, которое он дал в 2006 году на

конференции QCon London 2006:

• http :// www . infoq . com / interviews / jeff - sutherland - scrum - rules

Согласно этому интервью в компании Nokia, активно практикующей Scrum, применяют

следующий «тест»:

1. У вас итеративный процесс разработки?

(Are you doing iterative development?)

2. У вас итерации фиксированы, т.е. начинаются в назначенное время и

заканчиваются в фиксированное время?

(с) Заказные ИнформСистемы, 2008 год

(Do you have fixed iterations? Do you have an iteration that starts at a specified time

and ends at a fixed time?)

3. Длина итерации не превышает 6 недель?

(And that iteration has got to be less than 6 weeks)

4. В конце итерации вы имеете работающее ПО?

(Well, at the end of the iteration, do you have working software?)

5. Вам нужна детальная спецификация для того, чтобы начать итерацию?

(Do you have to have a specification in complete detail before you can start the

iteration?)

6. Важно иметь работающее ПО в конце итерации: вы проводите тестирование во

время процесса разработки?

(It's important for working software at the end to have testing as part of the

increment: Do you have testing in the middle of the development?)

Если ответы на все вопросы кроме 5-ого – ДА, то команда применяет итеративный

процесс разработки в полном смысле этого слова. Но это еще не обязательно Scrum.

Касательно Scrum есть четыре дополнительных вопроса:

7. У вас есть Product Owner, т.е. есть кто-то, кто представляет заказчика и работает

вместе с вами?

(Do you have a product owner? Do you have someone that represents the customer

who is working with you?)

8. Если у вас есть Product Owner, ведет ли он Product Backlog, т.е. список «фич»,

которые нужно запрограммировать? Приоритезирован ли этот список по важности

для заказчика? Есть ли оценка трудоемкости по каждому пункту?

(If you have a product owner, do they have a product backlog, a list of features to be

developed? Is that backlog prioritized by business value, and is it estimated how long

it is going to take to build those pieces?)

9. Строите ли вы график сгорания работ (burndown chart) во время итерации, чтобы

видеть, сколько работы осталось, и успеваете ли вы к концу итерации?

(When the team is doing the development, do you have a burndown chart that shows

how much work is remaining in the iteration as you are moving forward, so you can

track your progress? And from that, can you tell the velocity of the team, how fast is

the team moving?)

10. Во время итерации команда работает по принципу самоорганизации, т.е.

менеджеры не вмешиваются в работу команды по ходу итерации?

(Nokia has a rule that you can't have a project manager interfering with the team in

the middle of an iteration because that stops the self organization and it guarantees

you are going to have a suboptimal path to a solution.)

Если и на эти четыре вопроса у вас ответ ДА, то согласно Jeff Sutherland-у и его Nokia-

тесту – у вас Scrum!

Перевод последующих команд на Scrum

Здесь наблюдается следующий феномен: целый ряд команд, где еще не внедрен Scrum,

сами активно жаждут перехода на него, но есть и команды, достаточно прохладно

относящиеся к идее перехода на Scrum. И здесь, как оказалось, важно вовремя помочь

первой группе команд (провести для них тренинг и активно консультировать во время

первых итераций), так как в противном случае они пытаются перейти на Scrum

(с) Заказные ИнформСистемы, 2008 год

самостоятельно, что и сложнее для них, и рождает своеобразный диалект Scrum-а (по

началу понимания не хватает).

Что же касается остальных команд, то тут главное не спешить и слишком не давить: очень

опасно, когда переход на Scrum навязан чисто сверху. Опыт показывает, что со временем

количество скептиков уменьшается – народ неизбежно замечает, как повышается уровень

проектной жизни и интерес к работе в соседних командах, перешедших на Scrum.

Заключение

В заключение хочется отметить, что когда всё это начиналось, было очень много скепсиса

на всех уровнях, но он оказался неоправдан (по большей части). Те сложности и

трудности, которые гипотетически виделись перед началом реального внедрения Scrum, в

жизни не встретились (за весьма редким исключением), а столкнуться пришлось с совсем

иным.

Так что лучше не критиковать Scrum, исходя из исключительно умозрительных

построений, а взять и попробовать его использовать!

(с) Заказные ИнформСистемы, 2008 год