итеративная разработка.

То есть Scrum – это одновременно и инкрементальный, и итеративный подход.

Майк Кон в своей замечательной книге «Пользовательские истории. Гибкая разработка программного обеспечения»[37] хорошо объясняет главные отличия между понятиями «итеративный» и «инкрементальный»:

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

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

У нас уже есть план мероприятий для принятия первой части системы, пусть и известно, что она неполная или слабая в некоторых областях, и мы в несколько приемов усовершенствуем эти области, используя цикл «обзор-контроль-адаптация».

Scrum-команда, применяющая инкрементальную разработку, так же как она применяет цикл «обзор-контроль-адаптация» во время ежедневных scrum-митингов, использует эту технологию для проекта в целом. В этом цель планирования спринтов, управления бэклогом спринта и проведения ретроспектив.

Вот почему владелец продукта так важен для scrum-команды и ему отводится отдельная роль. Задачи владельца продукта:

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

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

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

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

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме итеративная разработка.:

  1. Исследовательские и внедренческие разработки
  2. РАЗРАБОТКИ
  3. Разработка стратегии позиционирования
  4. контроля разработки
  5. Разработка туристского продуктаa
  6. ЭТАПЫ РАЗРАБОТКИ КАДРОВОЙ ПОЛИТИКИ
  7. Процедура разработки бизнес-плана
  8. Разработка программы стимулирования
  9. Разработка компенсационного пакета
  10. Принципы разработки модели оплаты по результату
  11. Разработка интернет-магазина сторонней организацией
  12. Консалтинг и аутсорсинг при разработке бизнес-плана
  13. Методика разработки программ премирования директоров
  14. Разработка бюджета реализации инвестиционного проекта