Текст книги "Гибкое управление IT-проектами. Руководство для настоящих самураев"

Глава 8
Гибкое планирование: столкновение с реальностью

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

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

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

Случалась ли с вами такая история: проект запускается без всяких проблем, у вас отличная команда, правильно подобранная технология и безупречный план. В течение первых двух недель реализации проекта кажется, что все просто превосходно. И вдруг откуда ни возьмись… бам!

Ваш ведущий разработчик с головой погружается в другой проект – считается, что этот второй проект стратегически очень важен (странно, еще недавно такое же значение придавалось вашему проекту). «Ладно, время терпит, – думаете вы, – справимся». И вот внезапно все идет насмарку…

То, чего вы ожидали от команды, и то, что ей удается, – это, как говорится, большая разница. И потом, на полпути к завершению проекта…

Это простое, легко выстраиваемое веб-приложение вдруг оказывается гораздо более сложным и обескураживающим. То, что, казалось бы, было проще пареной репы, теперь представляется невыполнимой задачей, учитывая, сколько времени и ресурсов у нас осталось. А потом начинается катастрофа.

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

Если эта история задевает вас за живое, утешьтесь – вы не одиноки в своей беде. Команды меняются, планы урезаются, требования постоянно корректируются – в интересном софтверном проекте это обычное дело.

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

♦ представлял ценность для наших клиентов;

♦ был максимально наглядным, открытым и честным;

♦ позволял нам сдерживать данные обещания;

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

Итак, мы очертили контекст, в котором обычно происходят изменения. Теперь рассмотрим гибкий план.

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

История о том, как меня один раз попросили уйти с проекта

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

Объективно система стоила $2 млн, но мы пытались управиться, имея $700 тыс. Когда стало очевидно, что бюджет более чем в два раза меньше, чем необходимо, компания стала закручивать гайки, требуя от нас, чтобы мы работали сверхурочно и выполнили проект «в соответствии с планом».

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

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

В итоге я потерял этого клиента. Честно говоря, мы допустили несколько крупных ошибок: не сделали стартовой колоды в начале проекта, не совсем внятно объяснили, как происходит гибкое планирование.

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

Как вы помните, при гибком планировании список того, что нужно сделать, называется журналом пользовательских пожеланий (бэклогом). В нем перечисляются все функции, которые клиент хотел бы видеть в заказанной программе.

Скорость, с которой пользовательские истории преобразуются в готовые программные функции, в гибкой методологии называется скоростью работы команды (team velocity). C ее помощью измеряется производительность команды, она же помогает делать прогнозы на будущее.

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

Чтобы приближенно спрогнозировать сроки, в которые продукт будет готов, мы берем общий объем работы по данному проекту, делим его на предполагаемую скорость команды и подсчитываем, сколько итераций должно пройти до завершения проекта. Так у нас получается план проекта.

Количество итераций = Общий объем работ / Примерная скорость работы команды.

Например:

Количество итераций = 100 баллов / 10 баллов на итерацию = 10 итераций.

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

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

Теперь, когда мы приступили к разработке, произойдет одно из двух. Мы обнаружим, что:

♦ работа идет быстрее, чем ожидалось;

♦ работа идет медленнее, чем ожидалось.

Быстрее, чем ожидалось, – это ситуация, в которой вы и команда работаете с опережением плана. Медленнее, чем ожидалось (и это бывает чаще), означает, что вам еще много нужно сделать, а времени на все не хватает.

Сталкиваясь с ситуацией, когда сделать нужно слишком много, гибкие команды пытаются уменьшить объем работы (так поступаем все мы, когда, например, обнаруживаем, что слишком много запланировали на выходные). Вместо того чтобы упрямо следовать первоначальному плану, его нужно менять, как правило – снижать объем работ.

Благодаря изменению объема работ гибким командам удается выполнять стоящие перед ними планы.

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

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

Строго говоря, клиент теперь не обязательно откажется от старой истории, если у него появится новая. Например, если старая история описывает функцию, которая действительно потребуется при работе и за которую клиент готов заплатить.

Чего действительно не следует ожидать клиенту, так это возможности добавить в список дополнительный пункт без отказа от какого-то из имеющихся пунктов. Это принятие желаемого за действительное, и таким поступкам нет места в гибком планировании.

Если встает дилемма – отодвинуть дату релиза или изменить объем работ, сторонники гибкой разработки обычно предпочитают второй вариант. Ничто не происходит в нашем деле так легко, как постоянное сдвигание дат выпуска. А вот делать готовые программы вовремя – это гораздо сложнее.

Но независимо от того, есть ли у вас жесткая дата окончания разработки или вы ведете работу до того, как будет готов основной функционал, гибкий подход к объему работ – та концепция, которую клиент должен очень хорошо усвоить. Только тогда ваши планы останутся реалистичными, а ваша команда не будет брать на себя больше, чем сможет сделать. Здесь может возникнуть вопрос: а что делать, если клиент не хочет гибко подходить к плану и настаивает на том, чтобы вы и ваша команда работали сверхурочно?

В таком случае есть два варианта.

♦ Можете продолжать лгать, смотреть на работу сквозь пальцы и придерживаться старого плана, как это делают все остальные. Или же дать чрезмерно оптимистичную оценку, раздуть расчеты, игнорировать скорость работы команды и молиться, чтобы в конце все разрешилось само собой (то есть рассчитывать на чудо).

♦ Или, если ничего не помогает, можно рассказать о ситуации без прикрас, какова она есть на самом деле, и посидеть в наступившей неловкой тишине, пока клиент не поймет, что вы не собираетесь уступать. Вы не будете больше создавать видимость и участвовать в распространении той величайшей лжи, которая существует в информатике на протяжении уже более 40 лет. Никто и не говорил, что самураем быть легко.

А теперь давайте рассмотрим, как составить первый гибкий план.

Создание первого гибкого плана не особо отличается от подготовки к выходным, на которые запланировано много дел. Все начинается с хорошего списка.

Этап 1. Подготовка журнала пользовательских пожеланий

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

Обычно на проработку хорошо составленного журнала пожеланий требуется от одного месяца до полугода. Нет смысла отслеживать истории, реализация которых планируется на более поздний срок, так как:

♦ вы не знаете, что произойдет в мире через полгода;

♦ возможно, этими историями так и не придется заниматься, поэтому сейчас думать о них точно незачем.

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

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

Определение релиза. Релиз – логически объединенная группа историй, которая представляет ценность для вашего клиента. То есть это набор, который стоит разрабатывать и впоследствии развертывать. Кроме того, релиз иногда называют минимальной коммерчески ценной функциональностью (Minimal Marketable Feature set, MMF[14]14
  Software by Numbers: Low-Risk, High-Return Development [DCH03].


[Закрыть]).

Первая «М» в аббревиатуре MMF, означающая «минимальная», напоминает нам, что требуется в кратчайшие сроки начать выдавать полезный результат (и о том, что зачастую 80 % ценности системы обеспечивается всего 20 % ее функций). Итак, мы хотим выбрать наименьшее количество функций, которые принесут наибольшую пользу в первой версии нашей программы.

Обратите внимание на слово «коммерчески» в этом термине. Оно означает, что функциональность должна иметь ценность для клиента (иначе он просто не будет ею пользоваться). Итак, минимализм и коммерческая ценность – два основных параметра, по которым следует формировать набор историй для первого релиза.

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

Этап 2. Определение времени, необходимого на разработку

В главе 7 мы рассмотрели методы, применяемые гибкими командами для оценки времени, которое потребуется на разработку той или иной функции.

Основная причина траты времени в ходе проектов

А вы знали, что 64 % функций любой программы используются редко или вообще не используются? Невероятно, но факт![15]15
  Данные исследования аналитической компании Standish Group по докладу ее руководителя Джима Джонсона, прочитанному на XP2002.


[Закрыть]

Подумайте об этом. Сколько функций вы используете в программе Microsoft Word? Пять процентов? Десять процентов? Может быть, процентов двадцать, если вы очень опытный пользователь.

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

На данном этапе мы пытаемся понять, насколько велика стоящая перед нами задача и сколько времени понадобится на ее решение – один, три, шесть или девять месяцев.

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

Этап 3. Расстановка приоритетов

В любой момент может случиться что-то неожиданное (то есть проект может быть отменен или сокращен), поэтому в первую очередь нужно реализовать самые важные функции.

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

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

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

Имея список, в котором расставлены оценки и приоритеты, мы практически готовы говорить о датах. Но перед этим еще нужно сориентироваться, насколько быстро способны работать вы и ваша команда.

Скорость – это командная черта!

Когда мы строим планы исходя из скорости работы нашей команды, за исход мы ручаемся тоже как команда. Мы говорим: «Как команда мы чувствуем, что сможем выполнять вот такой объем работы, от итерации к итерации».

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

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

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

Этап 4. Оценка скорости работы команды

Гибкое планирование действует потому, что мы строим планы на будущее, но основываемся при этом на результатах, которых смогли достичь в прошлом.

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

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

Скорость работы команды = Выполненные истории / Итерация.

Однако обычно размеры историй значительно различаются, и в таком случае скорость работы команды будет выражаться следующей формулой:

Скорость работы команды = Балльная оценка выполненных историй / Итерация.

Сейчас, в самом начале проекта, скорость работы будет колебаться, и пусть вас это не волнует. Это нормально, пока команда не освоится с работой и не найдет наилучший способ взаимодействия.

Но через 3–4 итерации скорость должна начать выравниваться и вы начнете понимать, насколько быстро команда справляется с проектом.

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

Также напомните команде, что значит «сделано» (см. раздел 1.3), и еще раз поясните, что при гибкой разработке под реализацией истории понимается анализ, тестирование, проектирование и написание кода. Всё вместе.

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

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

Этап 5. Определение сроков

Есть два способа примерно спланировать сроки работы. Можно выполнять проект к определенному сроку (by date) или до реализации основного набора функций (by feature set).

Выполнение к определенному сроку

Когда проект выполняется к определенной дате, мы как будто проводим линию на песке и говорим: «Проект будет закончен к этому моменту во что бы то ни стало».

Когда обнаруживаются новые важные пользовательские истории, то более ранние, не менее объемные, но менее важные, отбрасываются.

Поэтому мы вынуждены принимать жесткие решения о компромиссах заранее (компромиссы будут касаться, например, функционала приложения), но достаточно категорично даем понять, что дело не терпит отлагательств.

Можно более гибко подходить к дате, уделяя внимание основному набору возможностей, то есть работать до реализации основного набора функций.

Выполнение до создания определенного набора функций

Мы выбираем основные функции и разрабатываем их до полной готовности.

Гибкий подход к функционалу приложения по-прежнему актуален (поскольку в ходе работы будет обнаруживаться, что нужны и новые функции), но суть в данном случае такова, что команда должна разработать несколько крупных блоков, а дата уже не так важна – главное, чтобы весь набор основных возможностей был реализован.

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

Именно так и создается гибкий план! Вы выстраиваете взвешенный журнал пожеланий, в котором учтены все приоритеты, оцениваете скорость работы вашей команды и осознанно выбираете дату окончания работ.

Пока мы только начинаем работу, нужно поговорить еще об одном отличном инструменте выстраивания перспектив – о графике прогресса разработки (burn-down chart). Затем обратимся к искусству гибкого планирования.

Хотя формально мы еще не обсуждали график прогресса разработки, вам уже доводилось сталкиваться с ним на страницах книги. Это график, показывающий, насколько быстро мы как команда перерабатываем пользовательские истории. Кроме того, он позволяет прогнозировать, какова будет скорость работы в дальнейшем.

По оси Y мы отслеживаем количество оставшейся работы (в рабочих днях или баллах), а по оси X – время, отпущенное на итерацию. Просто запишите объем работы (количество баллов), остающийся на каждую из итераций, и отобразите это на графике. Угловой коэффициент (уклон прямой лини) – это скорость команды (позволяющая судить, сколько работы команда способна выполнить за итерацию).

График прогресса разработки – отличное средство, позволяющее узнать, в каком состоянии находится ваш проект. Просто взглянув на него, можно узнать следующую информацию:

♦ сколько работы сделано;

♦ сколько работы остается сделать;

♦ скорость команды;

♦ ожидаемую дату завершения работы.

Каждый столбец (итерация) на следующей схеме представляет собой объем оставшейся работы по данному проекту. Мы завершаем работу, когда высота столбца становится нулевой.

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

Однако в реальности график прогресса разработки обычно выглядит так:

Дела редко идут по плану. Скорость работы команды колеблется. Обнаруживаются новые истории. От некоторых старых историй приходится отказываться.

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

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

Графики прогресса разработки описывают ситуацию как она есть. Это крайне репрезентативная часть гибкого планирования. Мы ничего не прячем и не приукрашиваем реальность. Регулярно пересматривая график прогресса разработки вместе с клиентом, мы можем открыто и честно делать прогнозы, причем все будут понимать, к какому сроку мы рассчитываем завершить работу.

График объема работы

Кроме графика прогресса разработки, часто используется и обратный график (burn-up chart). На нем отображается динамика объема работы.

Некоторые специалисты предпочитают пользоваться именно графиком объема работ, так как на нем отображается процесс появления новых историй. Если провести в его верхней части непрерывную линию, можно сразу увидеть любой рост объема работ, и отслеживать этот рост во времени становится несколько проще.

Если вам нравится наглядность графика объема работ, но вы не хотите отказываться от простоты и самой концепции графика прогресса разработки, можно объединить эти две схемы. Просто отслеживайте общий объем работ для каждой итерации на графике прогресса разработки, а одновременно с этим следите за количеством оставшейся работы.

Каким именно графиком пользоваться, полностью зависит от вашего выбора. Просто убедитесь, что у вас есть простой и наглядный способ сориентироваться, сколько работы еще остается и когда с ней удастся разобраться.