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

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

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

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

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

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

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

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

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

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

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

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

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

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

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