Alex
А кто-нибудь имеет истории успеха использования JIRA для планирования спринта? На текущий момент не получается быстро получить фокус на интересующих задачах, из-за чего пришли к использованию страницы в confluence для раскидывания задач - так как это в итоге оказывается быстрее и нагляднее. Но workflow при этом страдает - дублирование информации, всё равно приходится возвращаться в JIRA и менять / создавать там задачи и всё такое. Или это нормальная практика и просто надо на планирование закладывать гораздо больше времени? Или же есть какие-то крутые альтернативы JIRA, которые быстро работают и позволяют удобно работать с задачами с настраиваемыми flow и настраиваемыми отчётами?
Julia
Ну мы как-то так придумали свой плагин Structure:) когда доски становится мало, хочется посортировать-погруппировать. Сейчас перед планированием мы задачки по спец формуле сортируем, типо wsjf, и группируем по источнику задачи(типо роалмап, фидбек, тех долг,...) и набираем в спринт из всех групп, чтобы ничего не проседало
Julia
по репортам-посмотрите плагин easyBI
Julia
про наш продукт можно вот тут посмотреть: https://marketplace.atlassian.com/plugins/com.almworks.jira.structure/server/overview или мне в личку написать))
Julia
easyBI: https://marketplace.atlassian.com/plugins/com.eazybi.jira.plugins.eazybi-jira/server/overview
Alex
Ну мы как-то так придумали свой плагин Structure:) когда доски становится мало, хочется посортировать-погруппировать. Сейчас перед планированием мы задачки по спец формуле сортируем, типо wsjf, и группируем по источнику задачи(типо роалмап, фидбек, тех долг,...) и набираем в спринт из всех групп, чтобы ничего не проседало
Спасибо! Потыкаю, выглядит вроде неплохо, плюс еще заметил плагин для ганта от вас же, который выглядит вполне прилично )
Julia
спасибо:)
Глебка
есть у кого то практики как понять команде что нам не нужен определенная роль. например аналитик. знаю есть техника какая то, но где бы про нее почитать?
ruslan
исследование или планирование?
Дарья, мельком обратил внимание на вашу проблему. Посмотрите видео выступления Рамиля из СКБ Контур - говорит про диагональное планирование спринтов, возможно вам это чем-то поможет . https://youtu.be/ueOoqG2gKwY
ruslan
Daria
Mikhail
PM
Коллеги, добрый день! А к PMP никто не готовится сейчас? Есть вариант пошарить расходы на тесты от Риты.
A1ex$r\/
Коллеги, добрый день! А к PMP никто не готовится сейчас? Есть вариант пошарить расходы на тесты от Риты.
это Вам скорее сюда https://t.me/pmi_ru
PM
Alexsrv, спасибо!
Daria
Это ж баяяянский баян
Yehor
Забыл подписать, это из книги скрам, Сазерленда)
Yehor
Ну и плюс не претендую на супер новую информацию, решил повторить старое доброе чтиво)
Дмитрий
Николай
в паре с этой https://www.mann-ivanov-ferber.ru/books/upravlenie-produktom-v-scrum/
Шохова - читать скрам-мастеру, Пихлера - продукту
Vladislav
Vladimir
Вот возник вопрос. А на картинке разве не каскадный подход?
так он везде каскадный, разница только в длительности
ruslan
Вот возник вопрос. А на картинке разве не каскадный подход?
Суть в том, чтобы аналитические работы в беклоге проводить задолго до начала спринта. Одно из возможных решений - кто-то за спринт может все этапы одной задачи пройти и зарелизить, а есть ситуации множества задач на этапе бекенда, в спринт которой задача полного цикла уже не помещается и тогда, с целью уменьшения неизвестности - полноцикловую задачу желательно планировать до начала спринта и пройти этапы проектирования, дизайна и если повезёт - фронтенда (и чего там ещё бывает) ..
Свят
Суть в том, чтобы аналитические работы в беклоге проводить задолго до начала спринта. Одно из возможных решений - кто-то за спринт может все этапы одной задачи пройти и зарелизить, а есть ситуации множества задач на этапе бекенда, в спринт которой задача полного цикла уже не помещается и тогда, с целью уменьшения неизвестности - полноцикловую задачу желательно планировать до начала спринта и пройти этапы проектирования, дизайна и если повезёт - фронтенда (и чего там ещё бывает) ..
Т.е.аналитику делать вне спринта? Участник команды просто не берет задачи из беклога, а исследует будущую задачу?
Mikhail
так он везде каскадный, разница только в длительности
Нет. Он не должен быть каскадным. В этом как бы смысл.
Dmitry
Суть в том, чтобы аналитические работы в беклоге проводить задолго до начала спринта. Одно из возможных решений - кто-то за спринт может все этапы одной задачи пройти и зарелизить, а есть ситуации множества задач на этапе бекенда, в спринт которой задача полного цикла уже не помещается и тогда, с целью уменьшения неизвестности - полноцикловую задачу желательно планировать до начала спринта и пройти этапы проектирования, дизайна и если повезёт - фронтенда (и чего там ещё бывает) ..
религиозно правильно, либо спринт делать таким чтобы задача вмещалась (но не дольше 4-х недель), либо задачу уменьшать до такой чтобы влезла. просто впихивать водопад в спринты изначально провальная идея.
Vladimir
Нет. Он не должен быть каскадным. В этом как бы смысл.
Не понял, какой смысл? Почти любая работа проходит известные стадии.
Друго дело что в скраме все стадии помещаются в спринте.
Стас Щетинников
Вот возник вопрос. А на картинке разве не каскадный подход?
На самом деле, да. Потому что аналитика, юзабилити, разработка и тестирование - это работы, которые нужно делать для того, чтобы закончить задачу. Но это НЕ СТАДИИ процесса. В отличие от стадий, эти работы могут делать в любое время и в любой последовательности. Аналитика может оказаться нужной после юзабилити или тестирования.
Mikhail
Не понял, какой смысл? Почти любая работа проходит известные стадии.
Друго дело что в скраме все стадии помещаются в спринте.
Это называется засунуть вотерфолл в скрам. Почитайте the new new development game, из которого аджайл выполз. Там как раз про стадии. В Том числе
Vladimir
Я конечно почитаю, но все таки на пальцах можете объяснить?
Чтобы сформулировать нужен хотя бы минимальный анализ (хотя бы формулировка гипотезы) (формирование бэклога)
Затем формулировка требований (формирование бэклога)
Затем тестирование требований (груминг, планирование спринта)
Затем планирование (груминг, планирование спринта)
Затем реализация (внутри спринта)
Затем тестирование (внутри спринта)
Подтверждение гипотезы (фидбек от пользователей)
Каскады могут варьироваться.
Mikhail
ну например, BDD/TDD - тесты пишутся до разработки, контракты - бэк пишется параллельно с фронтом
Mikhail
если задачи неольшие, то аналитику тоже можно втягивать внутрь и корректировать движение по ходу ПАРАЛЛЕЛЬНО с разработкой
Vladimir
Вы говорите о возможном распараллеливании каскадов.
Vladimir
Хорошо, допустим несколько каскадов становятся одним. Хотя это не так.
Vladimir
Но вы не избавитесь от всех каскадов таким образом
Стас Щетинников
Я конечно почитаю, но все таки на пальцах можете объяснить?
Чтобы сформулировать нужен хотя бы минимальный анализ (хотя бы формулировка гипотезы) (формирование бэклога)
Затем формулировка требований (формирование бэклога)
Затем тестирование требований (груминг, планирование спринта)
Затем планирование (груминг, планирование спринта)
Затем реализация (внутри спринта)
Затем тестирование (внутри спринта)
Подтверждение гипотезы (фидбек от пользователей)
Каскады могут варьироваться.
То, что работы зависят друг от друга, не значит, что они идут каскадом. Каскад - это когда следующий зависит только от предыдущих. Но в жизни очень много циклов - когда у тебя тестирование выявляет баги аналитики или юзабилити, и все уходит на второй/третий круг. Именно поэтому каждый каскад или стадия не могут гарантировать, что результат их работы имеет четкое value. Это value не подтверждено, пока ВСЯ цепочка не пройдет - вплоть до выкладки на продакшн.
Стас Щетинников
Поэтому бессмысленно выявлять каскады.
Стас Щетинников
или стадии
============ FALCON ============
Идеальное враг хорошего)
Стас Щетинников
В станадартном waterfall-е у тебя 90% времени проекты проводили в тестировании
Стас Щетинников
то, что называлось integration hell
Vladimir
Нет смысла выявлять каскады... задумался
Vladimir
Стас, вы говорите о всего лишь о другой длительности каскадов
Vladimir
Да и скрам не говорит, что вы должны использовать BDD к примеру
Vladimir
Можно распараллелить каскады, можно сократить длительность каждого. Но суть итеративной разработки - маленькие каскады внутри каждого цикла
Стас Щетинников
нееет, и еще раз, нет. Каскад - это когда у тебя есть конвеер и результат с прошлого каскада можно точно использовать в этом. В промышленном производстве возвраты со предыдущий стадий крайне редки, в софтваре - они практически гарантированы.
Стас Щетинников
еще раз, работы в рамках задачи могут разные, они могут быть в разной последовательности и друг от друга зависеть. Но это не делает эти работы каскадными (как это трактовалось в waterfall).
Vladimir
Сам первоисточник не читал, но вроде в этом чате упоминали, что невозможность возврата на предыдущий каскад в вотерфоле это совсем не то что придумал автор.
Vladimir
Возвраты возможны и противоречия с вотерфолом тут нет
Стас Щетинников
Даже посмотрите на изначальную работу по waterfall-у винстона.
Стас Щетинников
Vladimir
Так почему же вы считаете что этап аналитики (формирования бэклога) нельзя использовать в разработке (спринте)?
Vladimir
А если можно - то это вотерфолл? )
Стас Щетинников
Так почему же вы считаете что этап аналитики (формирования бэклога) нельзя использовать в разработке (спринте)?
можно конечно, но он не гарантируется. Т.е. мы не можем написать отдельно ТЗ и уволить всех аналитиков. Потому что скорее всего (точнее наверняка) они что-то там написали неправильное.
Vladimir
все верно, как и в случае с вотерфолом
Vladimir
Вы ведь видите стрелки в обе стороны на картинке
Vladimir
Немного холиваров не помешает :)
Vladimir
Как говорит один участник сообщества "Чат ожил!"
Mikhail
Давайте вот как. Каждый может делать так, как считает нужным. Если это помогает, то и супер. Просто делать в одном спринте фронт, а во тором бэк - это не скрам. Просто вотерфолл с короткими каденциями. Выполнение работы стадия - за стадией - это вотерфолл даже если он засунуть в две недели. Все проблемы вотерфолла с ним остаются.
Mikhail
Если не видно разницы между скрамом и вотерфоллом, то может проблем никаких и нет
Стас Щетинников
Вы ведь видите стрелки в обе стороны на картинке
да, не ту скинул картинку :) Это та, на которой ройс как раз объясняет, почему стадии не работают ;)
Vladimir
Михаил, да есть проблемы. Распараллеливать обязательно надо. Я говорю, что не надо витать в облаках и думать что у вас нет стадий. Стадии есть всегда и везде, даже если вы их осознанно не выделяете.
Vladimir
Стас, на эту тему Элия М. Гольдратт хорошо еще объяснил почему тупое следование вотерфоллу приводит к большим проблемам.
https://www.ozon.ru/context/detail/id/141279570/
Mikhail
У меня нет стадий. У меня есть работа, которая должна быть сделана
Стас Щетинников
Mikhail
Тут нужно думать как все работы разделить на минимальные задачки ведущие к результату. Может быть не нужно делать весь бэк, а потом весь фронт? Просто часть работ по бэку + фронт положить в один спринт, потом улучшить функциональность. Если ты сначала сделал БЭК, то что ты покажешь на демо? как у тебя круто сервисы работают?
Mikhail
Когда люди с WF переходят на итерации, больше всего обсуждается как раз вот эти слои, т.к. раньше бы написали всё и сделали всё, а теперь нужно придумывать
Mikhail
Ну так презентация у тебя пойдет и бэка и фронта, а не частично
Стас Щетинников
Вопрос в том, что стадий - нет. При разработке софта. Есть работа, которую надо сделать. И эта работа не укладывается в конвеерные стадии (ну даже с возвратами назад и do it twice) оно не работает.
Mikhail
Ну так презентация у тебя пойдет и бэка и фронта, а не частично
Я про паверпойнт. Его же можно показать
Стас Щетинников
Есть разные виды работ - бек, фронт, аналитика и тд.
Vladimir
Ну как же нет. Вы ведь сначала формируете бэклог, а потом берете из него задачи в спринт и только после реализации проверятете гипотезы на пользователях
Mikhail
аааа.. стоп. фишка то показывать живой продукт, а не презы
Mikhail
когда показываешь сценарий на живом продукте больше профита, чем ты красивую презу сделаешь
Vladimir
Приятного вечера! Спасибо за беседу )
Max
Приятного вечера! Спасибо за беседу )
Тот самый мультик про вотерфол, который незаслуженно ругают.. https://cartmendum.livejournal.com/44064.html