Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
А после попадания задачи в джире в последнюю колонку, именно она же переходит разработчикам? Или создается новая?
1) Спасибо, интересно.
2) Есть ли источники по теме, которые вы бы посоветовали, чтобы ознакомиться с разными вариантами?
3) Все тексты и user stories пишутся в Jira или в отдельной системе?
4) Помимо документации на каждую задачу отдельно, есть ли общая документация по архитектуре системы, которая меняется реже?
5) Если да, то как решается задача её стандартизации и актуальности?
6) Пишутся ли все тексты руками, или в них есть кусочки, которые генерируются автоматически (пример: список полей в таблице)?
2. Салют, по источникам — свой опыт, бложик (в профиле), ну и стандартные книжки:
— www.slideshare.net/mobile/LuxoftAgilePractice/user-story-canvas
— nomad8.com/acceptance_criteria
— www.romanpichler.com/blog/10-tips-writing-good-user-stories
— www.mountaingoatsoftware.com/agile/user-stories
— www.mountaingoatsoftware.com/uploads/documents/adding-detail-to-user-stories.pdf
— www.modernanalyst.com/Resources/Articles/tabid/115/ID/4903/5-Common-User-Story-Mistakes.aspx
3. High-level описание фичи пишется в confluence article, которая связана с эпиком 1 к 1. Мы тут как раз на последнем митапе кратко про цикл документооборота в confluence разговаривали.
User Story пишутся в соответствующем типе тикетов в жире.
4. Да, общая докментация тоже лежит в Confluence, но — там она периодически пополняется blog post'aми коллег, которые что-то где-то перепиливают. Вообще писать блог посты время от времени просят всех, ибо это показывает изменения в организации и порождает срачики в комментах, что мы все на работе любим =)
5. Если касаться фич и как оно должно работать, и кто обновляет как калькуляции в системе работают — иногда они устаревают. По мере того, как мы замечаем проблемы и расхождения с реалиями — документация поправляется. Если документ устарел — он не удаляется, а для ретроспективы остается, и в шапке пишется что более актуальная версия — вот она (и ссылка). Документации море, и что-то через сито просачивается, и становится неактуальным. Порой клиенты и партнеры по интеграциям на это тыкают. Вообще в конце видяшки из предыдущего пункта я об этом с гоготом рассказываю =)
6. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
— www.slideshare.net/mobile/LuxoftAgilePractice/user-story-canvas
— nomad8.com/acceptance_criteria
— www.romanpichler.com/blog/10-tips-writing-good-user-stories
— www.mountaingoatsoftware.com/agile/user-stories
— www.mountaingoatsoftware.com/uploads/documents/adding-detail-to-user-stories.pdf
— www.modernanalyst.com/Resources/Articles/tabid/115/ID/4903/5-Common-User-Story-Mistakes.aspx
3. High-level описание фичи пишется в confluence article, которая связана с эпиком 1 к 1. Мы тут как раз на последнем митапе кратко про цикл документооборота в confluence разговаривали.
User Story пишутся в соответствующем типе тикетов в жире.
4. Да, общая докментация тоже лежит в Confluence, но — там она периодически пополняется blog post'aми коллег, которые что-то где-то перепиливают. Вообще писать блог посты время от времени просят всех, ибо это показывает изменения в организации и порождает срачики в комментах, что мы все на работе любим =)
5. Если касаться фич и как оно должно работать, и кто обновляет как калькуляции в системе работают — иногда они устаревают. По мере того, как мы замечаем проблемы и расхождения с реалиями — документация поправляется. Если документ устарел — он не удаляется, а для ретроспективы остается, и в шапке пишется что более актуальная версия — вот она (и ссылка). Документации море, и что-то через сито просачивается, и становится неактуальным. Порой клиенты и партнеры по интеграциям на это тыкают. Вообще в конце видяшки из предыдущего пункта я об этом с гоготом рассказываю =)
6. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
По сути это адаптированный design thinking.
Не поверите, но неделю назад перешли на него же :)
Не поверите, но неделю назад перешли на него же :)
Если вы про design sprints (могу ошибаться, ибо с принципом design thinking знаком постольку-поскольку), то все же мы отличаемся от него именно в сторону практичности/формализации.
То есть если в design thinking idea -> prototype -> test (именно в customer value формате), то у нас idea -> approve -> requirements + (prototype -> mockup -> design). То есть мы не пробуем разные идеи, а скорее реализовываем достаточно конкретные вещи, которые не надо уж прямо тестировать на пользователях (в оснвном).
То есть если в design thinking idea -> prototype -> test (именно в customer value формате), то у нас idea -> approve -> requirements + (prototype -> mockup -> design). То есть мы не пробуем разные идеи, а скорее реализовываем достаточно конкретные вещи, которые не надо уж прямо тестировать на пользователях (в оснвном).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анатомия распределенной команды — процесс подготовки требований