🦠
Ретро достаточно, правда бессмысленно без инкремента
Sergey
Так инкремент же будет.
🦠
Нет, пока аппрува нет
Pavel
ОК, две проблемы:
1. На планинге некому отвечать на вопросы/подверждать аксептансы -> будет много предположений
2. В течение спринта/на демо некому будет подтвердить, что сделанное - таки ценность, а не фигня -> нет возможности адаптироваться
Sergey
Это хде так написано ? DoD сделан? Инкремент есть
🦠
Так если спринт на две недели и планинга не надо
Pavel
Сергей, а если в DoD прямо сказано "аппрув ценности от продак овнера"?:)
Sergey
Странный у вас DoD :)
Pavel
An item considered to be "Done" only if:
- Code passed through a code review process
- Test cases covering the item are in the test management platform
- Test cases were executed against the item and no bugs were found
- All related code is integrated and deployed on a staging environment
- Regression and Integration testing did not expose any new bugs
- Product Owner confirmed that all acceptance criteria met
🦠
Нормальный для сложного продукта
Pavel
Нормальный Шу
🦠
Павел, если не секрет, что деливерите?
Pavel
Внутренняя система для кейтеринговой компании.
🦠
Посреди отпуска?
Pavel
Не получится. Нет связи и отъезд незапланированный и срочный
🦠
Я думаю вернется злым и неотдохнувшим
Sergey
У нас в DoD реализация функционала и все остальное. А после PBR приемочные критерии по задаче, согласованные с продактом. И полная самостятельность команд по реализации.
🦠
Интересно, как обстоит дело с continuous delivery в такой ситуации
🦠
Если инкремент засчитан только по факту одобрения продактом
🦠
Фича-флаги?
Sergey
Ага
Pavel
Фича-флаги и environment swap
Pavel
Это как раз просто
🦠
У нас просто с таким количеством микросервисов не оч получилось в фичафлаги
Pavel
Мне опять же не нравится, что накопится изменения между open/shadow
🦠
Звучит вполне жизнеспособно
Pavel
Если инкремент засчитан только по факту одобрения продактом
И, на всякий случай, PO подвреждает, что аксептансы по каждой сторе выполнены, а не "аппрувит" инкремент :)
Pavel
Инкремент вообще никто не аппрувит.
Sergey
Это ж они его постоянно дергают получается. Ни шагу без согласования?
Pavel
Разумеется
Pavel
А чо, ждать, пока он в конце спринта соизволит взглянуть на результаты?
Pavel
Хера, PO должен быть actively engaged
Sergey
Pavel
Иначе хрен поймет, что команде надо давать свободу :)
Pavel
Сергей, то продактов должно быть больше одного. И пожалуй больше двух. Идеально - 7 :)
Sergey
У семи нянек дитя без глазу :)
Pavel
Если рассматривать ситуацию в отрыве от нынешнего клиента - PO должен взаимодействовать с командой в течение спринта.
Sergey
Должен
Pavel
И чем активней он взаимодействует - тем лучше результат
Pavel
Прописывать это взаимодействие в DoD или нет - зависит от стадии, на которой команда находится :)
Sergey
А вот тут не уверен. Пусть пилят, будет плохо - позовут.
Pavel
А вот тут не уверен. Пусть пилят, будет плохо - позовут.
ИМХо лучше пусть общаются и делают хорошо, чем делают плохо и зовут :)
Sergey
А пусть цели нормально ставит, тогда и дергать не будүт. Зачем его дергать?
Pavel
Тю. Ты еще скажи "пусть требования заранее и полностью пишет" :)
Sergey
Команда пусть детализирует задачу.
Pavel
Давай разберемся, что такое "детализирует".
Pavel
Вот например, есть вот та стори с курьером, что я писал выше.
Sergey
Pavel
Кто должен ответить на вопрос "есть два варианта подсчета оптимального маршрута - с учетом пробок через API google и без учета пробок внутренним алгоритмом" с учетом, что API google команда не изучала и с этой имплементацией надо делать spike, а внутренний алгоритм делает стори - двоечкой, но в качестве предсказания - сомневается.
Sergey
Пусть у юзеров спросят, эксперты есть ...
Pavel
Энд юзеры скажут "конечно с пробками".
Pavel
но есть тонкая разница между "идеально, но потом" и "неидеально, но сейчас".
Pavel
Как вот в конкретно этой ситуации команда без PO должна прниять решение? Это не говоря о том, что решение влияет на цель спринта (поставить что-то потенциально не нужное или не поставить что-то потенциально нужное" :)
Sergey
Юзеры лучше продакта знают что им нужно :)
Sergey
Pavel
Нет, совершенно не факт.
Pavel
Юзеры точно знают, что им нужно идеальное решение.
Pavel
Это не значит, что в продукте должно появиться идеальное решение - в продукте должно появиться решение проблемы.
Sergey
Любая цепочка даст искажение. Напрямую :)
Pavel
Напрямую курьер хочет телепорт, а бизнес может себе позволить только самокат :)
Pavel
Т.е. "спрашивать эндюзера/кастомера" - правильно. Но это не значит, что ТОЛЬКО мнение кастомера должно быть единственно верным
Sergey
Я учу их самих принимать решение. Как только они начинают кажлый раз согласовывать это жопа. А дайте я подумаю, а мне некогда ...
Pavel
Это ты правильно учишь.
Pavel
В принципе :)
Sergey
Это сильно тормозит разработку
Pavel
Я учу не принимать решений на основе неполной информации :)
Sergey
Она никогда не будет полной :)
Pavel
Она бывает достаточно полной для принятия решения и недостаточно полной для прнятия решения :)
Sergey
Это как в бизнесе. Нет идеалтных решений. Нет белого и черного, есть серое.
Pavel
Сергей, ты с Lean Startup знаком, кстати?
Pavel
С циклом, не с книгой.
Sergey
Ну Ты үтрируешь. Понятно что ситуации всяккие бывают, бывает и не обойтись без него.
Pavel
Сергей, я не особо утрирую. Суть в том, что роль PO в scrum специально существует, чтобы помогать команде с пониманием требований.
Pavel
Не для составления расписаний, не для генерации end-to-end requirements, а для того, чтобы в общении с end customers, users, stakeholders и т.п. у команды был единый канал.
Sergey
Я, кстати, еще до того как вляпался в Скрам, всегда подчиненным говорил, что руководитель это ка врач, нехрен к нему все время бегать и согласовывать, приходите когда болит.
Sergey
Pavel
На PBR тоже нужно иметь один канал :)