Комментарии 161
Вообще я обычно описываю ребятам их обязанности, возможности и пр. согласно SCRUM'y, ну а сам играю роль этакого зонтика скрам мастера. Потому что без принятия самой командой, скрама не получится, но обучить команду, дать им правильную культуру скрама и помогать им её взростить — прямая обязанность SM'a. Притом через некоторое время они сами и отклонение от эталона заметят и порядок наведут. Главное их от негативного внешнего влияния защищать.
А разве качество — это не мимо? Не, ну вот серьезно — разве 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.
Очень скоро RIM умер и даже теперь Blackberry в убытках. Это кстати не едиственная компания, которуя я знаю и что с ней стало в результате прогрессивных методов эффективных менеджеров.
Когда приходит VP с опытом написания софта отпуска таблеток в больнице и учит синьер инженеров как писать высоконагруженные сервера становится печально.
В конце вылилось в то что 90% времени стали тратить на митинги, где девелоперы находясь то в одной виртуальной группе выслушали очередную прогрессивную ахинию.
На девелопмент времени уже не оставалось. Рим развалился. Кто сам сбежал, кто дождался жирного бонуса.
, когда к нам привнесли Agile и Scrum атесстованные мастера, у нас стало 5-7 ПМ-ов на каждого девелопера, целая группа архитекторов (чем они занимались я за несколько лет так и не понял).
Не думали ли вы, что одновременно, или даже последовательно идущие события не всегда имеют прямую связь между собой?
Я это к чему — когда цели ставятся так, в заведомо странной постановке, можно уже не разбирать, что было причиной — Agile или что-то еще. Если мы не знаем, чего хотим достигнуть — мы этого точно не достигнем никогда.
Ну вы же понимаете, надеюсь, что это не происходит само собой? И вообще ничто не происходит само собой? Что повышение качества — это работа, которая требует времени и стоит денег? Т.е., грубо говоря, проведение ретроспективы — это и есть та работа. И когда говорят, что хотят улучшить скорость и качество — надо заведомо готовиться к увеличению стоимости, разве бывает иначе?
Тут как и везде нужно понимать, если мы ловим рыбу, то не ловим на золотой крючок, ибо дороже выйдет. У скрама, как и любого формализованного процесса есть накладные расходы, пожалуй, их нет только в подходе "Пиши код бл**ть!", но большой продукт уровня Enterprise врядли можно создать по подобной методологии. :)
Просто зачастую с помощью коллективного разума на той же ретре можно найти какие-то вещи которые можно оптимизировать и срубить с этого дофига профита. Вот например эффективное испольование по сути ретро описано в этой книге.
Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
Но прямо сейчас — а особенно в сочетании с сокращением сроков разработки — это вряд ли.
Как правило эффект от экономии наступает через спринт. Т.е. если внедрили и оно заработало, то где-то со следующего спринта будет достаточно ощутимый эффект. Это конечно не прямо сейчас, но вполне ближайшая перспектива.
Дано: Разработчик Вася может не докоммитать код в гит. Васе стучали по голове тапком, но Вася упрям и невнимателен. Как итог на QA сервера попадает битый код\solution\продукт, который работает лишь местами. QA инженеры тратят время на то чтобы зайти, посмотреть что билд битый и пойти поругаться.
Решение: Вводим дополнительную настройку CI которая позволяет закоммитать в бранч проекта только после того как пройдёт промежуточный билд фичи. Линкуем статус фичи в билде и статус фичи в системе учёта задач, т.е. пока не будет норм. билда статус сменить нельзя на complete.
Итог: если Вася всё также невнимателен, то QA не тратят время на проверку, мы экономим время и средства и повышаем качество продукта.
Это можно отнести к качеству?
В общем случае отчего низко качество разработки: Либо разработчик Вася просто низкой квалификации (тут есть варианты, может он просто новенький), либо эта квалификация низкая у кого-то еще (аналитики, QA и пр.), либо плохо с взаимодействием — из-за чего Васю не понимает QA Петя. И это уже поправить быстро нельзя. Хотя да, внедрение другой методологии может поправить взаимодействие в команде — но вряд ли все-таки быстро.
Вводим дополнительную настройку CI
А причём тут скрамы и спринты? Автоматические и автоматизированные методы контроля качества не привилегия ни то, что скрама, а даже аджайла.
Вот ещё пример из достаточно раннего, сейчас вспомнил. Кстати реально существовавшая ситуация.
Дано: есть legacy система, её нужно мигрировать на новые "рельсы", тобишь с применением модных и современных фрэймворков. В системе достаточно строгие требования по валидации и UI элементам. Разработчики могли забить на расположение элементов или не докрутить валидацию.
Решение: расширили DoD, введя чеклист из, вроде, 10 пунктов, где было описано проверь то, затем проверь то и если есть это, то ещё и вон то. Распечатали и повесили у каждого на перегородку, Плюс ввели в воркфлоу в джире дополнительный этап — проверка согласно DoD. На это выдавалсь 20-30 минут где-то (за это время можно и проверить и сходить покурить, сам заполнял такие листы и тогда ещё курил), как итог разработчик прикреплял заполненный чеклист (да он был и в электронном виде).
Итого: Количество UIных багов сократилось в 7 раз. В течении 2х недель.
А теперь представьте что это был проект в котором работало 70 разработчиков и примерно 50 тестировщиков.
Подходит под описание качества?
И если задача изначально ставится как «хотим это и это» — то никакая методология тут ничего не даст, потому что чудес не бывает. И тут можно уже не разбирать детально причины провала — постановка противоречивых целей и есть одна из главных причин.
есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести.
Ах, если бы это было так! В реальности, зачастую бывает совсем по-другому, и вовсе не потому, что команда не умеет «готовить» Scrum. А потому, что качество — это просто ещё одна из характеристик создаваемого программного продукта, и далеко не всегда заказчик готов платить за решение, сделанное полностью «по фэншую».
Есть такое. Просто иногда нужно это очень аккуратно размазать в project plan'е и не палиться. Т.е. задачу можно сделать за 4ч., но заложив накладные расходы на нормальный процесс мы получим 5ч., вот последнюю цифру и отсылаем заказчику.
команду не трогают и работают через него (СМ)
А потянет ли 1 СМ команду из 25 разрабов и 13 менеджеров? :)
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
работая параллельно над тремя-пятью проектами каждый
Разве скрам подходит для аутсорса? :)
Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а.
А если много запросов с одного проекта? :)
Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема?
Короче, все зависит от людей.
Дебилы могут испоганить что угодно. :)
Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса.
Хм.
А у нас не так.
Менеджеры из бизнеса называются просто бизнес.
А менеджеры проектов являются и PO.
Вот эти PO и неадекватные. :) Вообще не фильтруют бред от бизнеса.
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :) Если бы скрам внедряли адекватные люди, то возможно и проблем бы не было. Да проблем не было при любой методологии.
Скрам — это гибкая методология?
Как часто допускается вносит изменения в ТЗ?
Коммуникация вместо разраб <-> менеджер будет разраб <-> СМ <->менеджер? :)Да, разумеется. Собственно основная проблема, которую так или иначе пытаются решить все эти методологии — это решить всем известную проблему. Менеджеры часто искренне стараются помочь разработчикам делать своё дело (а иначе зачем они нафиг нужны?), но не понимая чем «время творца» отличается от «времени менеджера» делают только хуже. И даже рассказы в красках не помогают. Приходится вводить какую-то формализацию, позволяющую оставить разработчикам возможность, собственно, разрабатывать.
(менеджеры не из бизнеса, а менеджеры проектов, бизнес-аналитики)
А то что два митинга — это еще два часа из моего и так совсем не резинового временного бюджета — это не доходит?В том-то и дело, что нет! Менеджеры свою основную работу часто делают на тех самых митингах (по русски, вообще-то — совещаниях) и дополнительные совещания для них весьма полезны (вместо досятка писем достаточно переоброиться лично парой фраз). Представить себе, что для разработчика, в общем-то ситуация противоположная — они просто не могут. Не «не хотят» — не могут. Они по-другому устроены в большинстве своём, иначе они выбрали бы другую работу! Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»
Многие менеджеры искренне полагают, что тот факт, что разработчики не умеют жить по их расписанию — проблема, которую нужно исправить — и на фирме наступит согласие. Так зачастую и происходит — а что при этом людей, способных глубоко вникнуть в суть проблемы и сделать всё быстро и качественно на фирме не остаётся совсем — вещь, которая из их сознания ускользает.
Типичная реакция на рассказ — там же, в комментариях: «Какие мы нежные. Поплачьте в углу, только соплями не захлебнитесь, нытики.»
Я довольно давно занимаюсь разработкой, но вот в таком тоне со мной никто ни разу не говорил.
Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках 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
Ок, пусть нету.
Потянет ли 1 СМ команду из 25 разрабов? :)
Он будет ТЗ писать? :)
Удалось ли вам прочитать хотя бы те цитаты, которые я привел? Хотя бы выделенное жирным ;)
Там есть про рекомендуемый размер комаднды.
Посмотрите в скрам гайд.
Задача SM — чтобы процесс соблюдался, а не писать ТЗ.
Задача PO — чтобы продукт был клёвый — управление беклогом и приоритетами.
Никаких ТЗ в скраме нет, как собирать требования, в какой форме их представлять — не ограничивается. Скрам про управление процессом разработки.
В Agile духе писать User Stories.
Если вы хотите разобраться — читайте гайд — он написан понятным языком и хорошо структурирован.
Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
линк
проектные менеджеры должны играть роль скрам мастера
Нету ТЗ.
В Agile духе писать User Stories.
Та плевать как вы это назовете.
Скрам про управление процессом разработки.
Судя по всему это 5-ое колесо в телеге. :)
Та плевать как вы это назовете.
Это как раз одна вещей, которая сильно улучшает ваимодействие между людьми — называть одно и то же одними и теми же словами :)
Нету менеджеров. А под менеджерами я понимал то, что тут называют СМ:
Не-не-не. Не перевирайте, пожалуйста, мои слова. Я описал фикс и моё видение для кокретного состава команды, приведённого в изначальном комменте. Исходя из того что в рамках бизнеса состав команды поменять невозможно, можно лишь сделать иной сетап с иными входными инструкциями к дейтсвию. Иногда это помогает.
Вот так у нас внедрили скрам. :)
Лучше бы часы придавили. :)
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :)
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
Команда была самоуправляема до внедрения модных методологий, а чем больше внедряют методологию, тем больше выходит наоборот.
Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления.
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
а предложения по улучшению процессов
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас 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 менеджерами есть еще одни менеджеры, а уже над теми бизнес. :)
Нужно еще больше менеджеров (мастеров)?
Или таки меньше? :)
Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
это и есть суть Agile, который про ушедшие от водопада бизнесы, которые вынуждены были становиться все динамичнее и динамичнее, отвечая на вызовы рынка.
Только выходит наоборот. :)
Адекватно оттюненный водопад лучше неработающего скрама (а это почти всегда так). :)
Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет.
Как на всё это влияет водопад? :)
Какие технические метрики тогда определяет водопад?
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.
Вопрос: сколько букв вы сэкономили используя эти сокращения и сколько раз «что это за херь?» прозвучало из уст читателей? Это того стоит? Посчитайте общее количество букв в этом топике и количество сэкономленных букв. Прикиньте какие это доли процента. 0.01%? Меньше?
Не соглашусь. Я столько видел кривых имплементаций скрама, что аж жуть берёт.
Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: "Хочу большой корабль, способный бороздить бескрайние, чёрные глубины." Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.
А то что многое зависит от команда — да, никто и не спорит.
Скрам тоже итеративен, кстати. Но он не методология, а фреймворк, поэтому иногда скорость фикса той или иной проблемы зависит от опыта, знаний и команды. Тот же RUP\XP предоставит наличие дополнительных артефактов, но проблемы сам тоже не пофиксит. Всё от людей зависит.
«Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: „Хочу большой корабль, способный бороздить бескрайние, чёрные глубины.“ Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.»
Ответом на это является инкрементность и итеративность. Клиент приходит, рассказывает сказки, через равные интервалы видит результат, вносит коррективы и так по кругу. Внимание, вопрос: где тут Скрам? Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность через механизм спринтов. Но суть в том, что самих по себе их достаточно для обеспечения того, что вы описываете, и Скрам тут — ни к селу, ни к городу. Другое дело, если бы вы говорили, что инкрементности и итеративности может быть недостаточно для обеспечения надлежащего качества/объема работ или попадания в сроки при заданном бюджете. Вот тогда можно было бы говорить о Скраме как об инструменте, с помощью которого можно понять, где есть проблемы (на стороне PO, на стороне команды или и там, и там), которые снижают оные показатели. Еще раз — лакмус.
И как вас SCRUM поможет попасть в бюджет при Fix Price и изначально зафакапленной оценке? Как на это поможет XP?
Ответом на это является инкрементность и итеративность.
Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность
Скрам тут — ни к селу, ни к городу.
Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
Вот например, статья — первоисточник. Похоже руководство просто решило подзатянуть гайки, заставить сотрудников работать интенсивнее, пусть и с перегибами. Так вышло, что перегиб принял форму скрама. А мог выразиться в штрафах за минутные опоздания и запретах обеденных перерывов… Едва ли проблему можно было бы решить просто приходя вовремя и не обедая.
Один DT — один PO и желательно один проект (или обязательно один Product Backlog), или необходимо менять серьёзно процесс, менять методологию с чистого SCRUM'а на Kanban (а ещё лучше помесь сделать SCRUMBan, и да, тут нет ничего страшного, если будет интересно, расскажу, как это делать и внедрять плюс всякой разной чернухи).
Очень интересно. Вот конкретная ситуация есть, дано:
— одна команда
— два бизнеса, аналогичные по сути, но с поправками на разные юрисдикции, языки, обычаи делового оборота и некоторые регламенты
— технически две независимые системы уровня ERP+CRM, плюс интеграции с внешними системами, плюс по публичному веб-сайту с развитым «личным кабинетом», практически аналогом фронтофиса в сотнях отделений «на земле», функциональность пересекается процентов на 90 в идеале, по факту около 50 сейчас (где-то реализована одна фича, где-та другая, а должен быть один набор фич), архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолита. В идеале и кодовая база должна быть общей, но с полгода назад для второго (нового) бизнеса форкнули репозитории первого и с тех пор развиваются независимо, сводясь лишь иногда копипастой баг-фиксов, и то не всегда когда надо бы. Для команды по факту есть два глобальных проектах с кучей подсистем, обычное дело для одной юзерстори затронуть с три-четыре подсистемы.
— бизнес не воспринимает системы как единое целое, для него проект — это бизнес-фича, набор новых юзерстори и(или) качественное изменение старых. Это может быть новая подсистема, это могут быть заметные изменения в нескольких существующих. У каждого такого проекта свой владелец, но и у каждой подсистемы с видимым UI есть владелец в бизнесе, у некоторых подсистем в двух бизнесах один владелец, у некоторых (например по бухучету) два, но кроме них задачи команде или отдельным специалистам ставят и другие заинтересованные лица, обычно подчиненные владельца, но нередко и из параллельных департаментов. Конфликты интересов по приоритетам обычное дело, из-за чего часто в работе несколько задач с одинаковым приоритетом, что часто приводит к тому, что вместо запуска одной фичи через месяц, а второй через два, обе релизится в лучшем случае через два c половиной.
— наиболее квалифицированных членов команды часто вызывают на внезапные (для них) длительные совещания по планированию запуска новых фич, по которым им ставится неформальная задача «подумать», не фиксируемая в трекере в принципе
— временная оценка задач дается командой в часах в форме «минимум 80 часов», но бизнес практически всегда переводит её в даты для себя, хорошо если из расчёта 40 часов в неделю и воспринимает не как прогноз, а как обязательство
— постоянные задачи по поддержке, типа зайти в базу ручками и что-то добавить/изменить задним числом. Задачи быстрые, но частые. За месяц грубо набегает время, достаточное для создания UI для таких кейсов
— технический долг огромный, ядро системы разработано в 2011-м, сменилось полностью минимум три поколения разработчиков, считая сейчас четвертое, в которое из третьего перешел только я. Навскидку нужно два месяца работы всей команды без отвлечения на текущие задачи чтобы прикрыть хоть наиболее важные костыли, и даже известные баги и дыры в безопасности и инкапсулировать не самые важные. Долг постоянно растёт. При том что бэклог бизнес-задач на полгода точно.
Попытка внедрения скрама провалилась, как по мне то прежде всего из-за организации работ по бизнес-проектам с собственным бэклогом у каждого, невключения даже в них задач поддержки и «подумать» и низкой взаимозаменяемости. Что кто делает в принципе было понятно, но как делает, никто толком не знает, каждый занимается своей задачей в «своих» подсистемах. После увольнения нескольких человек целые подсистемы болтаются «бесхозными», на любую задачу по изменению логики разработчик просит минимум неделю чтобы только дать оценку, а ещё лучше две-четыре недели, чтобы переписать.
Были попытки как-то упорядочить, разделить команду на две, условные бэкенд и фронтенд, но получилось ещё хуже, даже когда был только один бизнес, а потом началась подготовка ко старту второго. Опять команду разбили на две, но уже по глобальным проектам, но из-за низкой взаимозаменяемости разбиение было довольно условным, хотя было строгое указание каждый занимается прежде всего своим, а другому проекту помогает в свободное время, которого никогда не было. В итоге стояли задачи по обоим и тимлиды и пмы проектов договаривались «мы тебе нашего бэкендера на три дня, а ты нам своего верстальщика на пять», хотя по сути команды были «фуллстэк», способные с нуля решить любую задачу. Но таких практически не было.
Что нам лучше подойдёт?
Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
Не первый раз, с удивлением, слышу что скрам неприменим в случае когда бюджет важен. Как будто бывают другие случаи.
Что вы на самом деле имели ввиду говоря что Scrum не стоит использовать если бюджет является важным фактором?
архитектура когда-то была обычная трехзвенка, сейчас стала сервис-ориентированная с уклоном в микросервисы путем выделения из легаси-монолитаА как вы решаете вопрос с транзакциями?
Обычно, если изначально был монолит, там можно было с ними не заморачиваться. Но если выносить куски в сервисы, которые меняют данные, получается непросто.
Если я правильно помню, то 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
1. Оставить всё как есть и ждать падения часов.
2. Внедрить SCRUM, но с риском в 90% (по тутошним комментариям), что скрам будет неправильным и всё сразу полетит к чертям.
Первый раз всегда больно, а потом уже нравится. :D
Реально, но лучше разделять. Т.к. когда человека раздирают между несколькими проектами, то у него эффективность будет снижаться. Это если мы говорим про разработчиков и тестировщиков.
- Можно чуть более детально описать? Потому что достаточно общо и сложно какие-то детальные рекомендации дать.
Понятно, что в идельном мире, у одного человека 1 проект. В реалиях, если компания не исчисляет сотрудников тысячами этого очень сложно добиться и придется совмещать. Но даже в реальной ситуации можно выкручиваться и я предполагаю что желательно если и разделять человека на проекты, то хотя бы делить группы проектов по методологиям. Будет ли выигрышь, если людей распределять, не между проектом 1-Scrum и проектом 2-Waterfall, а между проектом 1-Scrum и проектом 2-Scrum. Или если у человека будет 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, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам
- Являются ли эти проблемы проблемами для самого тим лида?
- Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Надо сделать так, чтобы команда выработала. SM тут по сути решающей роли не имеет. Поэтому и проблема уйдёт по идее.
<:o)
Перед тем, как пробовать сдать PSM-II – подучись еще. В этом разборе много расхождений с гайдом и много собственных выводов, которые с очень большой натяжкой можно назвать реальностью.
Source:
У меня есть PSM-II и я внедрял Scrum не раз, так что думаю, могу как-то котироваться ;)
P.S.
Не ради холивара, конечно же. Рад, что кто-то пытается самостоятельно учиться в этой сфере.
Сделайте 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.
Если команды компонентные это зависимость на между командами, а не на нижнем уровне. Можно делать гибриды — достаточно простые правки бекэнда могут делать фронтендеры и мерджить после ревью бекендом. В остальных случаях зависимостями надо управлять в любом случае. Надо пересмотреть видео выше — там есть разные варианты.
В случае современной 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 как набор конкретных методик и практик это разные вещи.
Я бы сказал, что тут можно достаточно сильно варьировать методику в зависимости от того, как определять "Продукт" и "Команду" в конкретном случае. Грубо говоря, подставить в соответсвующие параметры адаптеры для каких-то вещей вне данного процесса.
Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.
Я где-то встречал мысль, что чтобы узнать что-то новое надо постараться внедрить идею буквально ища смысл в ее деталях — тогда это заставит взглянуть на процесс с другой стороны и узнать что-то новое. Иначе просто человек отвергнет что-то значимое исходя из своих текущих стереотипов и останется при своих
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.
Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком. Например, почему мы не используем специальных завязывальщиков шнурков?
В каком-то конкретном случае может окупать, а в каком-то может и нет.
Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком.Окупает почти всегда. Вот как раз из-за необходимости «коммуницировать». Задача документации — донести информацию до человека, который «не в теме». Разработчику сложно написать хорошую документацию потому что он о том, что документируется слишком много знает!
Всегда есть проблема коммуникации между тем, кто документацию пишет и тем, кто её читает.
Можно взять другого разработчика, который «не в теме» и попросить его написать документацию. Результат уже будет лучше. Но проще и полезнее — нанять техрайтера.
Разумеется если у документации будет слишком мало читателей (в команде три человека и больше никому документация не нужна), то тут смысла в отдельном техрайтере нет — но только в очень маленьких командах.
Например, почему мы не используем специальных завязывальщиков шнурков?Потому что тут нет «третей стороны», которую имитирует техрайтер.
Из всего текста, прочитанного мною в изначальном топике, я не встретил упоминания роли Product Owner (везде далее РО). Кто же такой РО — человек ответственный за конечное видение, развитие проекта и управление бэклогом проекта, у него есть ещё ряд обязанностей, но пока что ограничимся этими.
Тут следует заметить, что наличие product owner'а — не изобретение скрама. Ещё Том Демарко писал о необходимости наличия бизнес-аналитика, который будет собирать требования от пользователей, перерабатывать их и формулировать их в виде требований к системе. При разработке видеоигр есть продюсер, который ответственен за разработку концепции игры и за то, чтобы игра соответствовала желаниям пользователей (целевой аудитории).
В данном случае скрам просто занимается переименованием уже известных вещей.
бизнес-аналитика, который будет собирать требования от пользователей, перерабатывать их и формулировать их в виде требований к системе.
В скраме у PO нет таких обязанностей. Он отвечает за беклог, но не обязан сам делать все это.
Так что возражение остаётся прежним: привычной роли в разработке ПО придумали иное название. Суть-то не поменялась.
Так какое старое название для PO я так и не понял. Продюсер-в-игровой-студии? Но даже если такой продюсер и был PO сам термин не эквивалентен. Он, возможно, более общий. Это как сказать, "зачем вы ввели понятие "хордовые", если собаки и рыбы нам давно известны.
И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
Предлагаю обсуждать не чьи-либо сомнения (это — неконструктивно), а факты.
А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому. В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название. В чём новизна?
Нужны чёткие критерии отличия и обоснование, почему эти критерии важны. А иначе выглядит, как обыкновенный ребрендинг.
А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому
Это ваше суждние, я не факт. И судя по тому, что вы понимали под PO в первой версии, я ему не доверяю :)
В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название.
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :). Это и есть новизна. А что вы ожидали — небывалого мегапрорыва от введения ровно одной роли?
я ему не доверяю :)
«Я-суждения» не являются аргументами при ведении дискуссии.
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :).
Ещё одно «я-суждение».
А в целом — приведите аргументы, почему функция «управления бэклогом» требует отдельной роли, хотя с этим хорошо справляется и продюсер.
Я совершенно не знаю, требуют или не требуют отдельной роли функция "управление беклогом". Мне хотелось бы узнать, кто такой продюсер — нет ли у вас ссылки на описание такой же степени однозначности и понятности как в скрам гайде?
Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.
Еще более подробно обязанности продюсера изложены во внутренних документах игровых студий.
При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.
Если посмотреть внимательно на определения, то PO и перечисленные категории пересекающиеся множества — продюсер может быть как PO так и не PO, и PO может быть как продюсером так и нет. PO специфический термин в рамках именно скрама.
В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название. В чём новизна?
Собственно новизна при разработке управленческих методологий часто и заключается в выделении чётких ролей из успешных образцов имеющихся процессов. Все хорошо работающие процессы разработки схожи, выполняется в итоге примерно одинаковый набор функций, вопрос лишь как их распределить по ролям и во времени.
Вот в этот момент должен был вступить в игру SM и послать всех менеджеров в пешее эротическое путешествие оградить разработчиков(DT) от менеджерского беспредела. Желание менеджмента понятно и применимо: оценить, измерить, сэкономить бабла (не ну всё менеджеры этим занимаются, от этого никуда не деться). Но в данном случае в дело должен был вмешаться SM, принимая весь удар на себя, объясняя всем что делает команда, чем занимается и почему их нельзя трогать.
На мой взгляд, крайне слабое решение. Как делается у нас? Если ожидания менеджеров или заказчиков — в плане трудозатрат — не совпадают с оценкой команды, то запускается процедура согласования. Что она включает?
Во-первых, подключаются более опытные инженеры, которые пытаются найти проблемные места, из-за которых «раздувается» эстимейт. Эти проблемные места могут объясняться наличием «рисков незнания» (технологии, стандартного подхода к решению аналогичных задач, пробелами в требованиях и т.д. и т.п.). Если проблемы заключаются в незнании подходов и методологий, то опытные инженеры проясняют их, в результате чего риски снижаются и снижается оценка. Если проблемы в неясности требований, то проясняются требования.
Во-вторых, заказчикам и менеджерам объясняется, из-за чего раздувается оценка. Нередко случается так, что на оценку влияет какое-нибудь совершенно несущественное требование, без реализации которого заказчик может обойтись. Такие требования исключается. Если же оценку увеличивает важное требование, то инженеры и заказчики совместными усилиями думают, а можно ли его как-нибудь переформулировать так, чтобы реализация не требовала бы значительного времени.
Разговор же с менеджерами и заказчиками в стиле «Это наша оценка, и отстаньте от нас» вряд ли повышает успешность проекта.
Если подходить к вопросу торга при оценке задач чисто с рыночных позиций, то в условиях свободного рынка, кастомизация продается дороже, а не дешевле типовых решений. Типовые же решения стоят вполне определенные деньги. Затраты снижаются за счет реюзинга, автоматизации и инноваций. Для обмена знаниями между инженерами рулит парное программирование и образовательные программы, а не стресс на глазах заказчика и менеджмента.
Возвращаясь же к нашим наемным работникам, то после «внедрения» scrum, все это и правда классно складывается на оперативных показателях. Как минимум, пока команда не разберется что к чему и соглашается на переработки. Но у этого есть свои побочные эффекты, из-за которых в нормальных компаниях, применяют другие методики управления, а не голимый scrum.
SCRUM не подразумевает под собой переработки, как и любая другая методология. Если случаются подобные эксцессы, то это локальная криво настроенная управленческая практика, но ни как не вина методологии\подхода\фреймворка.
Из-за этого недооценки командами объема работ на первых этапах случаются регулярно. На моей практике еще не было случая, чтобы в такой ситуации менеджмент упустил возможность напомнить команде о важности соответствовать своим должностям и выполнять работу к обещанному сроку. Отсюда систематические переработки. У вас иной опыт?
Обученные команды торгуются за комфортные условия круче московских таксистов, и тут уже менджмент теряет всякий интерес к этой методологии.
Да, у меня опыт иного характера. Я совершенно спокойно получал пи****лей от деливери менеджера, общался с заказчиком, увеличивал скоуп и торговался, что-то резал, что-то вмещал в бюджет. Как показывает практика, если не рашить упорото команду она выдаст отличный результат.
Ну а про оптимизм я полностью согласен. Я даже выработал такую штуку как коэффициент Глеба, что позволяет митигировать такие риски. Со мной работал парень, который давал заниженные оценки, очень низкие. После 2-3 факапов, я отследил сколько времени он реально тратит и сравнил с его оценкой. Потом все его оценки умножал на этот коэффициент и отсылал заказчику. Как итог всё работало и все были довольны. :)
Обратная сторона Agile — разбирая чужие ошибки