Самое ценное - это оплата по сбп. Тогда надо подумать, как можно в самом урезанном варианте сделать оплату, чтобы оно работало. Скорее всего это поместится в спринт
Далее, мы изучаем как им пользуются. Скорее всего все будут плеваться, жаловаться, но даже это - уже что-то, есть что изучить
Далее, мы выкатывам уже удобства, по qr code и так далее
Продакт понимает, что фича очень крупная и идёт к разработке, событие выяснить, что можно урезать так, чтобы влезло в спринт. При этом продакт каждый раз оценивает, будет ли в этом смысл
В целом, так работает событие pbr: продакт идёт разбивать фичи на мелкие куски с хоть какой-то ценностью для клиента
Яркий пример TPS в Европе - Porsche годов 1995-2003
Изучите что было до и что стало
На самом деле есть 4 примера компаний из запада, которые смогли принять философию и добиться примерно того же результата, что и Тойота. Это из книги "бережливое производство"
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером
Опять же: не будет скрам мастер решать технические задачи. Опять вы вместо того чтобы идти за помощью в решением технических проблем, идете к СМ, который понятия не имеет что за проблема. Он скорее психолог, поможет разобраться в себе, поможет вам обратиться к команде, чтоб не подставить их, ведь вы можете провалить спринт.
Чистый скрам мастер не может помочь команде во взаимодействии
Это его работа, пересчитайте скрамгайд
- коучит участников команды в части самоуправления и кросс-функциональности; - помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, соответствующих определению готовности; - способствует устранению препятствий, мешающих прогрессу Scrum Team; а также, - убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени.
Про скрам мастера часто говорится, что он не решает "мои проблемы"
А он и не должен, если честно. ваши проблемы могут решить ваши однокомандники, но вы их видимо за программистов не считаете, раз идете к СМ(который часто вообще не из IT)
тем более если считаете, что в продукте есть "мой код", за которого вы отвечаете. Поэтому выше был комментарий про излишнее "я". И это не про "моя реакция на события и положение", это отсутствие понимания командной работы.
У вас хорошее понимание процессов скрам, но твердое неверие в идеи командой работы, коллективной ответственности, и т.д.
очень сложно понять, что тут заголовок, а что тут мусорный текст со ссылкой. Всю статью глаза мозолит, сложно читать Хотел пробежаться по заголовкам, понять все ли знаю А тут постоянно этот текст со ссылкой бедные глаза мои...
Если учесть что 85% электроэнергии вырабатывается от сжигания углерода, то так себе история с "не выбрасывать углерод" И самое ужасное - динамика доли зеленой энергетики за 10 лет практически не поменялась, где-то на уровне 85% стоит
Надо смотреть на все это как на туман войны в игре - у тебя есть хаос, и надо исследовать. Пока не сделаешь несколько мелких шагов не поймёшь что дальше
В гибких методолгиях есть место стратегии, просто не такая конкретная, и может меняться
Насчёт архитектуры - эта вещь динамическая, она меняется. Архитектура подстраивается под нужды, его можно менять в случае необходимости. Если архитектуру прибить гвоздями в начале развития продукта - ничего хорошего не выйдет.
Ссылок на авторитетов не смогу дать, не видел таких материалов. В скрам гайде не нашел момента, если команда целиком саботирует процесс.
На практике у меня была одна команда, которая решила саботировать - они даже играл CS во время работы все вместе. Через несколько месяцев всю команду уволили, хотя там были пару очень крутых спецов.
В целом, надо работать с командой целиком. Если вся команда саботирует, значит воздействовать на всю команду целиком. Если кто-то конкретный саботирует, то скрам мастер должен это выявить и показать команде, что внутри есть паразит. Если коллег это устраивает, то тут ничего не поделать. Если совсем никак не реагируют на проблемы, я бы (мое личное мнение) уволил всю команду.
Да, бывает такое. Это значит что компания ещё не готова к серьезным изменениям.
Я обычно просто спрашиваю - что будете делать, если узнаете что ваш разработчик не имеет задач. Если отвечают, что срочно дают новые задачи, значит в этой компании всегда есть и будут сверхурочные
По сути, авралы возникают не потому что программисты балбесы, а потому что так устроено в этой компании, что дают задачи всегда выше возможностей
Скрам же говорит следующее: нужно организовать такой темп работы, чтобы она продолжалось бесконечно. И любые авралы сводят на нет самый просто темп.
Это если вы бежите марафон, а вам говорят: "следующий километр нужно бежать как спринт". Ок, вы ускорились, пробежали как спринт, но марафон вы теперь вряд ли нормально завершите, если вообще сможете завершить. По сути, это и есть выгорания, напряги и так далее
И скрам лишь выявил проблемы, показал что это не нормально. Нужно начать работать с культурой компании, объяснять руководству, что есть понятие темпа, что программисты люди трудолюбивые, их не надо кнутом гнать, они и так готовы днем и ночью работать, если хотя бы не мешать им заниматься любимой работой.
В скраме, если разработчик не имеет задач в спринте, он не берет новую задачу из следующего спринта, он берется за устранение технического долга. Поэтому в скраме очень важно чтобы продукт был рабочим, чтобы не было багов. Не так важно сколько новых фич вы выпускаете, если у вас половина сайта в багах. Лучше доведите до ума то что есть, и только потом делайте новые. И чтобы каждая новая фича не убивала существующие. Отсюда вытекает, что команда должна в быстро проверять, не сломали ли они что-то из существующего. Для этого они пишут автотесты. Итого: автотесты в скраме пишут разработчики для себя, чтобы видеть, не сломали ли они что-то из существующего. не в скраме чаще всего(не всегда) автотесты пишут потому что: тим лид сказал / по шапке дадут / так принято / это модно. Но не как помощь для самого программиста
Практически всегда горстка профессионалов разбавляет толпу обычных работяг.
Тут важно дать всем одинаковые права/обязанности. Да, будут спецы очень крутые, будут спецы так себе. При этом скрам ориентирован на те сферы, где очень много хаоса, например стартапы. Там нет понимания что делать через месяц, есть примерные планы, но все это может полностью поменяться, перестроиться, и пойти в другом направлении. И именно в таком ключе, когда нужно принимать решение относительно некоторого будущего(не в целом планов, а чего-то маленького), становится не сильно важно, какой ты крутой спец в технологиях. Тут и самый простой мидл может оказаться точнее матерых сеньоров. И именно в таких случаях надо слушать всю команду, о чем думают все.
Я сам работал в чистом скрам команде, почти год. начинал с джуна, и уже через месяц участвовал в принятии решений, понимал что в целом я с сеньорами на одном уровне. Да, задачи я решал в порядок медленнее/хуже, но решение принимали мы все вместе - как делать то или иное.
В другом месте работы, за меня решали абсолютно все, чуть ли не как столбец назвать в бд, как назвать переменные, какие файлы создать. Настолько сильная детализация задачи убивает любой вкус решения, становится неприятно даже делать задачу. Само собой как-то охота тянуть, потому что вы уже все за меня порешали, я стал тупым исполнителем. Не давали право выбора, право решать хоть самой мелкой задачи самостоятельно.
Вторая часть - про руководителей. Видел пример скрам команды в высшем звене. Не был внутри, не могу даже предположить как там может это сработать. Все таки, я больше программист, не могу думать за руководство.
Скрам в первую очередь все же ориентирован на команды исполнителей, самодостаточную, самостоятельную, ни от кого других не зависящей. Получается, если собрать руководителей, то они ничего самостоятельно не смогут решать, могут только делегировать, поэтому скорее всего полноценной скрам команды не получится, ИМХО.
Простите, но это Ваши выводы. я таких выводов не делал
Если пройтись по пунктам: а) Да, тяжело сделать полноценный скрам в команде дворников. И не надо этого делать
б) Наличие тимлидов уже противоречит чистому скраму. В скраме есть команда, и в команде есть только разработчики, никаких иерархий. в скриншоте выше сказано, что такое команда в определении скрама. Ещё один скрин. Это все из скрам гайда, там всего 13-17 страниц.
Если кроме тимлидов никто не способен к самоорганизации - лучше признаться, что у Вас не скрам и полностью от него отказаться. Это будет честный поступок. Не можете - не делайте, все просто. Не нужно винить систему, не следуя его инструкциям. Вот если я возьму нет тот фреймворк/БД/ЯП/... я потом буду ругаться на него, то скорее всего проблема изначально в выборе инструмента Образно, если взял SQLite для хранения 1млрд данных, то скорее всего я косякнул. И это нормально, просто нужно понимать, что выбираете и зачем.
в) тут ничего не понял. Опять какие-то кнуты, контроль, которых нет в чистом скраме
Бывают идеи, которые нужно несколько месяцев разрабатывать. И при этом не факт что это взлетит
Бизнес хочет дёшево и быстро проверить, сработает ли гипотеза или нет. Для этого нужно короткими шагами выкатывать клиентам и изучать их поведение
Самое ценное - это оплата по сбп. Тогда надо подумать, как можно в самом урезанном варианте сделать оплату, чтобы оно работало. Скорее всего это поместится в спринт
Далее, мы изучаем как им пользуются. Скорее всего все будут плеваться, жаловаться, но даже это - уже что-то, есть что изучить
Далее, мы выкатывам уже удобства, по qr code и так далее
Вот вам и два спринта с конкретными ценностями
Продакт понимает, что фича очень крупная и идёт к разработке, событие выяснить, что можно урезать так, чтобы влезло в спринт. При этом продакт каждый раз оценивает, будет ли в этом смысл
В целом, так работает событие pbr: продакт идёт разбивать фичи на мелкие куски с хоть какой-то ценностью для клиента
Крутой подход, в каком плане это уже становится стандартом на рынке
Мне кажется в этом русле no-code, low-code решения хорошо могут себя показать
Как вариант посчитать успешные стартапы и какие они поменяли методологии. Хотя бы на "выживших" исследовать.
Но, чую, процентов 90 стартапов работают в духе agile
Яркий пример TPS в Европе - Porsche годов 1995-2003
Изучите что было до и что стало
На самом деле есть 4 примера компаний из запада, которые смогли принять философию и добиться примерно того же результата, что и Тойота. Это из книги "бережливое производство"
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженеромОпять же: не будет скрам мастер решать технические задачи. Опять вы вместо того чтобы идти за помощью в решением технических проблем, идете к СМ, который понятия не имеет что за проблема. Он скорее психолог, поможет разобраться в себе, поможет вам обратиться к команде, чтоб не подставить их, ведь вы можете провалить спринт.
Это его работа, пересчитайте скрамгайд
Всё это в руках ПО
Вы - разработчик. Теперь половина претензий отпадает к скраму. Потому что вы возомнили себя владельцем продукта
Про скрам мастера часто говорится, что он не решает "мои проблемы"
А он и не должен, если честно. ваши проблемы могут решить ваши однокомандники, но вы их видимо за программистов не считаете, раз идете к СМ(который часто вообще не из IT)
тем более если считаете, что в продукте есть "мой код", за которого вы отвечаете. Поэтому выше был комментарий про излишнее "я". И это не про "моя реакция на события и положение", это отсутствие понимания командной работы.
У вас хорошее понимание процессов скрам, но твердое неверие в идеи командой работы, коллективной ответственности, и т.д.
очень сложно понять, что тут заголовок, а что тут мусорный текст со ссылкой. Всю статью глаза мозолит, сложно читать
Хотел пробежаться по заголовкам, понять все ли знаю
А тут постоянно этот текст со ссылкой
бедные глаза мои...
Разве?
Я думал Дейминг приехал из Детройта после второй мировой и начал всех учить
Это же его теория - PDCA, ещё до появления тпс была
Да, Порше в 93 начали производить по тпс, позвали консультантов и все поменяли
К 2003 году рентабельность достигала 17%, что по меркам автопрома сумасшедшая цифра.
От ГЭС сейчас все отказываются, потому что оказалось что рыбки страдают. Теперь тенденция на отказ от них
Ветер и солнце очень не стабильные явления, сейчас например в Европе штиль, не крутятся ветряные станции
Откуда 16+5+2 дало 50%, так и не понял
Если учесть что 85% электроэнергии вырабатывается от сжигания углерода, то так себе история с "не выбрасывать углерод"
И самое ужасное - динамика доли зеленой энергетики за 10 лет практически не поменялась, где-то на уровне 85% стоит
После документалки Асафьева Стаса про экологию всё эко движение кажется играми в песочнице
ЗЫ: документалка на 4 часа, https://youtu.be/_HbEl-2n5AQ
Заказчик не может предугадать хотелки клиентов.
Надо смотреть на все это как на туман войны в игре - у тебя есть хаос, и надо исследовать. Пока не сделаешь несколько мелких шагов не поймёшь что дальше
В гибких методолгиях есть место стратегии, просто не такая конкретная, и может меняться
Насчёт архитектуры - эта вещь динамическая, она меняется. Архитектура подстраивается под нужды, его можно менять в случае необходимости. Если архитектуру прибить гвоздями в начале развития продукта - ничего хорошего не выйдет.
Ссылок на авторитетов не смогу дать, не видел таких материалов.
В скрам гайде не нашел момента, если команда целиком саботирует процесс.
На практике у меня была одна команда, которая решила саботировать - они даже играл CS во время работы все вместе. Через несколько месяцев всю команду уволили, хотя там были пару очень крутых спецов.
В целом, надо работать с командой целиком. Если вся команда саботирует, значит воздействовать на всю команду целиком. Если кто-то конкретный саботирует, то скрам мастер должен это выявить и показать команде, что внутри есть паразит. Если коллег это устраивает, то тут ничего не поделать. Если совсем никак не реагируют на проблемы, я бы (мое личное мнение) уволил всю команду.
Да, бывает такое. Это значит что компания ещё не готова к серьезным изменениям.
Я обычно просто спрашиваю - что будете делать, если узнаете что ваш разработчик не имеет задач. Если отвечают, что срочно дают новые задачи, значит в этой компании всегда есть и будут сверхурочные
По сути, авралы возникают не потому что программисты балбесы, а потому что так устроено в этой компании, что дают задачи всегда выше возможностей
Скрам же говорит следующее: нужно организовать такой темп работы, чтобы она продолжалось бесконечно. И любые авралы сводят на нет самый просто темп.
Это если вы бежите марафон, а вам говорят: "следующий километр нужно бежать как спринт". Ок, вы ускорились, пробежали как спринт, но марафон вы теперь вряд ли нормально завершите, если вообще сможете завершить. По сути, это и есть выгорания, напряги и так далее
И скрам лишь выявил проблемы, показал что это не нормально. Нужно начать работать с культурой компании, объяснять руководству, что есть понятие темпа, что программисты люди трудолюбивые, их не надо кнутом гнать, они и так готовы днем и ночью работать, если хотя бы не мешать им заниматься любимой работой.
В скраме, если разработчик не имеет задач в спринте, он не берет новую задачу из следующего спринта, он берется за устранение технического долга. Поэтому в скраме очень важно чтобы продукт был рабочим, чтобы не было багов. Не так важно сколько новых фич вы выпускаете, если у вас половина сайта в багах. Лучше доведите до ума то что есть, и только потом делайте новые. И чтобы каждая новая фича не убивала существующие. Отсюда вытекает, что команда должна в быстро проверять, не сломали ли они что-то из существующего. Для этого они пишут автотесты.
Итого: автотесты в скраме пишут разработчики для себя, чтобы видеть, не сломали ли они что-то из существующего.
не в скраме чаще всего(не всегда) автотесты пишут потому что: тим лид сказал / по шапке дадут / так принято / это модно. Но не как помощь для самого программиста
В скраме больше осознанности что ли
Тут важно дать всем одинаковые права/обязанности. Да, будут спецы очень крутые, будут спецы так себе. При этом скрам ориентирован на те сферы, где очень много хаоса, например стартапы. Там нет понимания что делать через месяц, есть примерные планы, но все это может полностью поменяться, перестроиться, и пойти в другом направлении. И именно в таком ключе, когда нужно принимать решение относительно некоторого будущего(не в целом планов, а чего-то маленького), становится не сильно важно, какой ты крутой спец в технологиях. Тут и самый простой мидл может оказаться точнее матерых сеньоров. И именно в таких случаях надо слушать всю команду, о чем думают все.
Я сам работал в чистом скрам команде, почти год. начинал с джуна, и уже через месяц участвовал в принятии решений, понимал что в целом я с сеньорами на одном уровне. Да, задачи я решал в порядок медленнее/хуже, но решение принимали мы все вместе - как делать то или иное.
В другом месте работы, за меня решали абсолютно все, чуть ли не как столбец назвать в бд, как назвать переменные, какие файлы создать. Настолько сильная детализация задачи убивает любой вкус решения, становится неприятно даже делать задачу. Само собой как-то охота тянуть, потому что вы уже все за меня порешали, я стал тупым исполнителем. Не давали право выбора, право решать хоть самой мелкой задачи самостоятельно.
Вторая часть - про руководителей. Видел пример скрам команды в высшем звене. Не был внутри, не могу даже предположить как там может это сработать. Все таки, я больше программист, не могу думать за руководство.
Скрам в первую очередь все же ориентирован на команды исполнителей, самодостаточную, самостоятельную, ни от кого других не зависящей. Получается, если собрать руководителей, то они ничего самостоятельно не смогут решать, могут только делегировать, поэтому скорее всего полноценной скрам команды не получится, ИМХО.
Простите, но это Ваши выводы. я таких выводов не делал
Если пройтись по пунктам:
а) Да, тяжело сделать полноценный скрам в команде дворников. И не надо этого делать
б) Наличие тимлидов уже противоречит чистому скраму. В скраме есть команда, и в команде есть только разработчики, никаких иерархий. в скриншоте выше сказано, что такое команда в определении скрама. Ещё один скрин. Это все из скрам гайда, там всего 13-17 страниц.
Если кроме тимлидов никто не способен к самоорганизации - лучше признаться, что у Вас не скрам и полностью от него отказаться. Это будет честный поступок. Не можете - не делайте, все просто. Не нужно винить систему, не следуя его инструкциям. Вот если я возьму нет тот фреймворк/БД/ЯП/... я потом буду ругаться на него, то скорее всего проблема изначально в выборе инструмента
Образно, если взял SQLite для хранения 1млрд данных, то скорее всего я косякнул. И это нормально, просто нужно понимать, что выбираете и зачем.
в) тут ничего не понял. Опять какие-то кнуты, контроль, которых нет в чистом скраме
ЗЫ: я PSM I, https://www.scrum.org/certificates/405142, почта ilnuribat<собачка>gmail.com