Scrum. Революционный метод управления проектами

Открытость (Negotiable). История до своего завершения должна быть открыта для общего обсуждения; любой участник группы должен иметь возможность внести в нее свои поправки.

Ценность (Valuable). История должна приносить реальную пользу и увеличивать ценность проекта для заказчиков, пользователей и любых заинтересованных лиц.

Оценочность (Estimable). История должна быть удобна для оценки объема работы.

Лаконичность (Small). История должна быть краткой, компактно изложенной и конкретной, чтобы можно было просто и быстро планировать работы. Если история получилась слишком расплывчатой, перепишите ее, а лучше разбейте на мелкие функциональные фрагменты.

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

История Тима независима. Он мог выполнять свою операцию по обучению сил самообороны, не задумываясь о таких вещах, как, например, расход топлива вертолета, который доставлял его в лагерь. Его история открыта. Учитывая полевую практику, он мог добавлять ее или, напротив, сокращать в зависимости от того, как быстро усваивались знания его учениками. Его история имеет ценность. Она принесла реальную пользу, поскольку ученики узнали о строении человеческого тела, на­учились применять свои знания практически. Его история лаконичная. В ней кратко и емко изложены основы анатомии и физиологии. Сложной операции обучаемый не проведет, но первую помощь оказать сможет. Его история тестируема. Тим легко мог проверить по определенным критериям, как усвоен материал.

Любая пользовательская история, которую мы внедряем в практику, должна отвечать двум условиям: «готовность» — то есть соответствует ли она критериям INVEST; «выполненность» — то есть соответствует ли она тем критериям, по которым мы можем судить, что задача выполнена. При работе над реальными проектами мы видим, что если история действительно готова, команда удваивает скорость ее реализации. Когда в конце спринта история выполнена, команда в два раза увеличивает темпы работ в начале следующего спринта. Это один из ловких приемов Scrum, дающий возможность в два раза быстрее выполнить двойной объем работы.

ПЛАНИРОВАНИЕ СПРИНТА

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

Быстро решив все вопросы, команда дружно произносит: «Вперед!» — и приступает к работе.

УЗНАЙТЕ ДИНАМИКУ ПРОИЗВОДИТЕЛЬНОСТИ

Наконец мы готовы ответить на вопрос, когда будет выполнен наш проект. Мы измерили ускорение темпа, с которым группа двигается вперед. У нас написаны и собраны пользовательские истории, и потому мы знаем все задачи, которые должны быть выполнены. Мы уже успели оценить объем каждого задания. И мы готовы приступить к первому спринту. Длиной в неделю. В конце недели мы подсчитаем все завершенные нами истории и общее количество очков, на которое они были оценены. Это число покажет нам, насколько быстро движется группа и какова динамика производительности (для удобства сократим и в дальнейшем ограничимся одной «динамикой»). Выяснив текущую динамику, мы делаем последний шаг: подсчитываем оставшееся (несделанное) количество историй, оцениваем сложность каждой, опять складываем все очки и смотрим на получившееся число. Теперь мы ясно понимаем, когда сможем завершить проект.

Помимо этого, узнав свою динамику, вы можете определить самую важную в Scrum вещь: что мешает двигаться вперед еще быстрее? Что не дает наращивать темп? В прошлой главе мы поговорили о потерях и факторах, замедляющих ход работы. Теперь пора выяснить, как не допускать появления данных факторов и навсегда избавиться от самого понятия «потери».

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

— Вы уложитесь в заявленные сроки? — спросил старший вице-президент, хлопнув рукой по столу.

— Не знаю, — ответил я. — Но мы закончим до той даты, которую ваши люди назвали после пересмотра сроков. В противном случае я верну деньги.