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

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

♦ то, чем вы сейчас занимаетесь, не работает;

♦ вам срочно нужно выдать какой-то результат.

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

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

♦ Зачем мы здесь собрались?

♦ Чего мы пытаемся достичь?

♦ Кто наш клиент?

♦ Какие крупные проблемы мы должны решить?

♦ Кто командует?

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

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

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

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

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

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

Блаженное неведение

Помню, как однажды я спросил вице-президента о том, что он думает о гибком планировании. Он сказал: «Это называется “ни с тобой, ни без тебя”». С одной стороны, ему нравилась прозрачность гибких проектов, но в то же время она действовала ему на нервы. Раньше он мог просто закрыть глаза на происходящее и сказать, что все нормально. Но теперь проект на виду. Каждый день. В истинном виде. И от него не скрыться. Проект постоянно напоминает о том, как много еще остается доработать, и это, приходится согласиться, совсем не плохо.

Сценарий 1. Клиент обнаруживает новые требования

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

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

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

Сценарий 2. Работа движется медленнее, чем ожидалось

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

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

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

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

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

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

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

Если даты выглядят реалистично, то все в порядке! Продолжайте следить за процессом.

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

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

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

Сценарий 3. Команда теряет важного члена

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

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

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

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

Сценарий 4. Время на исходе

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

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

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

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

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

А теперь Мастер-сэнсэй снова встретится с вами, чтобы узнать, чему вы научились.

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

Сценарий: все параметры проекта жестко заданы, и изменить план нельзя.

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

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

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

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

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

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

МАСТЕР: Именно так.

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

МАСТЕР: Верно.

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

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

Что дальше?

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

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

И все начинается с самой обычной итерации.

Часть IV
Выполнение гибкого проекта

Глава 9
Управление итерациями

Добро пожаловать в часть IV! Здесь мы обратимся к планам, подготовленным в частях II и III, и превратим эти благие намерения во что-то, с чем смогут работать наши клиенты, то есть в готовые программы.

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

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

Итак, у вас есть план. Вы знаете, зачем собрались, и готовы работать. А что дальше? Как превратить карточку, на которой написано несколько слов, в готовую функциональную программу?

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

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

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

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

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

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

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

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

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

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

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

1. Анализ и проектирование (подготовка к работе).

2. Разработка (выполнение работы).

3. Тестирование (проверка работы).

Рассмотрим каждый из этих этапов более подробно.

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

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

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

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

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

Еще одна ключевая характеристика гибкого анализа – «точно в срок».

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

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

В случае работы подобным образом гарантируется следующее:

♦ при анализе учитывается только новейшая и ценнейшая информация;

♦ вы и клиент получаете возможность учиться и внедрять инновации по ходу работы;

♦ вам не приходится многое переделывать.

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

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

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

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

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

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

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

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

На данном этапе происходит встреча с клиентом, в ходе которой вы спрашиваете: «А как мы узнаем, что эта функция работает?»

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

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

А есть ли другие инструменты и методы, которые можно использовать при тестировании? Конечно! В вашем распоряжении – раскадровка, диаграммы параллельного исполнения (concurrency diagrams), карты процессов, каркасные представления (wireframes) и другие полезные средства, известные человечеству (другие идеи, связанные с анализом, описаны в разделе 6.4).

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

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

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