Scrum: Кто пишет ТЗ? На сколько детально?

Question

[Алексей Демин]

Привет коллеги!

Встал на нелегкий путь внедрения agile.
Все вроде понятно, есть свои камни, которые некоторые называют не перешагиваемыми (например то что большинство девелоперов у нас на удаленке и часто меняются). Но здесь уже есть кейсы по решению этих проблем и мы не сдаемся.
Но вот встает вопрос, ответ на который я не встречал во изученных руководствах. Все говорят про беклоги, спринты, ретроспективы и т.п.
А вот как пишется ТЗ?
Ну есть юзер стори, а программист хочет юмл, и прочие сложные штуки.
В вашей команде, кто пишет ТЗ?
На сколько оно детально расписано?
Как эта работа оценивается?

Большое спасибо за ответы.

Answer 1

[Сергей Протько]

А вот как пишется ТЗ?

никак.

Ну есть юзер стори, а программист хочет юмл, и прочие сложные штуки.

не хочет он uml и прочие сложные штуки. В этом обычно мало ценности в рамках scrum методологии.

Ну есть юзер стори

Ну вот и хватит, есть юзер стори, можно написать ТЗ по этой юзер стори, можно написать фичаспеку используя GivenWhenThen штуковины аля gherkin или просто юзать gherkin для нужного уровня детализации фичи. Бэклог состоит из кучи таких вот небольших ТЗ. Их по хорошему составляет продукт оунер или бизнес аналитик или еще кто. Хорошая практика - груминги или бэклог рефайменты, это митинги где чистится бэклог. Ну то есть мы берем скажем несколько фич с перху бэклога и проводим дополнительную декомпозицию, задаем вопросы и т.д. что бы к моменту когда эти фичи будут взяты в спринт все уже было на руках.

p.s. А зачем вам скрам? Возьмите канбан для начала и если захотите, добавляйте правила из скрама.

Comments

[Сергей Протько]

OnYourLips: противоречия нет ровно так же как и ценности. Есть намного более удобные способы описывать требования и делать декомпозицию чем проектирование модели предметной области через UML. Конечно, есть проекты где это полезно, проекты с очень сложной бизнес логикой и т.д. Но как по мне фичаспеки с примерами (в контексте BDD) и тесты тут справляются лучше. Да и я уж не помню когда видел в последний раз как бизнес аналитики делают что-то сложнее из того что связано с UML кроме как определение акторов и запись юз кейсов.

Answer 2

[margarita_free]

При такой методике я лично применяю сразу проектировки интерфейса, если пишу для веба или структуру, если это ПО (в любом случае, story)
После этого, я уже описываю более подробно элементы, страницы, расположение и функционал.
Структура может меняться в процессе 15-ти дневного цикла.

Answer 3

[kabashowlab]

Пишу я сам.
Не так давно начал этим заниматься из-за гос.заказа.
Куча согласований, документы через службу безопасности, потом утверждение договора юристами (к слову это заняло 24 дня), потом бухгалтерия, потом только подписание и оплата.
На деле ребята адекватны. Был составлен Бриф *к слову о Брифе у нас*
Бриф даю заполнять Заказчику, там вопросы аля, цель создания, выявление бюджетов, немного о блоках
которые хочет видеть Заказчик типа (Новости, каталог и пр.) Способ дальнейшего ведения проекта (отдают нам на поддержку или силами менеджера и пр.)
Тех.Задание пришлось писать самому. Первая версия была вода. Её не одобрили и сразу дали понять что все должно быть расписано. Начиная от что такое сайт, Битрикс, кастомизация и пр. Так же четкие этапы работ и что они получают после каждого этапа.
Договор весьма продуманный, каждый пункт ссылается на другой или приложения к договору.
Такой опыт.)
Писать не сложно, сначала думал мол зачем это делать, но часто возникают споры. Мол а давайте из визитки сделаем интернет-магазин, а это другие деньги уже, которые платить никто не хочет.
Таким образом я прикрываю "тыл" себе и заказчику понятно, что будет в итоге.
Нет никаких недосказаностей. И соответственно нет проблем.

Comments

[akass]

эм... а в чем тут agile?

[kabashowlab]

Алексей, не внимательно прочитал. Конечно же к aile не имеет никакого отношения. Видимо засиделся вчера )))) Это всё к теме сайтов конечно же. Прошу прощения тогда за оффтоп.

[Ivan22]

Вот нет никакого скрама - и в итоге: "Нет никаких недосказаностей. И соответственно нет проблем."

Answer 4

[⚡ Kotobotov ⚡]

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