F-Secure разрабатывает в Финляндии антивирусные программы и программное обеспечение в сфере безопасности для международного рынка. Партнер компании предложил ей войти в специфический сегмент рынка антивирусного обеспечения, где она раньше не участвовала, предстояло разработать дополнительный функционал для партнерской компании, которая затем бы продавалась под ее брендом.
F-Secure использовала эмпирический подход к разработке программного обеспечения в течение трех лет. В компании знали, сколько в среднем полезного функционала ее команды разработки могут создать в течение одной итерации. Основываясь на этом знании, она согласовала с партнерской компанией план разработки: создать частичный релиз программного обеспечения к запланированной пресс-конференции, а вскоре после этого выпустить на рынок первый релиз. К несчастью, команды F-Secure, назначенные для разработки этого продукта, создали в течение первых трех итераций меньше функциональных возможностей, чем планировалось, 25 % необходимого для пресс-конференции. Уже было ясно, что продукт не будет готов вовремя.
Партнер и руководство F-Secure обсудили замедление прогресса в разработке и приостановили все процессы. Деньги были потрачены, но ничего полезного не было создано. Партнер, узнав, что не получит продукт в срок, остановил все приготовления к пресс-конференции, свернул маркетинговую активность и тем самым спас себя от потери репутации на рынке. Ценным опытом, полученным в результате этого проекта, было ограничение потерь.
Многие люди испытывают трудности с эмпирическим процессом. Может так случиться, что команда не разработает столько функциональных возможностей, сколько планировалось. Тому, кто вкладывает деньги, труднее всех: он точно знает, что хочет получить после каждой итерации, и, если команда не оправдывает ожиданий, заказчика ждет разочарование. Демонстрируя его, он, по сути, разрушает эффективность и дух команды.
Эмпиризм искусство сделать лучшее, что ты можешь, с тем, что у тебя есть. Эмпиризм открывает все виды возможностей. Однако если вы думаете, что можете решить, чего вы хотите, и давить, чтобы это получить, к сожалению, это закрывает перед вами другие возможности. Вы больше не имеете дела с реальностью, а стараетесь сделать реальностью то, что хотите, приказываете. Такой подход может быть приемлем в простой ситуации, но, когда проблема сложная, он лишь деморализует и разочаровывает.
Самая важная задача менеджера помочь людям делать их работу. Дайте им цель и позвольте им ее достичь. Уберите с их пути все препятствия. Делайте все возможное, чтобы они стали более эффективными и продуктивными. Только в этом случае организация может превратить плоды их работы в капитал.
Требовать прозрачности и создать соответствующую обстановку для ее процветанияЧтобы принять обоснованное решение, у вас должно быть твердое понимание реальных фактов. В эмпирическом процессе разработки программного обеспечения инкремент ясная и прозрачная информация, на которой основано принятие решений.
Люди должны чувствовать себя в безопасности, обсуждая критические вопросы, открыто выражать то, что они думают и чувствуют, и взаимодействовать с другими без препятствий и вреда. Все это основа эмпирического процесса. Множество рабочих пространств небезопасны. Политические программы и скрытые мотивы искажают прозрачность. Основная задача менеджера создать защищенное место, где люди уважают друг друга и чувствуют себя в безопасности.
Прозрачность нейтральна в том смысле, что это не хорошо и не плохо. Она просто должна быть. Обсуждение необходимо при принятии трудных решений. Если решения принимаются в угоду руководству, если разработчики искажают реальность, чтобы нравиться начальству, эмпирический процесс развалится на части.
Компания Kronos из Бостона девелопер софта для планирования ресурсов организации и учета рабочего времени. Компания предприняла попытку использовать эмпирический метод, чтобы ускорить свои процессы разработки. В 2008 году правление компании было недовольно прогрессом в разработке нового релиза. Команде девелоперов дали это понять и попросили работать усердней. Те, пытаясь соответствовать требованиям руководства, стали создавать функционал быстрее, чем обычно, но с гораздо более низким качеством.
В конце каждой итерации руководство поощряло разработчиков за их тяжелый труд. Однако инкремент не был прозрачным. Руководство думало, что инкремент полностью закончен и стабилен, а он между тем был только частично законченным и практически полностью нерабочим. Когда Kronos приблизилась к дате релиза, недостатки были обнаружены, и дата выхода сдвинулась на шесть месяцев.
Рассчитывать, что ваши люди могут сделать большеРазработчики лучше всех ориентируются в процессе и знают, как лучше. Эта мысль идет вразрез с большинством управленческих курсов. Менеджер должен ставить перед собой цели, выяснять, как их добиваться, а потом заставлять остальных следовать его плану. Однако в таком случае вся работа зависит от опыта, интеллекта и организаторских способностей конкретного менеджера.
Если люди, делающие свою работу, свободны решать, что им делать, они могут адаптироваться к обстоятельствам и реальности, с которой сталкиваются. Они могут поделиться идеями и опытом, чтобы прийти к лучшему решению. Когда они пробуют какой-то подход и он не работает, то они могут предложить что-то другое. Это называется самоорганизацией и повышает общий уровень знаний всех членов команды. Они не ограничены мышлением менеджера и свободны сделать свою работу лучшим способом.
Роль менеджера при таком подходе только устанавливать цели, содействовать и устранять препятствия. Он наделяет членов команды правом принимать решения.
Помогите людям ослабить их желание определенностиМир изменчив. Разработка программного обеспечения тоже изменчива. Но решения по-прежнему нужно принимать, и организация, которая принимает лучшие решения, процветает. Программное обеспечение за 30 дней дает вам надежную, полезную информацию о том, что будет происходить по крайней мере каждые 30 дней. Итерация ограниченная по времени авантюра. Команда способна практически без сбоев создать программное обеспечение, представляющее определенную ценность. Даже в худшем случае, когда команда не создает ничего, это дает ценную информацию о том, что пока это невозможно.
Расположенная в Филадельфии компания Primavera, которой сейчас владеет Oracle, создает программное обеспечение для управления проектами, основанными на предиктивном процессе. Учредители понимали иронию: использовать эмпирический процесс разработки программного обеспечения для создания своих предиктивных (прогнозируемых) инструментов. Тем не менее, чтобы решить свои проблемы, они должны были к нему прибегнуть.
В конце самой первой итерации команда разработки и высшее руководство собрались посмотреть демонстрацию инкремента. Функционал работал прекрасно. Однако СТО указал на то, что команда планировала создать семь функций, а реализовала только пять. СТО почувствовал себя некомфортно. Он попросил команду собрать статистику как много времени занимает та или иная работа. Он подумал: если собранная статистика будет объединена в базу данных, команда станет более тщательно выполнять задачи. Они могли бы оценивать размер предстоящей работы по статистике из базы данных в начале новой итерации. Тогда они могли бы знать заранее, что сделают только пять функций.
Разработка программного обеспечения непредсказуема. Прошлое не может предсказать будущего, так как разработка программного обеспечения отличается каждый раз. База данных не будет полезной.
Мы все хотим определенности, но это часто недостижимо. Однако мы можем действовать с умом, принимать правильные решения и держать под контролем риски. Вот почему эмпирический процесс разработки программного обеспечения выигрывает и вот почему короткие итерации снижают риск.
Степень успеха, которого вы добьетесь при применении эмпирического процесса разработки программного обеспечения, существенно зависит от управления в вашей организации и того, как это управление приведет всех к вышеуказанным изменениям.
Раздел II. Как создать программное обеспечение за 30 дней
Организации хотят стать более гибкими, более творческими и более продуктивными, а также увеличить свою прибыль. Они хотят радовать своих клиентов и обгонять конкурентов. Многие организации решили использовать Scrum как одну из ключевых стратегий. Иногда его применяют только для самых важных задач, иногда организация создает новый IT-отдел параллельно с существующим, использующим каскадный процесс. Иногда вся организация трансформируется, чтобы стать более гибкой, конкурентоспособной. Вне зависимости от поставленной цели требуется изменение обычного подхода к делу. Как и в большинстве значительных изменений, неорганизованный подход независимо от его достоинств обречен на провал. Переход к Scrum, описанный в этом разделе книги, пошаговый.
Мы начнем с быстрого знакомства с ним, затем разделим метод на три шага, каждый из которых рассмотрим в отдельной главе.
Scrum на уровне проекта. Этот подход применяется «по необходимости» (от лат. pro re nata (PRN), что означает «бери, когда нужно»). Например, когда кто-то нуждается в программном обеспечении за 30 дней или меньше. Глава 6 объясняет, как реализовать Scrum на уровне проекта с минимальными расходами и самыми быстрыми результатами.
Scrum на уровне возможностей. Студия разработки программного обеспечения, в которой реализуются Scrum-проекты, создается отдельно от остальной части организации. Студии ставится задача создать конкурентное преимущество с помощью использования Scrum. Она управляется с высокой степенью автономии и свободна от бюрократии. Когда преимущество от использования Scrum становится очевидным, студию используют чаще. Глава 7 описывает этот шаг.
Scrum на уровне организации. На этапе организации опыт и знания, полученные студией разработки, распространяются на всю компанию, ее общую производительность и гибкость. Глава 8 описывает этот шаг, а кроме того, рассказывает, как применять Scrum, чтобы внедрить его в организации. И как отделить разговоры о применении Scrum от реального его использования.