Насколько реалистично писать «Историю пользователей» с «всеми» крайностями и сценариями?

Question

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

Часто возникает конфликтная ситуация в нашей команде, где Design, PO, BA, Dev, QA, PM обвиняют друг друга.

PO, Design, BA говорят, что это очень мелкие детали, которые сами по себе станут длинным документом, трудно сказать, что каждый отдельный nitpick, и QA/DEV должен думать об этих случаях при планировании. Но QA/DEV сопротивляются, заявляя, что это не их работа, и если не заявлено, что они не несут ответственности, они будут делать только то, что указано явно. Пытается провести смертельную атаку и поблагодарить BA, Dev, QA за то, что он беспокоился о скорости, не обращая внимания ни на кого. Очки, очки, очки, о которых он говорит. Он даже не помогает команде сосредоточиться на продукте, управлять конфликтом, обеспечивать/облегчать обучение или процесс, который может улучшиться. Он даже не понимает, не сработает ли сборка, окружающая среда снизилась, а работа с Dev будет отложена.

На что должен обратить внимание разработчик/qa? Получает ли он точки истории или получает продукт с качеством?

Кому действительно нужно беспокоиться о точках? Может ли PM оказать давление на Dev, QA, BA, не понимая реальности?

Кто на самом деле ответственен за недостающие более тонкие детали? Дизайн, ПО, BA? Или QA/Dev должен был подумать об этом до оценки?

Ситуация усугубляется изо дня в день, много политики и раскола в наших отношениях!

Возможен прослеживание к этим вопросам: In agile/scrum user stories, how much detail is enough?

Answer 1

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

Истории пользователей ДОЛЖНЫ заставить команды и клиентов говорить больше.

Но это не может быть реалистичным для вашего situations.You не может иметь клиент или играющий испытывают трудности, чтобы связаться с regularly.You может оказаться в ситуации, в которой «контракт или аутсорсинг развития», в которой вы должны сделать на основе разговор на документах. Я знаю, что это нехорошая ситуация, но ведь мы просто разработчики, и иногда мы не можем менять рабочие среды и стили. [Конечно, оставляя проект всегда вариант :-)].

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

Для этого ознакомьтесь с бесплатной книгой Крейга Лармана. Он объясняет это в части 6.21 [на основе RUP]. applying-evolutionary-use-cases. И Ивар Якопсон представляет новые «срезы для прецедентов». Проверить Free Use-Case 2.0 ebook

и некоторые конкретные ответы на ваши вопросы:

- ли это получение сюжетных точек или получить продукт с качеством?

Я думаю, что вы также новый ответ: получение продукта с качеством - это наше внимание.

Кто действительно несет ответственность за то, что упустили более тонкие детали?

Кажется, что ваша компания участвовала в Agile Hype, но они действительно не понимают этого. Если у вас есть «силосы», как отдельные QA, BA или Design Team, вы продолжите играть «обвиняя игру».

Вы все ответственны за отказ. И это OKEY, чтобы потерпеть неудачу. Разработка программного обеспечения - экспериментальная деятельность. Важная вещь - это НЕ БЫСТРО, РАНЬШЕ И ДЕШЕНО. Один из способов сделать все из вас ответственным - создавать Командные группы вместо силосов. http://featureteamprimer.org/

Чтобы получить более глубокое понимание основ Agile и это «обвинив игру» корни, смотреть видео Larman на YouTube Scaling Agile & Scrum with Offshore Development .ps: Хотя речь идет о Offshore развития и о Scrum, он дает очень глубокое понимание об основах из Agile.I думаю, это заставит вас также «улыбнуться». :-)

Answer 2

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

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

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

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

Answer 3

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

Обычно это возможно в начале проекта или в простых проектах или в тренингах!