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

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

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

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

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

1. Что у нас получается по-настоящему хорошо?

«Джимми, классно ты поработал над тестированием компонентов!»

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

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

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

2. Что нам требуется делать лучше?

«Народ, при реализации последней партии историй допущено много ошибок. Давайте немного сбавим темп, подтянемся и убедимся, что уделяем достаточно внимания тестированию компонентов».

«В последней базе кода было много дубликатов. Не забывайте при работе отводить время на рефакторинг кода».

«Я полностью запорол эту историю с функцией печати. Разрешите, я попытаюсь переделать ее в следующей итерации – обещаю, следующая версия будет гораздо лучше».

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

Подробное руководство по организации ретроспектив дается в книге Agile Retrospectives: Making Good Teams Great [DL06].

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

Ежедневная планерка нужна для быстрого обмена важной информацией с командой. Это собрание, которое должно стать первым и последним. Оно длится 5–10 минут, и на нем никто не сидит (чтобы напомнить людям, что планерка должна быть краткой). Как правило, в ходе планерки вы уточняете, над чем нужно поработать, и сообщаете все, о чем, по вашему мнению, следует знать остальной команде.

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

♦ что он делал вчера;

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

♦ есть ли что-нибудь, замедляющее его работу.

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

♦ что вы вчера сделали, чтобы изменить мир к лучшему;

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

♦ как вы намерены преодолеть все преграды, которые оказались у вас на пути.

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

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

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

От вас зависит и ответ на вопрос, должны ли все эти собрания быть отдельными или их можно объединить?

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

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

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

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

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

Ой-ой. Кажется, сэнсэй хочет проверить, весь ли материал вы усвоили. Идите лучше к нему в додзё и проверьте, имеет ли все это смысл. Удачи!

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

Сценарий 1. Неполная история

МАСТЕР: Однажды на собрании по планированию итерации выяснилось, что одна из историй готова лишь наполовину. Молодой проект-менеджер хотел продемонстрировать прогресс, поэтому предложил учесть половину баллов одной истории при расчете скорости команды в данной итерации, а остальные баллы причислить уже к результатам следующей итерации. Хорошая ли это идея?

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

МАСТЕР: Так ли это? Ответь мне. Может ли крестьянин везти рис на телеге с одним колесом? Может ли человек есть только одной палочкой? Может ли клиент воспользоваться функцией, если она готова лишь наполовину?

УЧЕНИК: Нет, Мастер.

МАСТЕР: Для адепта гибкой разработки пользовательская история не бывает выполнена наполовину, на три четверти или на четыре пятых. История либо готова, либо нет. Поэтому при расчете скорости конкретной итерации учитываются только полностью готовые истории. Все незавершенные истории переносятся на следующую итерацию.

Сценарий 2. Ежедневные планерки не помогают

МАСТЕР: Я знаю одну команду, руководитель которой боролся за то, чтобы все сотрудники присутствовали на ежедневных планерках. Члены команды думали, что планерки особо не нужны и лучше сразу приступать к работе, а при необходимости советоваться друг с другом. Как поступить команде?

УЧЕНИК: Руководитель команды должен напомнить всем о том, как важно, чтобы работа шла согласованно, и как необходимы для этого ежедневные планерки.

МАСТЕР: Да. Команда может пересмотреть цели ежедневной планерки, а также уточнить, зачем она нужна в первую очередь. Но что, если, несмотря на это, команда ощущает ненужность планерок?

УЧЕНИК: Не вполне понимаю тебя, Учитель. Как быстрая ежедневная ориентировка и настройка всех на общий лад может казаться тратой времени?

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

УЧЕНИК: Вы хотите сказать, что некоторым командам ежедневная планерка не требуется?

МАСТЕР: Я хочу сказать, что команда должна продолжать проводить планерки, если видит в этом смысл. Если польза не ощущается – нужно изменить формат планерки или вообще отказаться от нее.

Сценарий 3. Итерация, за которую не было создано ничего ценного

МАСТЕР: Однажды команда прошла целую итерацию, но не смогла по ее завершении выдать какой-либо ценный результат. Неудача была полностью на их совести. Они не смогли разработать план, слишком поздно начали и вообще были ленивы. Зная, что им предстоит преподнести клиенту дурную новость, они отменили презентацию. Мудро ли они поступили?

УЧЕНИК: Хотя я и могу себе представить, как команда могла бы с достоинством выйти из ситуации, пусть ей и не удалось предъявить никакого ценного результата, мне кажется, что если им действительно было нечего показать, то отмена презентации была оправданна. Но лучше бы они честно рассказали, почему возникла такая ситуация.

МАСТЕР: О, ученик, ты хорошо схватываешь. Иногда случается, что тебе не удается сделать за итерацию чего-то ценного, но обычно ненамеренно или из-за лености. Как команда может побороть такую леность?

УЧЕНИК: Ты полагаешь, Мастер, презентацию не следовало отменять? А следовало встретиться с клиентом и признать, что предъявить ему нечего?

МАСТЕР: Вот именно! Иногда угрызения совести – лучший урок. Встретившись с клиентом и ощутив, каково это – ничего ему не показать, – ты узнаешь, как велико отрезвляющее действие такой встречи. Пережив стыд, хорошая команда приложит все усилия, чтобы подобное больше не повторилось.

УЧЕНИК: Спасибо, Мастер. Я обдумаю твой урок.

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

Что дальше?

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

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

Глава 11
Визуальное оформление рабочего пространства

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

Почему бы не сделать такое же расписание для своего проекта?

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

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

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

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

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

Брр! Что же делать? Выдвигаемые требования совершенно безумны. Вы это знаете. Команда это знает. Кажется, что ситуацию не понимает только начальство.

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

Организация брифинга с управленцами

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

Сначала вы показываете гостям стартовую колоду проекта – карточки теперь красиво наклеены на стену.

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

Впечатленные менеджеры подходят поближе и спрашивают, на каком этапе проекта вы находитесь. Чтобы ответить на вопрос, вы обращаете их внимание на схему готовности (release wall).

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

Рассказывая о задачах, решаемых командой в этой итерации, вы показываете менеджерам раскадровку данной итерации.

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

По мере того как история проходит разные стадии разработки, она движется по схеме слева направо. И только когда история полностью разработана, протестирована и одобрена клиентом, она оказывается в столбце «Завершено».

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

Чтобы ответить на этот вопрос, вы показываете им всего две диаграммы, которых они еще не видели. Это график скорости работы вашей команды и схема прогресса разработки.

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

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

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

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

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

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

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

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

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

♦ стену с карточками историй;

♦ схему готовности;

♦ графики скорости работы команды и прогресса разработки;

♦ стартовую колоду, если для нее найдется место.

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

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

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

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

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

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

Вот еще несколько идей по визуальному оформлению рабочего пространства.

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

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

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

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

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

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

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

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

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

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

К сожалению, объем книги ограничен и мы не можем тщательную обсудить эту тему. Однако данному вопросу посвящена отличная книга Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software [Eva03]. Очень рекомендую ее прочитать.

Наконец перейдем к работе над ошибками.

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

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

УЧЕНИК: Мастер, а что делать, если не получается визуально оформить мое рабочее место?

МАСТЕР: Действительно, в некоторых офисах командам, занимающимся проектами, запрещается наклеивать на стены рабочие схемы. Если столкнешься с таким противодействием, смирись с ним и подумай, как работать в сложившихся условиях.

УЧЕНИК: Да, Мастер. Но должен ли я бороться за визуальное оформление? Или следует просто свыкнуться с тем, что у меня на работе его не будет?

МАСТЕР: Это зависит от тебя. Можно идти на компромиссы. Можно уступить. Или можно бороться. Временами и в определенных условиях может быть оправдан любой из этих вариантов. Слушай свое сердце, ищи единомышленников и решай, стоит ли ввязываться в этот бой.

УЧЕНИК: Если это действительно очень важный участок работы, как можно идти на компромиссы?

МАСТЕР: Сталкиваясь с подобными ситуациями, некоторые умельцы научились делать складывающиеся раскадровки, которые позволяют не захламлять офис и обеспечивают для команды возможность свободного общения на протяжении рабочего дня. Другие пользуются онлайн-инструментами и виртуальными раскадровками, чтобы делиться важной информацией, а также обеспечивать слаженную работу команды.

УЧЕНИК: Значит, визуальное оформление рабочего пространства может быть и виртуальным?

МАСТЕР: Нет. Реальные наглядные материалы всегда лучше, но иногда ты просто не можешь себе их позволить.

УЧЕНИК: А если я решу бороться? Что делать тогда?

МАСТЕР: Можешь просто начать готовить визуальное оформление, ежедневно пользоваться им при реализации проекта и надеяться, что в результате переговоров и объяснений клиент поймет, как полезно это оформление.

УЧЕНИК: А если не поймет?

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

Что дальше?

Наше путешествие близится к концу. Вы подыскали всех нужных людей (см. главу 3), составили план (см. главу 8) и знаете, что нужно для его исполнения.

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

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

Начнем с того, что лучше всего экономит время в любом софтверном проекте, – с автоматического тестирования компонентов.