Софт за 30 дней. Как Scrum делает невозможное возможным - Джефф Сазерленд Страница 10
Софт за 30 дней. Как Scrum делает невозможное возможным - Джефф Сазерленд читать онлайн бесплатно
Ознакомительный фрагмент
Эмпирический процесс разработки программного обеспечения, использующий итеративно-инкрементальные методы, с нами уже более чем 20 лет. Используя его, вы можете создать плотный контроль над рисками с помощью ограниченных по времени инкрементов программного обеспечения. Это обеспечивает прозрачность путем доставки законченного, готового к использованию прироста полезного функционала каждые 30 дней (или в меньший срок), так что потери могут быть сведены к минимуму. Это обеспечивает скорость и гибкость настройки приложения для более полного удовлетворения возникающих потребностей и тем самым значительно увеличивает применимость. Мы больше не беспокоимся, что наши требования не будут выполнены. Мы больше не волнуемся, что бюджет увеличится. Мы больше не должны зависеть от абстрактных представлений о динамике проекта, таких как диаграммы Ганта или прототипы. Мы точно знаем, где мы находимся с точки зрения ценности продукта и графика, по крайней мере каждые 30 дней.
Если вам все еще интересно, сейчас самое время увидеть, решает ли эмпирический подход к разработке программного обеспечения ваши проблемы и отвечает ли вашим потребностям. Пришло время создать пилотный проект – небольшое предварительное исследование, – чтобы оценить целесообразность, временные и финансовые затраты и выявить побочные эффекты. В этой главе мы вам расскажем:
1) как провести пилотное исследование этого нового метода разработки программного обеспечения;
2) какую информацию вы сможете обрести в ходе этого исследования;
3) как это работает для других людей (проблемы, которые они обнаружили, и что потребовалось для их решения).
В этой главе мы также остановимся на том, что вы должны сделать, чтобы добиться успеха, шаг за шагом, дадим более подробное описание и проиллюстрируем его примерами. Они могут быть прочитаны позже, когда эксперимент уже будет идти полным ходом.
Процесс, которому вам необходимо следовать во время пилотного проекта, достаточно прост:
1) сформируйте команду;
2) подумайте, что бы вы хотели создать;
3) закончите маленький кусочек работы полностью;
4) оцените, что бы вы хотели сделать следующим;
5) определите, что может быть улучшено, и улучшите это;
6) продолжайте повторять шаги с третьего по пятый, пока не будете удовлетворены результатом.
Прежде чем начать, обдумайте, что случится, если пилотный проект будет неудачным, или что – если он закончится успехом. Сколько времени и денег вы готовы потратить на то, что может и не работать. Что вы будете делать, если ценный функционал у вас будет получаться, инкремент за инкрементом, и вы захотите продолжить? К концу пилотного проекта вы будете знать, захотите ли вы повторить эмпирический процесс разработки программного обеспечения в большем масштабе. Конечно, у вас будет программа, которая была разработана во время пилотного проекта.
Эмпиризм используется в организации везде
Еще одна вещь, которую нужно осознать до того, как начать пользоваться эмпирическим процессом, – то, что он уже давно укоренился в других частях вашей организации и кажется новым только для разработки программного обеспечения. Например, типичная торговая организация использует эмпиризм в течение всего годового цикла. Вначале они составляют годовой план – прогнозируется ожидаемый объем продаж за год. В течение первых нескольких месяцев года перспективы понятны и шаги для продвижения продаж определены. Потенциальные клиенты, которые, вероятно, станут покупателями, уже известны и включены в прогнозы на второй квартал. Прогнозы на вторую половину года не определены и включают в себя только идеи и цели. В течение года менеджеры по продажам продолжают обновлять каналы сбыта. Возможные доходы могут быть предсказаны только на два или три месяца вперед, а в остальном план остается неясным. Каждый месяц продажи, изменения в предстоящих продажах, а также прогнозы пересматриваются. Дальнейшие усилия по сбыту и экспедиционные расходы компании соответствующим образом корректируются.
Вот как выглядит процесс.
1. Сформируйте команду. Соберите всех менеджеров по продажам вместе, обсудите, как идут дела в компании, проведите обзор конкурентов, информируйте продавцов обо всех новых продуктах компании.
2. Обдумаете, куда бы вы хотели двигаться. Создайте каналы сбыта, определите цели и доходы за год с небольшой точностью. Определите территории и доли рынка.
3. Сделайте маленький фрагмент работы полностью. Продавайте в течение месяца, чтобы посмотреть, что получилось. Также посмотрите, что получилось с будущими каналами сбыта.
4. Обдумайте, что бы вы хотели сделать следующим. Обновите каналы сбыта и сфокусируйте усилия на следующем месяце.
5. Продолжайте делать и оценивать. Повторяйте эти шаги каждый месяц.
Торговая организация никогда не будет использовать предиктивные процессы в своей работе. Слишком мало что известно и слишком многое может измениться, чтобы планировать доходы и их источники в первый день года.
Пример пилотного проекта
Как мы говорили ранее, пилотное исследование – небольшой эксперимент, чтобы оценить выполнимость проекта, временные и финансовые затраты, а также побочные эффекты. Его цель состоит в том, чтобы определить, помогут ли эмпирические процессы в разработке программного обеспечения. Мы предлагаем опробовать наш метод на том, что доставило вам серьезные проблемы. Это должно быть что-то ненадежное, сложное, в чем вы не уверены.
Следующий пример пилотного проекта может послужить вам моделью. У финансовой организации из Огайо множество совместных фондов для различных отраслей и клиентов. Большинство клиентов управляют своими счетами онлайн через интернет-портал. У вице-президента фондового отдела имелся смартфон, на котором он пользовался приложениями для оплаты счетов. У него возник вопрос, возможно ли создать приложение, позволяющее клиентам управлять своими фондами через телефон. Такое приложение повысило бы активность текущих пользователей. Если о будущем приложении для смартфона сообщить заранее, до конкурса на разработку, то за это время можно привлечь дополнительных клиентов.
Он передал свою идею в IT-отдел и попросил о помощи. В IT-отделе эта идея понравилась, и они были готовы ее развивать, это отвечало их потребности совершенствоваться в области мобильных технологий. IT-команда предложила начать с разработки требований к приложению. Они подсчитали, что на это потребуется пять или шесть месяцев. Когда станут известны требования, они смогут зафиксировать сроки и стоимость проекта. Пять аналитиков и один управляющий проектом разработают требования.
Вице-президент должен был инвестировать только лишь в первую фазу проекта 500 тысяч долларов – приличные деньги всего лишь за описание требований того, что он хотел. Цена разработки самого приложения была неизвестна, но можно было предположить, что она будет в разы выше первоначальных затрат. Ему следовало предоставить предложения своему начальнику в комитете финансов и в IT (для планирования). Никто не хотел рисковать такими средствами без полной уверенности в успехе продукта.
Конец ознакомительного фрагмента
Купить полную версию книгиЖалоба
Напишите нам, и мы в срочном порядке примем меры.
Комментарии