Видео об инкрементах и инкрементальности: Кстати, а зачем нужно, чтобы умещалось в один спринт?
Следование принципу Скрама об инкрементальности. Следование, конечно же, не слепое – у работы инкрементами множество плюсов, о них (будет) написано здесь.
Scrum требует, чтобы Scrum Master способствовал возникновению среды, в которой: 1. Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog. 2. Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность. 3. Scrum Team и заинтересованные лица инспектируют результаты и вносят правки для следующего Sprint. 4. Повторить.
Вся Scrum Team несет ответственность за создание ценного, полезного Increment в каждом Sprint.
Developers — это люди в Scrum Team, которые привержены созданию любого аспекта готового к использованию Increment в каждом Sprint.
Increment Increment — это конкретная ступенька к достижению Product Goal. Каждый Increment является дополнением ко всем предыдущим. Они тщательно проверяются для обеспечения совместной работы всех Increments. Чтобы предоставить ценность, Increment должен быть пригодным для использования. В рамках одного Sprint можно создать несколько Increments. Итоговые Increments представляются в ходе Sprint Review, тем самым поддерживая эмпиризм. Однако Increment может быть поставлен заинтересованным лицам еще до окончания Sprint. Sprint Review не должно считаться единственным моментом для поставки ценности. Работа не может считаться частью Increment, если она не соответствует определению готовности.
Определение готовности — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту. В момент, когда элемент Product Backlog стал соответствовать определению готовности, рождается Increment. Определение готовности обеспечивает прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Increment. Если элемент Product Backlog не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения. Если определение готовности для Increment является частью единых стандартов организации, все Scrum Teams должны использовать его в качестве необходимого минимума.
Решения Product Owners отражены в содержании и порядке элементов Product Backlog, а также в инспектируемом Increment во время Sprint Review.
Scrum Master служит Scrum Team несколькими способами, в том числе: ...• помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, соответствующих определению готовности; ...
Тема третья: как будет выполняться выбранная работа? Developers для каждого выбранного элемента Product Backlog планируют работу, необходимую для создания Increment, соответствующего определению готовности. Это часто делается путем декомпозиции элементов Product Backlog на более мелкие задачи продолжительностью не более одного дня. То, как это делается, остается на усмотрение разработчиков. Никто не указывает им, как превращать элементы Product Backlog в Increments ценности.
Каждый артефакт содержит приверженность, которая предоставляет информацию для поддержания прозрачности и сфокусированности, и по которой оценивается прогресс. • Для Product Backlog это Product Goal. • Для Sprint Backlog это Sprint Goal. • Для Increment это определение готовности.
Sprint Backlog Sprint Backlog состоит из Sprint Goal (почему), набора выбранных на Sprint элементов Product Backlog (что), а также осуществимого плана действий по поставке Increment (как).
Эта страница – "заглушка", чтобы проверить спрос на эту тему. Ведь было бы странно, если бы я писал о проверке гипотез, но сам не проверял бы их. Если наберётся хотя быть 100 посещений этой страницы за квартал, то я перенесу эту статью сюда (статьи на Тильде получаются красивыми, но на оформление уходит несколько часов). А до этого момента вы можете прочитать другие статьи в моем блоге на SkillsCup.com.