Все менеджеры проверяли прогресс в создании инкремента каждые 30 дней. Сначала люди, находясь в разных местах, изучали законченный инкремент и затем в формате телеконференции обсуждали прогресс и проблемы, а также планировали объем работы для следующей итерации. Обучающие курсы помогли каждому стать более организованным. Пол обновил рабочее пространство в Iron Mountain, чтобы команда разработки стала более продуктивной и эффективной. Потери от нескоординированной работы, которую приходилось переделывать, были устранены. Потери от ручного тестирования, которое можно делать автоматически, также были устранены. Высшее руководство Iron Mountain решило развивать LiveVault. Новая маркетинговая программа и усилия по продвижению были запущены. Еще три релиза выпустили в течение следующих шести месяцев.
Вернемся к истории финансовой организации из Огайо, вице-президент которой расположил команду разработки рядом со своим офисом. Он поделился своими идеями о приложении и сказал, что хочет проверить эмпирический процесс разработки, чтобы узнать, поможет ли он быстро создать приложение. Члены команды провели целый день, узнавая друг о друге. Они анализировали, как может выглядеть приложение, и выбрали первоначальный внешний вид пользовательского интерфейса. Они оценили требования по защите, производительности и стабильности будущего приложения и составили список того, что приложение сможет делать, когда будет закончено, и что они, по их мнению, смогут реализовать за три месяца итераций.
Команда решила, что, для того чтобы оценить, будет ли разработка осуществимой, они должны выяснить в течение первой итерации следующее.
1. Может ли команда разработки создать приложение в рамках существующей технологии?
2. Можно ли приложение эффективно подключать к функционалу портала без использования интерфейса интернет-портала?
3. Как должно выглядеть это приложение?
Члены команды определили, что должно быть выполнено и какой функционал должен быть реализован, чтобы ответить на эти вопросы. Программа-минимум состояла в том, чтобы получить на экране страницу регистрации, но отклонять идентификационные данные пользователя. Максимальная же цель была в том, чтобы регистрация работала и открывала функционал портала в приложении.
Пять членов команды никогда не работали вместе, кроме того, ни один из них никогда не работал с таким типом приложений и технологий. У них было много предложений и возражений. Чем больше они разговаривали, тем больше сталкивались с трудностями совместной работы. Необходимость создать инкремент по окончании итерации добавляла больше стресса.
Пять членов команды никогда не работали вместе, кроме того, ни один из них никогда не работал с таким типом приложений и технологий. У них было много предложений и возражений. Чем больше они разговаривали, тем больше сталкивались с трудностями совместной работы. Необходимость создать инкремент по окончании итерации добавляла больше стресса.
Чрезвычайно важны обсуждения, за которыми стоят сильные чувства участников. Но такие обсуждения возможны только тогда, когда все ощущают себя защищенными. Каждый должен чувствовать, что его мнение будет принято с уважением. Каждый должен иметь возможность спорить, не соглашаться и бороться за применение лучшего подхода к решению проблемы. Менеджер пилотного проекта уже проходил это раньше. Он рассказал членам команды об уважении и помог создать правила этикета общения в команде. В соответствии с ними было запрещено отбрасывать идеи и мнения других, относиться друг к другу пренебрежительно и использовать оскорбления. Без этих и других правил работа в команде в открытом общем офисе может стать трудной.
Первоочередной задачей проекта стало планирование того, как будет выглядеть приложение. Следующий шаг планирование того, как команда начнет превращать дизайн приложения в работающее программное обеспечение.
Команда должна была подводить ежедневные итоги и давать оценку тому, что сделано в течение дня и какие проблемы возникли, а также решать, каким наиболее важным задачам будет посвящена завтрашняя работа.
День за днем члены команды подгоняли друг к другу различные фрагменты общей головоломки. Они учили приложение подсоединяться через операционную систему смартфона к интернет-приложению портала. Кроме того, определяли коммуникационные протоколы для взаимодействия и разбирали, как активировать функциональные возможности входа в систему на портале. Вице-президент и менеджер пилотного проекта напомнили, что приложение должно быть защищенным, стабильным и производительным. Члены команда провели ряд тестов, чтобы оценить эти характеристики, и внесли изменения в программное обеспечение, чтобы соответствовать этим требованиям.
Примечание: сотрудники IT-отдела постоянно приходили в офис команды разработки с различными просьбами и мешали команде. Менеджер проекта попросил их всех уйти и решать свои проблемы где-нибудь в другом месте.
Даже то, что, казалось бы, вызывает незначительную задержку, может снизить общую эффективность команды более чем на 50 %. Вице-президент знал, что висит на крючке у руководства, желающего проверить эффективность эмпирического процесса, и не хотел все испортить из-за того, что его сотрудников отвлекают.
Команда разработала часть программного обеспечения для приложения к концу итерации. Теперь кто угодно мог скачать приложение на смартфон, запустить его и увидеть такую же страницу входа в систему, которую видят пользователи портала. Приложение работало стабильно, отвечало всем требованиям и было готово к дальнейшему безопасному улучшению. Несмотря на то что члены команды разработки надеялись добавить больше функционала, чем просто вход в систему, они были довольны полученным результатом, так же как и вице-президент.
Вице-президент организовал четырехчасовое совещание в конце итерации, чтобы провести разбор того, что получилось. Несколько человек из фондового отдела и некоторые менеджеры из отдела информационных технологий также были приглашены на совещание. С их помощью вице-президент и члены команды разработки дали оценку, как работает эмпирический процесс, обсудили политику непрерывности девелопмента и убедили остальных в ее необходимости, а кроме того, оценили дизайн приложения и то, как оно соединяется с интернет-порталом. Было предложено несколько улучшений.
В конце совещания менеджер пилотного проекта напомнил всем, что они должны решить, стоит ли продолжать разработку в оставшиеся две итерации. Несколько человек выразили мнение, что знаний, полученных в ходе пилотного проекта, вполне достаточно и он может считаться завершенным. Фондовый менеджер не был с этим согласен, его поддержали большинство участников совещания, которые решили продолжить, чтобы узнать, будет ли эмпирический процесс продолжать работать. Также они хотели дальнейшего улучшения функционала приложения для смартфонов.
Некоторые участники совещания были настроены критически. Они заявили о своем разочаровании и напомнили разработчикам, что те планировали запустить вход в систему, но не смогли этого добиться. Вице-президент возразил, заявив, что они вступили в незнакомое поле и члены команды экспериментируют и учатся. Они сделали максимум возможного в ходе первой итерации и обрели навыки и опыт.
Дискуссия пошла в сторону обсуждения различий между традиционным, или предиктивным, методом разработки и эмпирическим процессом. Вице-президент при поддержке менеджера пилотного проекта напомнил всем, что цель эмпиризма определение границ возможностей того, что можно сделать. Так как все увидели результаты итерации, они могут планировать следующий этап работы. Он напомнил, что даже после одной итерации у них уже есть фрагмент работающего приложения. Более того, они получили ценное доказательство, что приложение жизнеспособно и уже сейчас есть что показать потенциальным клиентам. Имеется готовый блок программного обеспечения, который можно достраивать. Если бы это был предиктивный процесс, который он рассматривал изначально, то на данном этапе он в лучшем случае получил бы только документацию по требованиям к будущему приложению.
Вице-президент принял решение показать приложение некоторым своим клиентам, чтобы определить, будут ли они в действительности им пользоваться. Он станет работать с клиентами в течение каждой итерации и пригласит их на следующее совещание, чтобы они смогли высказать свое мнение.
Менеджер пилотного проекта предложил организовать встречу команды и провести ретроспективный обзор предыдущей итерации. Он хотел, чтобы члены команды открыто обсудили свои ощущения и мнения о том, как может быть улучшен порядок работы.
Все перечисленное ниже может случиться в течение итерации, и команде следует это обсудить.
Очень мало функционала было создано. Команда разработки должна всегда стараться предоставить как минимум один элемент бизнес-функционала с каждой итерацией, даже если он будет небольшим. Однако в некоторых случаях разработчики могут сделать слишком маленький фрагмент функционала или не создать полезного функционала совсем. Они, возможно, должны много сделать в областях, которыми следует заняться в первую очередь: в технологии, архитектуре или автоматизации, и это не оставит достаточно времени на реализацию функционала. Или они просто не обладают достаточными навыками в разработке, чтобы оправдать затраты, и должны быть переучены, или их надо заменить.
Предоставленный функционал недостаточно близок к желаемому. Вице-президент мог обнаружить, что разработчики не понимают, чего он хотел, поэтому ему следует более тесно сотрудничать с членами команды, чтобы более эффективно доносить до них идеи и требования и быть уверенным, что они их поняли. Если члены команды мало знают о мобильных приложениях или управлении фондами, он должен проводить больше времени, работая с ними, или найти новых членов команды.
Итерация кажется неуклюжей. Не исключено, что члены команды пилотного проекта чувствуют себя так, словно изучают новый танец. Им надо понять, как работать вместе по-другому таким образом, чтобы чувствовать себя лучше и получать более впечатляющие результаты.
Члены команды могут вообще не работать вместе хорошо. Необходимо подробно проанализировать, как члены команды взаимодействуют друг с другом, иногда бывает полезно пригласить внешнего посредника, который может показать пути более эффективной совместной работы и принятия решений. Иногда приходится реорганизовывать команду, вводить в нее новых участников. Конечно, создание новой команды означает, что предыдущий опыт будет потерян.