Что мы должны называть спринтами в гибкой разработке, если не продаем консалтинг клиенту?

Я бы назвал их «итерациями». Вы можете описать свой процесс с точки зрения итераций для ваших клиентов - например, мы работаем в двухнедельных итерациях. Это означает, что в первый день мы определяем работу, которую собираемся выполнить в следующие две недели... и т.д...

Условия государственного сектора

Каждая отрасль и сектор имеет свой собственный диалект . В государственном секторе гибкие методы обычно называют «модульной разработкой», а спринты обеспечивают «инкременты» или «полезные сегменты». Пример см. на стр. 7 Руководства по заключению контрактов для поддержки модульной разработки .

Условия частного сектора

Для компаний, которые разбираются в методах Agile, часто бывает полезно определить термины так, как вы их подразумеваете. Для своих клиентов я обычно определяю agile-фреймворки (например, Scrum) как:

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

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

Смотрите также

• http://www.cio.gov/documents/25-point-implementation-plan-to-reform-federal%20it.pdf
• http://scrum.jeffsutherland.com/2010/01/iterative-vs-incremental-development.html

С точки зрения Scrum спринт — это не просто итерация. У него также есть обязательства (планирование) и ответственность (демонстрация) .

Если вы измените терминологию, вы не сможете общаться с другими практикующими. Если руководство не понимает определения спринта и останавливается на терминологии, оно может подумать, что скрам означает, что разработчики будут строиться и делать это каждое утро:

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

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

Я не думаю, что вам действительно нужно беспокоиться о семантике. «Спринт» — это довольно стандартная терминология, и клиентов больше будут интересовать итоговые обзоры спринтов/графики выгорания и т. д. Пока работа выполняется, что в названии?

Сказав это, если вам действительно нужно изменить имя, как насчет таймбокса? Если вы используете гибкую терминологию DSDM, вы можете разбить проект на итеративные циклы, а затем разбить итерации на временные интервалы. Это то же самое, что и «спринт», но с другим названием.

Как насчет «временных рабочих пакетов»?

Какова перспектива того, что вы называете спринтом для вашего клиента? Есть ли у клиента видимость и получение результата, который он оценивает и должен утвердить? Предоставляет ли он отзывы о продукте, который вы рассматриваете для будущих выпусков? Достаточно ли четко и понятно определен продукт, чтобы завершить разработку? На мой взгляд, вы должны встать на ноги, чтобы назвать это так, чтобы это имело для него смысл, а также быть достаточно ясным, чтобы команда могла понять точку зрения клиента. Без дополнительной информации вы можете назвать это «выпуском», «версией» или чем-то подобным. Тема важна, так как скорее опишет и поможет оправдать ожидания.