Evgeniy
Внутри они говорят так: мы делаем какие-то проекты по водопаду, какие-то - по scrum. Но всегда помним, что у нас есть еще несколько подходов: псевдо-scrum, псевдо-водопад и псевдо-управление_проектами )))
Ⓢⓔⓡⓖ
Я раньше думал что agile трансформацию нужно начинать с kanban потому что он гибче и его внедрять можно постепенно, по частям. Оказалось- для больших коллективов нужно вправлять мозги идеологией и (относительно) четким набором правил, а это как раз скрам
Алекс
Понеслась !!! :)
Ⓢⓔⓡⓖ
Скрам не запрещает изменение требований, если не будет изменена или отменена цель спринта
В разработке цель обычного спринта- это реализовать набор требований
Вова
Ну хотели живого обсуждения, вот оно
Ⓢⓔⓡⓖ
Ну и где живое обсуждение ? Затихли все сразу
Алекс
Пишу
Alexandr
В разработке цель обычного спринта- это реализовать набор требований
это плохая цель спринта :) цель должна быть не просто - сделать все что запланировано на спринт, задачи следуют целям, но не равны цели спринта
Алекс
В разработке цель обычного спринта- это реализовать набор требований
А какая бизнес цель доработки этих требований ?
Ⓢⓔⓡⓖ
Это зависит от стадии проекта. Если допустим есть 100 багов в продуктовом бэклоге, выбираем 50 и ставим цель - уменьшить кол-во багов на 1/2. Баги как правило во всех компонентах равномерно, т.е. их объединить по содержанию редко получается
Ⓢⓔⓡⓖ
Т.е. это если продукт почти готов и идёт багфиксинг
Алекс
Это зависит от стадии проекта. Если допустим есть 100 багов в продуктовом бэклоге, выбираем 50 и ставим цель - уменьшить кол-во багов на 1/2. Баги как правило во всех компонентах равномерно, т.е. их объединить по содержанию редко получается
это не бизнес цель - это тех долг, о котором должен знать владелец продукта и учитывать в бэклоге
Ⓢⓔⓡⓖ
Да, наверное можно сказать что баги это неосознанный техдолг
Ⓢⓔⓡⓖ
Ну вообщем если в этом спринте фиксим разнородные баги, то всё равно по большому счету- какой их состав. Цель снизить общее кол-во на 1/2
Алекс
Т.е. это если продукт почти готов и идёт багфиксинг
команда должна минимизировать количество багов для этого есть DoD и внедрение инженерных практик
Вова
Ну вот если пример выше называть скрамом, то я не против он прижился в банках
Ⓢⓔⓡⓖ
А если мы где-то в середине разработки, то там всё по-другому. Требования выбираются из продуктового бэклога на основе однородности и приоритезации, в начале спринта проходят планирование, и тут уже крайне нежелательно менять их состав. Так ведь ?
Ⓢⓔⓡⓖ
Крайне нежелательно- для разработчика.
Ⓢⓔⓡⓖ
команда должна минимизировать количество багов для этого есть DoD и внедрение инженерных практик
Должна. И как это сделать? Многие баги только пользователи могут выловить
Алекс
Ⓢⓔⓡⓖ
, если они не ставят под угрозу цель спринта.
Алекс
Да
Алекс
Или спринт может быть отменён владельцем продукта
Ⓢⓔⓡⓖ
Алексей, хороший PO не будет часто пользоваться правом изменения scopa спринта?
Алекс
Алексей, хороший PO не будет часто пользоваться правом изменения scopa спринта?
Если рынок такой, все меняется быстро. Возможно, что уменьшение спринта до 1 неделя исправит ситуацию.
SeWa
@Sergei_88 , разве скрам даёт чёткие инструкции что когда делать? или речь про эти самые групповые активности?
Ⓢⓔⓡⓖ
Относительно всего agile всё очень даже чётко
vladislav_gatsenko
одни скрам мастера тут?))
SeWa
не, ещё я есть
Artem
Если рынок такой, все меняется быстро. Возможно, что уменьшение спринта до 1 неделя исправит ситуацию.
Камон! Приведите пример, где рынок кардинально меняется за 2-3 недели, что надо прям внутри спринта все сильно менять. Несколько задач, блокер какой-нибудь понятно, но не весь спринт
SeWa
выход нового ФЗ, конкурент нечто выкатил, заблочили ферму с серваками, пришёл новый владелец
Алекс
любой высококонкуретный рынок,
Artem
Это форс-мажоры. Они не каждый спринт
Artem
Если же все прям ежедневно меняется, то скрам просто не подходит в таком случае
Алекс
а что в этом случае порекомендуете ?
Artem
Приоритизацию бэклога ситуативно. И канбан практики
Artem
Или
Artem
Разделить команде на 2 части
Anton
Камон! Приведите пример, где рынок кардинально меняется за 2-3 недели, что надо прям внутри спринта все сильно менять. Несколько задач, блокер какой-нибудь понятно, но не весь спринт
Привожу реальный кейс. В спринтах пилим лэндос с элементарной обвязкой по воронке продаж. В результате очередного PBR в соседней команде выясняется, что все лэндосы надо интегрировать в новую архитектуру по иному принципу. PO принимает решение о том, что работу 3х спринтов придётся выкинуть. ) Кстати, SM провафлил и не сказал APO в той команде об этом, в результате чего один из разработчиков в гневе побежал ругаться, что им ничего не сказали.
Artem
Одна тушит пожар и реагирует на форс-мажоры
Artem
А вторая работает в более спокойном режиме над долгосрочными темами
Anton
В результате спринт остановили, но новый не стали запускать, чтоб каденции не ломать - несколько дней команда делала чего хотела (баги фиксили, учили матчасть и т.п.)
Artem
Привожу реальный кейс. В спринтах пилим лэндос с элементарной обвязкой по воронке продаж. В результате очередного PBR в соседней команде выясняется, что все лэндосы надо интегрировать в новую архитектуру по иному принципу. PO принимает решение о том, что работу 3х спринтов придётся выкинуть. ) Кстати, SM провафлил и не сказал APO в той команде об этом, в результате чего один из разработчиков в гневе побежал ругаться, что им ничего не сказали.
Здесь явно проблема не в высококонкурентном рынке. Скорее проблемы в коммуникациях между командами
Anton
да, не в рынке. Но цель спринта перестала быть актуальной - всё по фен-шую.
Artem
Как на счёт надергать людей из разных команд в одну, которая бы проблемы интеграции решала?
Anton
не понял. причём здесь интеграции?
Anton
у них работа не пересекалась
Artem
Лендосы же в новую архитектуру...
Anton
не, лэндосы были отдельно. Совсем отдельно. А тут на PBR другой команды, которая делала переработки по архитектуре (техдолг) приняли решение. В результате вторую команду от лэндосов совсем освободили.
Artem
главное, нашли виноватого :)
Офтоп: Хорошая кстати тема в переписке с заказчиком добавлять фейковый е-мейл условного Ивана Иванова. И от его имени отвечать. В случае факапа говорить заказчику, что мы его уволили, и удалять его из переписки 😀
Михаил Е.
👍🏼
Михаил Е.
крутой бизнес-хак )
Anton
Пардон, я не соизволил почитать всю переписку. Мой коммент не в тему оказался.
Алекс
на первые 2 раза прокатит, но потом нужно будет увольнять Ивановых отделами, а потом департаментами
vladislav_gatsenko
а толку? ну произошел капец.. всё. увольнением ничего не решишь.
Anton
Скрам не запрещает изменение требований, если не будет изменена или отменена цель спринта
Помоему тут пошёл замес
vladislav_gatsenko
заказчик разочарован и пойдет к другим
Dmitry
ИМХО опять речь про форсмажоры. Или архтитектура каждый спринт кардинально меняется?
Artem
заказчик разочарован и пойдет к другим
Не всегда все так однозначно. Особенно если проект длительный. А заказчику нужно спустить пар. Впрочем никому не советую пользоваться этой практикой. Лучше работать лучше. Ваш капитан))
vladislav_gatsenko
ну ладно
Anton
ИМХО опять речь про форсмажоры. Или архтитектура каждый спринт кардинально меняется?
Да, конечно, далеко не каждый. Вообще редкая ситуация. Я могу себе представить, когда спринт отменяется по рыночным причинам. Например, PO выявил, что бизнес-модель надо корректировать в части каналов, и срочно (раньше делали ставку на соцсети, а тут выяснилось, что нафиг не работает и надо лэндосами тащить). Меняет модель, соответственно правит бэклог продукта. Команда как раз фигачит интеграцию в VK. Он дёргает рубильник и погнали перепланинг.
Anton
Но ведь отмена спринта - это не единственная причина изменения scope спринта
Anton
scope запросто может меняться в рамках цели спринта. Применение скрама вообще ограничено ситуациями, когда надо экспериментировать. Имхо, конечно.
Mikhail
Dmitry
scope запросто может меняться в рамках цели спринта. Применение скрама вообще ограничено ситуациями, когда надо экспериментировать. Имхо, конечно.
если экспериментировать нужно чаще чем раз в спринт, то может, действительно, канбан?
Anton
если экспериментировать нужно чаще чем раз в спринт, то может, действительно, канбан?
Да. Я запросто могу себе представить старт нового продукта, когда нужна lean startup доска, пример которой приводит Эрик Рис в своей знаменитой книжке. Но при этом до скрама ещё не понятно - дело дойдёт или нет?
Anton
Там надо за две недели проверить 20-30 экспериментов. Какой тут нафиг скрам
Anton
Там жесткие pivot-ы бизнес-модели, скрам стоит в сторонке и потирает руки в предвкушении.
Andrew
Обращаясь к коментам повыше, Сберджайл на самом деле срощенная химера из сейфа, скрама и ватерфола.Этакий гомункул
M
А группа все увеличивается и увеличивается. Жаль 90% это молчуны
Всем привет! На таком количестве участников это не плохо, что молчуны. Был в одном говорливом канале там что-то в потоке читать/комментировать было тяжко. Отвлекся на часик и на тебе 1000 постов. Прокрастинация сразу просыпается :)
Anton
Коллеги, откликнитесь те, кто делал skill starmap у себя в командах, где есть тимлиды (исторически или ещё как-то). Меня интересует, чего у них там по скилам?
Andrew
А тимлид входит в DT? Каков его вклад в создание инкремента?
Ⓢⓔⓡⓖ
если экспериментировать нужно чаще чем раз в спринт, то может, действительно, канбан?
Народ начинает потихоньку вникать 😁 а то мне как-то сказали что внутри спринта можно и несколько релизов делать
Dmitry
Алекс
Народ начинает потихоньку вникать 😁 а то мне как-то сказали что внутри спринта можно и несколько релизов делать
ЭЭЭ. внутри спринта можно хоть кадые 2 часа релизиться :)
Anton
А тимлид входит в DT? Каков его вклад в создание инкремента?
Андрей, привет! ) Речь веду про организации, где не сразу удаётся сделать no titles в команде, и там остаётся тимлид, который раздаёт задачи, контролирует их выполнение, выполняет прочие менеджерские функции, и до кучи ещё руками помогает (кодит).