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

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

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

Несколько слов о парном программировании

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

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

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

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

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

Например, в гибком проекте не обойтись без определенных вещей:

♦ нужно писать автоматизированные тесты;

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

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

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

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

Далее, в частности в главах 12–15, мы подробно обсудим рефакторинг, разработку на основе тестирования (test-driven development) и непрерывную интеграцию и увидим, как все эти методы помогают получить код, готовый к практическому использованию.

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

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

Начинаем с нулевой итерации

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

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

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

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

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

Коллективное владение кодом

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

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

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

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

Знаю, о чем вы подумали. С учетом всего тестирования, которым пронизан гибкий проект, нуждаемся ли мы в пользовательских тестах приемки (user acceptance test, UAT) перед сдачей программы в эксплуатацию? Ответ – да, нуждаемся. И вот почему.

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

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

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

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

Что, если вам не разрешат отслеживать ошибки?

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

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

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

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

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

Работа в канбане ограничивается концепцией, называемой «работа, выполняемая в данный момент» (work in progress, WIP). В каждый момент времени команде разрешено синхронно заниматься решением ограниченного количества задач.

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

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

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

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

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

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

Но в этом отношении канбан характеризуется очевидной простотой. Ситуация примерно такова, как если бы вам сказали: «Понимаешь, дружище, у нас тут дел невпроворот. Мы бы не отказались взяться за твой проект, но работать сможем только над четырьмя вещами одновременно». Никаких баллов. Нет оценок, которые нужно объяснять. Проза жизни. Одновременно мы можем заниматься только таким-то количеством задач.

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

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

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

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

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

Подробнее познакомиться с новейшими и наиболее важными фактами, связанными с канбаном, можно на сайте http://finance.groups.yahoo.com/group/kanbandev/messages.

А теперь вы готовы к новой встрече с сэнсэем.

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

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

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

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

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

Что дальше?

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

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

Глава 10
Создание гибкого плана коммуникации

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

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

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

Две неотъемлемые характеристики гибкого проекта – это формирование ожиданий и обеспечение отдачи со стороны клиента.

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

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

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

♦ убедитесь, что подготовлена работа на следующую итерацию (проведено собрание по планированию историй);

♦ получите реакцию на истории, выполненные в ходе последней итерации (презентация);

♦ спланируйте, как будет протекать следующая итерация (планирование итерации);

♦ постоянно ищите способы оптимизации работы (мини-ретроспектива).

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

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

Без ошибок не обойтись, так что не заморачивайтесь на них!

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

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

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

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

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

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

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

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

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

У вас получилось! Вы сделали что-то ценное. Вы знаете, сколько проектов длятся неделями, месяцами, а иногда и годами без получения какого-либо полезного результата? Много.

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

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

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

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

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

Кроме того, собрание по планированию итерации отлично подходит для экспресс-проверки состояния проекта.

1[16]16
  Считается, что это сообщение появилось в связи с серьезной аварией на корабле «Аполлон-13». – Примеч. пер.


[Закрыть]

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

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

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

Как получаются конструктивные отзывы

Существуют два способа налаживания коммуникации. Можно подать ее прямо и холодно:

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

Или можно выразиться дипломатичнее:

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

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

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

Эффективная коммуникация подробно описана в классической книге Дейла Карнеги «Как завоевывать друзей и оказывать влияние на людей» [Car90].

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