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

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

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

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

Вот почему многих разработчиков привлекают гибкие команды. Да, вы должны будете заботиться о планировании и привыкать к использованию таких инструментов, как доска задач и график выполнения. Agile-методологии основаны на практиках, выбранных именно потому, что они просты и сокращены до минимума, необходимого для эффективного планирования и выполнения проекта. Участвуя в планировании проекта (и на самом деле заботясь о нем!), вы получаете явную выгоду: удается избежать чувства досады, вызванного срочными изменениями, задавая трудные вопросы в тот момент, когда проект находится на стадии планирования. Это возможно только потому, что эффективные гибкие команды общаются со своими пользователями с самого начала проекта. Много хороших разработчиков начали свое участие в планировании, в первый раз задав одному из своих пользователей трудный вопрос, который в противном случае встал бы позднее. Возможность избежать вечной проблемы, когда в последнюю минуту приходится переделывать код, оказывается отличным стимулом для внедрения Agile.

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

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

• менеджер, который получает сметы, строит графики проектных работ и руководит повседневной работой команды;

• эксперт по продукции в роли бизнес-аналитика, который определяет требования, направляет их команде и гарантирует, что она создает необходимое программное обеспечение;

• куратор, который работает с топ-менеджерами и руководством вашей компании, информирует их о том, как окупаются их инвестиции в проект.

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

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

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

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

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

Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).

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

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

• Составьте список всех документов, которые вы и ваша команда создали или использовали. Есть ли среди них то, что команда не использует для построения кода?

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

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

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

• Узнать больше о ценностях и принципах Agile-манифеста и о том, как он был создан, можно в книге Алистера Коберна «Быстрая разработка программного обеспечения» (М.: Лори, 2013).

• Узнать подробнее о значимости итерации и других аспектов agile-управления проектами можно в книге Джима Хайсмита Agile Project Management: Creating Innovative Projects (Addison-Wesley, 2009).

• Узнать больше о сложных задачах, с которыми сталкиваются команды, желающие стать гибкими, и о том, как их преодолеть, можно в книге Майка Кона «Scrum. Гибкая разработка ПО» (М.: Вильямс, 2016).

• Узнать больше о том, как оставить в прошлом командно-административное мышление, можно, прочитав книгу Лиссы Адкинс Coaching Agile Teams (Addison-Wesley, 2010). В настоящее время эта книга готовится к изданию.

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

• Помогите команде понять, что сверхурочная работа – это причина сокращения объема созданного кода, более того – она ухудшает его качество.

• Поговорите с каждым членом команды о том, какой работой он занимается. Что им движет? Что расстраивает? Чем он руководствуется при принятии решений?

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

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