Как стать автором
Обновить

Комментарии 161

Спасибо за разбор. У нас тоже был неСкрам значит. В связи с чем вопрос, а предполагает ли успешный скрам активное участие команды во внедрении? Ну хотя бы изучение что такое Скрам самостоятельно, что бы фиксировать отклонения от эталона? Или достаточно лишь ознакомиться с новой инструкцией по порядку взятия задач в работу и т. п.?
Всё зависит от уровня команды и предъявляемых к ним требований. Так например есть даже специальный документ для членов DT — Professional Scrum Developer — PSD.
Вообще я обычно описываю ребятам их обязанности, возможности и пр. согласно SCRUM'y, ну а сам играю роль этакого зонтика скрам мастера. Потому что без принятия самой командой, скрама не получится, но обучить команду, дать им правильную культуру скрама и помогать им её взростить — прямая обязанность SM'a. Притом через некоторое время они сами и отклонение от эталона заметят и порядок наведут. Главное их от негативного внешнего влияния защищать.
>улучшение скорости и качество — хорошо, на что тратят время разработчики — это мимо и не к SCRUM'у.

А разве качество — это не мимо? Не, ну вот серьезно — разве Agile где-то обещает именно повышение качества?

Особенно в такой вот постановке «улучшить скорость и качество» — при том что большинство людей прекрасно знает, во что это как правило выливается. В повышение стоимости, разумеется. Они точно этого хотели?
А разве качество — это не мимо? Не, ну вот серьезно — разве Agile где-то обещает именно повышение качества?

Аgile не обещает, а вот SCRUM обещает. Agile и SCRUM — не одно и тоже.
В SCRUM есть такое понятие как Definition of Done которое играет большую роль в рамкам спринта, в котором как раз таки quality goals do not decrease.


Есть ряд нюансов, таких что quality goals вырабатываютя ST'ой. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.


Кроме того — During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.


Т.е. есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести. Но в состав ST входит и РО, а он как раз заинтересованное лицо и представляет всех stakeholder'ов, но в одном лице и если качество не будет соответствовать, ему сделают секир башка. Поэтому РО играет большую роль в определении DoD и как итог определении качества всего продукта.


ЗЫ: все выдержки взяты из SCRUM Guide.

Когда я работал в компании РИМ у нас на 15 девелоперов было 1PM, 1 директор и 1 VP (и не одного специального архитектора), компания купалась в деньгах, когда к нам привнесли Agile и Scrum атесстованные мастера, у нас стало 5-7 ПМ-ов на каждого девелопера, целая группа архитекторов (чем они занимались я за несколько лет так и не понял).
Очень скоро RIM умер и даже теперь Blackberry в убытках. Это кстати не едиственная компания, которуя я знаю и что с ней стало в результате прогрессивных методов эффективных менеджеров.

Когда приходит VP с опытом написания софта отпуска таблеток в больнице и учит синьер инженеров как писать высоконагруженные сервера становится печально.

В конце вылилось в то что 90% времени стали тратить на митинги, где девелоперы находясь то в одной виртуальной группе выслушали очередную прогрессивную ахинию.
На девелопмент времени уже не оставалось. Рим развалился. Кто сам сбежал, кто дождался жирного бонуса.
, когда к нам привнесли Agile и Scrum атесстованные мастера, у нас стало 5-7 ПМ-ов на каждого девелопера, целая группа архитекторов (чем они занимались я за несколько лет так и не понял).

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

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

Тут как и везде нужно понимать, если мы ловим рыбу, то не ловим на золотой крючок, ибо дороже выйдет. У скрама, как и любого формализованного процесса есть накладные расходы, пожалуй, их нет только в подходе "Пиши код бл**ть!", но большой продукт уровня Enterprise врядли можно создать по подобной методологии. :)
Просто зачастую с помощью коллективного разума на той же ретре можно найти какие-то вещи которые можно оптимизировать и срубить с этого дофига профита. Вот например эффективное испольование по сути ретро описано в этой книге.

Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются

В долгосрочной да, может. Хотя до этого еще надо дожить.

Но прямо сейчас — а особенно в сочетании с сокращением сроков разработки — это вряд ли.

Как правило эффект от экономии наступает через спринт. Т.е. если внедрили и оно заработало, то где-то со следующего спринта будет достаточно ощутимый эффект. Это конечно не прямо сейчас, но вполне ближайшая перспектива.

Мы о каком-то разном качестве очевидно говорим. Я не думаю, что качество разработки в команде можно повысить в рамках спринта, чтобы под этим не понималось.

Дано: Разработчик Вася может не докоммитать код в гит. Васе стучали по голове тапком, но Вася упрям и невнимателен. Как итог на QA сервера попадает битый код\solution\продукт, который работает лишь местами. QA инженеры тратят время на то чтобы зайти, посмотреть что билд битый и пойти поругаться.


Решение: Вводим дополнительную настройку CI которая позволяет закоммитать в бранч проекта только после того как пройдёт промежуточный билд фичи. Линкуем статус фичи в билде и статус фичи в системе учёта задач, т.е. пока не будет норм. билда статус сменить нельзя на complete.


Итог: если Вася всё также невнимателен, то QA не тратят время на проверку, мы экономим время и средства и повышаем качество продукта.


Это можно отнести к качеству?

Можно конечно. Просто это частный случай.

В общем случае отчего низко качество разработки: Либо разработчик Вася просто низкой квалификации (тут есть варианты, может он просто новенький), либо эта квалификация низкая у кого-то еще (аналитики, QA и пр.), либо плохо с взаимодействием — из-за чего Васю не понимает QA Петя. И это уже поправить быстро нельзя. Хотя да, внедрение другой методологии может поправить взаимодействие в команде — но вряд ли все-таки быстро.

Definition of done это как раз про договоренность команды что она считает правильным и как комуницировать между разнми стадиями разработки.


Еще иногда бывает, что на ретроспективе команда решает автоматизировать проверку каких-то критериев.

Вводим дополнительную настройку CI

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

Тут уже более частная тема — можно ли вообще повысить качество разработки за короткий срок.

Вот ещё пример из достаточно раннего, сейчас вспомнил. Кстати реально существовавшая ситуация.


Дано: есть legacy система, её нужно мигрировать на новые "рельсы", тобишь с применением модных и современных фрэймворков. В системе достаточно строгие требования по валидации и UI элементам. Разработчики могли забить на расположение элементов или не докрутить валидацию.


Решение: расширили DoD, введя чеклист из, вроде, 10 пунктов, где было описано проверь то, затем проверь то и если есть это, то ещё и вон то. Распечатали и повесили у каждого на перегородку, Плюс ввели в воркфлоу в джире дополнительный этап — проверка согласно DoD. На это выдавалсь 20-30 минут где-то (за это время можно и проверить и сходить покурить, сам заполнял такие листы и тогда ещё курил), как итог разработчик прикреплял заполненный чеклист (да он был и в электронном виде).


Итого: Количество UIных багов сократилось в 7 раз. В течении 2х недель.


А теперь представьте что это был проект в котором работало 70 разработчиков и примерно 50 тестировщиков.


Подходит под описание качества?

Вы получили хороший и быстрый эффект потому, что ваши работы масштабировались на 120 человек. Т.е. все по большому счету делали примерно одно и тоже и допускали примерно одинаковые баги. Но это все равно частный случай.

Это не всегда так. Это не всегда так просто достигается.
Да речь даже не о накладных расходах. Просто качество и скорость разработки — это противоречивые критерии. Они сами по себе не достигаются одновременно — а только ценой повышения стоимости.

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

Всегда нужно разбирать причины провала, чтобы снова не зафакапить. Я, например, веду в OneNote общие заметки по проектам, только для себя лично. Этакий post mortem. Чтобы в дальнейшем не зафакапиться, бо и у самого скелетов в шкафу хватает.

есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести.


Ах, если бы это было так! В реальности, зачастую бывает совсем по-другому, и вовсе не потому, что команда не умеет «готовить» Scrum. А потому, что качество — это просто ещё одна из характеристик создаваемого программного продукта, и далеко не всегда заказчик готов платить за решение, сделанное полностью «по фэншую».

Есть такое. Просто иногда нужно это очень аккуратно размазать в project plan'е и не палиться. Т.е. задачу можно сделать за 4ч., но заложив накладные расходы на нормальный процесс мы получим 5ч., вот последнюю цифру и отсылаем заказчику.

«Прятать шляпу» — это святое :) Правда, есть особо въедливые заказчики, эдакие control freak'и, которые сами перепроверяют чуть ли не каждую строчку в коде, и, если, например, увидят там юнит-тест, хотя сами говорили «юнит тесты не пишем» — жди скандала.

Unit тесты в отдельную сборку. :)

команду не трогают и работают через него (СМ)

А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)

работая параллельно над тремя-пятью проектами каждый

Разве скрам подходит для аутсорса? :)

Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а.

А если много запросов с одного проекта? :)

Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема?

Короче, все зависит от людей.
Дебилы могут испоганить что угодно. :)

Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса.

Хм.
А у нас не так.
Менеджеры из бизнеса называются просто бизнес.
А менеджеры проектов являются и PO.
Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.

А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :) Если бы скрам внедряли адекватные люди, то возможно и проблем бы не было. Да проблем не было при любой методологии.

Скрам — это гибкая методология?
Как часто допускается вносит изменения в ТЗ?
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
Да, разумеется. Собственно основная проблема, которую так или иначе пытаются решить все эти методологии — это решить всем известную проблему. Менеджеры часто искренне стараются помочь разработчикам делать своё дело (а иначе зачем они нафиг нужны?), но не понимая чем «время творца» отличается от «времени менеджера» делают только хуже. И даже рассказы в красках не помогают. Приходится вводить какую-то формализацию, позволяющую оставить разработчикам возможность, собственно, разрабатывать.
Именно. Вот довольно типичная картина из жизни: говоришь PM, что не хватает времени, так как занят несколькими проектами. И митинги, в том числе, отнимают слишком много полезного времени. В ответ организуется еще два дополнительных митинга на неделе. Спрашивается — для чего? Чтобы помочь с работой? Так я не просил вроде, да и не может он этого. Чтобы лучше понимать, чем я занят, и контролировать сроки проекта? А то что два митинга — это еще два часа из моего и так совсем не резинового временного бюджета — это не доходит?
А то что два митинга — это еще два часа из моего и так совсем не резинового временного бюджета — это не доходит?
В том-то и дело, что нет! Менеджеры свою основную работу часто делают на тех самых митингах (по русски, вообще-то — совещаниях) и дополнительные совещания для них весьма полезны (вместо досятка писем достаточно переоброиться лично парой фраз). Представить себе, что для разработчика, в общем-то ситуация противоположная — они просто не могут. Не «не хотят» — не могут. Они по-другому устроены в большинстве своём, иначе они выбрали бы другую работу! Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»

Многие менеджеры искренне полагают, что тот факт, что разработчики не умеют жить по их расписанию — проблема, которую нужно исправить — и на фирме наступит согласие. Так зачастую и происходит — а что при этом людей, способных глубоко вникнуть в суть проблемы и сделать всё быстро и качественно на фирме не остаётся совсем — вещь, которая из их сознания ускользает.
Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»

Я довольно давно занимаюсь разработкой, но вот в таком тоне со мной никто ни разу не говорил.

Попробуйте объяснить менеджерам, что отвлекать вас в середине рабочего дня нельзя, и если захотят что-то спросить, уточнить, или предложить, пусть приходят после 17:00. Тогда и услышите от них всё, что они думают по этому поводу )))

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


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

когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают
Нет, потому что «что такого, мне всего на 1 минутку спросить» и тут нужна инфа по своей задаче, которая попадёт в следующий спринт, а разработчик делает «чужую» (это если BA контактируют с разработчиками в обход SM и PO)

Разные системы координат. Если менеджер гавно, то лучше уйти. Я как-то почти год мучался, держал проект в зелёной зоне (это когда всё хорошо), когда соседние проекты рушились. Со мной половина delivery менеджеров уже не здоровалась (не удивлюсь если и иголки Вуду втыкали в мою куклу, в грёзах так точно). Но проект держался, команда была довольна, они работали, создавали продукт. Соседние проекты сидели в жёлтой и красной зонах — это когда плохо и очень хе**во. А я был просто конченный мудак (с точки зрения некоторых менеджеров), отстаивал интересы команды, но только и клиент оставался всегда доволен. :)

А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)

Никаких менеджеров в скраме нет.


http://www.scrumguides.org/scrum-guide.html#team


Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.


Как часто допускается вносит изменения в ТЗ?

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.


As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team

Назовите их бизнес аналитики, PO, как угодно.

Ок, пусть нету.
Потянет ли 1 СМ команду из 25 разрабов? :)
Он будет ТЗ писать? :)

Удалось ли вам прочитать хотя бы те цитаты, которые я привел? Хотя бы выделенное жирным ;)


Там есть про рекомендуемый размер комаднды.


Посмотрите в скрам гайд.
Задача SM — чтобы процесс соблюдался, а не писать ТЗ.


Задача PO — чтобы продукт был клёвый — управление беклогом и приоритетами.


Никаких ТЗ в скраме нет, как собирать требования, в какой форме их представлять — не ограничивается. Скрам про управление процессом разработки.


В Agile духе писать User Stories.


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

Это из-за различия терминологии.

Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
линк
проектные менеджеры должны играть роль скрам мастера


Нету ТЗ.
В Agile духе писать User Stories.

Та плевать как вы это назовете.

Скрам про управление процессом разработки.

Судя по всему это 5-ое колесо в телеге. :)
Та плевать как вы это назовете.

Это как раз одна вещей, которая сильно улучшает ваимодействие между людьми — называть одно и то же одними и теми же словами :)

Ну так называйте ТЗ — ТЗ!
Вы же говорите, что ТЗ нету.
Поэтому из-за различия терминологий и непонятки.

Найдите, пожалуйста, определения, что такое техническое задание, User Story и Product Backlog item и посмотрите различия.

Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:

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

Та я вижу, что Вы уже поменяли свое мнение. :)

Вот так у нас внедрили скрам. :)
Лучше бы часы придавили. :)

Где я мнение поменял?
Я дал своё видение как оно должно быть или как бы пробовал на входе это переделать при существующем раскладе. Я мнение не менял.

Поменяли свое мнение (видение) на описанную мной ситуацию…

Детали?

А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :)

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

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

Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.

Что значит «втюхать»? К нам приходит начальник, приводит человека и говорит его во всем слушаться. Человек говорит делать то-то и то-то и говорит, что это называется скрам. Мы делаем то, что он говорит и получается ерунда какая-то. Логичный для нас вывод, что то, что называется скрам — ерунда какая-то. Мы разработчики, мы не менеджеры, нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.

Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.


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


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

Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления. Без всяких формальных методологий почему-то я отвечаю только за свою работу только перед непосредственным начальником, но как только начинается сверху «так жить нельзя, внедряем XYZ», то и продуктивность моя падает, и ответственности я начинаю нести больше, а предложения по улучшению процессов типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».
Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления.

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


а предложения по улучшению процессов

Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.


типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».

Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?


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


Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.

Какая кому разница, что вас не устраивает, если вы объект?

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

Внося предложения я становлюсь субъектом не процесса управления разработкой, а субъектом процесса управления процессом разработки, но быть субъектом процесса управления разработкой я не хочу. Проще говоря, у меня есть мнение как лучше управлять разработкой, по сути как лучше управлять мной, но сам участвовать в этом управлении не хочу. А «эффективные менеджеры», внедряя какой-то модный процесс, пытаются прежде всего повесить на меня роль субъекта управления разработкой, но не допускают меня в роль субъекта управления управлением. Грубо, они хотят чтобы я участвовал в принятии решений что и как делать в рамках спринта, чтобы сделать как можно больше важного именно сейчас, но к принятию решения сделать спринт единственным, но бесконечным, не допускают.
Грубо, они хотят чтобы я
У меня такая же проблема. Спрашивают, не желаю ли я получить новую эргономичную клавиатуру (и вообще, интересуются, какие клавиатуры мне больше нравятся), но моё мнение о покупке X-BOX в офис их вообще не интересует.

Непонятно, почему отмена итераций -> субьет процесса управления процессом, а, например, замена комитментов на форекасты -> субъект процесса :). К тому же, когда вы меняете процесс управления процессом — это опосредованное управление процессом :).


Мне кажется, уже схоластика пошла какая-то. Я за этим вижу форму игры ПБВНДН

А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)

В скраме команд из 25 человек не бывает или это уже будет не правильный скрам. Команда должна быть от 3х до 9 человек — это достаточно жёсткое тербование. Таким образом, мы получаем около 4х команд, по 6-5 разработчиков в каждой. Да, такой состав один скрам мастер потянет, а отбиваться от 13ти менеджеров не такое уже и дурное занятие при наличие необходимого опыта.


Разве скрам подходит для аутсорса? :)

Аутсорс это такие же проекты как и всё остальное. Есть 2 основных типа оплаты проекта: Fix Price (когда платят за проект определённую сумму, т.е. продукт стоит столько-то и не центом больше) и Time&Material(когда платят за работу, т.е. за сколько часов отчитались, столько и получили), на второй тип оплаты проекта всё ложится просто изумительно; с первым же придётся немного погеммороится — там нужно сразу заложить в проектный план(ну или видение проектного плана) всю скрам коммуникацию. а это примерно 2ч из 8ч рабочего дня; но ничего сложного в этом нет. Я сам работаю только в аутсорсе, так сложилось, и вполне годно применяю скрам.


А если много запросов с одного проекта? :)

Смотреть надобно, если это багофикс или maintenance, то тут лучше Kanban, если новый development, то таки лучше как правило SCRUM.


А менеджеры проектов являются и PO. Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.

Посмею заметить, что это не правильно. Люди от бизнеса должны быть РО, а проектные менеджеры должны играть роль скрам мастера. Но если люди не адекватные, то тут печаль-беда.


Скрам — это гибкая методология?

Да, гибкая.


Как часто допускается вносит изменения в ТЗ?

Смотрите, в скраме нет такого понятия как ТЗ. Там есть project backlog и есть sprint backlog. Первый можно изменять когда угодно и как угодно, изменения должен вносить Product Owner. Второй же — sprint backlog — он формируется development team'ом, согласно приоритетам product owner'a, но его изменять не может никто. Только если члены команды разработки видят что там дофига как-то работы и что-то не учли, то они(и только они) могут раздробить какие-то задачи или выделить из уже сущесвтующих в рамках этого спринта и положить в sprint backlog. Т.е. по сути в течении спринта, sprint backlog принадлежит только команде разработки и никто туда соваться не имеет права. А большой бэклог, пожалуйста, и в хвост и в гриву, меняйте. Главное чтобы бюджета хватило. :)

Аутсорс это такие же проекты как и всё остальное.

Под аутсорсом понимается веб с кучей клиентов (сайтов).

Посмею заметить, что это не правильно. Люди от бизнеса должны быть РО, а проектные менеджеры должны играть роль скрам мастера. Но если люди не адекватные, то тут печаль-беда.

А, тогда у нас 25 разрабов, они, конечно поделены на команды.
И 13 скрам-мастеров. :)

Т.е. по сути в течении спринта, sprint backlog принадлежит только команде разработки и никто туда соваться не имеет права.

Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?
Под аутсорсом понимается веб с кучей клиентов (сайтов).

Может быть стоит посмотреть в сторону микса скрама и коньбана.


И 13 скрам-мастеров. :)

Не, у вас 13 менеджеров :) Они ни разу не скрам мастера, судя по всему. :)


Если PO вносит кардинальные изменения, то нужно ли команде продолжать делать старое неактуальное задание или делать новое? Как на это смотрит скрам?

Тут должен смотреть Product Owner, если он видит что цели спринта уже не принесут ему business value или они уже obsolete, то он может прервать спринт. Но скрам на подобное смотрит ОЧЕНЬ отрицательно, хотя и допускает. При том если часть сделанной работы можно использовать в дальнейшем, то её нужно использовать. При этом если спринт прерван, то тут же начинается новый, но уже согласно новым целям и бизнес видению.

Не, у вас 13 менеджеров :) Они ни разу не скрам мастера, судя по всему. :)
Хм.
Ну так я и говорю, что это менеджеры проектов. :)

Значит у нас скрам-мастеров нету и мы работаем по скраму.
Скрам-мастеры в скраме как бы и лишние. :)

Или с кем cкрам-мастеры будут общаться? С теми 13 менеджерами проектов? :)
У нас уже и над теми 13 менеджерами есть еще одни менеджеры, а уже над теми бизнес. :)

Нужно еще больше менеджеров (мастеров)?
Или таки меньше? :)

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

Скрам — это фреймворк. А фреймворк — это, вообще говоря, задание потока управления. Например, ночью спите, в 8 на работу, в 6 с работы, отдых до полуночи, и так по кругу. Фреймворк «я трудоустроен» управляет потоком вашей деятельности. То же самое делает и Скрам, а задача его — дать вам понимание относительной эффективности продакт менеджемента и практик разработки. Это же в самом Скрам гайде написано, но, мне иногда кажется, что люди смотрят в книгу, а видят фигу. Сам по себе Скрам не говорит вам ни как бэклог формировать, ни как планировать, ни как разрабатывать. Вы делаете все это так, как считаете нужным, а Скрам дает вам понять, насколько это удачные или неудачные решения, а спроектирован он таким образом, чтобы проблемы всплывали, как можно быстрее. Таким образом Скрам не про «скорость и качество», а просто про качество, а скорость — лишь побочный эффект, т.к. качественное проще модифицировать, а постоянные модификации и адекватное реагирование на них — это и есть суть Agile, который про ушедшие от водопада бизнесы, которые вынуждены были становиться все динамичнее и динамичнее, отвечая на вызовы рынка.
это и есть суть Agile, который про ушедшие от водопада бизнесы, которые вынуждены были становиться все динамичнее и динамичнее, отвечая на вызовы рынка.

Только выходит наоборот. :)
Адекватно оттюненный водопад лучше неработающего скрама (а это почти всегда так). :)
Потому что водопад прост, как пять копеек. С точки зрения понятности процесса, понятное дело. Вокруг аджайла и скрама же молодые и перспективные, как здесь справедливо уже было замечено, выстроили целый ритуальный культ. Вы вот заметили, что ни в этой статье, ни в статье, на которую эта статья ссылается, по факту нет ничего про саму разработку. Т.е. пришли некие люди, поменяли процесс. Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет. Есть только пара слов про убиение творческого начала. Потому что все это лишнее, мешающее, приземленное и плебейское, когда речь идет о высоком — поставке ценности, ценностях команды, самоорганизации и разделении принципов. Как это все может вообще работать при такой интерпретации? Да вообще никак. Оно, собственно, и не работает.
Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет.

Как на всё это влияет водопад? :)

Водопад — это процесс разработки, поэтому влияет напрямую. В ванильном водопаде, например, нельзя проектировать, когда пошел уже этап конструирования. Ну вот нельзя и все. Соответственно про TDD, например, как про инженерную практику можно забыть. Скрам, как ниже правильно отметил ApeCoder, — это не процесс, это организационно-коммуникационный фреймворк, который про то, как заставить всех общаться в ключе выявления изъянов в процессе, который может быть любым (даже водопадом при некоторых допущениях).

Какие технические метрики тогда определяет водопад?

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

Что такое метрики я знаю, а вот какие конкретно водопад предлагает?

Вы, наверное, невнимательно прочитали мой предыдущий ответ. Попробуйте еще раз.

Прочитал, но конкретики не нашёл, поэтому вернусь к вопросу. Какие конкретно метрики водопад предлагает использовать?

SCRUM — это про процесс — организацию и коммуникацию.


https://martinfowler.com/bliki/FlaccidScrum.html


XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.
DT, PM, SM и т.д.
Вопрос: сколько букв вы сэкономили используя эти сокращения и сколько раз «что это за херь?» прозвучало из уст читателей? Это того стоит? Посчитайте общее количество букв в этом топике и количество сэкономленных букв. Прикиньте какие это доли процента. 0.01%? Меньше?
С каждым днем во мне укрепляется уверенность, что скрам придуман и продвигается с единственной целью — самообеспечение. Все эти скрам-тренера, скрам-консультанты… Огромное количество людей кормится на ритуальной части. А результат внедрения скорее зависит от качества команды — хорошей будет достаточно описания технологии, чтобы извлечь возможные для себя выгоды, а плохая завалит все и сведет к имитации процесса, сколько тренингов не проводи и как их не сопровождай. Под командой я имею в виду всю цепочку, заинтересованную в производстве: заказчик-менеджер-исполнитель. На практике все равно все сведется к банальным вещам — достаточно ли у заказчика денег, есть ли талантливые архитекторы, эффективен ли менеджмент, мотивированы и квалифицированы ли исполнители, реалистична ли задача…

Не соглашусь. Я столько видел кривых имплементаций скрама, что аж жуть берёт.
Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: "Хочу большой корабль, способный бороздить бескрайние, чёрные глубины." Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.
А то что многое зависит от команда — да, никто и не спорит.

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

Скрам тоже итеративен, кстати. Но он не методология, а фреймворк, поэтому иногда скорость фикса той или иной проблемы зависит от опыта, знаний и команды. Тот же RUP\XP предоставит наличие дополнительных артефактов, но проблемы сам тоже не пофиксит. Всё от людей зависит.

Хорошо, давайте разбираться. Ваш пример:

«Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: „Хочу большой корабль, способный бороздить бескрайние, чёрные глубины.“ Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.»

Ответом на это является инкрементность и итеративность. Клиент приходит, рассказывает сказки, через равные интервалы видит результат, вносит коррективы и так по кругу. Внимание, вопрос: где тут Скрам? Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность через механизм спринтов. Но суть в том, что самих по себе их достаточно для обеспечения того, что вы описываете, и Скрам тут — ни к селу, ни к городу. Другое дело, если бы вы говорили, что инкрементности и итеративности может быть недостаточно для обеспечения надлежащего качества/объема работ или попадания в сроки при заданном бюджете. Вот тогда можно было бы говорить о Скраме как об инструменте, с помощью которого можно понять, где есть проблемы (на стороне PO, на стороне команды или и там, и там), которые снижают оные показатели. Еще раз — лакмус.

И как вас SCRUM поможет попасть в бюджет при Fix Price и изначально зафакапленной оценке? Как на это поможет XP?

Скрам поможет вам понять на ранних этапах, что вы не успеваете в свой фиксед прайс. После первого же спринта у вас разработчики собираются на ретро и начинают ныть, что не успели полбэклога они потому, что постоянно меняли одни и те же файлы все вместе, из-за чего уходила тонна времени на слияние. Скрам заставляет их не молчать в тряпочку, не дуться втихую на Васю и не обсуждать эти проблемы только с Петей на перекуре, потому что остальные «ну дебиииилы», а говорить об этом открыто. Задача SM'а не дать скатиться этому в базар. И если он со своей задачей справится и поможет команде самоорганизоваться, т.е. самой поднимать проблемы, обсуждать их и находить решения, то есть все шансы вернуться на нужные рельсы и таки успеть фиксед прайс в срок. В данном конкретном примере, команда имела бы все шансы решить, что им срочно нужно в систему контроля версий, иначе кердык.

Таким образом приходим к тому что не поможет. Не так ли?

Почему вы так решили? :)
Ответом на это является инкрементность и итеративность.
Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность
Скрам тут — ни к селу, ни к городу.

Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?

Безусловно. Иногда Скрам описывают как контейнер для процесса, хоть это и не совсем корректно.
Кривая имплементация обычно обусловлена куда более серьезными проблемами проекта, чем неправильный подход к разработке. А десант скрам-поддержки от специализированной компании может говорить прекрасные и правильные вещи, но изменить ничего не в состоянии. Они просто поддерживают ритуал — видимость прогресса, что даже опаснее, на мой взгляд, чем честный фейл в самом начале.
Вот например, статья — первоисточник. Похоже руководство просто решило подзатянуть гайки, заставить сотрудников работать интенсивнее, пусть и с перегибами. Так вышло, что перегиб принял форму скрама. А мог выразиться в штрафах за минутные опоздания и запретах обеденных перерывов… Едва ли проблему можно было бы решить просто приходя вовремя и не обедая.
Замените «скрам» на «пикап»
Один DT — один PO и желательно один проект (или обязательно один Product Backlog), или необходимо менять серьёзно процесс, менять методологию с чистого SCRUM'а на Kanban (а ещё лучше помесь сделать SCRUMBan, и да, тут нет ничего страшного, если будет интересно, расскажу, как это делать и внедрять плюс всякой разной чернухи).

Очень интересно. Вот конкретная ситуация есть, дано:
— одна команда
— два бизнеса, аналогичные по сути, но с поправками на разные юрисдикции, языки, обычаи делового оборота и некоторые регламенты
— технически две независимые системы уровня ERP+CRM, плюс интеграции с внешними системами, плюс по публичному веб-сайту с развитым «личным кабинетом», практически аналогом фронтофиса в сотнях отделений «на земле», функциональность пересекается процентов на 90 в идеале, по факту около 50 сейчас (где-то реализована одна фича, где-та другая, а должен быть один набор фич), архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолита. В идеале и кодовая база должна быть общей, но с полгода назад для второго (нового) бизнеса форкнули репозитории первого и с тех пор развиваются независимо, сводясь лишь иногда копипастой баг-фиксов, и то не всегда когда надо бы. Для команды по факту есть два глобальных проектах с кучей подсистем, обычное дело для одной юзерстори затронуть с три-четыре подсистемы.
— бизнес не воспринимает системы как единое целое, для него проект — это бизнес-фича, набор новых юзерстори и(или) качественное изменение старых. Это может быть новая подсистема, это могут быть заметные изменения в нескольких существующих. У каждого такого проекта свой владелец, но и у каждой подсистемы с видимым UI есть владелец в бизнесе, у некоторых подсистем в двух бизнесах один владелец, у некоторых (например по бухучету) два, но кроме них задачи команде или отдельным специалистам ставят и другие заинтересованные лица, обычно подчиненные владельца, но нередко и из параллельных департаментов. Конфликты интересов по приоритетам обычное дело, из-за чего часто в работе несколько задач с одинаковым приоритетом, что часто приводит к тому, что вместо запуска одной фичи через месяц, а второй через два, обе релизится в лучшем случае через два c половиной.
— наиболее квалифицированных членов команды часто вызывают на внезапные (для них) длительные совещания по планированию запуска новых фич, по которым им ставится неформальная задача «подумать», не фиксируемая в трекере в принципе
— временная оценка задач дается командой в часах в форме «минимум 80 часов», но бизнес практически всегда переводит её в даты для себя, хорошо если из расчёта 40 часов в неделю и воспринимает не как прогноз, а как обязательство
— постоянные задачи по поддержке, типа зайти в базу ручками и что-то добавить/изменить задним числом. Задачи быстрые, но частые. За месяц грубо набегает время, достаточное для создания UI для таких кейсов
— технический долг огромный, ядро системы разработано в 2011-м, сменилось полностью минимум три поколения разработчиков, считая сейчас четвертое, в которое из третьего перешел только я. Навскидку нужно два месяца работы всей команды без отвлечения на текущие задачи чтобы прикрыть хоть наиболее важные костыли, и даже известные баги и дыры в безопасности и инкапсулировать не самые важные. Долг постоянно растёт. При том что бэклог бизнес-задач на полгода точно.

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

Были попытки как-то упорядочить, разделить команду на две, условные бэкенд и фронтенд, но получилось ещё хуже, даже когда был только один бизнес, а потом началась подготовка ко старту второго. Опять команду разбили на две, но уже по глобальным проектам, но из-за низкой взаимозаменяемости разбиение было довольно условным, хотя было строгое указание каждый занимается прежде всего своим, а другому проекту помогает в свободное время, которого никогда не было. В итоге стояли задачи по обоим и тимлиды и пмы проектов договаривались «мы тебе нашего бэкендера на три дня, а ты нам своего верстальщика на пять», хотя по сути команды были «фуллстэк», способные с нуля решить любую задачу. Но таких практически не было.

Что нам лучше подойдёт?

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


Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.


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


У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?


Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?

Не первый раз, с удивлением, слышу что скрам неприменим в случае когда бюджет важен. Как будто бывают другие случаи.


Что вы на самом деле имели ввиду говоря что Scrum не стоит использовать если бюджет является важным фактором?

Что вы на самом деле имели ввиду говоря что Scrum не стоит использовать если бюджет является важным фактором?

Я???

архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолита
А как вы решаете вопрос с транзакциями?

Обычно, если изначально был монолит, там можно было с ними не заморачиваться. Но если выносить куски в сервисы, которые меняют данные, получается непросто.
Прежде всего на уровне разделения на сервисы решаем. Где ACID железно необходим, стараемся в одном сервисе. А там где можно чутка что-то рассогласовать ненадолго, то мониторингом. В одном месте только распределенные двухфазные транзакции.

Если я правильно помню, то Scrum хоть и не равно Agile, но ноги у него растут из Agile, в котором четко прописано, что рекомендованный размер команды 6-8 человек. Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент. Если есть потребность в столь больших командах оправданы внедрения элементов WaterFall и требуется тратить время на бюрократию с документацией, иначе очень много проблем от "испорченного телефона".
Изменения в ТЗ вносится на 1 спринт, в течении спринта менять моветон. Длительность спринта -вопрос философский, обычно от 1ой недели до 1го месяца.

Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.


Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент.

Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE

@ApeCoder всё правильно ответил, я лишь немного дополню его ответ.


Если есть потребность в столь больших командах оправданы внедрения элементов WaterFall и требуется тратить время на бюрократию с документацией, иначе очень много проблем от "испорченного телефона".

Есть ещё масштабируемый SCRUM, так называемый SAFE Его можно на любой размер натянуть. :) А вообще да, подробили команду 3-9 человек и вперёд. SAFE больше подойдёт когда 50+ человек.


Изменения в ТЗ вносится на 1 спринт, в течении спринта менять моветон. Длительность спринта -вопрос философский, обычно от 1ой недели до 1го месяца.

Изменения в Project Backlog вносятся когда захочется, а вот в Sprint Backlog вообще никто вносить не имеет права за исключением Development Team. Я в этом комменте чуть детальнее описал.


Что же касается длительности, отчасти философский, там есть несколько рекомендаций, сводящихся к тому что чем короче-то тем лучше, но по длине они должны оставаться достаточными чтобы выпустить рабочую версию продукта (shippable increment). Там есть только верхнее ограничение — 1 месяц, а так хоть однодневные спринты можно делать. :) На практике как правило это 2 недели ~ 10 дней.

Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время.
— расскажите, как вы скрещиваете поддержку и разработку? или что, надо поделить команду на 2 части: разработку и support?

Это я в отдельном топике запилю, пожалуй, для коммента достаточно много писать.

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

Выделенный скрам мастер зависит от бюджета, если бюджет проекта позволяет, то можно и пожировать. Но я к таким не отношусь, я обычно играю роль человек-оркестр: Project Manager\Delivery Manager\Project Coordinator\Architect\Development Lead\Team Lead. И все эти роли вполне успешно можно совмещать с ролью SCRUM Master'a.


ИМХО

Я как-то общался с выделенными скрам мастерами, ну чё сказать. Они отчёты делают по 2-3 дня. Я поржал тогда с них, а они обиделись. :) Я то отчёты генерю за 15 минут в тулах.

Подскажите пару рекомендаций:
1) Реально ли использовать 1го сотрудника в проектах с разными методологиями(Scrum, support, Waterfall) или лучше стараться максимально разделять по проектам исходя из используемых методологий?
2) Как организационно в небольшой компании совмещать методологии? Например, разработчики и тестировщики разделены тим-лидами, что хорошо в случае WaterFall или CanBan. Agile и Scrum не очень разделяют такие взгляды, для них характерно другая расстановка ролей и 2 тим-лида в одну команду не очень хорошо укладываются, потому как TL должен взять на себя роль Product Ownera(PO), а 2 PO — это как 2 хозяйки на одной кухне.
Небольшая компания, где менеджеры не хотят набирать на каждую роль человека и приходится балансировать изображая человек-оркестр.

Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?

Чем дальше лес, тем больше дров и непонимания. :)
Проще работать по старинке, пока все работает как часы. :)

Главное чтобы потом этими часами насмерть не придавило. :D

Ну так IT-директор посмотрит на все эти отзывы и подумает, что делать
1. Оставить всё как есть и ждать падения часов.
2. Внедрить SCRUM, но с риском в 90% (по тутошним комментариям), что скрам будет неправильным и всё сразу полетит к чертям.

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

Стокгольмский синдром?

Отнюдь.

Значит, описанное здесь в статье — это нормально, и можно списать на «первый раз»?

Судя по всему стокгольмский синдром у вас, бо не вошло. У нас же всё замечательно. :P
И не спорьте.

Значит, вы и есть те самые 10% счастливчиков.
  1. Реально, но лучше разделять. Т.к. когда человека раздирают между несколькими проектами, то у него эффективность будет снижаться. Это если мы говорим про разработчиков и тестировщиков.


  2. Можно чуть более детально описать? Потому что достаточно общо и сложно какие-то детальные рекомендации дать.
  1. Понятно, что в идельном мире, у одного человека 1 проект. В реалиях, если компания не исчисляет сотрудников тысячами этого очень сложно добиться и придется совмещать. Но даже в реальной ситуации можно выкручиваться и я предполагаю что желательно если и разделять человека на проекты, то хотя бы делить группы проектов по методологиям. Будет ли выигрышь, если людей распределять, не между проектом 1-Scrum и проектом 2-Waterfall, а между проектом 1-Scrum и проектом 2-Scrum. Или если у человека будет 2 проекта уже не столь принципиально одна в них методика или разная?


  2. Кейс примерно такой:
    Проектальная компания, порядка 40-45 человек из них около 25 разработчиков и 5 тестировщиков. Остальные менеджмент, компания территориально разделена. Менеджмент — одна локация, разработчики и тестировщики — другая локация. Локации — 1 часовой пояс, но 3000 км.
    Проекты есть разные, небольшая нагрузка по саппорту, 2-3 основных длительных проекта в которых задействованы от 10 человек(разработчиков и тестировщиков) компании и проекта 3-4 где потребность в людях возникает периодически(3-4 человека), так сказать фоновые проекты.
    Девелоперы делятся между 4мя лидами, тестировщики закреплены за 1м лидом. Основные проекты ведуться 1 по сценарию приближенному к WaterFall, 2 других на субподряде у основного заказчика декларируется Scrum.
    Вот пытаюсь во всем этом нащупать балланс, учитывая что раньше практически все проекты шли по WaterFall c некоторыми изменениями. Либо, действительно упразднить такое явление как Team Lead тестировщиков и двигаться в сторону перераспределения ролей по Scrum сценарию(PO, SM ...). Либо искать еще какие-то варианты перераспределения, например как предложили выше, оставить тимлидов разработчиков и перевести тимлида тестировщиков в discipline.
    Вопрос вызван тем что работь на субподряде по жестким методикам стало крайне тяжело, когда есть зависимотсти своего кода от кода и сроков внешней команды заказчика,

По первому вопросу: я работаю в большой компании, у нас более 20к сотрудников по всему миру. Но у нас SCRUM очень успешно используется. Тут зависит больше от того оплачивает ли проект 100% человека. Если оплачивает, то нет смысла разрывать человека между несколькими проектами и это уже менеджмент косячит, пытаясь урвать как можно больше бабла.
По второму вопросу подумать надо.

По второму вопросу, я бы поступил так.
Тим лидов оставить, можно даже названия их не менять. Одному из лидов дать роль Scrum Master'a. Из всех проектов сформировать проектный портфолио, расставив проектные приоритеты. Чтобы было понимание, что если что-то в фоновом проекте появляется и он имеет высокий приоритет то это добавим в спринт. Спринты же сделать достаточно короткими, что-то около недели, чтобы можно было быстро переключаться в случае чего. Т.е. если что-то приходит по высоко-приоритетным проектам, то задержка будет около недели и можно с высокой точностью сказать когда разработка будет закончена и отдана в релиз. На мой взгляд, неделя — допустимая задержка.
И чисто моё ИМХО, я не увидел у вас наличие бизнес аналитика, лучше наймите, потому что мне не очень понятно кто у вас сбором требований занимается. Возможно сможете высвободить чуток времени разработчикам, если они задают много вопросов и тратят на это много времени.

Спасибо, за ответы будет над чем подумать. Линия в принципе понятна, дальше буду уже из нюансов смотреть на какие роли кого двигать. По-хорошему, бы ставить тим лидов разработчиков Scrum Master в своих проектах. Но не хватает у них навыков, случаются факапы с качеством продукта. Тимлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам, он зацикливается на положительных тестах фичера разработанных в рамках спринта из-за чего не выделяется время на регрессионные и негативные тесты и мало исследуется влияние нового фичера на уже существующие.

имлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам

  1. Являются ли эти проблемы проблемами для самого тим лида?
  2. Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?

Надо сделать так, чтобы команда выработала. SM тут по сути решающей роли не имеет. Поэтому и проблема уйдёт по идее.

SM тут по сути решающей роли не имеет

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

Прикольно читать «Свидетелей SCRUM'а»
<:o)
Искренний совет автору:
Перед тем, как пробовать сдать PSM-II – подучись еще. В этом разборе много расхождений с гайдом и много собственных выводов, которые с очень большой натяжкой можно назвать реальностью.

Source:
У меня есть PSM-II и я внедрял Scrum не раз, так что думаю, могу как-то котироваться ;)

P.S.
Не ради холивара, конечно же. Рад, что кто-то пытается самостоятельно учиться в этой сфере.

Было бы интересно более детальное мнение. Например, какие основные ошибки допустил автор.

Как только дойдут руки, сразу напишу. (чтобы написать нормальный разбор, нужно время)
Либо автор сам уже напишет, к тому времени.

Буду ждать, для меня это интересное предложение!

Насколько я понимаю, ничего не мешает сениор тим-лиду быть СМ-ом. У меня вопрос к обитающим в комментах — уважаемые эксперты, я пишу диплом о разработке ПО (геймдев) на СКРАМе. Хочу склепать за полтора года студией в 20 человек игруху на PS4. Заказчиком выступает в данном случае аудитория РФ с PS4, из их предпочтений будет формироваться ТЗ с помощью маркетинга (аутсорсинг). Возможно ли, на ваш взгляд, если в команде должно быть не более девяти человек, сделать две непересекающиеся СКРАМ команды со своими СМ-ами и ярко выраженной специализацией (допустим, код и дезигн) и подавать каждой из них ТЗ на спринт в зависимости от фидбека маркетинга и требований другого отдела? Это может растянуть сроки, но повысить качество продукта, а в данном случае основное требование — бездефектность.

Сделайте 2-3 команды, дайте им одного Scrum Master'a и общий бэклог. Ибо можете столкнуться с проблемой, что каждая команда копает в своём направлении или делает то, что уже сделано другой командой. А насчёт универсализации — все девелоперы — вы этого не добьётесь в наших реалиях, так что наличие специализаций я считаю нормально, хоть это и расходится с официальной позицией Scrum Guide.

ярко выраженной специализацией (допустим, код и дезигн)

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.


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

Постановка вопроса уже вызывает много вопросов. Но в науке, в отличии от практики, даже отрицательный результат это тоже результат. Хотя уж на совсем очевидные грабли наступать, конечно, не стоит. Пообщайтесь со своим научным консультантом на тему выбранной проблемы, гипотезы и метрик.
Как говорил Ильич: «Недостатки у человека как бы являются продолжением его достоинств. Но если достоинства продолжаются больше, чем надо, обнаруживаются не тогда, когда надо, и не там, где надо, то они являются недостатками».

Scrum, будучи монолитным «framework for managing product development», декларирует слишком много прикольных, но второстепенных, в общем-то, практик. Будучи декларированными эти практики становятся почему-то вдруг важными и при внедрении заставляют менять то, что нормально работает.

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

Scrum предполагает включение и синхронизацию разработки product increment в пределах спринта и команды. Поэтому он плохо подходит для команд с высокой степенью специализации разработчиков, команд, распределенных географически или по времени, при наличии зависимостей от внешних подрядчиков, в ситуации комплексных фич, при наличии контроля качества снаружи, формализованной приемки и т.п… Чтобы обеспечить синхронизацию, процесс вынужден блокироваться, что уже само по себе вызывает кучу вопросов и поводов для менеджерского креатива. Отсюда же и ограничение на размер команд.

Я так понимаю, управление зависимостями — это просто уровень выше чем скрам. См. тут, например.


То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.


Отсюда же и ограничение на размер команд.

Я думаю, управление ограниченным количеством чего угодно есть свойство человеческого мышленгия. Например когда ходил в детстве в походы, мой руководитель говорил, что оптимальное число тургруппы тоже в районе 8 человек.

То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.

Могут быть горизонтальные зависимости на нижнем уровне. Грубо, скрам-команда разработчиков мобильного приложения и скрам-команда бэкенда с АПИ, в том числе (но не только) для него. Нет АПИ — не проверить приложение в условиях приближенных к боевым, нет приложения — не проверить АПИ.

Разбиение на команды, это не данность. Можно перейти к feature teams.

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

Если команды компонентные это зависимость на между командами, а не на нижнем уровне. Можно делать гибриды — достаточно простые правки бекэнда могут делать фронтендеры и мерджить после ревью бекендом. В остальных случаях зависимостями надо управлять в любом случае. Надо пересмотреть видео выше — там есть разные варианты.

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

В случае современной web-разработки, product increment в виде какого-нибудь банального лендинга может задейстовать целую зондер-команду всяких-разных специалистов. Например:
1. Sales/account manager
2. Business analyst
3. UX/UI designer
4. Frontend developer
5. Backend developer
6. DBA
7. QA
8. DevOps
9. Delivery manager
10. Tech writer
11. SEO engineer

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

Я не вебдев и не очень понимаю, зачем столько для лендинга. Например, зачем Tech Writer. Да, в скраме пропагандируют совмещение в рамках команды, T-shaped и М-shaped specialists.

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

В ситуации заказной разработки, крупные заказчики часто отдают наружу лишь отдельные функции в рамках проекта. Нередко QA находится на стороне заказчика, с какими-то своими циклами тестирования и релизов. На выходе требуется не только код, но документация, вместе с инструкциями по развертыванию, тестированию и сопровождению.

Вот для примера лендига — там столько специфики, что нужен специальный Tech Writer чтобы ее написать? Разработчик не может?

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

То есть у конкретного лендинга есть столько специфики, что разработчик не может взять рыбу и поменять конкретные места, ему проще как-то описать это техпису, что бы он потом описал это пользователям?


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

В этом все и дело. Agile как концепция и Scrum как набор конкретных методик и практик это разные вещи. Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.

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

Я бы сказал, что тут можно достаточно сильно варьировать методику в зависимости от того, как определять "Продукт" и "Команду" в конкретном случае. Грубо говоря, подставить в соответсвующие параметры адаптеры для каких-то вещей вне данного процесса.


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

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


Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.

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


В каком-то конкретном случае может окупать, а в каком-то может и нет.

Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком.
Окупает почти всегда. Вот как раз из-за необходимости «коммуницировать». Задача документации — донести информацию до человека, который «не в теме». Разработчику сложно написать хорошую документацию потому что он о том, что документируется слишком много знает!

Всегда есть проблема коммуникации между тем, кто документацию пишет и тем, кто её читает.

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

Разумеется если у документации будет слишком мало читателей (в команде три человека и больше никому документация не нужна), то тут смысла в отдельном техрайтере нет — но только в очень маленьких командах.

Например, почему мы не используем специальных завязывальщиков шнурков?
Потому что тут нет «третей стороны», которую имитирует техрайтер.
Из всего текста, прочитанного мною в изначальном топике, я не встретил упоминания роли Product Owner (везде далее РО). Кто же такой РО — человек ответственный за конечное видение, развитие проекта и управление бэклогом проекта, у него есть ещё ряд обязанностей, но пока что ограничимся этими.

Тут следует заметить, что наличие product owner'а — не изобретение скрама. Ещё Том Демарко писал о необходимости наличия бизнес-аналитика, который будет собирать требования от пользователей, перерабатывать их и формулировать их в виде требований к системе. При разработке видеоигр есть продюсер, который ответственен за разработку концепции игры и за то, чтобы игра соответствовала желаниям пользователей (целевой аудитории).

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

В скраме у PO нет таких обязанностей. Он отвечает за беклог, но не обязан сам делать все это.

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

Так что возражение остаётся прежним: привычной роли в разработке ПО придумали иное название. Суть-то не поменялась.

Так какое старое название для PO я так и не понял. Продюсер-в-игровой-студии? Но даже если такой продюсер и был PO сам термин не эквивалентен. Он, возможно, более общий. Это как сказать, "зачем вы ввели понятие "хордовые", если собаки и рыбы нам давно известны.


И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.

И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.

Предлагаю обсуждать не чьи-либо сомнения (это — неконструктивно), а факты.

А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому. В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название. В чём новизна?

Нужны чёткие критерии отличия и обоснование, почему эти критерии важны. А иначе выглядит, как обыкновенный ребрендинг.
А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому

Это ваше суждние, я не факт. И судя по тому, что вы понимали под PO в первой версии, я ему не доверяю :)


В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название.

Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :). Это и есть новизна. А что вы ожидали — небывалого мегапрорыва от введения ровно одной роли?

я ему не доверяю :)

«Я-суждения» не являются аргументами при ведении дискуссии.

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

Ещё одно «я-суждение».

А в целом — приведите аргументы, почему функция «управления бэклогом» требует отдельной роли, хотя с этим хорошо справляется и продюсер.

Я совершенно не знаю, требуют или не требуют отдельной роли функция "управление беклогом". Мне хотелось бы узнать, кто такой продюсер — нет ли у вас ссылки на описание такой же степени однозначности и понятности как в скрам гайде?

Впервые термин продюсер применительно к разработке видеоигр использовал Трип Хоукинс, основатель Electronic Arts, в 1982 году.

Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.

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

При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.
Для scrum несложно искать аналогии во всем потому, что тут все занимаются всем понемногу. Проводя аналогии между разными областями, вы начинаете строить обобщения и наделять термины несвойственными им значениями, в результате чего получаются некорректные выводы. Принципиальная разница между разными моделями не в их, кажущихся на первый взгляд, сходствах, а в отличиях.

Если посмотреть внимательно на определения, то PO и перечисленные категории пересекающиеся множества — продюсер может быть как PO так и не PO, и PO может быть как продюсером так и нет. PO специфический термин в рамках именно скрама.

В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название. В чём новизна?

Собственно новизна при разработке управленческих методологий часто и заключается в выделении чётких ролей из успешных образцов имеющихся процессов. Все хорошо работающие процессы разработки схожи, выполняется в итоге примерно одинаковый набор функций, вопрос лишь как их распределить по ролям и во времени.
Вот в этот момент должен был вступить в игру SM и послать всех менеджеров в пешее эротическое путешествие оградить разработчиков(DT) от менеджерского беспредела. Желание менеджмента понятно и применимо: оценить, измерить, сэкономить бабла (не ну всё менеджеры этим занимаются, от этого никуда не деться). Но в данном случае в дело должен был вмешаться SM, принимая весь удар на себя, объясняя всем что делает команда, чем занимается и почему их нельзя трогать.

На мой взгляд, крайне слабое решение. Как делается у нас? Если ожидания менеджеров или заказчиков — в плане трудозатрат — не совпадают с оценкой команды, то запускается процедура согласования. Что она включает?

Во-первых, подключаются более опытные инженеры, которые пытаются найти проблемные места, из-за которых «раздувается» эстимейт. Эти проблемные места могут объясняться наличием «рисков незнания» (технологии, стандартного подхода к решению аналогичных задач, пробелами в требованиях и т.д. и т.п.). Если проблемы заключаются в незнании подходов и методологий, то опытные инженеры проясняют их, в результате чего риски снижаются и снижается оценка. Если проблемы в неясности требований, то проясняются требования.

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

Разговор же с менеджерами и заказчиками в стиле «Это наша оценка, и отстаньте от нас» вряд ли повышает успешность проекта.
«Это ваша оценка вряд ли повышает успешность проекта.» В самом деле, для того, чтобы продуктивно торговаться, нужно иметь специфический набор навыков. Такой формат удобен людям с нормальным управленческим образованием, поставленной риторикой и прокаченными софт-скиллами, в большей степени, чем тем, кто умеет программировать компьютеры.

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

Возвращаясь же к нашим наемным работникам, то после «внедрения» scrum, все это и правда классно складывается на оперативных показателях. Как минимум, пока команда не разберется что к чему и соглашается на переработки. Но у этого есть свои побочные эффекты, из-за которых в нормальных компаниях, применяют другие методики управления, а не голимый scrum.

SCRUM не подразумевает под собой переработки, как и любая другая методология. Если случаются подобные эксцессы, то это локальная криво настроенная управленческая практика, но ни как не вина методологии\подхода\фреймворка.

Вы наверно согласитесь, что переходный процесс, связанный с внедрением новой методики, вряд-ли может быть линейным и гладким если ни кто не собирается внедрять вечность? Поэтому отклонения происходят всегда. Технарям, зачастую, свойственен оптимизм в плане прогнозов, а работать с рисками они не умеют. Скрам-покер при планировании добавляет азарта, т.к. в целом играет на понижение оценок.

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

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

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

Ну а про оптимизм я полностью согласен. Я даже выработал такую штуку как коэффициент Глеба, что позволяет митигировать такие риски. Со мной работал парень, который давал заниженные оценки, очень низкие. После 2-3 факапов, я отследил сколько времени он реально тратит и сравнил с его оценкой. Потом все его оценки умножал на этот коэффициент и отсылал заказчику. Как итог всё работало и все были довольны. :)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории