К основному контенту

Эстимация нефункциональных требований

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.




Несколько недель назад я обещал написать статью об особых сложностях, связанных с оценкой (эстимацией) нефункциональных требований. Для начала давайте вспомним, что нефункциональные требования – это требования, которые больше связаны с состоянием самой системы, нежели с деталями ее функциональности. Обычно нефункциональные требования касаются производительности, корректности, удобством сопровождения системы (maintainability), функциональной совместимости (interoperability), ее переносимости на другие платформы (portability) и т.д. Кстати, нефункциональные требования также могут быть описаны в виде Пользовательских Историй. Трудность при их эстимации состоит в том, что эти требования имеют двойные издержки. Первый тип издержек – это стоимость первоначального соответствия, а второй – стоимость непрерывного соответствия этим требованиям. Давайте рассмотрим конкретный пример, чтобы на практике разобраться с этими типами издержек.


Представим, что наша команда работает над новым продуктом, к которому имеются требования к производительности. В течение первого спринта команда может помнить об этих требованиях, но, скорее всего, они не будут сразу заниматься тестированием производительности продукта, поскольку еще написано недостаточно кода. Несомненно, на протяжении последующих нескольких спринтов команда будет писать код, и, скажем, к пятому спринту она решит, что кода написано уже достаточно и захочет занятся тестированием его производительности. Помните, мы говорили, что первый тип издержек – это стоимость первоначального соответствия? В данном случае она будет равняться выполненному в пятом спринте объему работ по тестированию производительности. На самом деле, его не намного сложнее оценить, чем остальные элементы Беклога Продукта, которые команда оценит в идеальных днях или же условных единицах работы  - "story points".

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

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

Возвращаясь к вопросу, как же нам оценивать данные издержки? Я думаю, лучше это делать раздельно. Для начала оцените стоимость первоначального соответствия, так же, как вы это делаете для любого другого элемента Беклога Продукта. Команда и Владелец Продукта так же должны оценить, когда они смогут его выполнить. Добавление тестирования производительности после пяти спринтов очень отличается от его добавления после двадцати. Для согласования доли этого налога команда и Владелец Продукта определяют, когда будет проходить его «выплата» – каждый спринт или же каждые n спринтов. Тогда команда сможет прикинуть, сколько работы необходимо выполнить на протяжении запланированного количества спринтов, и распределить этот объем на каждый спринт.

Для примера представим, что команда и Владелец Продукта договорились проводить тестирование производительности продукта каждый четвертый двухнедельный спринт. Если команда оценила этот объем в 6 условных единиц работы, то на каждый спринт приходится примерно по 1,5 единицы. Если скорость (velocity) составляет 30 таких единиц, то эти 1,5 единицы составляют 5%-ный налог. Вероятно, что в первый раз команда ошибется с точностью такой оценки. Это не страшно, так как с количеством пройденных спринтов она сможет четко отследить, сколько усилий уходит на тестирование производительности, и использовать эти наблюдения для корректировки последующих оценок стоимости непрерывного соответствия продукта нефункциональным требованиям.


Переведено с английского проектом Agile Translations - Ильей Павличенко,  Дарьей Дубининой,  Андреем Перервой и Игорем Добритским. 

Оригинальная статья: "Estimating Non-Functional Requirements".

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн