Книги
Постигая 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-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Помогите команде понять, что сверхурочная работа – это причина сокращения объема созданного кода, более того – она ухудшает его качество.
• Поговорите с каждым членом команды о том, какой работой он занимается. Что им движет? Что расстраивает? Чем он руководствуется при принятии решений?