Текст книги "Постигая Agile"

Выполнение проекта – перемещение по проекту

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

Принцип № 7. Работающий продукт – основной показатель прогресса

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

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

Ответ кроется в самом программном продукте. Вы можете мгновенно увидеть реально работающее программное обеспечение, оно перед вами, вы «получаете» его. Вы сразу видите, что этот продукт делает (или не делает). Если менеджер обещал предоставить то, чего данное ПО не в состоянии выполнить, то может возникнуть неловкая ситуация. Но скрыть это невозможно, потому что программа говорит сама за себя.

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

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

Принцип № 8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки

Команда проекта «Электронная книга» – далеко не первая из тех, кто напряженно работает, чтобы уложиться в нереальный срок. Жесткие рамки сдачи проекта – основной инструмент в командно-административном наборе. Всякий раз, когда приближается дедлайн, все первым делом думают о работе по ночам и в выходные дни. Невыполнимый срок – это коварный инструмент, заставляющий команду работать на пределе и сокращающий еженедельные сроки.

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

Именно поэтому agile-команды стремятся к сохранению устойчивого темпа. Они планируют выполнение задания, которое действительно можно сделать за выделенное для него время. Итеративная разработка позволяет добиваться этого. Намного проще оценить, сколько программных продуктов можно разработать в течение двух, четырех или шести недель, чем за год-полтора. Давая реальные обещания, команда создает среду, в которой работа по ночам – это исключение из правил[22]22
  Это хороший пример упрощения, о котором говорилось в главе 1. Правда, сейчас мы будем говорить о том, что «устойчивый темп» означает следующее: команда имеет достаточно времени для создания ПО, поэтому ей не нужно работать по ночам и в выходные. Далее мы подробно расскажем о важности устойчивых темпов для рабочей среды в команде и для культуры компании в целом, а также о том, что она оказывает влияние на качество производимого ПО.


[Закрыть].

Принцип № 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта

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

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

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

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

Лучшая рабочая среда для команды проекта «Электронная книга»

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

Еще хуже то, что в самом начале проекта команда заложила дизайн программного обеспечения и архитектуру для поддержания очень подробной спецификации. В итоге получился крайне сложный код, который трудно расширить. Это привело к большому количеству изменений в коде и к такому же числу «заплаток», которые запутывают код. Если бы команда придерживалась итеративного подхода и поставляла рабочее ПО на протяжении всего проекта, то могла бы планировать каждую итерацию для сохранения стабильного темпа работы. Упрощенный подход just-in-time («точно вовремя») к архитектуре позволил бы создать более гибкий и расширяемый дизайн.

Давайте представим, что наша команда проекта «Электронная книга» применила эти принципы и сейчас они похожи на хорошо отлаженную машину по производству программного обеспечения. Они регулярно воспроизводят и поставляют работающее программное обеспечение и постоянно корректируют работу, чтобы быть уверенными в умении создавать ценное ПО. Члены команды хорошо коммуницируют, документируют только то, что им действительно нужно, используют методы проектирования и строительства, позволяющие создавать обслуживаемый код. И все это – без необходимости работать сверхурочно. Наша команда стала гибкой!

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

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

Ключевые моменты

Наиболее эффективный способ коммуникации в ходе реализации проекта – поставка рабочего программного обеспечения и передача его в руки пользователя (принцип № 7).

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

Хорошо разработанное и реализованное программное обеспечение намного быстрее поставляется клиенту, потому что в него проще вносить изменения (принцип № 9).

Постоянное совершенствование проекта и команды

Один из основных принципов проектирования не только программного обеспечения, но и во всем инженерном деле – это KISS[23]23
  Keep it simple, stupid.


[Закрыть] («чем проще, тем лучше»). Agile-команда живет по этому принципу, когда планирует проект, разрабатывает программное обеспечение и движется вперед.

Принцип № 10. Простота – искусство минимизации лишней работы – крайне необходима

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

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

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

Этот аргумент имеет смысл в ситуации с ремонтом дома. Дело в том, что в этом случае нет ничего более разрушительного, чем взять кувалду и сломать стену. Но программные проекты отличаются от домов и прочих физических объектов. Удаление кода не несет глобальных разрушений, потому что вы легко можете восстановить его из системы управления версиями. Самая разрушительная вещь для вашего проекта – это создать новый код, а затем другой, зависимый от первого, и так далее, как выстраивают костяшки домино. Получится до боли знакомый эффект каскадных изменений… И в итоге вы останетесь с неремонтопригодным, запутанным спагетти-кодом.

Максимальное увеличение объема работы не поможет избежать этой путаницы. Лучше создавать систему без большого количества зависимостей и ненужного кода. Наиболее эффективный способ создания максимально полезного и ценного программного обеспечения – это работа с клиентами и заинтересованными сторонами. Если функция не является ценной, то в долгосрочной перспективе для компании дешевле не создавать ее вовсе. Потому что расходы на содержание дополнительного кода выше, чем стоимость самой разработки. Когда команды пишут код, они могут хранить свои несложные проекты программного обеспечения, создавая дизайн ПО на базе небольших автономных единиц (например, классов, модулей, сервисов и т. д.), которые делают только одну вещь – помогают избежать эффекта домино[24]24
  Еще одно упрощение. Позднее мы подробнее поговорим о том, как команды могут строить прекрасный код без предварительного создания больших конструкций, какое влияние они оказывают на проекты, и о том, как они могут влиять на работу, пока изменения еще не охватили весь проект.


[Закрыть].

Принцип № 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд

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

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

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

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

Принцип № 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы

Команда не может быть гибкой, если не совершенствует способы создания программного обеспечения. Agile-команды постоянно занимаются контролем и адаптацией – они следят за тем, как работают их проекты, и используют эти знания для улучшений в будущем. И делают это не только в конце проекта – на ежедневных встречах члены команды ищут пути изменения и меняют текущую работу, если в этом есть необходимость[25]25
  Еще одно упрощение. Пока мы просто выдвинем идею, что agile-команды занимаются проверкой сделанного и адаптацией. В главе 4 вы подробнее узнаете об этом на примере scrum-команды и о том, как это связано с самоорганизацией команд.


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

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

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

Ключевые моменты

Гибкие команды создают максимально простые решения, избегая ненужных функций или чрезмерно сложного программного обеспечения (принцип № 10).

Самоорганизующиеся команды разделяют ответственность за все аспекты проекта, начиная с замысла создания продукта и заканчивая его реализацией (принцип № 11).

Выделяя время на то, чтобы обсудить уроки, которые они получили после каждой итерации и в конце проекта, agile-команды постоянно улучшают свои компетенции в области разработки программного обеспечения (принцип № 12).

Agile-проект: объединение всех принципов

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

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

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

Часто задаваемые вопросы

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

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

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

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

Я менеджер проекта, и мне до сих пор непонятно, как я могу вписаться в agile-команду. Какова моя роль во всем этом?

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

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

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

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

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

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

Но если вся команда участвует в планировании, то значит, никто ни за что не отвечает? Это непрактично. Как принимаются решения?

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

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

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

Что вы можете сделать сегодня

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

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

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

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

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

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

Где вы можете узнать больше

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

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

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

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

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

Подсказки

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

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

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

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

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