Майк Кон — важная фигура в мире Agile и Scrum. Он занимается консалтингом топ-фирм, среди его кейсов можно найти компании из списка Fortune 40. Одна из его книг — «Agile: оценка и планирование проектов».
За Agile закрепился миф — в этой методологии нет места планированию. Такого мнения придерживались даже представители, казалось бы, передовых компаний.
За отсутствие планирования принимается то, что оценка работ ведётся в каждой итерации, а не один раз — в начале работы над проектом.
Майк Кон говорит, что оценка и планирование — это те темы в сфере Agile, по которым ему задают больше всего вопросов. Свою позицию и принципы, которые легли в основу agile-трансформации многих крупных компаний, автор отражает в книге. А мы сделаем её небольшое саммари.
Под планированием понимается ответ на вопрос «Что необходимо сделать и какому сроку?» В него входит ещё три подвопроса:
- Насколько это объёмно?
- Как это должно быть сделано?
- Сколько работы будет сделано к определённому моменту?
Оценка и планирование критически важны. Без планов не будет правильных инвестиционных решений, подобранных специалистов, нужных функций, но в замен всплывёт множество проблем.
Процесс планирования сложен. При его проведении команды часто впадают в крайности. Кто-то полностью отказывается от планирования, кто-то планирует чересчур глубоко. Всё это неправильно.
Планирование — это поиск стоимости. Через него мы принимаем оптимальное решение для разработки продукта. Этот вопрос нельзя решить за один день, поэтому Майк предлагает подходить к планированию итерациями. Шаг за шагом команда понимает, что делать дальше. Такой процесс планирования сокращает риски, снижает неопределенность, делает решение более качественным и способствует распространению информации.
Хороший план — тот план, на основе которого можно принимать взвешенные решения. На начальном этапе план более размыт, имеет только основные вехи. На более позднем этапе план уже более точный. Но даже размытый план нужен продукту. Он помогает другим сотрудникам примерно ориентироваться в разработке, на базе него они будут принимать решения. Например. отдел маркетинга сможет запланировать рекламные материалы и крупные pr-кампании.
Agile-подход предполагает реализацию не планов, а планирования. План — это бумага, а планирование — это процесс.
Процесс планирования важнее плана.
Например, новые обстоятельства могут влиять на планы. В динамический процесс легче внести изменения и оценить их. В Agile-подходе мы признаём, что не сможем учесть все аспекты продукта с самого начала. В процессе разработки у нас будет немало раундов планирования. Мы будем внедрять изменения по мере их надобности.
Плохое планирование
Вторая глава книги посвящена тому, когда планирование даёт плохие результаты. Традиционные подходы к планированию нередко подводят. Смета часто бывает урезанной, а времени не хватает, придуманные заранее функции оказываются невостребованными, а фактический срок выполнения значительно превышает предполагаемый... В традиционном планировании есть проблема: оно сфокусировано на деятельности, а не на поставке функции.
Первая проблема — деятельность, а не стоимость.
Продавать можно функцию, но не проделанную работу. Вторая проблема — поиск видов деятельности, а не недостающих функции. Планирование по видам деятельности не может обеспечить независимый отрезок работы.
Нельзя забывать закон Паркинсона: работа растягивается так, чтобы занять все отведённое на неё время. При календарном подходе никому не удаётся закончить работу раньше.
Ещё одна проблема — многозадачность, когда одновременно выполняются несколько вещей. Многозадачность сильно влияет на производительность, и не в лучшую сторону. Если приходится заниматься одновременно двумя вещами, то страдают две из них. Это лишь иллюзия скорости.
Другая важная причина — запланированные работы не имеют приоритета. Традиционные планы составляются с уверенностью, что всё из них будет сделано. Команда создаёт функции беспорядочно. В конце приходится сокращать набор функций, и не факт, что в списке сокращений окажутся только неважные фичи.
В традиционном подходе к планированию также игнорируется неопределённость. Первоначальный анализ требований воспринимается как установленный навсегда. Не учитывается то, что ситуация поменяется, пользователи передумают, компания сменит цели, разбегутся работники, случится коллапс и прочее.
Планирование в Agile
При планировании agile-команды разделяют оценку размера и оценку сроков. Сроки обозначаются после оценивания размера проекта.
Функции могут представляться в виде пользовательских историй. И пользовательские истории, и другие виды задач оцениваются в относительных единицах измерения — в пунктах или очках историй. Например, мы оцениваем историю в два пункта. Значит, она в два раза больше, чем история в один пункт. И она же в два раза меньше истории в четыре пункта. Размер истории определяется практически интуитивно. Это что-то вроде сочетания трудоёмкости, сложности, риска, уровня мастерства команды и других факторов.
Существует два похода подхода к оценке размера:
- выбор наименьшей истории, которая станет историей в 1 пункт,
- выбор эталонной средней истории, относительно которой нужно отмерять другие.
Оценка дается всем историям, которые составлены для проекта. В этом процессе участвуют даже те истории, что пока нечётко сформулированы. Эти примерные оценки всё равно дадут возможность ориентироваться.
То, насколько быстро команда выполняет пункты историй, показывает её скорость. В конце каждой итерации нужно отслеживать скорость команды. Показатели скорости помогают учитывать ошибки планирования. Эта метрика позволяет оценить объём работ еще на этапе планирования спринта.
Относительные оценки (очки и пункты) используются для того, чтобы отделить оценку трудозатрат от скорости. У каждой команды своя скорость. Сроки проекта определяется скоростью команды, а не оценками задач.
Майк говорит, что когда мы работаем итерациями, мы справляемся с неопределённостью. В классическом подходе оценка — это обязательство. Заказчик требует продукт к опредёленной дате. Но команда не может дать оценку и тем самым принять такое обязательство, потому что она не может учесть все факторы и риски на первой встрече.
Для хорошей работы команда должна понимать, что оценки — это не обязательства, и предположения будут уточняться.Разработка ведётся с учетом agile-манифеста, поэтому команда готова к изменениям изначально. Agile-планирование предполагает постоянный сбор новых данных о проекте. Они воспринимаются как поток возможностей.
Майк Кон выделяет несколько принципов планирования:
- Многоуровневость — планирование делится на уровень дня, итерации, релиза, продукта, портфеля продуктов и всей стратегии.
- Вместо четких критериев в начале работы над проектом определяются критерии удовлетворённости клиента. Это не только основные цели, но и дополнительные пункты, например, соответствие календарному графику, бюджету, должному качеству. Эти условия могут дополняться по ходу итераций.
В agile-планировании также есть термин идеальное время. Есть общее затраченное время, а есть чистое время, которое отводилось на выполнение задач. Предсказать что-то в идеальном времени гораздо легче, но оно редко совпадает затраченным. Кроме работы над пользовательскими историями, каждый в команде тратит своё время поддержку текущей функциональности, совещания, работу с персоналом, общение, обучение, деловую переписку, переключение на задачи и множество другой деятельности, которую нельзя изъять из обычного рабочего дня.
Несмотря на то, что пользовательские истории могут оцениваются в идеальных часах и днях, нужно понимать, что фактическая работа будет идти дольше. Но можно стремиться к тому, чтобы команда меньше отвлекалась и более продуктивно работала.
Как давать оценки?
В agile-подходах оценки даются с учётом того, что они не могут быть максимально точными. Чрезмерно большие затраты на планирование нерациональны. Надёжность плана достигается частой поставкой продуктов.
Планированием занимается вся команда. Это происходит потому, что заранее неизвестно, кто именно будет выполнять задачу. Во-вторых важно то, что коллективная оценка будет более точной.
Для оценок Майк советуют выбирать цифры одного порядка. Он использует две шкалы:
- 12358 (последовательность Фибоначчи),
- 1248 (прогрессия).
Более сложная шкала, например, от 10 до 100, где история может иметь и 66 и 67 пунктов, — это ложный уровень точности. Разницу в размере этих историй уловить трудно, а времени затрачивается больше.
Есть три метода оценки:
- экспертная оценка (эксперт знает),
- оценка по аналогии (сравнить с прошлой),
- разбивка на мелкие части (деление на шаги с определенной сложностью).
По мнению Майка Кона, лучший способ оценки — это покерное планирование. Каждый из команды получают колоду карт со шкалой оценок. Ведущий зачитывает описание каждой истории. Команда задаёт уточняющие вопросы. Каждый выкладывает карту, которая характеризует, сколько усилий потребуется на решение этой задачи. Если оценки слишком разнятся, авторы крайних позиций объясняют причину своего выбора. Проводится ещё один раунд.
Иногда покерное планирование проводится урезанным составом. Команда может разбиваться на две или три группы, каждая из которых будет оценивать разные задачи. Впервые покерное планирование проводится до официального начала проекта, в нулевой итерации. Затем покер используется во время планирования спринта или груминга: для оценки новых историй и переоценки старых.
Приоритизация
Расстановка приоритетов — это то, что выгодно отличает agile-подход.
При расстановке приоритетов учитываются прибыль и затраты: какой финансовый эффект даёт эта история и какие затраты на разработку она требует? Затем подключаются знания о продукте и знания о проекте. Также учитываются риски, которые снижает реализация данной истории.
Майк отдельно касается приоритизации по финансовой отдаче. Глава, посвящённая этому, полна практических примеров и таблиц с расчётами. Финансовый анализ нужен для определения приоритетов, так как мы имеем дело с бизнесом, где главная задача — получить деньги или сэкономить их. Для приоритизации также можно использовать модель Кано, о которой мы писали в отдельной статье.
Автор показывает, как разбивать пользовательские истории на группы, с учётом их функциональности или расходов на них. Он учит, как составлять план релизов и итераций. Рассказывает, от чего зависит выбор длины спринта, как оценивается скорость, как определяются истории и дата релиза, какие запасные буферы нужно закладывать каждому проекту и как выполнять работу над одним проектом в нескольких командах. Этот раздел значительно дополняет ScrumGuide.
Книга составлена как пособие для практикующих agile-коучей, руководителей компаний, продуктовых менеджеров. В конце каждой главы есть краткое резюме, с которым можно ознакомиться, если у вас нет времени на прочтение всей книги. В конце каждого эпизода даётся ряд вопросов, по которым вы можете скорректировать свою работу. Например, во введении в планирование Майк выдвигает такие вопросы для обсуждения:
«Какой объём планирования оптимален для вашего проекта?
Какие ещё доводы в пользу планирования вы можете привести?
Вспомните наиболее успешный проект, в котором вы участвовали. Какую роль планирование сыграло в нём?»
Всю книгу невозможно пересказать, потому что каждая глава имеет высокое практическое значение. Если вы работаете по Agile и имеете сложности с планированием или чувствуете, что есть аспекты для улучшения, — «Agile: оценка и планирование проектов» для вас.
