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

Несмотря на то что предиктивный, или каскадный, процесс испытывает трудности, многие организации продолжают пытаться заставить его работать. Мы встретились в 2005 году с СТО и персоналом компании розничной торговли Marks and Spenser из Великобритании, чтобы обсудить эмпиризм и Scrum. Компания только что модернизировала весь процесс развития, приобретя в PricewaterhouseCoopers (PWC), интернациональной консалтинговой компании, набор методологий, инструментов, обучения и услуг по внедрению. Подход PWC был предиктивным, или каскадным.

Но CTO Marks and Spenser хотел понять эмпиризм. Когда мы объяснили ему процесс, он заметно разволновался, прервал нас и сказал, что его компания тоже использует эмпиризм. Всякий раз, когда один из их больших проектов по разработке, основанный на подходе PWC, попадает в беду, они его останавливают и затем применяют другой подход, чтобы вернуть процесс на правильный путь или закончить. Он сказал, что это их «туз в рукаве», имея в виду трюк, который позволяет компании выходить из трудных ситуаций.

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

Поскольку наш мир становится все более сложным, для организаций и бизнеса открывается все больше перспектив. Мечта каждого предпринимателя и бизнесмена с душой предпринимателя  воспользоваться преимуществом новой возможности, выяснить, какая будет цена и какие риски нужно предвидеть. Если риски приемлемы, предприниматель захочет продолжить шаг за шагом, настолько быстро, как только можно, чтобы воспользоваться открывающимися возможностями. Тем не менее, как бы мы ни хотели контролировать риски, все может быстро выйти из-под контроля. Здесь очень желательны смелая осторожность и осторожная смелость. Мы называем способность брать преимущество от появляющихся возможностей гибкостью. Мы можем развернуться на месте, немедленно развить смелые инициативы и начать управлять рисками. Мы можем заставить наших конкурентов рыдать по утрам и мы можем радовать наших новых клиентов. Гибкость  это способность пользоваться возможностями или бороться с трудностями с расчетными рисками. Сегодня это наиболее значимое конкурентное преимущество. Мы создаем это преимущество и контролируем риски, ограничивая все наши проекты сроком в 30 дней или меньше. В этом случае мы можем пробовать идеи и без сожаления от них отказываться. Уже на ранней стадии нам понятно, что они, к примеру, слишком дорогостоящие или нереальные. И мы останавливаемся до того, как потратим слишком много денег.

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

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

Эмпирический процесс разработки программного обеспечения, использующий итеративно-инкрементальные методы, с нами уже более чем 20 лет. Используя его, вы можете создать плотный контроль над рисками с помощью ограниченных по времени инкрементов программного обеспечения. Это обеспечивает прозрачность путем доставки законченного, готового к использованию прироста полезного функционала каждые 30 дней (или в меньший срок), так что потери могут быть сведены к минимуму. Это обеспечивает скорость и гибкость настройки приложения для более полного удовлетворения возникающих потребностей и тем самым значительно увеличивает применимость. Мы больше не беспокоимся, что наши требования не будут выполнены. Мы больше не волнуемся, что бюджет увеличится. Мы больше не должны зависеть от абстрактных представлений о динамике проекта, таких как диаграммы Ганта или прототипы. Мы точно знаем, где мы находимся с точки зрения ценности продукта и графика, по крайней мере каждые 30 дней.

3. Попробуй это сам: пилотный проект

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

1) как провести пилотное исследование этого нового метода разработки программного обеспечения;

2) какую информацию вы сможете обрести в ходе этого исследования;

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

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

1) как провести пилотное исследование этого нового метода разработки программного обеспечения;

2) какую информацию вы сможете обрести в ходе этого исследования;

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

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

Процесс, которому вам необходимо следовать во время пилотного проекта, достаточно прост:

1) сформируйте команду;

2) подумайте, что бы вы хотели создать;

3) закончите маленький кусочек работы полностью;

4) оцените, что бы вы хотели сделать следующим;

5) определите, что может быть улучшено, и улучшите это;

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

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

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

Вот как выглядит процесс.

1. Сформируйте команду. Соберите всех менеджеров по продажам вместе, обсудите, как идут дела в компании, проведите обзор конкурентов, информируйте продавцов обо всех новых продуктах компании.

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

3. Сделайте маленький фрагмент работы полностью. Продавайте в течение месяца, чтобы посмотреть, что получилось. Также посмотрите, что получилось с будущими каналами сбыта.

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

5. Продолжайте делать и оценивать. Повторяйте эти шаги каждый месяц.

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

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

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

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