Текст книги "Постигая Agile"
Автор книги: Дженнифер Грин
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +12
сообщить о неприемлемом содержимом
Текущая страница: 3 (всего у книги 34 страниц) [доступный отрывок для чтения: 11 страниц]
Серебряной пули не существует
Сегодня мы знаем, что нет идеального способа создания программного обеспечения. Но в прошлом веке многие представители отрасли с этим бы не согласились. Существовало мнение, будто можно найти обладающий высокой эффективностью метод «серебряной пули», позволяющий разом решить все проблемы проекта. Казалось, что разработчики могут создавать программное обеспечение, просто следуя инструкциям или собирая программный продукт как на конвейере.
(По иронии судьбы одна из самых цитируемых работ в области программной инженерии – это эссе Фреда Брукса No Silver Bullet («Серебряной пули не существует», 1986). В нем он убедительно доказывает, что эта задача невыполнима. Что еще нужно, чтобы остановить бесплодные попытки найти загадочную панацею?)
Предлагалось большое количество радикальных способов, претендующих на звание «серебряной пули». Они, как правило, были двух видов: методология, дающая командам надежный способ создания программного обеспечения, или технология, которую программисты могли использовать для предотвращения или устранения ошибок. Идея состояла в том, что если компания приняла решение о выборе методологии и технологии, то вся команда должна была следовать им неукоснительно, поскольку только в этом случае можно создавать отличное ПО.
Дэн и Брюс не понаслышке знают, что все это иллюзии, потому что на протяжении многих лет управляли проектами, хватаясь за разные методики и технологии, не получая при этом каких-либо реальных улучшений. Попытки компании найти серебряную пулю для процесса программной разработки, как правило, заканчивались печально для всех участников. Но хуже всех приходилось Брюсу и Дэну, потому что им насильно предлагалось следовать за вечно меняющимися процессами.
Джоанна тоже сталкивалась с этим. На предыдущей работе она регулярно выдвигала множество жестких требований и давала массу распоряжений, чтобы придумать план разработки программного обеспечения. Команды приступали к буквальному выполнению ее плана. Однако они были обречены на создание негодного и бесполезного ПО. Пользователь получал устаревший продукт, не успев им воспользоваться.
Правда, некоторым командам, с которыми работала Джоанна, удавалось выпускать отличное программное обеспечение на основе водопадного процесса (или подобного ему) со сложной в разработке предварительной документацией. Она руководила рядом лучших проектов разработки ПО для медицинских устройств, в которых применялся водопадный подход.
Водопад действительно бывает полезен. Если вы хорошо знаете, что необходимо вам прежде всего, и первым делом создаете именно это, то получаете довольно эффективный способ создания ПО. Проекты создания программного обеспечения для медицинских устройств, которыми руководила Джоанна, – это тот редкий случай, когда требования к программе действительно писались в самом начале работы и в ходе проекта практически не было изменений.
Но для запуска успешного водопадного проекта требуется нечто большее, чем просто стандартные требования, отсутствие которых создает так много проблем. Команды, разрабатывающие прекрасное ПО при помощи водопадного подхода, как правило, имеют несколько общих характеристик. Это:
• хорошая коммуникация, потому что успешные команды, уполномоченные компанией вести водопадную разработку, постоянно поддерживают контакт со своими пользователями, менеджерами и руководителями на протяжении всего проекта;
• хорошие методики, особенно такие как анализ кода и автоматизированное тестирование, которые направлены на поиск ошибок на раннем этапе. Обычно это называется «предотвращение дефектов» и необходимо команде, чтобы прежде всего понять, как эти ошибки попали в код;
• ящики, полные документации, которые редко открываются, потому что люди в команде понимают, что сам факт написания плана и вопросы, которые возникают во время планирования, – это важнее, чем слепое следование этому плану.
Есть еще одна сторона общей картины. Дэн начал свою карьеру после революционного переворота 1990-х годов в области инструментов разработки ПО и технологий, поэтому он трудился только в командах, которые использовали объектно-ориентированную разработку для создания лучших образцов программного обеспечения. Системы контроля версий, автоматическое тестирование, лучшие интегрированные среды разработки (integrated development environments, IDEs), которые включают в себя функции для автоматизации программирования, такие как рефакторинг и проектирование классов, и другие революционные средства, помогали Дэну сохранить контроль над кодом. У Брюса опыт взаимодействия с проектами гораздо длительнее, чем у Дэна, он наблюдал разные команды разработчиков, которые часто использовали программные средства для автоматизации рутинных и повторяющихся задач.
Брюс и Дэн знают по опыту собственных проектов, что наиболее успешные люди эффективно используют такие методы, инструменты и идеи. Это позволяет им выделять больше времени на контакты с пользователями и партнерами, а также думать о проблемах, которые приходилось решать вместо того, чтобы трудиться над кодом.
И оказалось, что водопадные проекты эффективны в тех случаях, когда их команды принимают многие ценности, принципы и практики, которые характерны для agile-проектов. Проекты, которые выполняются с использованием отдельных гибких методов и практик (а это нельзя считать настоящим следованием ценностям и принципам Agile), в итоге нередко сталкиваются с теми же проблемами, которые преследуют водопадные проекты.
К сожалению, Брюс, Дэн и Джоанна сумеют убедиться в этом лишь на собственном горьком опыте.
Ключевые моменты
Водопадный подход требует от команды полного описания программного обеспечения в начале проекта, а затем точного создания того, что было описано.
Водопадный подход затрудняет возможность реагировать на изменения из-за сосредоточения внимания на документах, а не на сотрудничестве.
Серебряной пули, или практики, которая помогает создавать безупречные проекты, не существует.
Команды, использующие водопадный подход, делают это путем принятия эффективных методов и принципов создания ПО, особенно таких, которые улучшают коммуникацию.
Agile для спасения! (Правильно?)
Вы, наверное, знаете, на что похож водопадный подход, даже если впервые столкнулись с термином «водопад»[8]8
Если вы менеджер проекта и готовились к экзамену PMP, то уже все знаете о водопадном подходе. Сертификация PMP охватывает не только программное обеспечение, но и множество методологий в различных отраслях промышленности. Хорошо иметь полный набор чертежей при строительстве небоскреба или моста, даже если эти документы меняются.
[Закрыть]. Джоанна, Брюс и Дэн тоже знают. Прежде чем приступить к планированию музыкального автомата, они говорили о том, каким образом водопадные процессы вызывали проблемы у их команд в прошлом.
Над последним проектом вместе с Брюсом и Дэном работал Том, менеджер по работе с клиентами. Он провел много времени в разъездах, помогая заказчикам в торговых галереях, казино, барах и ресторанах устанавливать и использовать разработанное для них ПО. Втроем они потратили несколько недель на создание спецификации для нового игрового автомата.
Том провел в офисе лишь половину из того времени, которое отвели ему Брюс и Дэн, чтобы начать проектирование программного обеспечения и планирование архитектуры. Как только все трое согласовали требования, они назначили встречу с CEO и топ-менеджерами компании, чтобы ознакомить их с требованиями, внести необходимые изменения и получить разрешение на начало разработки.
К этому моменту Том вернулся к работе с клиентами, переложив ответственность за проект на Брюса и Дэна. Они разбили проект на задачи, разделили их между членами команды, и все начали писать программное обеспечение. Когда команда практически закончила создание ПО, Том собрал группу бизнес-пользователей, менеджеров проектов и руководителей, чтобы продемонстрировать им почти готовую программу для слот-машины «Боец по выходным».
Но все прошло не так гладко, как ожидалось.
Во время демонстрации программы состоялся неприятный разговор с CEO[9]9
Chief Executive Officer – главное должностное лицо компании, аналог генерального директора в российской иерархии. Прим. ред.
[Закрыть]. Он сказал: «Программа выглядит замечательно, но разве не предполагалось, что она будет иметь режим видеопокера?» Это было неожиданное заявление. Судя по всему, директор был уверен, что они работают над программным обеспечением, которое может быть развернуто на базе либо игрового автомата, либо оборудования для видеоигры в покер. Состоялся напряженный разговор между топ-менеджерами, советом директоров и двумя крупными заказчиками. Жаль, что никто не потрудился передать команде детали разговора.
Конечно, если бы Дэн узнал об этом раньше, было бы легко изменить направление работы над проектом. Но теперь придется вырывать огромные куски из кода, который они уже написали, и заменять их на модернизированные части кода для видеопокера. Они потратили недели на устранение фатальных ошибок, вызванных проблемами интеграции. Дэн провел много бессонных ночей, объясняя Брюсу, что все это было абсолютно предсказуемо, потому что так бывает всегда, когда код создается для одних целей, а потом его спешно переориентируют. Теперь же ему предстоит увязнуть в распутывании спагетти-кода. Будет трудно поддерживать существующий базовый код, кроме того, команда разочарована, потому что это явно ошибочный путь.
Но в сложной ситуации оказались не только Дэн и Брюс. Менеджер проекта, руководивший им, был настолько расстроен случившимся, что покинул компанию. Он доверял тому, как команда характеризовала текущее состояние дел, но они были полностью обесценены изменениями. Команда понятия не имела, что им придется столкнуться с неожиданной сменой оборудования, и это не сделало жизнь руководителя проекта легче. Несмотря на то что ситуация изменилась, срок сдачи остался прежним. К моменту завершения проекта план устарел и стал бесполезен, однако менеджер проекта продолжал нести за него ответственность. После того как руководство раскритиковало его в пух и прах, он смог оправдаться лишь отсутствием в его команде хороших игроков. Затем он покинул компанию, и на его место взяли Джоанну.
Но сильнее всех был расстроен Том, потому что ему единственному пришлось работать с клиентами, когда они столкнулись с проблемами. Самый крупный клиент этого продукта – казино Little Rock в Лас-Вегасе – хотел настроить все свои игровые автоматы так, чтобы они соответствовали тематике игр, установленных в автоматах в городах штата Арканзас. Заказчик просил создать новую функцию, позволяющую менять игры между сменами, не перемещая игровые терминалы. Их инженеры то и дело натыкались на ошибки в программе, разработанной командой Брюса, поэтому Тому и Дэну приходилось неделями вести телефонные переговоры с инженерами, чтобы придумывать заплатки и временные решения. Little Rock не отменила контракта, но их следующий большой заказ перешел к конкуренту. Не секрет, что директора и менеджеры винят за потерю бизнеса проект Slot-o-matic Weekend Warrior.
В конце концов все узнали, что проект пошел не так. И каждый считал, что виноват кто-то другой. Казалось, никто понятия не имеет, как исправить эти повторяющиеся проблемы. И ПО, которое они поставляли, по-прежнему было недостаточно хорошо организованным.
Использование Agile влечет изменения
Брюс, Дэн и Джоанна пригласили Тома на обед. После разговора о прошлых проблемных проектах Джоанна предположила, что настало время попробовать agile-методологии.
Как и многие начинающие свое движение к Agile, они приступили к делу с дискуссии о том, что значит для них само это слово. Брюс сослался на сферу agile-разработки: специализированные книги, практики, тренинги, блоги и людей, практикующих Agile. Для Джоанны понятие Agile означало «способность проекта изменяться», основной набор методов, сосредоточенных на достижении цели. Дэн думал, что в рамках Agile не надо писать документацию, а нужно просто погружаться в код. Том понятия не имел, о чем они говорят, но был счастлив узнать массу способов избежать того, что случилось в прошлый раз.
«Стартующие в Agile» обычно начинают знакомиться с гибкими методами, практиками и идеями, и эта команда не была исключением. Дэн присоединился к ресурсу Agile Alliance и начал налаживать связи с другими agile-практиками. Брюс и Джоанна принялись читать блоги и книги о гибкой разработке и управлении проектами. Они познакомились с замечательными идеями и взялись воплощать их в жизнь, чтобы таким путем прогнозировать и устранять проблемы в своих проектах. Каждый из них обнаружил много полезного и сразу же начал пополнять этим свой арсенал.
Дэн уже писал автоматизированные модульные тесты для своих предыдущих проектов, но многие разработчики музыкальных автоматов никогда не делали этого. Он начал сотрудничать с разработчиками, чтобы организовать модульное тестирование и разработку через тестирование. Создал автоматизированный сборочный скрипт и настроил сервер сборки для проверки кода, создания программного обеспечения и проведения тестирования раз в час. И это сработало! Программисты сразу же увидели улучшение в их коде. Каждый день разработчик находил ошибку, которую никогда не выявил бы без автоматических тестов, и было ясно, что удалось избежать недельных отладок и отслеживания неприятных проблем в этой области. Мало того что стало меньше ошибок, облегчилась и процедура изменения кода, который пишут разработчики.
(Ничего страшного, если вы не знаете всех этих методов, включая разработку через тестирование. Вы познакомитесь с ними в нашей книге, мы будем выделять новые практики жирным шрифтом, чтобы их было проще обнаружить.)
Джоанна прошла обучение Scrum, и команда решила называть ее scrum-мастер (хотя во время обучения она узнала о большой разнице между понятиями «scrum-мастер» и «руководитель проекта» и вовсе не была уверена, что роль, которую она играет в проекте, действительно заслуживает названия «scrum-мастер»). Она помогает команде разбивать проект на итерации, отслеживая прогресс на доске задач и используя скорость работы команды и графики сгорания (линейные графики, которые позволяют ежедневно отслеживать объем выполняемой работы, «сжигание» ее до нуля, когда работа выполнена полностью), чтобы держать всех в курсе. Впервые команда действительно заинтересовалась тем, чем занят менеджер проекта, и это способствовало продвижению в работе.
Том тоже хотел пройти обучение Agile. Дэн, Брюс и Джоанна начали называть его владельцем продукта, и Том принялся писать пользовательские истории для команды, чтобы она лучше представляла свою задачу. Он работал с ними ради создания планов релизов, основанных на историях, и теперь чувствовал, что напрямую контролирует то, что будет создавать команда.
Но главное – Брюс начал проводить ежедневные митинги с Джоанной, Дэном и всеми программистами. Том тоже посещал их. Сначала не все удавалось, но к моменту, когда проект набрал обороты, никто не испытывал дискомфорта и все давали друг другу объективную оценку того, как продвигается их общее дело. Брюс убедил команду проводить совместную ретроспективу в конце каждой итерации и был рад, что коллеги действительно пытаются осуществить улучшения, о которых говорили в ходе ретроспективы.
«Лучше-чем-ничего» как результат
Все удавалось. Команда продвинулась, проект становился все лучше и лучше, но… до определенного момента.
За счет «внедрения Agile» все добились улучшений на своем рабочем месте. Дэн и разработчики начали развивать навыки и тщательнее писать код. Джоанна имела точное представление о том, в каком состоянии находится проект в каждый отдельный момент времени. Том гораздо больше общался с командой, и это давало возможность тщательнее контролировать программное обеспечение, которое они создавали, и, следовательно, максимально удовлетворять запросы клиентов. Брюс смог сосредоточиться на улучшении навыков своей команды и коммуникации.
Но действительно ли команда стала гибкой?
Они переняли немало хороших практик. Многие из этих методов были улучшенными версиями прежних, и все вместе они помогли каждому члену команды стать продуктивнее. В этом, несомненно, было продвижение.
Но наряду с тем, что команда становилась счастливее, а проект «Музыкальный автомат» действительно продвигался лучше, чем любой из предыдущих, у них все же остались опасения в отношении того нового, более гибкого мира, обитателями которого они оказались. Дэн, например, считал, что команда определенно создает код лучше, чем раньше, но приходится идти на отступления от технологий, чтобы уложиться в срок.
Джоанна довольна, что контролирует ход выполнения проекта. Но из-за того, что его приходится разбивать на короткие итерации, она чувствует себя некомфортно. Отказавшись от возможности использовать полный график проекта как дорожную карту, она обнаружила, что оказывается во все большей зависимости от команды, которая посвящает ее в текущую ситуацию во время ежедневных митингов. Эти встречи полезны, но на них в основном озвучивается статус каждого члена команды, а Джоанна лишь послушно все записывает, чтобы довести информацию до заинтересованных сторон. Она начала чувствовать себя простым координатором, а не менеджером, управляющим проектом. Теперь она фокусируется на статусе, что затрудняет выявление и устранение препятствий. Команда лучше реагирует на изменения, но это ставит Джоанну в неловкое положение, потому что все ее внимание теперь обращено на реагирование, а не на планирование.
Теперь Том – владелец продукта, и он в восторге от возможности определять, над чем стоит работать команде. Но он разрывается на части, потому что чувствует: команде нужно, чтобы он работал с ней полный день. Он должен принимать участие в ежедневных встречах и постоянно отвечать разработчикам, интересующимся деталями программы, которую они пишут. Иногда они спрашивают о том, чего он не знает, а порой он хочет, чтобы они ответили на эти вопросы сами. Ему и так есть чем заняться, но он чувствует, что остальные члены команды, дойдя до середины пути, готовы переложить всю ответственность за создание столь важного продукта именно на его плечи. А у него нет ответов на все вопросы.
В конце концов, его основная должность – менеджер по работе с клиентами. Ведь музыкальные автоматы не продают сами себя. Как можно вести отчетность и оставаться в курсе потребностей пользователей, если все его время уходит на ответы программистам?
Брюс рад, что команда работает продуктивнее. Но когда он внимательнее всматривается в происходящее, что-то кажется ему неправильным, но он не может понять, что именно. Очевидно, что это является улучшением, учитывая, что большинство его предыдущих проектов были на волосок от провала. По мнению Брюса, использование Agile сделало ситуацию лучше, уменьшило необходимость личного героизма, сократило количество работы по ночам и в выходные дни. Но он также чувствует, что появились новые проблемы.
Нередко члены команды и особенно ее руководитель испытывают то же самое, что и Брюс: некоторое разочарование после первой попытки применения Agile. Блоги и книги, которые они читали, и то, что они слышали во время обучения, обещали «поразительные результаты» и «гиперпродуктивные команды». Команда ощущает, что проект создания музыкального автомата – это улучшенная версия предыдущих проектов. Но, безусловно, и речи нет о гиперпродуктивности или поразительных результатах.
Сложилось общее мнение, что проект прошел путь от неконструктивной стадии к конструктивной – и это очень хорошо. Получилось то, что мы называем «лучше-чем-ничего». Но действительно ли суть Agile заключается в этом?
Раздробленное видение
Команды сталкиваются с проблемами с тех пор, как начали создавать ПО. Еще в 1960-х годах специалисты открыто говорили о том, что разработка программного обеспечения фактически разрушена. Они использовали термин кризис программного обеспечения, который был придуман на конференции для разработчиков НАТО в 1968 году вместе с другим термином – разработка программного обеспечения[10]10
Питер Наур и Брайан Рэнделл. «Разработка программного обеспечения: доклад о работе конференции под эгидой Научного комитета НАТО», Гармиш-Партенкирхен (Германия), 7–11 октября 1968 года (Брюссель. Отдел по научным вопросам, НАТО, 1969), 231.
[Закрыть]. «Кризис программного обеспечения» говорит о состоянии разработки софта в типичной компании 1970–1980-х годов, когда серьезные (знакомые и сейчас) проблемы были очень распространены, что приводило к провалу множества проектов. Со временем наша индустрия начала понимать основные источники кризиса ПО. Важной вехой стала публикация в 1970 году статьи Уинстона Ройса, инженера компании Lockheed, в которой описывалась крайне популярная, но неэффективная модель разработки ПО. В начале 1980-х этот метод был широко известен как водопадный подход. Потребовалось еще 10–20 лет, прежде чем многие команды, добивавшиеся успеха в прошлом, перестали слепо доверять ему. Многие команды обнаружили, что agile-методы могут решить проблемы, типичные для водопадного подхода, но одновременно выяснилось, что это не так просто, как кажется.
Разработчики используют программные средства каждый день, чтобы построить свой код. Специалист, владеющий несколькими инструментами, всегда более востребован, чем тот, кто знает меньше. Поэтому многие профессионалы, впервые сталкиваясь с Agile, сразу же воспринимают его как совокупность средств, способов и методов. Практически любой разработчик, начавший работу с Agile, в течение нескольких месяцев обновляет свое резюме, чтобы включить в него новую практику. Это первое впечатление от Agile – хороший признак, потому что оно помогает сделать agile-методы привлекательными и вызывает интерес.
Но видя в Agile лишь инструменты, технологии и методы, вы делаете только первый шаг на пути к «переходу к гибким технологиям» – и это создает проблемный побочный эффект. Взгляните на ситуацию с точки зрения Дэна. Как разработчик и архитектор он будет концентрироваться на том, что непосредственно влияет на развитие: методах, которые помогают ему улучшить код путем устранения или предотвращения ошибок, инструментах, позволяющих выполнять сборку быстрее и проще, и практиках, улучшающих способы разработки, проверки и сборки кода.
Джоанна как руководитель проекта прежде всего заботится о затратах на создание ПО и качестве результатов. То есть она будет концентрироваться на инструментах, которые помогут ей понять проект, наладить коммуникации, составить сметы и оценить усилия. Бизнес-пользователь, например Том, как правило, заинтересован, чтобы ПО обслуживало бизнес и было привлекательно для различных методов, помогающих команде правильно понимать то, чего хотят пользователи, поэтому ПО, которое они создают, имеет ценность. А руководитель команды, например Брюс, хочет убедиться, что все в команде движутся в одном направлении, коммуникации налажены и происходит обучение на собственном опыте. Они ищут инструменты, которые помогут в этом.
В частности, один из agile-подходов – пользовательская история – это способ выразить конкретную потребность пользователя. Она, как правило, записывается в виде нескольких предложений, часто на карточках, иногда в строго определенном формате, но порой и в свободной форме. Например, одна пользовательская история из проекта «Музыкальный автомат» звучит так: «В качестве постоянного посетителя этого бара я хочу иметь возможность проигрывать новый хит, который был выпущен сегодня».
Каждый человек в команде судит о пользовательской истории по-своему.
• Джоанна, менеджер проекта, которая пытается стать scrum-мастером, рассматривает пользовательскую историю как работу, которую нужно сделать, аккуратно упаковать и приготовить к сборке. Она записала каждую историю на карточку и прикрепила их к доске, чтобы держать все под контролем.
• Дэн, ведущий разработчик и архитектор, видит эту историю как небольшую часть всего функционала, написанную в доступной для понимания форме. Он может разбить историю на задачи, создать учетную карточку для каждой из них и написать свое имя, когда начнет с ними работать. Когда он закончит с разработкой, то переместит их в ту часть доски, где располагаются выполненные задачи.
• Том, владелец продукта, считает пользовательскую историю ценностью, которая будет предоставлена компании, потому что это позволяет ему видеть связь между тем, что создает его команда, и тем, что пользователи будут делать с уже разработанным ПО. Пользовательские истории помогают ему разговаривать с клиентами, чьими счетами он управляет. Именно благодаря им он способен понять, чего ждут клиенты от программного обеспечения для музыкальных автоматов, и гарантирует, что каждая история представляет собой то, что на самом деле нужно пользователю.
• Брюс, руководитель команды, рассматривает пользовательскую историю как конкретную цель, вокруг которой можно организовать команду. Он помогает выстраивать истории в порядке приоритетности и использует прогресс для поддержания мотивации команды.
Добавление пользовательских историй к такой команде, как эта, поможет улучшить способ разработки ПО, потому что каждый из четырех участников увидит, что история полезна лично ему.
Но это может сработать и против команды. В прошлых проектах Дэн имел подробную спецификацию, что оставляло мало места для маневра, теперь же он получил свободу принимать решения. Это хорошая практика, но она способна вызвать некоторые проблемы. Когда Дэн написал код для пользовательской истории «новейший хит», он думал, что нужна функция, позволяющая постоянному посетителю бара проигрывать любую песню, как только она будет загружена на сервер. Но после ее демонстрации Тому в конце итерации возникла дискуссия. Том объяснил: новые песни в музыкальном автомате означают, что владельцы бара должны платить более высокое роялти. Он обсудил с ними все детали, позволяющие постоянным клиентам проигрывать последние хиты максимально часто, но все же не настолько, чтобы это привело к чрезмерным затратам. Дэн был очень расстроен. Это означало, что ему придется полностью переписать большую часть функций. А Тома возмущало, что первый выпуск программы не будет включать эту функцию.
Если бы Дэн понял, что пользовательская история была важна для Тома, чтобы показать, в чем нуждаются потребители, то он, возможно, обсудил бы с Томом, какое ПО необходимо, прежде чем приступить к программированию. И наоборот, если бы у Тома было время подробнее узнать о том, как Дэн собирается писать программное обеспечение на основе ограниченного знания пользовательской истории, то, возможно, он убедился бы, что разговор необходим в начале итерации. Но общения не было, и поэтому проект столкнулся с теми же проблемами, что и в прошлых водопадных проектах: разработчики делали неверные предположения, писали код, а потом меняли его. Хотя этого можно было избежать, ведь после изменений он становился более хрупким.
Если каждый человек думает только о своей роли, рассчитывая, что конкретный способ описания пользовательской истории поможет ему, и не следит за тем, как остальные члены команды используют данную историю либо другой agile-инструмент, технику или метод, это может привести именно к тем проблемам, с которыми столкнулись Дэн и Том. Мы называем это раздробленным видением, потому что у каждого человека свой взгляд на тот или иной agile-инструмент.
Теперь распрощаемся с командой разработчиков потокового музыкального автомата – мы больше не будем вспоминать о ней в этой книге. Смогут ли они преодолеть свои проблемы и закончить сборку программного обеспечения? Продолжив читать эту главу, вы, возможно, обнаружите идеи, которые могли бы им помочь.
Как раздробленное видение вызывает проблемы в проекте
Когда каждый член проектной команды смотрит на применяемые методы лишь со своей позиции, постоянно возникают старые проблемы. В годы кризиса программного обеспечения разработчики сразу погружаются в ПО, не тратя время на то, чтобы понять потребности пользователей. О новых требованиях они узнают в середине проекта и вынуждены удалять из программы часть кода, чтобы заменить его. Многие agile-методы направлены на формирование у команд четкого понимания потребностей заказчика с самого начала проекта, что помогает избежать больших объемов неэффективной работы. Но когда в команде не налажены коммуникации – например, разработчик создает код и «спихивает» его владельцу, не задумываясь об истинных потребностях клиента, – это может привести к однообразным проблемам, которые придется решать постоянно.
Что касается владельцев продуктов, их радует, что Agile дает возможность решать именно те задачи, которые нужны пользователям. Ведь до этого им приходилось констатировать, что контроль над проектом утерян, и лишь беспомощно наблюдать, как команда программистов собирает прошлогоднее ПО, потому что последний разговор с пользователями состоялся именно в прошлом году. Но владелец продукта будет по-прежнему разочарован, зная, что пишет пользовательские истории лишь для того, чтобы обнаружить: команда исполняет не совсем то, что он имел в виду. Команда считает, что владелец продукта ждет от нее угадывания его мыслей, а владелец, напротив, полагает, что эти люди хотят узурпировать все его время и постоянно слышать ответы на любые имеющиеся у них вопросы.
Такой же разрыв происходит и с другими ролями в проекте. Менеджеры проектов и лидеры команд счастливы, что разработчики взяли на себя создание структуры и конкретизацию целей. Они отмечают постепенные улучшения, но, к сожалению, не фундаментальные изменения в работе. Последние невозможны, если члены команды работают, соперничая друг с другом. Менеджер проекта, который видит пользовательские истории, приклеенные к доске в качестве прямой замены диаграммы Ганта в файле Microsoft Project, но продолжает по привычке «командовать и контролировать», будет часто реагировать на изменения в проекте, требуя от команды работать сверхурочно, чтобы не отставать от первоначального плана. Руководитель команды может занять жесткую позицию, ограждая сотрудников от дополнительных задач, пересматривая график с точки зрения сроков или сокращения объема работ. И менеджер проекта, и руководитель команды могут улучшать проект, но если бы они рассматривали перспективы с точки зрения друг друга, то могли бы избежать конфликта и при этом достичь хорошего результата.
Другими словами, когда не налажены коммуникации, каждый на своем месте может использовать новые инструменты (пользовательские истории), но придерживается старых установок, что вызывает трения в команде. Новые инструменты лучше, поэтому дела идут успешнее. Но члены команды действительно не чувствуют большой разницы, потому что возвращаются прежние конфликты. И тогда рождается недоумение: неужели это все, что может Agile?
Как показывает опыт, многие команды столкнулись с подобной проблемой при внедрении отдельных практик и получили закономерный результат – «лучше-чем-ничего». Компания VersionOne разрабатывает гибкие программные инструменты и способствует развитию agile-сообщества во многих областях. Но ее главная заслуга – публикуемые ежегодно State of Agile Development Survey. Результаты 2013 года[11]11
Последний отчет о состоянии вы можете найти на сайте stateofagile.versionone.com.
[Закрыть] демонстрируют, что многие команды добились улучшений, применяя agile-методологии.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
