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

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

Как мастера Agile делают выдающееся ПО

Jonathon

The Agile Samurai Rasmusson

How Agile Masrets Deliver Great Software

The progmatic Bookshelf

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

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

© 2010 Jonathan Rasmusson.

© Перевод на русский язык ООО Издательство «Питер», 2012

© Издание на русском языке, оформление ООО Издательство «Питер», 2012

Об авторе

Джонатан Расмуссон, опытный предприниматель и бывший консультант по гибкой разработке (agile coach) в компании ThoughtWorks, занимается консалтингом на международном уровне, помогая клиентам находить наилучшие пути совместной работы и взаимодействий. Если Джонатан не едет на мотоцикле на работу по лютому канадскому морозу, то в свободное время он ведет блог http://agilewarrior.wordpress.com, где делится своим опытом из области гибкой разработки.

Благодарности

Эта книга никогда бы не получилась, если бы не поддержка Таннис – любви всей моей жизни – и трех наших чудесных детей, Лукаса, Роуэна и Бринна, которые прошли вместе со мной весь этот путь.

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

Следует также упомянуть тех разработчиков-первопроходцев, на труд которых я опирался при написании книги. Это Кент Бек, Мартин Фаулер, Рон Джеффрис, Боб Мартин, Джошуа Кериевски, Том и Мэри Поппендик, Кэти Сьерра и чудесный коллектив компании ThoughtWorks.

И, разумеется, эта книга никогда бы не состоялась, если бы не невероятно плодотворное сотрудничество и вдумчивый подход, проявленные рецензентами и комментаторами: Ноэлем Раппином, Аланом Френсисом, Кевином Гиси, Джессикой Уотсон, Томасом Гендроном, Дэйвом Клейном, Майклом Сикорским, Дэном Нортом, Джанет Грегори, Санджай Манчиганти, Венди Линдеманн, Джеймсом Эвери, Робином Даймондом, Томом Поппендиком, Элис Тот, Иэном Дизом, Меган Армстронг, Рамом Сваминатаном, Хэзер Карп, Чедом Фурнье, Мэттом Хьюзом, Майклом Менардом, Тони Семана, Ким Шриер и Рихейлом Кристофом. Особая благодарность Ким Уимпсетт и Стиву Питеру за превосходное техническое редактирование и набор текста.

Спасибо вам, мама и папа, за то, что любите и вдохновляете меня.

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

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

Мастер-сэнсэй

Рад встрече с вами

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

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

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

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

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

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

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

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

Как читать эту книгу

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

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

В части II рассказывается об одной из наиболее многообещающих деталей предлагаемого метода – о подборе средств, которые составят арсенал вашей команды при реализации проекта. Речь пойдет о так называемой стартовой колоде (inception deck).

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

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

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

Неслучайный юмор

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

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

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

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

А вот и Мастер-сэнсэй – легендарный гуру гибкой разработки, мудрый и опытный во всех аспектах рассматриваемой парадигмы.

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

Принцип гибкой разработки

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

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

Ресурсы в Интернете

У англоязычного издания этой книги есть собственный сайт http://pragprog.com/titles/jtrap, где подробнее рассказано о книге. Работать с ним можно следующим образом:

♦ участвовать в дискуссиях на форумах, обмениваться мнениями с другими читателями, энтузиастами гибкой разработки и со мной;

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

Итак, начнем.

От издательства

Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.

Часть I
Введение в гибкую разработку

Глава 1
Сущность гибкой разработки

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

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

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

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

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

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

1. Нужно разбить крупную проблему на мелкие задачи.

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

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

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

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

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

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

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

4. Работа требует участия клиента.

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

5. При необходимости нужно изменять курс.

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

6. Вы берете на себя ответственность.

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

♦ Вы отвечаете за качество.

♦ Вы придерживаетесь расписания.

♦ Вы устанавливаете определенную планку.

♦ Вы тратите средства так, как если бы они были вашими.

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

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

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

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

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

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

В гибкой разработке под журналом пожеланий (master story list)[1]1
  В английских источниках также употребляются термины backlog и product backlog, в русском языке встречается понятие «бэклог». – Примеч. пер.


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

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

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

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

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

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

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

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

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

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

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

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

♦ предложит элегантный метод работы;

♦ составит тщательный и полный план тестирования?

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

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

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

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

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

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

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

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

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

И не забывайте…

Путей всегда много!

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

♦ У вас есть скрам (Scrum) – этот метод управления охватывает гибкий проект как оболочка.

♦ У вас есть экстремальное программирование (Extreme Programming, XP) – требующие высокой дисциплины основные практики разработки программ, жизненно важные для любого гибкого проекта.

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

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

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

Но учитывайте, что ни одна книга или метод не дадут вам ответов на все вопросы – в любом случае что-то придется додумывать самостоятельно. Каждый проект особенный, и хотя определенные принципы и практики будут действовать всегда[2]2
  http://agilemanifesto.org.


[Закрыть], именно от вашей уникальной ситуации и контекста работы будут зависеть тонкости их применения.

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

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

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

♦ итерация (iteration) – то же, что и спринт (sprint);

♦ журнал пожеланий (master story list) – то же, что и бэклог (product back log);

♦ клиент (customer) – то же, что и владелец (product owner)[3]3
  «Владелец» – термин условный. Обычно так называют заказчика или его представителя, который определяет требования к продукту. В agile-команде эту роль может исполнять менеджер проекта, бизнес-аналитик или клиент. – Примеч. ред.


[Закрыть].

Что дальше?

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

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