каждый просто должен делать свою работу хорошо

Эх, Константин, принципы "адекватные люди" и "каждый просто должен делать свою работы хорошо" кажутся такими простыми, что мало кто по ним живёт, особенно в крупных корпорациях )))

И Аджайл-то именно об этом, по сути - о "делать свою работу хорошо" и "быть адекватным" )

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

Здесь тоже тонкая грань между формулировками. Так kpi почти любой можно назвать целью спринта. Одной из целей спринта. Или целью спринта для какой-то конкретной роли.

Здесь тоже тонкая грань между формулировками. Так kpi почти любой можно назвать целью спринта. Одной из целей спринта. Или целью спринта для какой-то конкретной роли.

Разница не в формулировках, разница в осмысленности. Целью спринта можно назвать что угодно, если вы (вы все - PO, SM, DevTeam) точно понимаете как и зачем она связана с целями продукта. А что такое "цель спринта для роли"?

Ну есть какая-то роль. Мы строим летающие тарелки и есть человек, который забивает где внутри тарелки 1 гвоздь. И иногда криво забивает. И мы говорим:"цель спринта построить 19 летающих тарелок и не больше двух гвоздей испортить". То есть kpi какой-то процессный, который на одну конкретную роль ложится. Возможно на одного человека. И это именно kpi. Но с помощью формулировок мы можем назвать его целью спринта. Как же тогда kpi от цели спринта отличить и отделить?

Ну есть какая-то роль. Мы строим летающие тарелки и есть человек, который забивает где внутри тарелки 1 гвоздь. И иногда криво забивает. И мы говорим:"цель спринта построить 19 летающих тарелок и не больше двух гвоздей испортить". То есть kpi какой-то процессный, который на одну конкретную роль ложится. Возможно на одного человека. И это именно kpi. Но с помощью формулировок мы можем назвать его целью спринта. Как же тогда kpi от цели спринта отличить и отделить?

О ужас :) Вы так командную работу никогда не получите, если будете оценивать отдельных людей извне команды, это раз. Предъяву надо кидать всей команде - и это либо "цель не достигнута, так как перерасход гвоздей", либо "цель достигнута, но количество загубленных гвоздей ужасно, сделайте с этим что-то". А уж команда пусть внутри себя обсуждает - выгнать Васю криворукого или поставить его на малярные работы, скажем, а забивать гвозди будет Петя. Два - "построить 19 тарелок" как цель спринта - это для какого продукта? Если у вас продукт = "летающая тарелка", которую вы не разрабатываете с нуля, а строите массово, забудьте про скрам и спринты, вы уже не в том домене, где вам скрам нужен. У вас уже поточное производство. Канбан применяйте )

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

если мы говорим про Scrum, то PO тоже часть команды и вся команда ответственна за результат)

PO часть Скрам-команды, разумеется))

Конечно :)

А как же PO, который увольняет команду?

Парни, приветствую. Подскажите чатик с аналитиками. Спасибо

А как же PO, который увольняет команду?

и наоборот бывает)

плюс вариации для продуктовых и аутсорсных компаний

А как же PO, который увольняет команду?

Точно так же, как команда, которая отторгает какого-то своего члена, или, наоборот, не желающая больше работать с конкретным РО. "Вся скрам-команда несёт ответственность" означает в том числе и то, что часть команды расстаётся с какой-то другой частью, если это нужно для повышения качества работы / несения ответственности и т.д.

Но 1 PO может уволить всю команду а 1 член команды уволить PO не сможет

И где тут равенство?

Но 1 PO может уволить всю команду а 1 член команды уволить PO не сможет

Хороший po будет это согласовывать с командой

Но 1 PO может уволить всю команду а 1 член команды уволить PO не сможет

Не, это вообще неправильная иерархия в компании

Никогда PO не бос над разрабами

Хороший po будет это согласовывать с командой

Что согласовывать? Если он всю команду увольняет

он обычно член вообще другой организации

Что согласовывать? Если он всю команду увольняет

Ну, это крайности

Дело не в хорошем/плохом PO. Это все равно что дизайнер уволит программиста

он обычно член вообще другой организации

Что вы имеете ввиду?

PO не член команды?

PO не член команды?

Он член команды, но формально команда ему не репортит

обычно команда репортит своему менеджеру/тимлиду/скрам мастеру

обычно команда репортит своему менеджеру/тимлиду/скрам мастеру

скрам-скрамом, я про формальную иерархию организации

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

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

кто-то должен отвечать за найм, за увольнение, за промоушен

вот это вот "команда решает" касается исключительно решений по проекту

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

в мальеньком продуктовом стартапе зачастую все репортят CTO или прямо CEO - то есть он твой формальный бос, который решает нанимать тебя или нет, сколько платить, увольнять и так далее

в компаниях по-крупнее есть мененджеры среднего звена

есть конечно вот эти вот бирюзовые организации и тп, но это уже next level.

Мне кажется правильно было бы репортить инвестору, или фаундеру

?

Мне кажется правильно было бы репортить инвестору, или фаундеру

Если компаниия из 3-х человек, то да, наверное будешь репортить прямо фаундеру

Т.к они заинтересованы в продукте, а CTO это по сути самый умный разраб

там еще ролей CEO/CTO может не быть

зачастую CTO это один из фаундеров

и по моему опыту зачастую вообще не компетентен технически =)

кто-то должен отвечать за найм, за увольнение, за промоушен

согласен, и это могут быть совсем не участники Scrum Team

согласен, и это могут быть совсем не участники Scrum Team

Угу. Вариантов масса. Например в Spotify есть такая штука - чаптер (то есть все тестировщики, все девелоперы) и начальние чаптера твой формальный бос. По сути это матричная огранизационная структура

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

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

у нас первое время административная структура и Скрам-команды существовали параллельно, но административная отмирает за ненадобностью)

Тому кто сможет сказать продолжать платить за спринты или продукт готов(как это переложить в кровавый иникрпрайз хз)

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

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

опять же - для получения обратной связи и поставки максимальной ценности)

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

Универсальности чего?

думаю, речь о кроссфункциональности), но она для команды в целом, совсем универсальных специалистов не будет, зато частичное перекрывание навыков очень полезно

Допустим у нас есть 3 отдела, в которых 3 разработчика, 3 тестировщика и 1 админ. Спринт 1 неделя в котором 3 стори. Разработка завершена во вторник, тестирование со вторника по четверг, в пятницу админ делает релиз. Чем занимаются разработчики со среды по пятницу, а тестировщик с понедельника по вторник?

поэтому в Скраме есть только роль члена команды разработки ;) и команда самв ищет пути создания инкремента

Менеджеров же нет. Есть только PO и команда, которая либо выполняет нужный продукт или нет

SM забыли(

Допустим у нас есть 3 отдела, в которых 3 разработчика, 3 тестировщика и 1 админ. Спринт 1 неделя в котором 3 стори. Разработка завершена во вторник, тестирование со вторника по четверг, в пятницу админ делает релиз. Чем занимаются разработчики со среды по пятницу, а тестировщик с понедельника по вторник?

Кирилл, это не скрам, а ватерфолл спринтами.

Так до вторника не чего инкрементить, т.к нечего тестировать)

Значит классическая орг структура на Скрам не ложится? До тех пор пока там не будет 3 роли?

Классическая структура с функциональными колодцами, конечно, не ложится.

Где есть разбиение по отделам

Подходит ли в таким случае Скрам для крупных серьезных продуктов, а не экспериментов?

Я больше склоняюсь к кабану, но у на почему то все в ИТ любят Скрам, хотя Андрей с вами полностью согласен, что при четкой орг структуре Скрам не заходит

Подходит ли в таким случае Скрам для крупных серьезных продуктов, а не экспериментов?

А что является серьезным крупным продуктом?

может быть, что Scrum не подходит, а если подходит, то есть варианты масштабирования)

Электронный банк к примеру

Биоинговая система приема платежей

Северсталь например ведет разработку по скраму :)

Совсем не it

Я просто все еще не понимаю чем занимаются тестировщики с понедельника по вторник в моём примере из жизни, а если сказать что они тоже код пишет, то мне немного стремно если они будут кодить финансовые системы(это будет как группа фельдшеров делающих операцию на сердце)😂

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

Я просто все еще не понимаю чем занимаются тестировщики с понедельника по вторник в моём примере из жизни, а если сказать что они тоже код пишет, то мне немного стремно если они будут кодить финансовые системы(это будет как группа фельдшеров делающих операцию на сердце)😂

Тестировщики могут договорится с разработчиками и писать тесты для ожидаемого кода, например :)

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

Но в целом идея понятна, если есть четкая орг структура и разбиение по отделам со спец навыками, то Скраму там не жить(резюмируя наш диалог)