Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

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

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

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

Все перечисленное ниже может случиться в течение итерации, и команде следует это обсудить.

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

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

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

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

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

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

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

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

Несмотря ни на что, вы будете накапливать, итерация за итерацией, функционал программного обеспечения. Это произойдет быстрее, чем вы привыкли. Вы сможете преодолеть проблемы и построить то, что может быть впоследствии доделано и реализовано.

Когда применяется каскадный процесс, изъяны его не очевидны и влияние на общую важность девелопмента скрыто. Когда вы применяете 30-дневные циклы разработки, все, что не функционирует в каскадном процессе, все его потери становятся видимыми.

Это полезная информация, но часто она требует необходимости согласованных усилий для улучшения ситуации. Эти усилия подробно описаны в разделе II.

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

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