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

4. Что могу сделать я?

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

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

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

Практика – искусство возможностей

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

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

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

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 от реального его использования.

5. Знакомство со Scrum

Scrum – это фреймворк (программная платформа) для управления сложным процессом, таким как разработка программного обеспечения. Он очень простой, состоит только из трех ролей, трех артефактов и пяти событий (табл. 5.1). Scrum связывает их вместе правилами игры.

Таблица 5.1. Основы Scrum

Разрабатывать программное обеспечение будет Scrum-команда, состоящая из того, кто хочет получить программное обеспечение (владелец продукта), менеджера (Scrum-мастер), а также разработчиков. Чтобы избежать путаницы, может быть только один владелец продукта, который решает, что будет разработано в каждой итерации, или спринте – в терминологии Scrum, – и оценивает результаты приращения функционала в конце каждого спринта. Scrum-мастер управляет проектом согласно правилам Scrum. Некоторые Scrum-мастера прошли обучение, другие имеют значительный, проверенный опыт в успешном его использовании. Главное – знание, как управлять Scrum-командой и проектом.

Создание Scrum-команды и планирование спринта

Первая задача Scrum-мастера – поиск разработчиков и создание команды разработки. Люди в этой команде должны иметь необходимую квалификацию по превращению потребностей и требований владельца продукта (бэклог продукта) в рабочие инкременты программного обеспечения после каждого спринта.

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

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

Когда планирование закончено, члены команды дают прогноз, какой объем работы они прогнозируют сделать к концу спринта. Это эмпиризм в действии: дать прогноз, посмотреть, что получилось в реальности, и принять решение на основании результата.

В силу необходимости двигаться дальше этот начальный этап должен быть протяженностью в один день.

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

Спринт за ценностью

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

Каждый день в течение спринта разработчики проводят 15-минутные совещания, называемые Scrum-митингами, чтобы спланировать предстоящую работу, все время стремясь достигнуть того, что было договорено. Чтобы максимизировать продуктивность разработчиков, задачи спринта должны быть согласованы как разработчиками, так и владельцем продукта. Они соглашаются, что создадут столько требуемого функционала, сколько возможно, и могут быть переориентированы перед каждым новым спринтом. Владелец продукта соглашается, что требования, над которыми работает команда, не будут меняться в течение спринта. Все, что не было запланировано (включая, например, участие разработчиков во встречах с потребителями), может подождать до следующего спринта. Производительность разработчиков повышается, когда их не прерывают. Применение более коротких спринтов обычно обеспечивает внесение более частых изменений – об этом мы поговорим в следующей главе.

Проведение обзора спринта

В конце спринта Scrum-мастер встречается с разработчиками для проведения обзора спринта. Эта встреча не должна продолжаться более четырех часов. Scrum-команда и ключевые заинтересованные стороны собираются и дают оценку результатам предыдущего спринта и прироста функционала. Обзор включает следующее: что было сделано, каков объем реализованных задач, насколько эффективна разработка и насколько полезен ее результат. Инкремент должен быть законченным фрагментом пригодного к применению программного обеспечения. Пункты бэклога продукта, которые выполнены не полностью, остаются в списке как «все еще требующие выполнения». Новые требования часто возникают в течение обзора спринта. Также часто появляются новые возможности и трудности. Иногда достаточно просто увидеть инкремент, чтобы зародились новые идеи.

Результаты обзора спринта могут включать один или несколько из следующих пунктов:

• начало использования разработанного функционала;

• решение, что делать в течение следующего спринта, и подготовка к нему;

• решение остановить работу.

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

Проведение ретроспективы спринта

Каждый участник Scrum-команды старается совершенствоваться спринт за спринтом. Ретроспектива спринта – мероприятие, где формулируются улучшения. Эта встреча ни в коем случае не должна длиться более четырех часов.

Ретроспектива спринта – естественный разрыв между спринтами, когда команда садится и обсуждает события предыдущего спринта, а также ищет пути улучшения своей работы и способов, которыми эта работа ведется.

Обсуждение может включать следующие вопросы:

• хорошо или плохо работают члены команды вместе и почему;

• больше или меньше работы, чем предполагалось, делает команда и почему;

• обладает ли команда всеми необходимыми навыками и обеспечением, требующимся для выполнения работы;

• понимают ли разработчики требования и почему;

• способна ли команда закончить спринт в соответствии с требованиями, и если нет, то почему;

• что можно добавить или выбросить из следующего инкремента функционала;

• что команда думает об использовании подхода Scrum.

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

Продолжение спринта

Scrum-команда продолжает повторять шаги, описанные ранее, пока цели не будут достигнуты, возможности максимально использованы, возврат инвестиций достигнут или пока не столкнутся с непреодолимым препятствием (рис. 5.1).

Рис. 5.1. Scrum в действии

Выводы

Scrum прост. Мы рассмотрели его и знаем его составные части. Мы знаем, как двигаться от планов к реализации. Теперь мы посмотрим, как заставить Scrum работать в вашей организации.