Книги
Постигая Agile
Благодаря Agile наша отрасль оказалась на переломе своего развития. Agile из аутсайдера превратился в работающий институт. В течение первых лет существования этого метода принявшие его люди активно старались убедить свои компании и коллег, что Agile действительно приносит пользу и им стоит заниматься. В настоящее время практически не осталось сомнений, что agile-методологии – это эффективный способ создания программного обеспечения. В 2008 году было проведено исследование[7], которое показало, что более половины всех опрошенных команд, занимающихся разработкой программных продуктов, используют agile-методологии, практики или принципы. С тех пор актуальность Agile только выросла. Agile-команды все чаще задумываются не только над тем, как стать более гибкими, но и как распространить Agile в своих компаниях.
Но так было не всегда. Традиционно при выполнении проектов по разработке программных продуктов компании использовали водопадный подход, согласно которому команда вначале определяет требования к продукту, планирует проект в целом, разрабатывает программное решение, а затем создает код и тестирует продукт. Значительная часть программного обеспечения – как грандиозного, так и совсем бестолкового – годами создавалась именно таким образом. Однако на протяжении десятилетий различные команды во всевозможных компаниях сталкивались с одними и теми же проблемами. И некоторые из них заподозрили, что главная причина неудач – сам водопадный подход.
История Agile началась, когда небольшая группа новаторов задумалась о новых способах решения этих проблем. Первым делом они составили список из четырех основных ценностей, общих для успешных команд и проектов (этот документ получил название Manifesto for Agile Software Development, или «Манифест гибкой разработки программного обеспечения»).
• Люди и взаимодействие важнее процессов и инструментов.
• Работающий программный продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.
В данной главе вы узнаете об этих ценностях – откуда они взялись, что означают и насколько применимы к вашему проекту. Вы проследуете за командой, уставшей от методологии водопада и впервые пытающейся реализовать agile-проект, до тех пор, пока она не поймет, как эти ценности действительно применимы к ней. Читая эту историю, обратите внимание на то, как лучшее понимание ценностей помогает избежать проблем.
Руководитель команды, архитектор и менеджер проекта заходят в бар…
Дэн – ведущий разработчик и архитектор в компании, которая создает игровые автоматы и киоски. Он участвовал в различных проектах, от аркадных игр и пинбола до ПО для банкоматов. Последние несколько лет он работал в команде, возглавляемой Брюсом. Команда занималась выпуском крупнейшего продукта компании, слот-машины Slot-o-matic Weekend Warrior («Боец по выходным»).
Джоанну наняли несколько месяцев назад в качестве менеджера проекта, чтобы возглавить проект создания программного обеспечения для новой линии потоковых аудиоплееров, которые компания хочет вывести на рынок и продавать барам и ресторанам. Девушку переманили из конкурирующей компании, уже имеющей успешный опыт выведения музыкального автомата на рынок. Она отлично ладит с Дэном и Брюсом и воодушевлена работой над новым проектом.
Дэна и Брюса новый проект вдохновляет меньше, чем Джоанну. Как-то раз они зашли выпить после работы, и Брюс с Дэном начали объяснять Джоанне, почему команда придумала для слот-машины имя «Боец по выходным».
Она не очень обрадовалась, узнав, что провальные проекты в этой компании – скорее правило, чем исключение. Последние три проекта, по мнению руководителей компании, были успешно доведены до конца только благодаря чрезвычайно напряженной работе Дэна и Брюса. Более того, им пришлось наступить на горло собственной песне, выбрав кратчайший путь в кодировании. Из-за этого их продолжает мучить совесть. Ведь им пришлось срочно подлатать прототип для одной функции и протолкнуть его в производство, а позднее выяснилось, что появились серьезные проблемы с производительностью, потому что отдельные части этого прототипа оказались непригодны к масштабированию.
Слушая их рассказ, Джоанна поняла, что стало причиной проблем: компания использовала самую неэффективную методику –
Джоанна по опыту знала, что теория часто отличается от практики и, хотя отдельные команды имеют эффективную модель водопада, многие все же борются с ней. Она решила, что эта команда может стать одной из них.
