Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Разработчик, agile-коуч и сертифицированный scrum-тренер (CST) в krivitsky.com
  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Вони НЕ працюють, як Area Product Owners — то є тема з LeSS Huge, де 8+ команд, і один PO вже не справляється.

    В постері — LeSS. Один на всіх. Один ПО, один Беклог на всі команди.

    Продакт менеджери працюють... продакт менеджерами, допомогаючи робити класний продукт. Але вони НЕ володіють беклогами. В деяких речах вони насправді — subject matter experts, деколи вони експерти в product discovery process.

  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Стаття як раз про це.

    Але проблема виявилася в тому, що кожна з команд вела власний беклог за своїм компонентом. Розробники брали з нього задачі, навіть якщо у конкретний момент часу ці тікети не були найважливішими та найпріоритетнішими для компанії та продукту загалом.
  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Ви неуважно читали статтю, я гадаю.

    Value Steam Mapping може не лише дати усвідомлення того, що усі Ваші компоненти насправді формують один єдиний продукт з точки зору клієнта, але й виявити що один чи декілька ваших компонентів можуть служити як окремий продукт, але для іншої цільової аудиторії.

    У Постера один продукт. З точки зору широкої дефініції продукту як того, что є enabler of the business model. Та насправді є різні клієнтськи портрети, B2B, B2B2C...

    Але ми хотіли прийти до такого широкого розуміння — в нас один продукт. Один на всіх. Ламаємо стіни.

    І для цього ми використовували системне мислення. З якого стає очевидно, що розщеплення продукту на куски і беклоги приводить до локальних оптимізацій: «моє — не моє», «наша хата з краю», «ми своє зробили»...

    Читаємо тут: https://less.works/less/framework/product

  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    2&3. За що відповідають у вашій моделі новопризначені продакт менеджери, враховуючи, що за єдиний наявний продакт беклог відповідає Product Owner = CEO?

    Ніякий PO не працює наодинці. Тим більше в маштабному продукті. Продакт менеджери Постера працюють як команда поруч з PO.

    Вони також допомагають командам дізнатися деталей елементів беклогу (який пріорітезує PO) та задизайніти гарні фічі.

    А як ви бачите роботу PO наодинці? Це нереально.

  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Епіхарію, відповідаю на ваше питання.

    1. На зображенні ’Як ми працбємо зараз’ вказано ’5 крос-КОМПОНЕНТНИХ інженерних команд’, звідси й питання. Зараз ви пишете про крос-функційні крос-компонентні кастомер-фейсинг команди. Навіщо для команд, що вже й так крос-функційні, наголошувати на їх крос-компонентності? Перше визначення є ширшим.

    Команда може будет кросс-ф і при тому працювати тільки над одним модулем системи — аналізувати, розробляти, тестувати. То є функції команди. Але не кросс-компонентність.

    Кросс-компонентні команди — це ортогональна дефініція. Ми маємо наувазі, що вони не тільки покривають всі функції, а й працюють кріз продукт.

    В однокомандному Скрамі — де на весь продукт є одна команда, дійсно, ніхто не говорить про крос-компонентність. Але в маштабі — то є сама важка річ.

    В матеріалах LeSS є така мапа: https://less.works/less/adoption/feature-team-adoption_map. Там по осі X: кросс-ф, а по осі Y: кросс-комп.

  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Гарне питання. Команди беруть роботу з єдиного продакт беклогу з глобальними пріорітетами, а не роблять те, що хотять.

  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Станіславе

    Постер навчив усіх інженерів, менеджерів та С-level системному мисленню та LeSS. Після цього альтернативи не розглядалися.

    Чому? Тому ще optimizing goal з LeSS співпав з тим, що було потрібно Постеру. А саме — адаптивність для пошуку цінності та ії постачання.

    Навіщо шукати іншу жінку, коли ти закохався?

    Підтримали: Taras Khariv, Andrii Kuzmenko
  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Романе

    У Постері на всю компанію — ОДИН продукт. Це теж була зміна. Зміна в розумінні свого продукту.

    Тому їм не потрібно робити value stream mapping.

    Підтримав: Marina Zaytseva
  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Романе. Уся ця стаття про орг зміни. Вчитайтеся.

    1. Постер пішов від підходу компонентних команд на feature cross-functional cross-component customet-facing команд. Це орг зміна.

    2. Постер прибрав позицію team-level product owner. Це дуже важка і суттєва орг зміна. Ці люди знайшли нову роботу всередині Постера. Де-кто з них пішов у команду. Де-кто став продакт менеджером

    3. Постер поставив 1 Product Owner. Це СЕО компанії. Це мега орга зміна.

    4. Постер перейшов на 1 продакт беклог із цілями замість 10 беклогів з тасками. Це орг зміна.

    5. Команди відкрили свої репозиторії одна для одної. Internal open source. Це суттєва орг зміна в інженерній культури.

    6. Постер прибрар позицію team lead що була всередені команди. Замість цього ввели позицію Engineering Manager. Це 3-4 людини на компанію. Кожна працює з
    2-3 командами. Мета — ростити development capacity команд

    І багато чого ще.

    Підтримав: Дмитро Дем'яненко
  • Як ми переходили з однокомандного Scrum на масштабований LeSS

    Людей не можна «переформувати». Poster зробив умови, в яких спеціалізовані розробники можуть також розвиватись в шир.

    Це не або те .. або те. LeSS цінує глибоких спеціалістів. І також прагне допомогти командам працювати над тим, що потрібно бізнесу та клієнтам. А це не завжди тільки те, в чому зараз є максимальна спеціалізація.

    Підтримав: Illia Kovalchuk
  • Карьера в IT: роль Scrum Master

    больше денег можно просить всегда, когда клиент доволен.

    Підтримав: Sergiy Prokhorenko
  • Карьера в IT: роль Scrum Master

    Олексий

    к сожалению, адекватной альтернативы слова

    коучинг
    на русском нет. найдете — пишите.
  • Карьера в IT: роль Scrum Master

    к скраму и правда накопилось в индустрии много претензий. но давайте разбираться:

    на моем опыте половина из них вызвана просто непониманием самих принципов (это лечится тренингами, отчасти), вторая половина тем, что компании, заявляющие о внедрении скрам, на самом деле не хотят меняться вовсе. и поэтому адаптируют каркас, не понимая, его сути. это опасно.

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

    есть такая метафора, что скрам — дает зеркало. это так, если его правильно внедрить. без всего мусора, с которым он ассоциируется.

    а то, что потом в этом зеркале видны кривые рожи (не примите лично!) — ну да, некомфортно, но ведь они там и раньше были. просто зеркало было замыленным.

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

    так, что скрам безопасен, если внедрен опытными людьми (отсюда и вся эта статья о скрам-мастерстве)

    безопасен...НО! кроме случаев, когда вместо скрама подается что-то очень кривое с таким же названием. к сожалению, 80% команд и компаний украины если не больше делают скрам очень криво. и это ведет очень часто к наращиванию тех долга, эксплуатации команды, недовольству команд и проч.

    вот это и нужно чинить. а не скрам.

    по поводу вреда кривого скрама есть есть крутая статья апологета xp по этому поводу: ronjeffries.com/...rticles/016-09ff/defense

  • Карьера в IT: роль Scrum Master

    разница не очевидная, но есть.

    на самом деле есть, как минимум, 4 стиля работы с группой (или человеком):
    — фасилитация (применимо только для группы)
    — коучинг
    — менторинг (наставничество)
    — обучение

    отличие обучения от коучинга в том, что первое подразумевает, что у клиента нет знаний, и что их нужно дать. коучинг же подразумевает, что у клиента уже есть все необходимое, ему нужно просто поддержать и помочь вопросами открыть для себя ответы.

    agile коучинг — это по сути смешение всех приведенных 4 стилей работы, отсюда часто возникает путаница.

    Підтримав: Михайло Міронов
  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    ищите дальше. такие проекты-команды-компании есть.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    “common sense is not that common” как известно.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    вижу в этом мире скопилось много обиженных «скрамом» людей. очень жаль.. и как минимум половина «озлоблённых» (как видно из комментариев) работающий скрам в глаза-то и не видела.

    жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.

    сходите может в гости в компании, где всё в порядке? поговорите с людьми, у которых есть позитивный опыт?

    слелайте что-то с собой толковое. правда.
    скептицизм — это вообще хороший знак, знак потенциала для развития.
    цинизм же — нет, тупик для мозга.

    решать вам.

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    на троллинг больше не отвечаю.

    Підтримав: Serhii Kalinets
  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    предоставлять клиенту качественный сервис по разработке ПО

    а у вас что, делание успешных продуктов не входит в спектр услуг?

  • «Аутсорсинг головного мозга». Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

    согласен полностью.

    но статья о том, как решать проблему уже после сейлов. конечно же, root cause — глубже.

    Підтримав: Volodymyr Yatsevsky
← Сtrl 1234 Ctrl →