Вам нужно доставить работающее программное обеспечение в сроки/спринт Agile?

Помимо четырех ценностей, эти принципы также актуальны:

Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.

и

Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, отдавая предпочтение более коротким временным рамкам.

и

Работающее программное обеспечение является основным мерилом прогресса.

Преимущества гибкой разработки программного обеспечения лучше всего реализуются за счет частой поставки работающего программного обеспечения.

Также важно отметить, что временные рамки не являются неотъемлемой частью гибкой разработки программного обеспечения. Слова «итеративный», «инкрементный», «итерация» и «временной интервал» нигде в Манифесте не встречаются. Тем не менее, некоторые методологии основаны на тайм-боксах — экстремальное программирование и Scrum — две популярные платформы, которые используют тайм-боксы. Другие — нет — Канбан можно использовать с непрерывным потоком.

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

Результат каждой итерации зависит от фреймворка. Например, Scrum требует, чтобы элементы бэклога продукта изменяли состояние продукта, которое должно быть завершено в каждом спринте. Другие методологии могут не иметь этого строгого определения. Вы можете определить методологию, которая обеспечивает ценность. Различные «двойные» методы также определяют ценность с точки зрения работы по обнаружению и доставке.

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

Вам нужно доставить работающее программное обеспечение в сроки/спринт Agile?

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

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

Однако... вы представляете интересную перспективу с этими вопросами:

• Означают ли приведенные выше мысли, что Agile-спринт/таймбокс не должен поставлять работающее программное обеспечение, а только что-то работающее, где работа определяется как то, что может проверить гипотезу о продукте?
• Учитывая, что спринт дает что-то, что может проверить гипотезу о продукте, есть ли у этого ограничения? Возьмем пример спринта, тестирующего бизнес-правила, может ли спринт предоставить только бизнес-правила, записанные на бумаге, а затем отправить человека для взаимодействия с конечным пользователем и вычисления входных данных конечного пользователя, следуя правилам и измеряя, получил ли конечный пользователь значение на выходе?

Я ответил на ваш вопрос в заголовке: «Если вы создаете программный продукт», и я сказал «да». Если ваш продукт представляет собой программное обеспечение, то следующее приращение или усовершенствование продукта, конечно же, будет в форме программного обеспечения. То, о чем вы спрашиваете вместе с другими вопросами, для меня больше похоже на предварительное исследование или некую исследовательскую деятельность, направленную на определение того, что должно войти в ваш программный продукт.

В этом случае вы можете использовать Spike внутри своего спринта для проведения исследовательского исследования. Затем в конце спринта вы предоставляете некоторую функциональность в программном продукте (не так много, как в других спринтах из-за всплеска), плюс результат вашего исследования (в виде бумажных форм или чего-то еще). Затем вы можете использовать новую форму продукта и бумажные формы, чтобы решить, что делать дальше (что добавить в программное обеспечение, если вам нужны дополнительные исследовательские исследования, возможно, бумажные формы можно улучшить, изменить и т. д., чтобы лучше собирать данные). информация и др.).

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

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

Затем вы можете переключаться между этими дорожками по мере необходимости, например:

или вот так:

Таким образом, вы держите все в порядке, вам не нужно смешивать разные результаты с одним и тем же «определением выполненного», ваши показатели не путаются от одного типа спринта к другому и т. д. Оба трека также могут продолжаться. в то же время, если у вас есть люди, которые могут работать над программным продуктом, в то время как другие возятся с бумажными формами в поисках информации.

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

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

Как уже упоминалось другими, спринты являются частью Scrum. Они не имеют ничего общего с Agile.

Раньше Scrum Guide ясно излагал идеи, но чем дальше мы продвигаемся, тем более неясными они становятся*. Текущее руководство по Scrum говорит, что мы должны предоставить приращение к концу спринта, и приращение связано с «ценностью». Создается впечатление, что авторы пытаются охватить большое количество ситуаций одним инструментом и поэтому стараются не быть точными. Итак.. Я думаю, что сам документ пытается сказать, что нет — вам не нужно выпускать новую часть функциональности для PRD в конце спринта. Но то, что большинство людей считает скрамом, приведет к релизу в конце каждого спринта.

Зачем нам спринты?

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

Спринты позволяют нам решать проект с помощью небольших частей работы, выполняемых часто.

Спринты сами по себе не способствуют частым выпускам. Вы можете сделать это без них. Более того, зачастую вы могли выполнить работу быстрее , чем спринты. Вы можете использовать «точно в срок» и/или «непрерывную доставку» для выпуска программного обеспечения гораздо чаще, чем при спринтах.

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

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

Написание бизнес-правил — это просто документация, которая не так полезна, как работающее программное обеспечение. Относится к следующему пункту.

Написание требований (похоже, это то, что вы имеете в виду под документацией) может быть ступенькой к работающему программному обеспечению, что делается позже. Так что уверен - работающее программное обеспечение лучше, потому что это означает, что было проделано больше работы. Как в непрерывных методах (ToC, JiT, CD), так и в подходах, основанных на времени (Waterfall, Scrum), вы сначала пишете требования, а затем пишете программное обеспечение.

Agile Manifesto, когда речь идет о чрезмерном документировании программного обеспечения, относится к:

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

Построение в порядке описанных слоев (бизнес-правила, код, который вычисляет эти правила (которые обычно находятся на бэкэнде), пользовательский интерфейс) является водопадом и представляет риски водопада.

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

Вы продолжаете упоминать «пользовательский ввод», но это НЕ то, что нам нужно для создания отличного программного обеспечения. Нам нужна информация . И в зависимости от проекта самая важная информация может меняться:

• Осуществимость: уверены ли мы, что действительно сможем реализовать такую ​​идею — может быть, технологии еще нет? А может технология есть, а идея непомерно дорогая/медленная/неудобная.
• Обучение: чем больше мы внедряем (не обязательно выпускаем), тем лучше понимаем предметную область и идею
• Инвестиции: уверены ли мы, что эта идея получит финансирование? Возможно, нам нужен прототип, а не реальное программное обеспечение в RPD.
• И, конечно же, типичные цели, такие как: уверены ли мы, что решаем проблемы наших пользователей? Это тот случай, который определенно выиграет от частых выпусков.

Это также может относиться к стадии, на которой находится проект. Например, в начале нам потребуется много предварительной работы (некоторые проекты требуют 6 месяцев, другие - 3 года). Но после того, как первоначальная работа сделана, мы можем захотеть выпускать чаще. И не только из-за обратной связи. Может быть, мы допустили ошибку и хотели бы ее исправить в ближайшее время, или маркетингу нужна эта функция быстро, потому что они уже обещали.

*Похоже, они пытаются замести следы, потому что каждый раз, когда я пытаюсь найти первую версию Scrum Guide, становится все труднее и труднее :)