скачать книгу бесплатно
Когда оказывается, что вам и вашему клиенту предстоит сделать слишком много, ваш единственный выход – сделать меньше. Гибко подходя к объему задач, вы сможете сохранить сбалансированные планы, а ваши обещания останутся реалистичными.
И если реальность идет вразрез с планом, нужно менять план. Адаптивное планирование – это краеугольный камень гибкой разработки.
Пока это все, что требуется сказать о гибком планировании. Такой метод планирования будет подробнее рассмотрен в главе 8.
Если сроки поджимают, то, как говорится, «надо – значит надо». Просто советую убедиться, что вы жертвуете собой ради стоящего дела, а не ради совершенно нереального обещания, данного примерно год назад при обзоре показателей эффективности работы.
Действительно, нереальные обещания время от времени даются и команды разработчиков сталкиваются с необходимостью сотворить невозможное. Но это неправильно. Работать с расчетом на чудо – не лучший способ реализации проекта и еще более порочный принцип по отношению к ожиданиям клиента.
При гибкой разработке необходимость в чудесах такого рода отпадает, так как вы собираетесь работать с клиентами открыто и честно с самого начала – рассказываете, что предстоит сделать, и позволяете принимать осознанные решения о функционале программы, финансировании и сроках.
Все дело в выборе. Можете продолжать веровать в миф о том, что все раз – и получится. Или можно разработать вместе с клиентом такой план, в который поверите и вы и он.
1.3. Сделано – значит сделано
Допустим, ваши дедушка с бабушкой за небольшое вознаграждение попросили соседского сына-подростка сгрести граблями опавшие листья во дворе на даче, сложить в мешок и отнести в лес. Сочтут ли дедушка с бабушкой работу выполненной, если парень сделает что-то из следующего:
? составит отчет о том, как он спланировал работу с граблями;
? предложит элегантный метод работы;
? составит тщательный и полный план тестирования?
Ничего подобного! Парень не получит ни копейки, пока не уберет листья, не уложит их в мешок и не отнесет куда следует.
При гибкой разработке применяется тот же принцип. В данном случае под реализацией функции понимается решение всех задач, необходимых для получения готового к работе кода.
Анализ, проектирование, написание кода, тестирование, разработка и дизайн уровня взаимодействия с пользователем (и проверка удобства этого уровня) – здесь перечислено все. Это не означает, что уже в первой версии программы у нас будут готовы все прибамбасы или что в конце каждой итерации у нас будет получаться готовый продукт. Но мы собираемся к этому стремиться.
Если с продуктом нельзя работать на практике – это означает, что он не готов. И именно поэтому разработчик, исповедующий гибкую методологию, должен серьезно к ней относиться и понимать три простые истины.
1.4. Три простые истины
Далее описаны три простые истины, действующие при руководстве проектами. Если руководствоваться ими, удается справиться со значительной долей нервозности и сбоев, с которыми регулярно приходится сталкиваться в софтверных проектах.
Принимая первую истину, мы перестаем бояться предстоящего проекта, который еще не известен нам во всех деталях. Мы понимаем, что требования еще предстоит разузнать и что работу вполне можно начинать еще до окончания сбора всей информации.
Осознавая вторую истину, мы перестаем бояться перемен или избегать их. Мы знаем, что рано или поздно они наступят. Принимаем их такими, какие они есть. И при необходимости корректируем наши планы в соответствии с ними.
Наконец, соглашаясь с третьей истиной, мы уже не драматизируем, если не успеваем сделать все запланированное в установленные сроки и испытываем недостаток ресурсов. Это нормальное состояние для любого интересного проекта. Вы делаете единственную вещь, которую можете сделать, – устанавливаете приоритеты, выполняете самую важную работу в первую очередь, а менее важную оставляете на потом.
Усвоив три эти простые истины управления проектами, вы увидите, что львиная доля стресса и волнений, традиционно связанных с написанием программ, куда-то исчезает. Вы сможете думать и изобретать с такой степенью сосредоточенности и ясности, какой не может похвастаться практически никакая другая область промышленности.
И не забывайте…
Путей всегда много!
Как и мороженое, гибкая разработка может иметь разные оттенки вкуса.
? У вас есть скрам (Scrum) – этот метод управления охватывает гибкий проект как оболочка.
? У вас есть экстремальное программирование (Extreme Programming, XP) – требующие высокой дисциплины основные практики разработки программ, жизненно важные для любого гибкого проекта.
? У вас есть бережливая разработка (Lean) – сверхэффективный аналог производственной системы, нацеленный на постоянную оптимизацию рабочего процесса (такая философия принята в компании «Тойота»).
А потом у вас появляется собственный гибкий метод. Например, такой метод может пригодиться для поиска выхода из ситуации, когда вы проехали со своей семьей на машине пару тысяч километров и обнаружили, что парк развлечений, в который вы направлялись, закрыт на ремонт.
Эта книга, как и вся остальная литература по гибкой разработке, – обычный обмен опытом. В ней рассказано о методах, которые я и другие авторы подобных книг нашли полезными при работе с клиентами. В данном издании я буду делиться с вами находками и инновациями, относящимися ко всем направлениям гибкой разработки, а несколько подобных методов нам придется изобрести самостоятельно. Читайте, изучайте, ставьте перед собой задачи и берите от книги именно то, что вам требуется.
Но учитывайте, что ни одна книга или метод не дадут вам ответов на все вопросы – в любом случае что-то придется додумывать самостоятельно. Каждый проект особенный, и хотя определенные принципы и практики будут действовать всегда[2 - http://agilemanifesto.org.], именно от вашей уникальной ситуации и контекста работы будут зависеть тонкости их применения.
Несколько слов о терминологии
В большинстве гибких методологий термины уже в основном устоялись, но некоторые понятия по-разному называются в скраме и экстремальном программировании.
В книге я постараюсь соблюдать единство терминологии (вообще, мне ближе экстремальное программирование), но хочу оговориться, что следующие понятия равнозначны и являются синонимами:
? итерация (iteration) – то же, что и спринт (sprint);
? журнал пожеланий (master story list) – то же, что и бэклог (product back log);
? клиент (customer) – то же, что и владелец (product owner)[3 - «Владелец» – термин условный. Обычно так называют заказчика или его представителя, который определяет требования к продукту. В agile-команде эту роль может исполнять менеджер проекта, бизнес-аналитик или клиент. – Примеч. ред.].
Что дальше?
Итак, мы познакомились с основами. Теперь пришло время включить вторую передачу и поговорить о том, что такое команда.
В следующей главе, которая рассказывает о командах гибких разработчиков, мы рассмотрим, как должна быть построена такая команда, как она должна работать над проектом, а также о некоторых вещах, которые каждый член команды должен уяснить до начала проекта.
Глава 2
Знакомство с командой разработчиков
Команда разработчиков при гибком методе работы – это нечто совершенно особенное. В типичном гибком проекте нет жестко заданных ролей. Все могут делать что угодно. И все же при всем хаосе, кажущейся неразберихе и отсутствии формальной иерархии отлаженным командам гибких разработчиков как-то удается регулярно создавать классные программы.
В этой главе будет подробно рассмотрено, что обеспечивает работу гибкой команды. Мы изучим характеристики хороших команд, построенных по такому принципу, различия между гибкими командами, а также обсудим несколько рекомендаций, упрощающих поиск квалифицированных сотрудников.
К концу главы вы будете представлять, как выглядит типичная гибкая команда, как самому собрать такую команду и чему эти люди должны научиться, прежде чем ринуться в бой.
2.1. Что особенного в проектах, связанных с гибкой разработкой
Прежде чем перейти к описанию тонкостей работы гибкой команды, нужно прояснить некоторые общие моменты, касающиеся гибких проектов в целом.
Первым делом отмечу, что в гибких проектах границы между ролями действительно размыты. Когда все идет хорошо, у человека, вливающегося в гибкую команду, возникает ощущение, что вся компания работает над маленьким стартапом. Люди принимаются за все сразу и делают все, что может приблизить проект к цели, – независимо от роли или должности конкретного участника.
Разумеется, у всех сохраняются основные обязанности и люди обычно занимаются тем, в чем они особенно хороши. Но в гибком проекте такие узкоспециальные роли, как аналитик, программист и тестировщик, на самом деле не существуют – как минимум не существуют в традиционном понимании этих ролей.
Вторая деталь, специфичная для гибких команд, заключается в том, что анализ, проектирование, написание кода и тестирование идут постоянно, то есть не прекращаются.
Это означает, что все этапы работы перестают изолироваться друг от друга. Люди, выполняющие работу, должны быть объединены в единое целое и вместе ежедневно заниматься проектом.
Третий аспект, который нужно прояснить заранее, – насколько важна для гибкости работы такая концепция одной команды и командной ответственности.
Качество выполнения гибкого проекта от начала до конца – задача всей команды. Отдела обеспечения качества (Quality Assurance, QA) нет, качество обеспечиваете вы сами, когда проводите анализ, пишете код или управляете проектом. Качество гарантируется на каждом шагу, поэтому в гибком проекте вы не услышите вопроса: «И как отдел гарантии качества проморгал эту ошибку?»
Итак, размытие ролей, постоянное сосредоточение на разработке и ответственность всей команды за все этапы проекта – вот что наверняка встретится вам при работе с гибкими командами.
Теперь давайте рассмотрим некоторые типичные дела, которыми занимаются гибкие команды. Это поможет нам самим успешно набирать такие команды.
2.2. Принципы действия гибкой команды
Прежде чем вы со своей командой начнете добиваться успеха, придется побороться за некоторые вещи, а также заточить команду для этих успехов.
Совместное размещение рабочих мест
Есть одна вещь, которая помогает радикально увеличить КПД вашей команды, – все должны работать в одном месте.
Команды, члены которых работают рядом, действительно показывают более высокие результаты. Ответы на вопросы находятся быстро. Проблемы решаются сразу же после их появления. Уменьшается количество трений между различными звеньями. Люди быстрее начинают доверять друг другу. С такой маленькой командой, работающей как единый организм, очень сложно соперничать.
Итак, если команды, работающие в одном помещении, так хороши, означает ли это, что удаленная команда не сможет выполнять гибкие проекты? Конечно, сможет.
Работа в удаленной команде стала для многих специалистов образом жизни. И хотя плотно сбитая, работающая в одном офисе команда всегда будет иметь некоторую фору перед удаленной, есть секреты, помогающие минимизировать это преимущество.
Например, в самом начале реализации проекта можно выделить определенный бюджет на то, чтобы собирать разработчиков вместе. Даже если такая встреча продлится всего несколько дней (еще лучше, если удастся поработать в таком режиме пару недель), время, потраченное на знакомство друг с другом, привыкание к юмору коллег и совместные обеды, чрезвычайно помогает превратить разношерстную команду в крепкий, высокопроизводительный коллектив. Итак, постарайтесь для начала собрать всех вместе.
В конце концов, в вашем распоряжении масса технических средств (Skype, видеоконференции, социальные сети), помогающих превратить удаленную команду в группу, не уступающую по производительности работникам из маленького офиса.
Привлечение клиентов
В наше время все еще существует масса программ, которые пишутся командами разработчиков совершенно без участия клиентов. Это прискорбно и просто преступно.
Как у команды может получиться выдающийся, инновационный продукт, если сами люди, для которых он пишется, не участвуют в работе?
Заинтересованный клиент не пропускает презентаций, задает вопросы, реагирует на ход работы, направляет разработку и делится идеями, помогающими команде сделать нечто неординарное. Такие клиенты становятся ключевыми членами команды и полноправными коллегами разработчиков.
Стимулируйте незапланированное сотрудничество
В книге о компании «Пиксар» (The Pixar Touch) Стив Джобс рассказывает, как сильно успех фильмов этой компании зависел от незапланированного сотрудничества. После выпуска фильма «История игрушек-2» (Toy Story II), который чуть не поставил всю компанию на грань банкротства, руководство осознало, что сотрудники оказались слишком разобщены, изолированы друг от друга. Все могло закончиться крахом, если бы не собрали всех участников работы над фильмом вместе.
Именно для этого студия «Пиксар» приобрела участок 20 акров в Эмеривилле, штат Калифорния, и собрала всех сотрудников под одной крышей. Результат последовал незамедлительно. Контакты наладились, сотрудничество оптимизировалось, и коллеги смогли выпускать крупный фильм каждый год.
Вот почему гибкие методы (например, экстремальное программирование и скрам) предлагают бороться за участие клиента в работе. Это выражается в выделении особой роли «заказчик в команде» (on-site customer) и в существовании в скраме специальной роли «владелец продукта» (product owner). Это очень важная работа. Подробнее все роли мы обсудим чуть позже.
Следующий принцип также проясняет, почему любой успешный гибкий проект требует участия клиента.
Вы можете спросить: «А что делать, если мой клиент не хочет участвовать в работе?» Возможно, клиент просто не может идти в ногу со временем или ему не особенно нужен этот проект, а быть может, он просто не считает, что вы движетесь к цели.
Какой бы ни была причина, вы должны завоевать определенное доверие клиента, это обязательно.
В следующий раз при встрече с клиентом скажите ему, что через две недели окончательно разберетесь с какой-то его проблемой.
Не просите разрешения. Не делайте из этого особенной церемонии. Просто возьмите какую-нибудь проблему или досадную помеху и покончите с ней.
Затем сделайте так. Встретьтесь с клиентом через две недели, докажите ему, что проблема полностью исчерпана, и проделайте такую же операцию снова. Найдите другую проблему и заставьте ее исчезнуть.
Возможно, вам придется поступить так два или три раза, а то и больше, чтобы клиент стал интересоваться текущими проблемами. Просто знайте, что рано или поздно такой интерес придет.
Клиент начинает смотреть на вас иначе и понимать, кто вы такой: толковый специалист, с которым нужно считаться, чтобы дело спорилось.
Понимаете, может быть тысяча причин, по которым ваш клиент не участвует в работе. Вероятно, он устал от проектов, выполняемых в IT-отделе, или эта программа для него не так важна. Не исключено, что вы недостаточно подробно рассказали ему о том, как важна именно его роль для успеха всего проекта. А быть может, клиент на самом деле очень занят.
Я пытаюсь сказать, что, если вам нужно завоевать определенное доверие, начните понемногу наращивать его, и в итоге вы добьетесь своего.
Самоорганизация
Гибкая команда предпочитает, чтобы перед ней поставили цель, а затем не мешали всей команде разработать способ ее оптимального достижения. Для этого гибкая команда должна быть самоорганизующейся системой.
Самоорганизация заключается в том, что при необходимости нужно переступить через свое эго и вместе с командой понять, как вы, будучи командой (со всеми вашими индивидуальными навыками, пристрастиями и талантами), сможете выполнить конкретный проект максимально качественно.
«Разумеется, Бобби хорошо клепает код. Но у него еще особый талант к проектированию, он поможет нам сделать некоторые макеты».
«Да, Сьюзи – одна из лучших наших тестировщиц, но ее настоящий конек – выстраивание перед клиентом перспектив работы. У нее это отлично получается, и ей нравится это делать».
Это не означает, что разработчик должен быть экспертом по визуальному дизайну, а тестировщики – брать на себя управление проектом.
Скорее это признание того, что для создания оптимальной команды нужно исповедовать принцип «роль для человека, а не человек для роли».
Итак, как добиться самоорганизации своей команды?
? Команда допускается к планированию, оцениванию и может распоряжаться проектом.
? Вы не придаете особого значения ролям и их названиям, а сосредотачиваетесь на бесперебойном производстве функциональных, протестированных программ.
? Вы ищете людей, способных брать на себя инициативу, то есть тех, кто сам прокладывает себе путь, а не сидит и не дожидается остальных.
Короче, вы отпускаете вожжи и позволяете сотрудникам самостоятельно делать свою работу.
Теперь необходимо отметить, что самоорганизация как таковая, конечно же, очень хороша, но вся соль в том, к чему она приводит, – в расширении возможностей и индивидуальной ответственности.
Ответственная и полноправная
Хорошая гибкая команда всегда стремится отвечать за результаты своей работы. Эти люди знают, что клиент полагается на них и понимает, что без такой команды не обойтись. Поэтому члены гибкой команды никогда не увиливают от ответственности, которая неотделима от стремления достигать новых результатов с самого первого дня.
Разумеется, индивидуальная ответственность развивается только в командах, наделенных реальной полнотой полномочий. Давая команде право самостоятельно принимать решения и делать то, что она считает нужным, вы освобождаете пространство для инициативы и работы по собственному усмотрению. Люди начинают решать проблемы, не дожидаясь, пока им позволят это сделать.
На данном этапе никто не застрахован от ошибок. Но поверьте, игра стоит свеч.
Конечно, создать ответственную и полноправную команду сложнее, чем просто сказать об этом. Не каждый готов к свободе действий. Зачем напрягаться, если можно просто прийти на работу, сесть и ждать, что тебе скажут.
