33 Виды документации в xp

Пользовательские истории

XP и другие гибкие методологии предпочитают общение лицом к лицу вместо всесторонней документации; быструю адаптацию к изменениям вместо фиксации на проблеме. Это достигается следующим:

• Истории короткие. Они представляют маленькие кусочки деловой ценности, которое можно реализовать в период от дней до нескольких недель.

• Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта

• Нуждаются в очень небольшом обслуживании

• Рассматриваются только в момент использования

• Поддерживают близкий контакт с клиентом

• Позволяют разбить проект на небольшие этапы

• Подходят для проектов, где требования изменчивы или плохо поняты.

• Облегчают оценку заданий

Ограничения

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

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

• Они могут плохо масштабироваться на больших проектах

• Они полагаются на компетентность разработчиков

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

Выбранные истории являются основой для планов итераций.

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

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

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

34+-

Достоинствами XP, если его удается применить,

является большая гибкость,

возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков,

высокое качество получающегося в результате кода

отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.

Ø  короткие сроки разработки версии

Ø  контроль времени разработки

Ø  максимально короткие сроки ввода программы в эксплуатацию

Ø  отсутствие строгой архитектуры системы (целостность кода обеспечивается постоянным тестированием, рефакторингом дизайна, частой мелкой интеграцией кода)

Ø  постоянная качественная обратная связь с заказчиком

Ø  сведение к минимуму энтропии (тенденции системы к накоплению ошибок с течением времени и к существенному росту стоимости внесения в нее изменений).

Ø  особенная внутренняя организация работы команды и рабочего пространства (небольшое количество человек, парное программирование)

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

 

35

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-бэклог), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено.

38

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

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

1. поиск плохо спроектированных участков кода (модели), для которых требуется проведение рефакторинга;

2. определение рефакторинга (синтез из поддерживаемых базовых рефакторингов), который следует применить;

3. проверка или доказательство неизменности поведения системы после выполнения преобразований;

4. реализация применения рефакторинга и, в частности, разработка пользовательского интерфейса и диалогов, поддерживающих процесс применения рефакторинга;

5. сохранение целостности модели, то есть распространение произведенных изменений на другие части модели (диаграммы, тесты);

6. оценка эффекта, полученного в результате применения рефакторинга.

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

Стереотипы являются одним из трех типов механизмов расширяемости в унифицированном языке моделирования (UML). Они позволяют проектировщикам расширять словарь UML для создания новых элементов моделирования, получаемых из существующих, но имеющих определенные свойства, которые подходят для конкретной проблемы предметной области или для другого специализированным использования. Термин происходит от первоначального значения слова «стереотип», который используется в печати. Например, примоделировании сети вам могут понадобиться символы для представления маршрутизаторов и концентраторов. С помощью стереотипных узлов вы можете представлять их в виде примитивных строительных блоков.

Графически стереотип отображается, как имя, заключенное в кавычки («», или, если такие кавычки недопустимы, <<>>) и расположенного над именем другого элемента. В дополнение или в качестве альтернативы она может быть обозначена соответствующей иконкой. Значок может даже заменить весь символ UML. Например, стереотипы диаграммы классов могут быть использованы для описания методов поведения, таких как «конструктор» и «геттер». Несмотря на свой внешнее представление, «интерфейс» не стереотип, а классификатор.^[1]

Subversion — централизованная система (в отличие от распределённых систем, таких как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.

Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель копирование — изменение — слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель блокирование — изменение — разблокирование.

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

При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, то автоматически создаётся новая версия.

Графическое представление поля выбора решения. Конусы неопределенности.

Стр 17-19

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