Многие знакомы с понятием гибкой разработки (Agile) и понятием спринтов (это из SCRUM или итераций если выражаться терминами Agile).

Что такое точка в спринте? Это наше понятие (возможно оно кем-то уже было придумано), которое означает что дальше планировать нет смысла.

Мы нашли два типа точки: Перебор и Качеля.

Перебор

Оптимальная длительность спринта по нашему опыту: 1-2 недели. Если мы видим что объем требований вылазит за эти рамки — стоит часть требований перетащить в план. Расставить приоритеты.

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

Если бы мы пробовали их делать проектным методом и сразу закладывали в план проекта, то после их реализации мы бы получили лишний бюджет, лишние затраты, потери времени и лишний (не нужный) функционал — в лучшем случае. В худшем — провал проекта.

Примеры:

  1. Делали CRM-систему. И закладывали туда очень сложную логику формы ввода данных клиента. В какой то момент мы отказались от этой идеи, поняв что нам хватает обычного справочника клиентов и сделанной логики полей. Сэкономили себе 50-100 тр.
  2. Писали сайт для банка. Планировали механизм открытие мобильной версии сайта на поддомене. В итоге отказались сделав выбор в пользу адаптивных механизмов. Сэкономили 100-200 тр.

Качеля

Это требование, которое может слишком сильно качнуть разработку в одну из сторон. Так сильно, что в зависимости от результата этого спринта, разработка может пойти по одному из нескольких путей. И состав будущих спринтов может сильно отличаться по списку требований, стоимости и срокам.

Примеры:

  1. Поиск подходящей готовой темы. Если найдем и подойдет, то часть разработки можно не делать. А если не подойдет, то придется рисовать, верстать и писать ряд плагинов под задачи. Разница в затратах 100-200 тр. Но найдем ли мы подходящую тему? Это вопрос открытый. И пока не попробуем — не узнаем.
  2. Поиск механизма улучшения поиска. Если подойдет Sphinx — то одни затраты. А если не подойдет? То другие решения и другие затраты.

Как только мы находим подобные требования, то спринт заканчивается на них. И все требования которые зависимы от этого результата выносятся в план. Пока не попробуем — не узнаем по какому плану пойдем.