17 Виды документации в xp
Пользовательские истории
XP и другие гибкие методологии предпочитают общение лицом к лицу вместо всесторонней документации; быструю адаптацию к изменениям вместо фиксации на проблеме. Это достигается следующим:
Истории короткие. Они представляют маленькие кусочки деловой ценности, которое можно реализовать в период от дней до нескольких недель.
Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта
Нуждаются в очень небольшом обслуживании
Рассматриваются только в момент использования
Поддерживают близкий контакт с клиентом
Позволяют разбить проект на небольшие этапы
Подходят для проектов, где требования изменчивы или плохо поняты.
Облегчают оценку заданий
Ограничения
Без определенных приемочных испытаний, они являются открытыми для различных интерпретаций, что усложняет их использование как основу для соглашения
Они требуют близкого контакта с клиентом на протяжении всего проекта, что в некоторых случаях может быть сложно либо приводить к накладным затратам
Они могут плохо масштабироваться на больших проектах
Они полагаются на компетентность разработчиков
Они используются для начала дискуссии. К сожалению, они могут не фиксировать окончание дискуссии и таким образом не в состоянии служить надежным методом документации системы.
Выбранные истории являются основой для планов итераций.
План итерацийПлан итераций ограничивает количество заданий, которые будут выполняться в данной итерации. Выборка производится на основании текущей скорости проекта, то есть на основе оценки идеального срока, умноженного на фактор загрузки. Истории пользователей получают приоритеты внутри цикла и трансформируются в задачи разработки, каждая из которых выполняется в течении одного-трех идеальных рабочих дней.
Если в результате детализации ожидаемое время разработки превосходит время цикла, то некоторые истории переносятся на более поздний срок. Этот эффект снежного кома — вполне обычная практика, поскольку детальные задачи часто распадаются на отдельные части, когда сумма времени для каждой превосходит время для целого.
План релизаПлан релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе. Преимущество отдается небольшим инкрементальным релизам. Выбранные к реализации истории транслируются в конкретные задания программирования, такие как создание формы ввода или процедуры запроса к БД. Обычно после нескольких итераций оценки необходимых операций осуществляются очень точно. Как только план выполнения итераций выходит из-под контроля и, по крайней мере, после каждых нескольких удачных итераций повторно собираются совещания по поводу нового плана релиза.
18Стратегии конструирования ПО водопадная, инкрементная, эволюционная
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.
По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Эволюционная модель. Инкрементная разработка
Идея, лежащая в основе инкрементной разработки, состоит в том, что программную систему следует разрабатывать по принципу приращений, так, чтобы разработчик мог использовать данные, полученные при разработке более ранних версий (релизов) ПО. Новые данные получаются как в ходе разработки ПО, так и в ходе его использования, где это возможно. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте. В ходе каждой итерации организация модели изменяется, и к ней добавляются новые функциональные возможности.
Для организации инкрементной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление проекта: добавляется новая документация как текстовая, так и графическая (например, новые диаграммы на UML), расширяется набор тестов, добавляются новые программные коды и т. д. Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементная разработка проходит лучше всего, если следующая итерация n+1 начинается после того, как обновление всех артефактов в итерации n закончено, и существенно хуже, если время, требуемое на обновление артефактов, значительно превышает выбранный интервал.
В результате каждой итерации получается работающее, но не полнофункциональное ПО, которое еще не является программным продуктом и не подлежит распространению. Результат каждой итерации в общем случае нельзя рассматривать и как прототип ПО. Точнее следует считать, что в результате каждой итерации создается версия некоторой части ПО. Необходимо заметить, хотя как правило на каждой итерации определяются и реализуются новые требования, некоторые итерации могут быть целиком посвящены усовершенствованию существующей программы, например с целью повышения ее производительности.
Гибкие технологии разработки ПО
Минимизируют риски благодаря разделению процесса разработки на маленькие промежутки времени (итерации), обычно 1-4 недели.
Каждая итерация может рассматриваться как полноценный проект (может включать в себя планирование, анализ требований, проектирование, реализацию, тестирование и документирование).
Обычно результатом итерации не является продукт, готовый к выходу на рынок. Но целью каждой итерации является получение стабильной версии продукта.
В конце каждой итерации происходит переоценка приоритетов проекта, что значительно сокращает риски.
Все гибкие методологии имеют общие характеристики:
• итеративная разработка;
• фокус на взаимодействии и коммуникации;
•полный или частичный отказ от создания дорогостоящих промежуточных артефактов проекта.
19 SCRUM
Основой Scrum является итеративная разработка. Scrum определяет итеративные правила управления проектом, которые призваны обеспечивать достижение максимального эффекта от реализованной функциональности.
В Scrum определяются основные правила взаимодействия участников команды, которые призваны обеспечивать максимально быструю реакцию на существующую ситуацию.
Каждая итерация в Scrum может быть описана так: планируем – фиксируем – реализуем – анализируем.
За счет фиксирования требований на время одной итерации и изменения длины итерации методология Scrum позволяет управлять балансом между гибкостью и предсказуемостью разработки.
Общие положения
3 роли:
владелец продукта (Product Owner) - отвечает за определение требований к продукту
команда (Team) - группа самостоятельных и инициативных разработчиков, ответственных за реализацию проекта
скрам-мастер (ScrumMaster) отвечает за решение всех организационных проблем и соблюдение методологии Scrum.
3 фазы проекта:
Подготовка (Pregame): общий план проекта, список основных требований к продукту, высокоуровневая архитектура продукта.
Реализация (Game): итеративное развитие продукта.
Завершение (Postgame): действия, необходимые для подготовки продукта к выходу на рынок.
Реализация проекта в Scrum
Фаза реализации разбита на последовательность итераций - спринтов (Sprint).
В результате каждого спринта в продукте реализуется новый, заметный для владельца продукта, объем функциональности.
В конце каждого спринта продукт остается в работоспособном состоянии.
Спринт начинается с сессии планирования (Sprint Planning Meeting) - определяется объем функциональности, которая будет реализована в течение спринта.
Ежедневно проводится собрание участников проекта - скрам-сессия (Daily Scrum Meeting).
По завершению спринта проводится демонстрационная сессия (Sprint Review Meeting).
Документация в Scrum
Всего 3 документа:
журнал продукта (Product Backlog) -высокоуровневый список функциональных и техническихтребований, необходимых для реализации продукта
журнал спринта (Sprint Backlog) - детализированный список функциональных и технических требований, необходимых для успешного завершения итерации
график спринта (Burndown Chart) - показывает ежедневное изменение общего объема работ, оставшегося до завершения итерации.
Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча.
Сам термин Scrum, я бы определила так — это методология управления проектами, которая построена на принципах тайм-менеджмета. Основной ее особенностью является вовлеченность в процесс всех участников, причем у каждого участника есть своя определенная роль. Суть в том, что не только команда работает над решением задачи, но все те, кому интересно решение задачи, не просто поставили ее и расслабились, а постоянно «работают» с командой, и эта работа не означает только постоянный контроль.
Основные термины, которые используются в методологии:
Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.
Scrum-мастер — это человек, которого можно назвать руководителем проекта, хотя это не совсем так. Главное, что это человек, «зараженный Scrum-бациллой» на столько, что несет ее как своей команде, так и заказчику, и соответственно следит за тем, чтобы все принципы Scrum соблюдались.
Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать.
Спринт - отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз).
Бэклог
(backlog) -
это список всех работ. Можно сказать,
что это ежедневник общего пользования 
Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.
Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт.
Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.
Планирование спринта — это совещание, на котором присутствуют все (команда, Scrum-мастер, Владелец продукта). В течение этого совещания Владелец продукта определяет приоритеты заданий, которые он хотел бы увидеть выполнеными по истечении спринта. Команда оценивает по времени, сколько из желаемого они могут выполнить. В итоге получается список заданий, который не может меняться в течение спринта и к концу спринта должен быть полностью выполнен.
Попробую объяснить все это на примере работы PR-агентства, как бы это могло выглядеть, если бы они работали по Scrum.
Компания клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum — этот человек называется Владелец продукта. Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер), в подчинении которого находится команда (Scrum-команда). На совместном совещании (планировании спринта) компания и агентство решают, что они будут отчитываться-планировать каждые 2 недели (длина спринта). На первые 2 недели они запланировали список задач (спринт-бэклог), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта), говорит какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное что здесь должно быть учтено, что на момент планирования первого спринта должен быть спланирован весь список заданий на 2 месяца (product-бэклог), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.