Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Project Manager в Transparen
  • Definition of Done, или кто за что отвечает

    Имея видимый для клиента DoD это построение прозрачных отношений и не более. При возникновении узких мест или же снижении пропускной способности мы показываем клиенту, что у нас есть проблема и мы ее решаем, так как качество готового инкримента у команды стоит на первом месте. Таким образом клиент видит, что команда работает над решением проблемы, а не сидит и ничего не делает, и клиенту уже проще принять риск и как вариант предложить команде свою помощь по его решению, но и не более. А влезание с изменениями в установленные командой правила разработки может привести большим факапам на проекте. Если у команды есть свои прописанные уставом DoD, то стоит об этом сказать клиенту в самом начале разработки. А уже если клиент захочет вставить туда своих 5 копеек, то нужно с ним договориться и принять общее решение.

    Підтримали: Oleksandr Nogai, Borys Dudka
  • Definition of Done, или кто за что отвечает

    Полностью согласен. Только клиент решает сделан функционал или же нет. Ему в этом могут помочь acceptance criteria, что в свою очередь он должен подписать их кровью перед началом разработки. Я до этого никогда не слышал чтоб DoD был пропушен самим клиентом. Все правила DoD решает команда и на каждый этап разработки он может быть свой.

  • Как мы создали свой подход к разработке без привязки к спринтам

    Исходя из статьи у них проблема была скорее всего не с использованием Scrum подхода, а с непониманием грамотной приоритизации невыполненых работ по всем текущим проектам в компании. Автор отметил, что они не хотели раздувать штат сотрудников для изоляции кроссфункциональных команд по каждому из Scrum проектов. Основная проблема состояла скорее всего в премещениях разработчиков между проектами, что в итоге теряло понимание ценности и достижения целей по окончанию каждого спринта, а также непопадание в сроки. Как результат, я вижу что они решили объеденить три комманды в одну и решать задачи по ходу их поступления и уровням приоритетов от каждого из PDMs. Это нормальный подход, который позволяет доносить понимание ценностей по каждому из проектов всем членам одной большой dev team. Такой подход практикуется в Канбане, главное чтоб работа с рисками и приоритетами велась адекватно используя тотже WSJF и модель KANO.

    Опять же это мои догадки, но я бы на их месте посмотрел бы на тотже SAFe. Если я не ошибаюсь с его пощью можно установить баланс между текущими проектами в организации без потерь связанными с дедлайнами по каждому спринту. И опять же, если отбросить метрики по velocity, то можно было бы спокойно делать итерации по двум проектам с меньшим весом, а на проект с высшим приоритетом переводить больше ресурсов с другихкомманд, сохраняя баланс и снижение рисков технического долга по другим проектам.

  • Как мы создали свой подход к разработке без привязки к спринтам

    Молодцы, что не останавливаетесь и эволюционируете. Вот читаю и понимаю, что это чистой воды протоканбан. Правильно ли я понимаю, что у вас один беклог на 3 продукта и одна кросфункциональная комманда? Не могли бы вы подробней расписать как вы приоритезируете фичи по важности поставки по всем 3 проектам сразу и как продак менеджеры договариваются между собой? Баланс разработки между продуктами уж очень напоминает ССРМ, что тоже перекочевал в канбан с теории ограничений. Михаил, всетаки у вас вновь изобрести колесо не получилось, одно из основных принципов канбана это использовать то, что уже есть и работает в организации сейчас. Так что впред и не останавливайтесь на начатом. Скоро накопите статистику и поймете, что оценка по скраму вам будет не нужна и вовсе, а будете ориентироваться на показания метрик где будете знать сколько понадобится на чендж реквест, а сколько на резработку челендж функционала. Но помните, что вытягивание будет работать только если грамотно выставлять WIP лимиты по незавершенной работе.

  • Kyiv DevOps Day

    Спасибо большое DataRobot за очень информативную и теплую атмосферу. Ребята, вы делаете большое дело. Да прибудет с вами DevOps! :)