Agile
Введение: «Что такое Agile?»
Agile – это особенная методология разработки программного обеспечения, которая была разработана ещё два десятка лет назад. Данная методология разрабатывалась исходя из стандартов проектного менеджмента, специально для проектов, которые занимались сугубо разработкой программного обеспечения.
Данная система включала в себя классический подход к планированию проекта с планом, выстроенным поэтапно, с указанием всех конкретных стадий развития проекта, а главное – дедлайнов. Agile по большей части ориентировался не на финальную цель плана, а на сам процесс планирования.
В общем и целом, каждый проект – это целый комплекс поочередно расставленных конкретных действий, которые выполняются в течении долгого времени целой командой людей. Любой проект становится в разы сложнее с ростом количества вовлеченных людей и количества действий, которые им необходимо выполнить. Из-за этого большинство начальников не хотят планировать что-то в долгой перспективе, отбрасывая подобное планирование в принципе. Данное «исключение» планирования приводит к хаосу, упущенным дедлайнам, переработкам и неисполнению прямых обязательств сотрудников, а потому можно сделать очень важный вывод о том, что планирование просто необходимо.
Существует и иная ситуация, в которой люди слишком сильно заняты этим самым планированием. Это приводит к перебору с рассмотрением каждой детали плана и игнорированию внешних изменяющихся условий. Как итог, в той ситуации, когда что-то идет не по плану, начинается паника и люди опускают руки.
И та, и другая ситуация – это две крайности, в которые нельзя впадать.
Настоящее хорошее планирование призвано скорее для оценки общего объема задач в проекте, предвиденья рисков и рассмотрение основных способов для их минимизации. План более ясно формулирует перед людьми конечную цель всех действий, а также налаживает правильную коммуникацию между всеми участниками проекта, в том числе между заказчиками. По-настоящему гибкий план — это план, который легко изменить. При этом каждое изменений в таком плане — это не катастрофа, а новый инсайт, который остается в проектной команде, несмотря на все изменения. Именно поэтому планирование более важно, чем план. Гибкое планирование, а не гибкий план — это основа методологии agile.
Среди основных черт гибкого планирования можно выделить фокус на процессе планирования, возможность вносить изменения в план в процессе и поощрение таких изменений.
Методология Agile прежде всего базируется на людях, их сотрудничестве и на совместно достигнутом результате, тогда как классическое планирование отдаёт предпочтение фокусу на процессах, торге и на наборе сухих действий.
Если вы собираете команду и даёте им гибкую систему agile, то вся команда начинает относиться к проекту не как к сухому набору разрозненных действий, а как к совместной живой работе, где каждый элемент имеет очень большое значение. Команда в таком случае идёт к общему результату, а не только лишь к выполнению своего участка.
Гибкое планирование отказывается от плана как единого списка одноуровневых задач или шагов. Цель agile-планирования — более общая, она состоит в том, чтобы к окончанию проекта добиться достижения тех условий, которые ставит заказчик. Эти условия состоят в сочетании свойств конечного продукта, сроков, стоимости и качества.
В методологии agile есть своя терминология, которую необходимо знать для понимания всего процесса.
Итерация – это отрезок проекта, на котором команда должна полностью выполнить определенный участок работу. Причем ключевой момент здесь именно в полном выполнении — результат итерации можно показать заказчику. Если речь идет о ПО, то результат итерации — это функционирующий и уже протестированный фрагмент кода.
Уровни планирования – это уровни, которые и отличают данную систему от классического планирования. В Agile существуют три уровня планирования – это уровень всего проекта, уровень итерации и уровень рабочего дня. Общая цель формируется на первом уровне, более подробные задачи на уровне итерации, а самые конкретные и узконаправленные задачи на третьем уровне.
Пользовательская история — это короткое предложение, описывающее одно из требований заказчика. Обычно история выглядит следующим образом: «Как <роль, например, новый пользователь>, я хочу <цель, например, иметь возможность зарегистрироваться на сайте>, чтобы <деловая выгода для заказчика, например, иметь возможность совершать покупки на сайте>». Одна итерация, в зависимости от величины, может включать одну или несколько историй.
Эпопея — это сочетание нескольких пользовательских историй, объединенных логически.
Идеальные дни — еще один способ измерения историй. Это количество чистого времени, которое команда тратит на проект.
Баллы — это единица измерения, которой можно выразить размер истории.
Часть первая: «Как правильно оценить задачи и графики в проекте?»
Итак, как же на деле работает гибкое планирование?
Первой обязательной ступенью всего процесса является оценка общего объема предстоящей работы. На данном этапе оценка происходит по временной шкале.
Основной и самый интересный момент гибкой методологии состоит в том, что размер и длительность проекта — это принципиально разные вещи. При agile-планировании мы всегда оцениваем размер проекта и вычисляем его длительность.
Процесс выглядит следующим образом. Мы разбиваем весь проект на истории. Каждой истории присваивается определенный размер в баллах.
Перед вами 10 собак разной породы. Чтобы описать их размер, мы можем, например, выделить самую маленькую из них взять ее размер за единицу, и описывать остальных собак относительно нее. В этой системе пудель будет в три раза больше, так что его размер будет 3 балла, овчарка — в 7 раз больше, так что ее размер — 7 баллов и так далее. Можно пойти другим путем, например, взять среднюю по размеру собаку и присвоить ей размер 5, а остальных сравнивать с ней. Так же можно оценивать и пользовательские истории.
Второй ступенью в системе является оценка скорости, с которой команда должна выполнять действия. Если история, например, размером всего в 4 балла, то обычная команда выполнит её за 7-8 дней, а вот на историю, размером в 2 балла, ей уже потребуется всего 3-4 дня.
Здесь мы разбиваем проект на отрезки и смотрим, какая будет длительность у всего проекта. Из частных временных отрезков мы связываем цельное время, за которое все люди должны будут выполнить общий проект.
Помимо обычных баллов, истории можно оценивать в идеальных днях. На первый взгляд это кажется проще, поэтому начинающим командам рекомендуют следовать этому методу. Суть его в том, что из 8 рабочих часов каждый сотрудник проводит на проекте, допустим, 4 часа чистого времени. Остальное время у него занято звонками, написанием электронных писем, участием в совещаниях и т. д. Соо��ветственно, два календарных дня — это один идеальный день. Данная методология требует оценки скорости работы каждого участника команды отдельно.
Но здесь стоит оговориться о том, что есть разница между обычными днями и идеальными днями. И она может быть значительной, если участники одной команды задействованы сразу на нескольких проектах единовременно.
Очень важно, чтобы пользовательские истории оценивал не человек со стороны, а именно исполнитель. При этом все члены команды понимают, что гибкое планирование по сути своей подлежит изменениям. Поэтому они уделяют время и внимание процессу планирования, но не позволяют этому процессу отнимать слишком много усилий. Как правило, наиболее подробно планируются ближайшие 2 итерации.
Всего существует три самых адекватных метода оценки пользовательской истории.
Это метод экспертного мнения, метод аналогии и метод оценки «по частям»
В первом методе привлекается эксперт, который уже занимался чем-то подобным, во втором анализируется опыт в похожих проектах самого пользователя, а в третьем методе вся история разбивается на части и оценивается по частям предыдущими двумя методами. Если вдруг в процессе работы выявилось, что оценка размера при планировании была произведена неверно, нужно произвести переоценку этой истории, а также других, размер которых выводили на ее основании. Только так можно получать и накапливать опыт в команде.
Когда вы выбираете метод оценки истории, будь то баллы или пересчет в идеальных днях, вам следует думать также и о ещё нескольких важных факторах.
Во-первых, оценка в баллах улучшает сплоченность команды, потому как вся команда принимает непосредственное участие в оценке. Идеальными днями лучше всего оценивать только лишь части какой-то истории, а не весь участок работы.
Во-вторых, оценка в баллах в любом случае более объективна, потому что не учитывает загруженность и скорость работы каждого отдельного члена команды.
В-третьих, балловая система является более абстрактной, а потому не заставляет человека делать классическую ошибку: привязывать идеальные дни к календарным дням.
В-четвертых, лучше всего использовать оценку в идеальных днях в том случае, если вы хотите быстро объяснить что-то человеку, который участвует в работе вне команды, например – заказчику.
Далее идет третья ступень планирования, а именно – оценка сути проекта.
На данном этапе из всех задач, стоящих перед командой, выявляются наиболее приоритетные прежде всего для заказчика, и именно они ставятся на первое место в общем плане действий.
Как правило, основная цель заказчика — получение прибыли. Он заказывает нам новый продукт, чтобы либо привлечь новых клиентов, либо предоставить новые платные услуги уже существующим клиентам, либо сэкономить деньги за счет оптимизации процессов. Здесь для приоритизации, скорее всего, придется прибегнуть к финансовому моделированию. Построив финансовую модель с учетом внедрения результатов проекта, можно будет точно посчитать, какую прибыль принесет заказчику разработка той или иной пользовательской истории — и какая из них, соответственно, более важная.
Часть вторая: «Планирование графика проекта – это важно»
На уровне проекта в системе agile планируется её основной финал, то есть конечная цель, к которой должна стремиться вся команда. На этом этапе заказчик должен понимать, как быстро он сможет начать зарабатывать на том продукте, который разрабатывает команды. Уже исходя из этого пункта он будет строить стратегическое планирование.
Для проектной команды конечная цель — тот маяк, к которому она движется. Важно, чтобы команда знала эту цель и не теряла ее из вида.
Если вы хотите сформулировать цель на уровне проекта, вам нужно выбрать самую оптимальную для данного действия длину итерации, а затем оценить скорость работы команды. После этого нужно поставить в приоритет пользовательские истории, за затем предоставить заказчику список историй, которые команда обязуется выполнить.
После всех этих действий нужно часто проверять и сверять с мнением и желанием заказчика актуальность конечной цели проекта.
Планирование на уровне итерации становится более детальным, и его нужно проводить перед началом каждой итерации. При этом в ходе планирования важно избежать ситуации, когда каждому участнику проекта просто раздаются его задачи. Это полностью разрушает командный дух. Нужно планировать всю итерацию полностью, а не для каждого участника индивидуально. Итерации обычно длятся от двух до четырех недель, поэтому они всегда планируются в идеальных часах. В конце каждой итерации следует также проводить встречу для оценки выполненной работы и извлечения уроков на будущее. При этом планирование итерации может быть основано как на скорости проекта, так и на выполнении обязательств.
Если вы хотите определить длину итерации, вам нужно выявить общую продолжительность проекта. Чем длиннее проект, тем длиннее итерация. При этом необходимо учитывать уровень неуверенности заказчика и нечеткость конечной цели, чем выше два этих параметра, тем короче должны быть итерации, чтобы заказчик получал как можно больше информации о том, что уже выполнено в данный момент. Частота получения обратной реакции на сделанную работу также очень важна - чем чаще, тем лучше. Но если, например, заказчик может встречаться с командой только раз в три недели — соответственно, нужно планировать итерации так, чтобы к моменту встречи предоставлять очередной результат. Обязательно имейте в виду, что ваша команда во время всей работы не должна быть ни перегружена, ни слишком расслаблена!
Когда длина итерации выбрана — держитесь ее и старайтесь соблюдать до окончания проекта. Единственное исключение — постарайтесь, чтобы конец очередной итерации не выпадал на конец квартала — обычно это очень нервное время в любой организации, и у команды будет дополнительная нагрузка, а также сложно будет получить обратную связь, потому что у всех будут другие дела.
Поскольку гибкое планирование не ставит перед собой задачу планировать ход проекта с точностью до дня, необходимо закладывать в план буферы. Буферы особенно полезны для тех проектов, где сложно сформулировать конечную цель или крайне высок риск серьезных негативных последствий в случае ошибок при планировании.
В Agile-системе используются буферы двух классических вариаций – по задачам и по времени.
При выборе буфера по задачам истории приоритизируются, после чего решается, какие из них обязательные, а какие – нет. Необязательные истории здесь и являются буфером.
Если же вы выбрали буфер по времени, то его нужно правильно вычислить. Чтобы сделать это, нужно оценить размер историй с вероятностью 50% и 90% (например, с вероятностью 50% размер этой истории 5 баллов, но с вероятностью 90% она больше — 7 баллов). Затем разницу между этими оценками для разных историй нужно суммировать и извлечь из суммы квадратный корень — так вы получите количество баллов, которое затем нужно разделить на скорость — так вы получите длительность временного буфера.
Также имейте в виду, что Agile-команда не может быть больше 10–12 человек, иначе будет сложно построить работу. Поэтому, если проект требует привлечения большего числа людей, лучше всего не объединять их в одну команду, а разбить на несколько команд.
Часть третья: «Важнейшая часть Agile – это налаженная коммуникация»
Проекты на основании такой системы планирования выстраиваются прежде всего в атмосфере доверия и постоянного общения друг с другом. Если такая атмосфера появляется в команде, люди могут моментально получать доступ к интересующей их информации, благодаря чему команда начинает работать более эффективно.
Если рассматривать уровень отслеживания проекта, то здесь коммуникация даёт людям информацию о том, на какой стадии находится проект по отношению к времени его сдачи. Обычно всё это выглядит как график на системе координат или шкала.
В уровне «итераций» процесс отслеживает в первую очередь команда, а не заказчик. В данном случае вся информация помещается на доску (магнитную, пробковую или какую угодно). Саму доску делят на две части – выполненные и невыполненные задачи, и каждая задача записывается на отдельном листке бумаги. Потом листки переносятся с одной стороны на другую по мере выполнения.
Когда вы занимаетесь коммуникацией, вам важно помнить, что коммуникация с заказчиком должна быть постоянной, полной, честной и обязательно двухсторонней! Информируйте вашего клиента о ходе работ и об изменениях в планах.
В этой ситуации очень важно, чтобы заказчик понимал то, что планирование – это не предсказания будущего и не точнейшая наука в мире, то есть если изменения вносятся в план, то это нормально, в особенности, если они оправданы.
Также помните, что очень хорошим тоном будет преподносить отчет о проделанной работе для заказчика после каждой итерации, так вы очень сильно повысите уровень видимого для заказчика профессионализма.