Comments 20
Живое обсуждение позволяет преодолеть или свести к минимуму недостатки, присущие документации:
к моменту использования она уже устарела
Обновить перед обсуждением или сразу записывать новое что запрещает? Кроме лени и раздолбайства?
неполон,
не проверяем,
А дать
написанный текст часто неоднозначен,
Ну да, а обсуждение «словами» просто образец однозначности?
документация часто навязывает конкретное, быть может, не самое эффективное решение
С каких пор User Story определяет «как сделать»?
Какие-то странные притяные за уши проблемы: если делать не правильно, то будет плохо. Вроде очевидно.
Я понял, что Вы против лени и раздолбайства. Согласен с тем, что если делать неправильно, то будет плохо.
Поделитесь, как делать правильно?
На уровне контракта (на юридическом уровне) будут оговорены механизмы «согласия» — критерии приемки, стандарты и т.д. Если у вас на нижележащих уровнях теряются эта информация — это печально. И это не зависит от User Story.
Если вы хотите что-то получить, сначала договоритесь как будете «измерять результат».
На уровне законодательства будет написано что-то вроде: если критерии приемки не согласованы сторонами в контракте, применяются отраслевые стандарты для экспертизы оспариваемых результатов и это будет что-то вроде «ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models»
Для Scrum «The Scrum Guide» написано "Definition of Done — When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done ” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency.… Any one product or system should have a definition of “Done” that is a standard for any work done on it. "
Если не измеримые и не согласованные ожидания\результат — на выходе может быть что угодно.
Вопросы коммуникаций — на то тоже есть рекомендаци вроде Communication Plan (кому и как предоставлятся информация и т.д.)
Кто за что ответственный — тоже есть рекомендации.
Из ничего и будет ничего…
Спасибо за подробный ответ. Мне кажется, теперь я Вас лучше понимаю.
Видимо Ваша работа связана с заказной разработкой. ТЗ прописано в договоре, отступать от которого нельзя.
Для Вас документация – первоисточник правды. Вы не можете позволить, чтобы она оказалась неточной, неполной или неоднозначной. Это логично.
Строго говоря, в этом случае Agile пользы не дает. Может даже навредить. Waterfall поневоле со всеми вытекающими последствиями. Но Вы чувствуете себя в нём уверенно, и, похоже, фундаментально он Вам нравится.
Любопытно, зачем Вы читаете статьи про Agile? Видите в нём какие-то преимущества? Идеи, которыми можно было бы обогатить Waterfall (например, Definition of Done)?
Видимо Ваша работа связана с заказной разработкой. ТЗ прописано в договоре, отступать от которого нельзя.
Нет. Мне все равно какой заказ\проект делать.
ТЗ прописано в договоре, отступать от которого нельзя. Строго говоря, в этом случае Agile пользы не дает.
Нет. Заключается договор на оказание услуг. Есть заинтересованность что бы после каждой итерации «тебя не послали» и\или «не сработал репутационный риск» или «заинтересован сделать продукт».
Любопытно, зачем Вы читаете статьи про Agile? Видите в нём какие-то преимущества? Идеи, которыми можно было бы обогатить Waterfall (например, Definition of Done)?
Вы не верно расставили причину и следствие :). Сначала идет юридическое «согласен» оформленное в виде акта приемки, Acceptance Certificate или как-то еще. В контракте будет написано что-то вроде: качество представленного решения должно быть подтверждено UAC\ логом прохождение тестов предварительно согласованных сторонами, код должен быть депонирован, и т.д.
А после контракта проектный менеджер должен выполнить шаг «организация и/или
команда управления проектом самостоятельно определяет применимость знаний к тому или иному проекту.»
Scrum\Kanban\Rup и т.д. фактически такой же «шаблон проектирования» только применяемый не к програмному коду, а к проекту\команде\людям.
Ответственность за корретное применение и адаптацию процессов этих «шаблонов» лежит на PM\заинтересованных людях. Пихать везде одно и тоже — глупо, иначе получается «человеку с молоткм везде мерещатся гвозди».
На практике получается так, что в общем User Stories (а не только карточка) используются в качестве напоминания и для трекинга, а требования и так описываются более детально в тасках для команды.
Да, я тоже про это упомянул:
User Story может ссылаться на развернутые требования, например, протокол взаимодействия или формулу расчета.
Мы работаем с Jira. Все User Story (а также дефекты, риски, исследования) хранятся там. Поначалу, это только заголовки, но постепенно обрастают подробностями, приложениями, комментариями. Недавно обсуждали в команде, нормально ли это, что в спринт попадают стори с одним лишь заголовком. Это обсуждение и подтолкнуло меня к написанию данной статьи.
А уже от User Story пляшут задачи, типа проанализировать, написать, протестировать и т.д.
User Story с оценками трудозатрат и профита понятны бизнесу и бизнес управляет их приоритетами.
На практике мы редко формализуем задачи (tasks) внутри стори. Стори уже достаточно декомпозированы, делаются в одном спринте. Если внутри стори появляется больше одной подзадачи, например, когда требуется участие нескольких человек, договорённости между ними вполне могут остаться устными. Документируем только спецификации типа api между фронтэндом и бэкэндом.
Достаточно декомпозированы на уровне критериев прёмки?
Декомпозированы, значит разбиты на более мелкие User Story, с оценками ниже определенного порога, так что каждую из них, можно было бы реализовать в рамках одного спринта. Каждая User Story при этом должна нести ценность для заказчика/пользователя. И должна иметь критерии приемки.
Во втором из трех видео-роликов, на которые я сослался в статье, как раз идет речь о том, как можно подходить к решению этой задачи.
Спасибо, да, посмотрел, хороший подход. Возможно трудности перевода, но я понял так, что не все story можно дробить таким образом и делит story на complex story и compound stoty. Майк приводит несколько примеров декомпозиции как раз compound story, например со способами оплаты или работой браузеров. Получается, что для complex srory нужно заводить таски.
Complex Story – большая, на вид неделимая задача. Большая она чаще всего потому что непонятно, как ее делать. Обычно к ней подступаются так: берут в спринт чисто исследовательскую задачу (называется Spike в XP, Enabler в SAFe). Если user story создает ценность для заказчика, то enabler создает знание. На выходе – план, как двигаться дальше, в идеале – набор сторей с оценками, пригодных для взятия в следующий спринт.
Complex Story – большая, на вид неделимая задача. Большая она чаще всего потому что непонятно, как ее делать.
Обычно такая Story называется Epic.
Например: Agile Epics или Define features and epics
Обычно к ней подступаются так: берут в спринт чисто исследовательскую задачу (называется Spike в XP, Enabler в SAFe).
Или если в процессе планирования выясняется, что «не влазит» в Sprint (или иной удобный для контроля «time frame», например требует более 16..24 часов) разбивается на Stories помельче. Зависит от типа проекта и применяемого процесса. Стратегия минимизации рисков простая: Большого слона едят по кусочкам.
Features, Epics – это немного другое. Это большие куски функциональности, которые заведомо будут включать в себя более мелкие User Story. Но и эти User Story тоже могут оказаться слишком крупными, чтобы брать их в спринт.
Речь шла не о том, что разбивать, а о том, как это делать. С этой точки зрения разбиваемые стори/фичи/эпики делятся на сложные (complex) и составные (compound). Составные разбиваются относительно легко – этому посвящен второй ролик Майка Кона. А о том, как разбивать сложные, я написал в комментарии выше.
Важный момент – во всех этих случаях речь не идет о тасках. Tasks – это план работ по конкретной стори. Мы не берем таски в спринт, мы берем стори целиком.
Когда мы разбиваем User Story, мы не создаем подчиненные ей User Story, мы замещаем исходную User Story двумя (или более) новыми. При этом все новые User Story входят в ту же фичу или эпик, что и исходная.
Между разработчиками и Product Owner действует соглашение: разработчики обязуются задавать вопросы, а PO обещает, что будет для них доступен.
Это всё прекрасно, но общение по задачам идёт не только в направлении от PO к разработчикам и обратно. Есть и горизонтальное общение (скажем, разработчиков с дизайнерами), и общение с внешним миром, и много другого интересного. Мир сложнее agile.
Всё верно. Agile приветствует прямое общение, я бы даже сказал, ставит его во главу угла.
Соглашение между PO и разработчиками я выделил, потому как оно особенно важно. Иногда PO (особенно, когда это реальный представитель заказчика) настолько занят и/или находится так далеко, что ответов на вопросы (не говоря уже уже об общении face-to-face) приходится ждать часами-днями-неделями. Это существенно снижает эффективность работы команды.
Также считаю неправильным, если разработчик взял и сделал задачу молча, не пообщавшись перед этим с PO – это обратная сторона соглашения.
Ну, и если идти дальше, хорошо бы, до того как делать задачу, обсудить ее решение с другими членами команды, как минимум с еще одним разработчиком и тестировщиком. Это повысит шансы того, что ничего не придется переделывать.
Насколько детальной должна быть User Story?