Лучшая поставка для проекта «Электронная книга»

Как эти принципы могут помочь нашему проекту «Электронная книга»? Вспомним о проблемах, с которыми столкнулась команда: их проект провалился, потому что отсутствовали важные функции, которые были у конкурентов (поддержка отраслевого стандартного формата для электронных книг и предоставление пользователям доступа к почте на этом устройстве), а функции оказались неактуальными (шаблон для создания интернет-магазина).

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

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

• После десяти месяцев разработки они произвели сборку программы, которую можно было загружать в прототип электронного устройства и раздавать бета-версии первым пользователям. Руководитель проекта, поговорив с ними, обнаружил, что они действительно хотели бы иметь доступ к документам Microsoft Word и газетным статьям в своих электронных книгах. Команда выделила часть следующего спринта на разработку почтового интегратора для электронной книги, чтобы пользователи могли рассылать статьи со своих устройств.

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

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

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

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

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

Рис. 3.2. В начале каждой итерации команда выбирает функции для реализации из списка невыполненных работ

В команде уже обсуждались способы сокращения объема работ, необходимых для сохранения этих документов. Состоялись обстоятельные дискуссии об «уровне детализации» документации. Но всякий раз при попытке что-либо убрать кто-нибудь приводит «вескую» причину, почему это не стоит делать. Ведь если не создать описание этой конкретной функции, требования, дизайна или примера, то кто-нибудь неправильно поймет документ. А если он будет неправильно реализован, то появится повод предъявить претензии. Со стороны кажется, будто каждый фрагмент документации необходим, потому что в противном случае над командой нависнет опасность создать плохое программное обеспечение.

Есть ли способ избежать этой опасности без вреда для проекта? Существует ли «правильный» уровень степени документированности проекта?

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

Еще по теме Лучшая поставка для проекта «Электронная книга»:

  1. Лучшая книга, какую я когда-либо читал!
  2. Сформируйте у персонала осознание потребности в качест­венной работе и создайте возможность для улучшения качества. 2. Установите цели для постоянного совершенствования дея­тельности. 3. Создайте организацию, которая будет работать над дости­жением целей, выработав условия для определения проблем, вы­бора проектов, сформировав команды и выбрав координаторов. 4. Предоставьте возможность обучения всем сотрудникам организации. 5. Выполняйте проекты для решения проблем. 6. Информируйте сотрудников о
  3. КТО ДОЛЖЕН БЫТЬ ХОЗЯИНОМ «ЭЛЕКТРОННЫХ» ПРОЕКТОВ
  4. Это не книга для начинающих
  5. Для кого предназначена эта книга
  6. ВВЕДЕНИЕ. Для кого эта книга?
  7. О том, для чего нужна эта книга
  8. Денис Каплунов. Контент, маркетинг и рок-н-ролл. Книга-муза для покорения клиентов в интернете, 2014
  9. Таблица 1.7 Контокоррентная книга (для учета расчетов с организациями и лицами) за ____________________200__г.
  10. Таблица 1.7 Контокоррентная книга (для учета расчетов с организациями и лицами) за ____________________200__г.
  11. Глава 1. Скрипты для электронной коммерции
  12. Глава 5. Программные продукты для создания электронного магазина
  13. Книга покупок и Книга продаж
  14. Электронный кэш – деньги для бандитов, наркомафии, террористов, киллеров и коррупционеров
  15. ПОСТРОЕНИЕ ЭЛЕКТРОННЫХ СИСТЕМ ДЛЯ ГОСУДАРСТВЕННОГО АППАРАТА
  16. ИСПОЛЬЗОВАНИЕ ЭЛЕКТРОННЫХ ПРОЦЕССОВ ДЛЯ РЕШЕНИЯ СЛОЖНЫХ ПРОБЛЕМ
  17. 1.8.2. Новая бизнес-модель для электронных медиа: доверительная реклама