Как измерить полноту проекта? [закрыто

Question

Существуют ли какие -либо формальные/неформальные меры сравнения завершенной функциональности с начальными требованиями проекта. В частности, моя цель - определить любые пропущенные требования на ранних этапах проекта. Пройдя через многие методологические статьи и книги Agile/Scrum, один из способов сделать это был бы обзор требований во время «обзора спринта», но мне было интересно, есть ли какие -либо другие методы/инструменты.

Спасибо,

Answer 1

Существуют ли какие -либо формальные/неформальные меры сравнения завершенной функциональности с начальными требованиями проекта.

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

Большинство гибких команд используют пользовательские истории в качестве «начальных требований». Пользовательская история будет вашим первоначальным требованием, которым было бы достаточно, чтобы начать команду. Используемая мера должна быть тем, что большинство команд называют «Критериями выполнения». Каждая пользовательская история должна иметь критерии выполненных. Например. Чтобы вызвать выполненное отставание, этот список вещей должен быть сделан. Установив это, мы не беспокоимся о том, как это будет сделано, только то, что нужно сделать.

Во время обзора Sprint команда сделала бы шоу и рассказывала о рабочем программном обеспечении, и если оно соответствует критериям выполненного, то PO одобрит его официально отмеченным.

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

Итак, чтобы подвести итоги:

Первоначальные требования, т. Е. Пользовательские истории должны иметь критерии «что», что нужно сделать ». Если что -то упущено и обнаружено во время Sprint, PO может изменить критерии выполненной истории пользовательской истории после получения одобрения от команды.

Во время обзоров Sprint рабочее программное обеспечение может быть измерено по критериям выполненного, и, если оно измеряется, пользовательская история может быть названа выполнена.

http://scrumalliance.org/articles/105-what-is-definition-of-done-dod

Answer 2

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

Обзор спринта - это одно место для сбора обратной связи и новых требований. Тесты на удобство использования также помогают. Но больше всего помогает использовать программное обеспечение командой QA и/или реальными пользователями.

Если вы использовали Jira и Greenhopper для управления вашими требованиями (в качестве историй), вы можете найти полезные поиск историй, созданных после определенной даты. Поиск измененных требований будет более интересным.

Answer 3

Завершено ли программное обеспечение? Очевидно, что настоящим эталоном для полноты является чьем -то мнение о том, что программное обеспечение должен делать.

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

Сообщение, которое я получил от Agile School of Gonder, заключается в том, что измерение полноты - это пустая трата времени - это действительно неправильный вопрос.

Например, с Scrum вы делаете приоритетное отставание от всех требований и просто начинаете работать в списке. Когда заканчиваются деньги/желание ... вы останавливаетесь.

Answer 4

Если вы идете по маршруту Agile/Scrum, как вы подразумеваете, то, как правило, вы захотите разбить проект на небольшие отдельные единицы усилий. Проект содержит эпосы (или является эпическим), эпос содержит истории, история содержит задачи. (Задача в идеале должна быть 4-8 часов работы. Что-то, что кто-то может сделать в рабочий день.)

Поскольку каждая история завершена, она должна быть проверена и проверена. Обычно это не выполняется для задач, потому что часто одна задача не может быть проверена пользователем, пока другие задачи для истории не будут завершены. Нельзя ожидать, что пользователь проверит «напишите метод для сохранения заказа в базу данных», но вместо этого тестирует ». Когда эта кнопка нажимается, порядок сохраняется в базе данных, а пользователю показывают обновленную корзину для покупок, чтобы включить повторно рассчитанные налоги и доставка ".

Это тестирование/проверка нет Сделано разработчиком. Это должно быть подтверждено тем, кто отвечает за продукт/проект или его делегат. Разработчик, естественно, проверит это так, как он или она написал, ожидая, что он будет работать таким образом. Если что -то было неверно истолковано в требованиях, это будет просто неверно истолковано снова.

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

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

Один из способов попытаться подойти к концепции жидких историй и меняющихся требований - не думать не с точки зрения «проектов», а просто эпопеи и истории. Эти дискретные подразделения должны быть полностью работоспособными и тестируемыми сами по себе (хотя у некоторых, конечно, есть другие в качестве предварительных условий). Изменение приоритетов может перемещать истории по желанию. «Проект» не должен быть «приостановлен», если приоритеты меняются, его истории просто перемещаются в отставание вместо других историй.

Идея состоит в том, что руководство - это рулевое управление, куда вы идете дальше, не просто предоставляете вам список направлений и надеясь, что вы прибудете к ним в правильном порядке.

В этом смысле «полнота» «проекта» почти полностью теряет свое значение. Сколько «полного» зависит от того, кто владеет продуктом/проектом. Они могут добавить к нему или удалить из него по желанию, легко сдвинуть приоритеты и т. Д., Если они хотят знать: «Когда мы прибудем в пункт назначения А?» Тогда это зависит от них. Вы дали им оценки о том, сколько работы участвует на каждом шаге на этом пути, они должны управлять тем, что, по их мнению, является лучшим направлением, чтобы попасть туда, пока вы предоставляете работу.