Pavel
Вообще чем больше команда умеет в работу с требованиями, тем меньше продакт оунер загружен работой с командой.
Igor
а как еще можно сделать PBR? просто в идеале story которые были зарефайнены должны еще быть оценены командой чтобы если чо их в спринт взять.
Pavel
Игорь, по разному.
Pavel
Можно хоть каждый день по полчаса\стори "рефанить", хоть в бэклог PBI на рефайнмент PBI добавлять :)
Igor
так это всё равно один event получается на спринте
Igor
просто он происходит каждый день
Igor
можно конечно сказать что это 5 разных митингов получится. но если делаем одно и тоже каждый день лучше так не говорить :D
Pavel
Я люблю когда рефайнмент раз в неделю. По пятницам во второй половине дня.
Pavel
Как ни странно, хорошая активность для завершения рабочей недели - требования пообсуждать. особенно если это делать в формате воркшопа.
Igor
у нас обычно по пятницам обзор спринта
Pavel
А я люблю обзор спринта по средам.
Igor
ну эт норм тема
Igor
мы так тоже делали
Igor
ток в нормальной команде :DDDD
Pavel
А сейчас что мешает?
Igor
а сейчас у нас команда маленькая укладываемся в "все в понедельник"
Pavel
Ну если для вас работает, то ок.
Igor
у нас просто не скрум, но близко
Pavel
Я не люблю ревью в пятницу, потому что откровенно задалбывает воеать с желающими в пятницу сбежать пораньше, потому что завтра выходной.
Pavel
Стехолдеров не наловишься.
Igor
у нас у остальных разрабов демо для стейкхолдеров в среду
Igor
при этом есть еще демо для тимлидов в пятницу
Igor
хуевые процессы такие хуевые
Igor
максимум что можем со своей стороны сделать это парировать процессы/хотелки других команд ибо предоставляем свой сервис им как услугу.
Pavel
Гм. Канбан?
Igor
неа, просто работа в спринтах. но для того чтобы задача попала к нам в беклог для этого собираем всю нашу команду и разговариваем с тем кому нужна от нас какая то хрень
Igor
мы предоставляем devops в нашей организации
Pavel
Ясно. Девопс - это хорошо.
Igor
если кому то надо чтобы что то деплоилось созваниемся всей нашей командой с "заказчиком" на месте же проводим PBR и задача пойдет дальше либо в backlog либо в спринт сразу если срочна.
Igor
в нашей схеме сложное самое было сказать "стоп, сейчас подключим всех остальных девопсов и продолжим разговор"
Igor
но как то справились :D
Pavel
Клево. Я бы кейс послушал\почитал :)
Igor
ну как нибудь когда этот кейс закончится :D ибо в связи с тем что хреновые процессы как то всё больше влияют на нашу работу, хочется взять и свалить :D
Igor
мы сейчас сделали себе "компонентную команду" хотя это на самом деле очень не хорошо. зато я понял почему на прошлой работе народ поделился и не хотел объединятся. притом там война такая шла прям :D
Igor
проблема была в том что у одной из компонентных команд была очень разная по уровню культура разработки.
Igor
бекенд на сколько я помню не юзал PR и мержили мастер очень через жопу :D у них была выделена под merge колонка в жире. когда ты работу по задаче доделал ты кидаешь таску в статус merge me. далее в день Ч(когда деплоим) специально обученный чувак проходит по этому статусу и мержит все ветки с названиями задач в этом статусе :D
Igor
видя этот пиздец, мобильные разработчики просто покрутили у виска и сказали - у нас будет своя команда со своими процессами :D
Pavel
У меня на одном проекте спринт заканчивался тем, что я ручками делал move всем айтемам из done в проект Validation, где следующие спринты специально обученные куи делали, хм, валидацию
Pavel
И толькоп осле валидации специально обученный 'девопс" делал deploy
Pavel
3-4 недели после спринта :)
Pavel
И нет, никакой острой необходимости так делать не было. Просто "у нас так принято".
Igor
ой да это херня. у нас там было 8 чтоле колонок со статусами. потому что еще у нас были тестеровщицы которым тоже надо было видеть какие задачи тестить.
Igor
так исторически сложилось это конечно тру причина так делать
Igor
мы в нашей конторе так писали "incident report" на каждое как кажется падение
Pavel
так исторически сложилось это конечно тру причина так делать
Да. Истинная причина была в том, что главный куй был таким же директором, как и главный дев.
Pavel
Пока их обоих решение объединить команды нормально не устроило - нифига не менялось.
Igor
у нас таки объеденили насильно. в результате правда нихрена должным образом не поменялось.
Igor
так как у одних в процессах пиздец и они эти процессы менять не хотели
Igor
у других свое видение того как должно работать и не желание убеждать вторых в этом ибо зачем? у них все равно бекенд. а у нас тут сборка и поставка в appstore и playmarket
Pavel
у нас таки объеденили насильно. в результате правда нихрена должным образом не поменялось.
Там фиг насильно объединить было. Последствия стартап-стайл роста. главный дев носил титул CTO, а главный куй был заодно VP of Product и чотатам оф клаент энгейджмент.
Pavel
Т.е. совмещал в себе куйство, саппорт и требования.
Igor
ой вей
Igor
у нас сейчас похожая херня :D
Igor
главный девелопер носит титул CTO(гордо носит). владельцам бизнеса пофиг на разработку, максимум занимаются приемкой на демо. на это демо никого кроме тимлидов нужного проекта не зовут :) при этом CTO имеет опыт разработки ток по фронту реальный.
Pavel
Норм :)
Igor
я было дело пытался всё это в норм русло привести. но диалога с боссами компании у разрабов нет. они реально ссутся вести диалог. там получается так что если босс говорит это ими не обсуждается.
Igor
"идеальный исплонитель"
Igor
у нас тут задумали "реструктуризацию". я под это дело сказал одному боссу что вот так и так есть agile есть манифест есть ценности и тд и тп. он говорит оке збс давайте обсудим все вместе. я когда начал про манифест говорить меня в итоге заткнули и спросили а реальные изменения структуры по отделам где :D
Pavel
А это вот основная печалька, кстати.
Pavel
Бизнес вполне готов to do agile, но совсем не готов to be agile
Pavel
По крайней мере не готов без длинных объяснений понять, что в манифесте написано.
Igor
я им говорю вот надо начать с PO это изменение. он должен продукт вижн сделать.
Pavel
SAFe на этом паразитирует :)
Igor
они мне говорят какой продукт вижен? продукт на столько инновационный что вижн у нас появится только когда запустимся :D
Igor
и что продукт должен к моменту запуска быть со всеми плюшками, а MVP это то что надо инвестору показывать и все :D
Pavel
+ еще со времен Six Sigma бизнес привык, что более-менее работающие процессы сопровождаются всяким мотивационным bullshit speech, который надо знать, чтоб сдать экзамен, но в реальной работе можно игнорировать :)
Igor
а я пытался объяснить
Pavel
хех, оять же, один из знакомых продактовнеров в качестве vision показывал нарезку сцен из голливудских боевичков и говорил "вот такую систему мы и строим".
Pavel
Там был real-time crime center - система, позволявшая в режиме реального времени координировать всякие полиции, скорые и пожарных во время крупных инцидентов.
Igor
так я пытался объяснить что эт такое и с чем его едят
Igor
и что он не должен быть точным
Igor
в плане того что это не тз :D но они понимают только тз. дальше мне сказали что им пофиг. у них там есть project manager или как я его называю owner :D когда я им сказал что это не одно меня опять же не поняли :D
Igor
есть "смотрящие" которые разрулят разработку, а есть они как заказчики. и они этот процесс видят только таким.
Igor
на предыдущей работе как раз где я был SM от меня хотели именно это :D
Pavel
https://www.youtube.com/watch?v=5FKJQdb8TRI
Pavel
Вот это показывал
Pavel
https://www.youtube.com/watch?v=tC24atC8rpA
Pavel
Вот это реальность :)