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

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

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

Люди в команде. Команды и люди делают работу лучше всего, когда их не прерывают. Команды больше совершенствуются, когда сами решают свои проблемы. А общение, в том числе лицом к лицу, – наиболее продуктивный способ для команды работать вместе.

Состав команды. Команды более продуктивны, если имеют один и тот же состав участников. Продукты более надежны, когда команда имеет все кросс-функциональные навыки, сосредоточенные на работе. Изменение состава команды часто временно снижает ее производительность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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