Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн книгу. Автор: Кен Швабер, Джефф Сазерленд cтр.№ 13

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

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

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

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

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

Определите, что может быть улучшено, и сделайте это

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

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

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

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

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

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

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

Продолжайте делать и оценивать, пока не закончите

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

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

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

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

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

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