Посмотрим чем закончится голосование, выжду неделю.
Пока на 2100 прочтений всего 166 проголосовавших (8% от прочитавших) из которых 71 не ведут списки дел или ведут его в голове (а это 42% из числа проголосовавших).
Не похоже что эта тема, как и с помощью каких инструментов вести свой список дел, интересна какому-то значимому количеству читателей хабра.
У меня не было цели собрать донаты с помощью этого опроса. Так что не ждитё на свой счёт 100К рублей.))
Это новая фича на хабре. Предположу что это ответ хабра на современный тренд, что появляются специальные площадки для монетизации своего контента не через рекламу, а донаты и подписку, типа Boosty и Teletype
Её, фичу, нельзя прикреплять к конкретной статье или посту, она работает на весь профиль автора.
Вижу вы пишите хорошие статьи на хабре, не стесняйтесь, включите эту фичу у себя в профиле.
Благодарю, что поделились. Предположу, что под книгой Буджо, имеется ввиду книга Райдер Кэрролл: Bullet Journal метод. Переосмысли прошлое, упорядочи настоящее, спроектируй будущее Если ошибся, то напишите что за книгу имели ввиду.
Если не кажется, у хабра нет требования чтобы все статьи были "очень технологичными". Это только ваше ожидание от хабра.
Моё ожидание, например, это больше статей, где люди делятся своим выстраданным опытом. Это экономит время и нервы другим читателям хабра на выполнение тех же экспериментов и обходе граблей.
Предположу что вы не с пелёнок начали писать высокотехнологический код, а учились на прописях буквы выводить. Потом куда-то подглядели, в чей-то опыт, и узнали как писать на машинном языке.
И в начале статьи есть предупреждение, для кого она будет бесполезна, если же вы ведёте список дел на бумаге и для вас мои решения это то до чего вы сами дошли или узнали где-то ещё, вы молодец. Если у вас есть свои какие-то инсайты по ведению списка дел на бумаге, поделитесь. Оценивать их технологичность не буду, даю слово.
Максим Евстратов Ок, статья хороша и с посылом я согласен. Но. Не раскрыто самое главное противоречие: на рынке в условиях конкуренции выделять ресурсы на обучение и эксперименты довольно дорого. Если у вас 30% фонда рабочего времени времени уходит на развитие сотрудника, а у соседней компании — нет, то кто окажется выбывшим в этой гонке?
Ок, но кажется, что в долгосрочном периоде вам это выгоднее все-таки вкладываться в развитие.... Однако любой долгосрочный период это сумма краткосрочных. Если в соседней компании сразу нанимают людей с нужными навыками, то они приносят ей уже 100% отдачу. А через 3-4 лет, когда их навыки устаревают, их можно заменить, купив с рынка новых, с актуальными навыками.
Есть и третий вариант — наибольшее конкурентное преимущество получат компании, в которых люди будут этим в свободное время заниматься, то есть требующие (хочешь работать - учить постоянно!), но не освобождающие для этого время работника.
Вот и получается, что вопрос в том, как любой компании, которая хочет и развиваться, и сохранять конкурентные позиции, и о сотрудниках заботиться, создать такую систему обучения, которая позволит достичь всех трех целей... Особенно если она не является сверхмаржинальным бизнесом и живет не на деньги инвесторов.
Evgenii Parfenov попробую с ответом зайти чуть с другой стороны, через байку из жизни.
У меня в команде было два инженера по тестированию, которые не умели писать автотесты. Те немногие автотесты что были в команде, были написаны разработчиками. Всё тестирование как нового функционала, так и старого осуществлялось вручную.
Что сделали: взяли на время в команду двух стажёров-джуниоров и эксперта по автоматизированному тестированию, научили джуниоров ручному тестированию, двух инженеров отправили учиться автоматизированному тестированию.
После возвращения с обучения они начали активно "погашать долг" по покрытию функционала автотестами. Спустя два года с момента начала затеи все автотесты пишутся в том же спринте в котором разрабатывается новый функционал. Тестирование теперь в 9 из 10 случаев осуществляется с помощью автотестов.
Результаты:
- Утечка багов из команды на более позднии стадии интеграции сократилась в 4 раза. С 28 багов в Программном Инкременте №9 до 7 в Инкременте №14. Больше нет утекающих "блокеров", которые блокируют интеграцию всего продукта пока команда не поставит фикс.
- Время интеграции результатов команды в продукт сократилось с 10 дней, до 1-2 дней в конце спринта. Интеграция начинается сразу же в ходе спринта по готовности фичи.
Если у вас 30% фонда рабочего времени уходит на развитие сотрудника, а у соседней компании — нет, то кто окажется выбывшим в этой гонке?
У меня в продукте также был поезд, который не вкладывался в качество, и итог такой что после 2-х лет этот поезд сейчас слабое звено всей "фабрики" и не позволяет всему продукту ускорится. Потому что Владелец Продукта поезда делал выбор в пользу бизнес-фичей. Сейчас он грозится выделить отдельный инкремент на то, чтобы ликвидировать долг, который создан в его поезде. Но пока у него не особо получается, на него давят акционеры с бизнес планами. Он скорее загнал себя и свой поезд в темный угол.
Слабое звено он по той причине, что за эти 2 года было сделана туча функциональности и продукт стал ещё более сложным и при этом обрёл качество "хай-лоад". И поэтому ситуация для этого поезда стала ещё более драматичной. Для них теперь каждый инкремент - это геройский подвиг. Требуется очень много усилий, чтобы всё работало. При этом соседние поезда сидят и "жмут кнопки" (автоматизация) и недоумевают почему рябятам требуется от 2-х до 4-х недель чтобы выдать стабильный инкремент.
Поэтому если у соседней компании нет этих вложений, молодцами они кажутся только здесь и сейчас.
Если в соседней компании сразу нанимают людей с нужными навыками, то они приносят ей уже 100% отдачу. А через 3-4 лет, когда их навыки устаревают, их можно заменить, купив с рынка новых, с актуальными навыками.
Мой опыт показывает, что люди с нужными навыками не очень стремятся устраиваться на работу в компании где "жопа". Для них эти компании не "секси". То есть им предлагают сделать то, что не делалось последние 4 года и сделать это быстро, потому что дальше уже невозможно (клиенты ругаются \ уходят). При этом в этой работе для них нет ничего нового, они вложат 1,5-2 года в это и при этом ничего новому для себя не научаться.
Людей с нужными навыками немного и за них есть конкуренция. Поэтому они чаще выберут компанию, которая уже движется в правильном направлении. Исключения, про которые я знаю, завязаны на очень много денег и как правило это приход в компанию для отсиживания года, получения годового бонуса размером в годовую зарплату, и "сваливания" в благополучную компанию где интересно работать.
Есть и третий вариант — наибольшее конкурентное преимущество получат компании, в которых люди будут этим в свободное время заниматься, то есть требующие (хочешь работать - учить постоянно!), но не освобождающие для этого время работника.
Это ведёт к выгоранию так как нарушен баланс "работа - личная жизнь". Это может сработать в отдельных случаях - на короткий промежуток времени, как геройский подвиг, но это не может быть системным решением.
Особенно если она не является сверхмаржинальным бизнесом и живет не на деньги инвесторов
Сверхмаржинальность здесь появляется за счёт способности делать правильный продукт правильно = быстро. Мы быстро делаем фичу и отдаём её пользователям, также быстро собираем обратную связь и корректируем фичу под ожидания\реальность.
То есть развитие (обучение) ведётся по двум направлениям:
"technical excellence" - цель которого сократит T2M и косты на быструю поставку.
"Market fit" (или fit for purpose) - с целью максимизировать создаваемую ценность для бизнеса и клиентов (отдачу) на те ресурсы что у нас есть.
Вот и получается, что вопрос в том, как любой компании, которая хочет и развиваться, и сохранять конкурентные позиции, и о сотрудниках заботиться, создать такую систему обучения, которая позволит достичь всех трех целей...
Моя точка зрения - чтобы продукт \ бизнес был успешн должна сходиться его экономика, но в эту экономику должна быть заложена эта система обучение (те самые 30% на обучение).
Если это есть, то ответ на вопрос "как" можно будет нащупать эмпирически.
Давайте предположим что продукт делает 500+ человек. За этот год в одном ежегодном релизе они выдадут продукт с тучей функциональности, потом весь следующий год будут собирать обратную связь от пользователей и исправлять то что попало мимо ожиданий, а весь следующий год мы, как пользователи, будем мучиться и страдать в 35 местах. При этом в худшем случае, через год можно найти, что в половине мест всё равно сделали не так и будем ждать ещё год до следующего релиза, когда сделают так как надо.
Быстрые релизы нужны для того, чтобы фокусироваться и поставлять то что нужно пользователю сейчас, также быстро собирать обратную связь и не заставлять нас, пользователей, страдать от неудачных решений (реализации).
То что вы описаете похоже на то, когда есть компонентные команды (продукт поделён на части и каждая команда отвечает за свою часть), и видно что приходит релиз с кучей минорных обновлений, когда самое главное так и не работает. Чаще всего эти команды ждут команду "бутылочное горлышко", когда у неё будет возможность сделать что-то важное, а сами делают и поставляют то что могут сейчас (минорную функциональность). = это история моего последнего места работы когда продукт делают 30+ команд (500+ человек)
Сначала прочитал как "постапокалипсическое общество" - уж больно похожа на него реальность иногда)
))) +1
Очень много проработав в корпоративной разработке софта, могу сказать, что это редкость, если на (само)обучение выделяется часть рабочего времени
За тем и пишу подобные статьи, чтобы рано или поздно это изменилось. - подливаю масла в огонь. Если все говорят что так правильно, то те кто делает по другому начинают хотя бы подвергать сомнению "статус кво". - вода камень точит.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
Поправьте меня если я не верно вас понял. Думаю здесь вы подразумеваете, что в команде есть процедуры, которые себя зарекомендовали и работают. Когда команда начинает переходить на работу в Scrum-фреймворке, его элементы начинают входить в конфликт с этими процедурами. Если оставить всё как есть, то при очередном аудите, как у команды дела с адаптацией фреймворка, можно нарваться на заключение, что команда делает не «православный» Scrum.
Если это то, что вы имели ввиду, то понимаю, самому порой жалко расставаться с этим, особенно когда сам принимал участие в становлении этой практики. Здесь у меня серебряной пули нет, что делать в этой ситуации. Иногда приходится «дисраптить» (разбирать на запчасти), иногда можно оставить если пользы больше чем вреда.
Конечное решение всегда за командой, а дальше мы уже по практическим результатом поймём что с этим делать дальше.
Получается, что ваша «Инъекция», это другое название ретроспективы из скрама? В чем отличие? Почему не хватает обычной ретроспективы?
Всё верно. Ретроспектива — это один из базовых инструментов в копилке Скрам-Мастера, через который проходят «инъекции». Её самому на 100% можно считать примером «инъекции», которая регулярно должна происходить в команде.
Отличие в том, что это не единственный инструмент в копилке СМ-а.
Встречи 1-1, Организация и проведение для команды бизнес-симуляций (игр), референс-визиты, организация школ по определённым практикам (автоматическое тестирование и деплой)… — всё, что позволит команде увидеть себя со стороны и «что, а так можно было?» (к чему действительно стоит стремится / как выглядит Скрам или отдельные инструменты, когда они действительно работают как и должны).
Ретроспективы уже достаточно. Всё остальное это либо реализация экшн-планов, которые были приняты на ретро, либо дополнительная активность СМ-а, направленная на поддержку членов команды, команды и происходящих в ней процессов.
Вообще, моя основная претензия к Скраму (возможно, я не умею его готовить), это «жесткость» методологии. При том, что это вроде как Agile. Ситуация как с CrossFit'ом, который не просто «прикольная методика интервальных тренировок», а «сертифицируемая торговая марка и нужно заплатить за франшизу». Шаг вправо или влево — расстрел на месте.
Так и тут — либо делаешь как Сазерленд написал, либо ты «предатель дела Скрама» (тут смотрим осуждающе на Скрамбат, Скрамбан и т.д.). Из-за этого ассоциации с карго-культом.
Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
Моя точка зрения на этот счёт звучит как СюХаРи. (Сю — «соблюдать», Ха — «прорываться» и Ри — «править код»)
Сперва мы берём фреймворк так как есть и выжимаем из него максимум (Сю). Он специально так зашейплен, что из него выкинуто практически всё лишнее, он очень поджарый. У меня в командах мы ещё используем вагон и маленькую тележку практик в дополнение к нему (продуктовые, DevOps...).
В тот момент, когда нам во фреймворке становится тесно, мы эмпирически заменяем какие-то из базовых событий на новые или делаем их иначе (Ха).
Например, мы научились автоматически собирать билд по коммиту, делать автотесты и деплоить по нажатию кнопки. То есть нам, чтобы доставить фичу на продуктив больше не нужно ждать конца спринта. Как только мы её закончили мы тут же можем показать её Владельцу Продукта, а он принять решение ставить ли её в этом виде на продуктив.
Здесь инспекция результатов происходит по запросу. У Обзора спринта начинает смещаться фокус от инспекции результатов к каким-то другим актуальным для команды вещам.
Примером же «Ри» — являются LeSS, Nexus… и больше всего новые редакции самого Scrum-фреймворка. Он же не всегда выглядел так как выглядит сейчас. Было бы забавным видеть, если бы «свидетели-последователи» разделились по историческим версиям фреймворка и воевали между собой за тот, который из них более правильный.
Странная получается ситуация. Вроде как Скрам это про «самоорганизацию» и «самоулучшение». А на практике, команде сначала принудительно Скрам внедрили, а потом сверху еще «надсмотрщика» поставили, чтобы он им не давал «заповеди» нарушать.
И такое тоже бывает, но это плохой заход в сторону Скрама.
Лучше когда ребята сами идут в эту историю из любопытства и понимания, что на рынке ценится опыт и знания работы в гибких подходах, и если компания, в которой сейчас работаешь, даёт возможность поучиться, отправит на тренинги бесплатно и ещё за это деньги будет платить… выглядит хорошей возможностью повысить свою ценность.
Сами идут — это также подразумевает, что соглашаются присоединится к команде, которая будет работать по Скраму. Или когда их собеседуют с рынка и обозначают, что их ждёт и это сознательный выбор.
Если команде Скрам «спустили», а до этого они работали по другому, тут Скрам-мастер в этом не виноват. Он может разобраться подходит ли команде и продукту этот фреймворк, и если нет донести это до лица принимающего решение, а после делать выводы как и остальные члены команды.
«Настоящий» Скрам-мастер предпочтёт не тратить своё время впустую, а найдёт другую возможность где он будет полезен, вместо того чтобы что-то «насаждать» и получать за это зарплату.
Понятно, что все мероприятия «по скраму», это именно что новая привычка, новый навык и нужно время для закрепления, но если команда отказывается от чего-то, возможно дело не в том, что им нужно новую инъекцию делать
Здесь инъекция это не принуждение к тому, чтобы продолжать делать то от чего команда отказывается. Инъекция это где-то совет и обсуждение почему что-то не получается, где-то это поход в соседнюю команду, чтобы обменяться с ними своими успехами и не успехами. Инъекция — это не щелчок кнутом «Не по скраму», а больше про поддержку и вдохновение.
а в том, что они пользы не видят или ее нет
Если команда не видит в каких-то элементах Скрама пользы это повод Скрам-Мастеру задуматься, что не так.
В конечном итоге мы не стремимся к карго-культу, а пытаемся извлечь пользу из нового способа работы, вместо того чтобы пилить софт хотим причинять пользу пользователям и делать это быстро, а не спустя полтора года разработки.
Как починить то, что не работает, от чего нет пользы?
Скрам-мастер может также пойти к другому Скрам-мастеру и с ним обсудить что не получается, позвать его в гости и попросить понаблюдать со стороны, дать обратную связь, если наш Скрам-Мастер сам не может понять в чём проблема.
Описание карточек:
2 набора карточек (по 100 шт. карточек в каждом, на группу участников примерно 10 человек). Как пользоваться GPA-карточками?
GPA-карточки позволяют в консультационной работе быстро выходить на индивидуальные ценности и убеждения руководителей или других клиентов Таким образом, убеждения и позиции, а с ними и собственные фильтры восприятия, могут мысленно анализироваться Изменения фильтров восприятия изменяют и границы нашего восприятия, увеличивая, тем самым, возможности нашей деятельности
GPA-карточки компетенции и обратной связи можно использовать в работе с отдельными лицами и/или коллективами (командами): 1. Различные компетенции, организованные в определенную структуру, воспринимаются всеми членами команды 2. Каждый из участников получает ответ на то, как он воспринимается в этой группе 3. Каждый получает возможность анализировать свои компетенции и проводить сравнительный анализ относительно других членов команды
Работа с картами позволяет в игровой форме находить точки соприкосновения для импульсов к обратной связи, составу команды и её развитию.
Ссылку на колоду карточек дать не могу так как по правилам Хабра это считается рекламой/пиаром продукта/товара (ссылка ведёт на их страницу в интернет магазине).
Поэтому предлагаю вам погуглить вот этот текст «Карточки GPA компетенций и обратной связи»
Это не я написал. Эта фраза автоматически вставляется самим хабром.
Это статья о донатах от редакции Хабра "Обновление донатов на Хабре" - https://habr.com/ru/companies/habr/articles/748160/
Ниже скриншоты с настройками публикации, где видно что такого текста я не добавлял нигде и не управляю добавлением этой строки на публикацию.
Скриншот текста статьи-опроса
Скриншоты настроек публикации
Посмотрим чем закончится голосование, выжду неделю.
Пока на 2100 прочтений всего 166 проголосовавших (8% от прочитавших) из которых 71 не ведут списки дел или ведут его в голове (а это 42% из числа проголосовавших).
Не похоже что эта тема, как и с помощью каких инструментов вести свой список дел, интересна какому-то значимому количеству читателей хабра.
Рад что вам интересно. :о) Скоро выйдет следующая статья об этом.
Подпишитесь как-то на время: либо на мой профиль либо на статью про ведение списка дел, я в комментарии к статье размещу новость, когда статья выйдет.
А ещё у меня к вам есть предложение стать её бета-читателем. Ваша обратная связь поможет мне сделать статью лучше перед тем как её увидит весь хабр.
У меня не было цели собрать донаты с помощью этого опроса. Так что не ждитё на свой счёт 100К рублей.))
Это новая фича на хабре. Предположу что это ответ хабра на современный тренд, что появляются специальные площадки для монетизации своего контента не через рекламу, а донаты и подписку, типа Boosty и Teletype
Её, фичу, нельзя прикреплять к конкретной статье или посту, она работает на весь профиль автора.
Вижу вы пишите хорошие статьи на хабре, не стесняйтесь, включите эту фичу у себя в профиле.
Использую электронную доску Miro.
Благодарю, что поделились.
Предположу, что под книгой Буджо, имеется ввиду книга Райдер Кэрролл: Bullet Journal метод. Переосмысли прошлое, упорядочи настоящее, спроектируй будущее
Если ошибся, то напишите что за книгу имели ввиду.
Спасибо что поделились своей историей. У меня такие же впечатления от ведения дел на электронной доске, как у вас от пробковой.
В следующей статье, про ведение списка дел на электронной доске, буду ждать вас в комментариях. Дам вам знать как она выйдет.
Мне кажется или вы не довольны статьёй?
Если не кажется, у хабра нет требования чтобы все статьи были "очень технологичными".
Это только ваше ожидание от хабра.
Моё ожидание, например, это больше статей, где люди делятся своим выстраданным опытом. Это экономит время и нервы другим читателям хабра на выполнение тех же экспериментов и обходе граблей.
Предположу что вы не с пелёнок начали писать высокотехнологический код, а учились на прописях буквы выводить. Потом куда-то подглядели, в чей-то опыт, и узнали как писать на машинном языке.
И в начале статьи есть предупреждение, для кого она будет бесполезна, если же вы ведёте список дел на бумаге и для вас мои решения это то до чего вы сами дошли или узнали где-то ещё, вы молодец. Если у вас есть свои какие-то инсайты по ведению списка дел на бумаге, поделитесь. Оценивать их технологичность не буду, даю слово.
Evgenii Parfenov
Максим Евстратов Ок, статья хороша и с посылом я согласен. Но. Не раскрыто самое главное противоречие: на рынке в условиях конкуренции выделять ресурсы на обучение и эксперименты довольно дорого. Если у вас 30% фонда рабочего времени времени уходит на развитие сотрудника, а у соседней компании — нет, то кто окажется выбывшим в этой гонке?
Ок, но кажется, что в долгосрочном периоде вам это выгоднее все-таки вкладываться в развитие.... Однако любой долгосрочный период это сумма краткосрочных. Если в соседней компании сразу нанимают людей с нужными навыками, то они приносят ей уже 100% отдачу. А через 3-4 лет, когда их навыки устаревают, их можно заменить, купив с рынка новых, с актуальными навыками.
Есть и третий вариант — наибольшее конкурентное преимущество получат компании, в которых люди будут этим в свободное время заниматься, то есть требующие (хочешь работать - учить постоянно!), но не освобождающие для этого время работника.
Вот и получается, что вопрос в том, как любой компании, которая хочет и развиваться, и сохранять конкурентные позиции, и о сотрудниках заботиться, создать такую систему обучения, которая позволит достичь всех трех целей... Особенно если она не является сверхмаржинальным бизнесом и живет не на деньги инвесторов.
Максим Евстратов
Evgenii Parfenov попробую с ответом зайти чуть с другой стороны, через байку из жизни.
У меня в команде было два инженера по тестированию, которые не умели писать автотесты. Те немногие автотесты что были в команде, были написаны разработчиками. Всё тестирование как нового функционала, так и старого осуществлялось вручную.
Что сделали: взяли на время в команду двух стажёров-джуниоров и эксперта по автоматизированному тестированию, научили джуниоров ручному тестированию, двух инженеров отправили учиться автоматизированному тестированию.
После возвращения с обучения они начали активно "погашать долг" по покрытию функционала автотестами. Спустя два года с момента начала затеи все автотесты пишутся в том же спринте в котором разрабатывается новый функционал. Тестирование теперь в 9 из 10 случаев осуществляется с помощью автотестов.
Результаты:
- Утечка багов из команды на более позднии стадии интеграции сократилась в 4 раза. С 28 багов в Программном Инкременте №9 до 7 в Инкременте №14. Больше нет утекающих "блокеров", которые блокируют интеграцию всего продукта пока команда не поставит фикс.
- Время интеграции результатов команды в продукт сократилось с 10 дней, до 1-2 дней в конце спринта. Интеграция начинается сразу же в ходе спринта по готовности фичи.
У меня в продукте также был поезд, который не вкладывался в качество, и итог такой что после 2-х лет этот поезд сейчас слабое звено всей "фабрики" и не позволяет всему продукту ускорится. Потому что Владелец Продукта поезда делал выбор в пользу бизнес-фичей. Сейчас он грозится выделить отдельный инкремент на то, чтобы ликвидировать долг, который создан в его поезде. Но пока у него не особо получается, на него давят акционеры с бизнес планами. Он скорее загнал себя и свой поезд в темный угол.
Слабое звено он по той причине, что за эти 2 года было сделана туча функциональности и продукт стал ещё более сложным и при этом обрёл качество "хай-лоад". И поэтому ситуация для этого поезда стала ещё более драматичной. Для них теперь каждый инкремент - это геройский подвиг. Требуется очень много усилий, чтобы всё работало. При этом соседние поезда сидят и "жмут кнопки" (автоматизация) и недоумевают почему рябятам требуется от 2-х до 4-х недель чтобы выдать стабильный инкремент.
Поэтому если у соседней компании нет этих вложений, молодцами они кажутся только здесь и сейчас.
Мой опыт показывает, что люди с нужными навыками не очень стремятся устраиваться на работу в компании где "жопа". Для них эти компании не "секси". То есть им предлагают сделать то, что не делалось последние 4 года и сделать это быстро, потому что дальше уже невозможно (клиенты ругаются \ уходят). При этом в этой работе для них нет ничего нового, они вложат 1,5-2 года в это и при этом ничего новому для себя не научаться.
Людей с нужными навыками немного и за них есть конкуренция. Поэтому они чаще выберут компанию, которая уже движется в правильном направлении. Исключения, про которые я знаю, завязаны на очень много денег и как правило это приход в компанию для отсиживания года, получения годового бонуса размером в годовую зарплату, и "сваливания" в благополучную компанию где интересно работать.
Это ведёт к выгоранию так как нарушен баланс "работа - личная жизнь". Это может сработать в отдельных случаях - на короткий промежуток времени, как геройский подвиг, но это не может быть системным решением.
Сверхмаржинальность здесь появляется за счёт способности делать правильный продукт правильно = быстро. Мы быстро делаем фичу и отдаём её пользователям, также быстро собираем обратную связь и корректируем фичу под ожидания\реальность.
То есть развитие (обучение) ведётся по двум направлениям:
"technical excellence" - цель которого сократит T2M и косты на быструю поставку.
"Market fit" (или fit for purpose) - с целью максимизировать создаваемую ценность для бизнеса и клиентов (отдачу) на те ресурсы что у нас есть.
Моя точка зрения - чтобы продукт \ бизнес был успешн должна сходиться его экономика, но в эту экономику должна быть заложена эта система обучение (те самые 30% на обучение).
Если это есть, то ответ на вопрос "как" можно будет нащупать эмпирически.
Давайте предположим что продукт делает 500+ человек. За этот год в одном ежегодном релизе они выдадут продукт с тучей функциональности, потом весь следующий год будут собирать обратную связь от пользователей и исправлять то что попало мимо ожиданий, а весь следующий год мы, как пользователи, будем мучиться и страдать в 35 местах. При этом в худшем случае, через год можно найти, что в половине мест всё равно сделали не так и будем ждать ещё год до следующего релиза, когда сделают так как надо.
Быстрые релизы нужны для того, чтобы фокусироваться и поставлять то что нужно пользователю сейчас, также быстро собирать обратную связь и не заставлять нас, пользователей, страдать от неудачных решений (реализации).
То что вы описаете похоже на то, когда есть компонентные команды (продукт поделён на части и каждая команда отвечает за свою часть), и видно что приходит релиз с кучей минорных обновлений, когда самое главное так и не работает. Чаще всего эти команды ждут команду "бутылочное горлышко", когда у неё будет возможность сделать что-то важное, а сами делают и поставляют то что могут сейчас (минорную функциональность). = это история моего последнего места работы когда продукт делают 30+ команд (500+ человек)
))) +1
За тем и пишу подобные статьи, чтобы рано или поздно это изменилось. - подливаю масла в огонь. Если все говорят что так правильно, то те кто делает по другому начинают хотя бы подвергать сомнению "статус кво". - вода камень точит.
опыт самого Spotify - https://www.jeremiahlee.com/posts/failed-squad-goals/?fbclid=IwAR1Ys95Qpbm786K-V_grlzOOs1DUCDkzFFkhVEydJT1YJej2nG5W_oeODU8
Если это то, что вы имели ввиду, то понимаю, самому порой жалко расставаться с этим, особенно когда сам принимал участие в становлении этой практики. Здесь у меня серебряной пули нет, что делать в этой ситуации. Иногда приходится «дисраптить» (разбирать на запчасти), иногда можно оставить если пользы больше чем вреда.
Конечное решение всегда за командой, а дальше мы уже по практическим результатом поймём что с этим делать дальше.
Отличие в том, что это не единственный инструмент в копилке СМ-а.
Встречи 1-1, Организация и проведение для команды бизнес-симуляций (игр), референс-визиты, организация школ по определённым практикам (автоматическое тестирование и деплой)… — всё, что позволит команде увидеть себя со стороны и «что, а так можно было?» (к чему действительно стоит стремится / как выглядит Скрам или отдельные инструменты, когда они действительно работают как и должны).
Ретроспективы уже достаточно. Всё остальное это либо реализация экшн-планов, которые были приняты на ретро, либо дополнительная активность СМ-а, направленная на поддержку членов команды, команды и происходящих в ней процессов.
Моя точка зрения на этот счёт звучит как СюХаРи. (Сю — «соблюдать», Ха — «прорываться» и Ри — «править код»)
Сперва мы берём фреймворк так как есть и выжимаем из него максимум (Сю). Он специально так зашейплен, что из него выкинуто практически всё лишнее, он очень поджарый. У меня в командах мы ещё используем вагон и маленькую тележку практик в дополнение к нему (продуктовые, DevOps...).
В тот момент, когда нам во фреймворке становится тесно, мы эмпирически заменяем какие-то из базовых событий на новые или делаем их иначе (Ха).
Например, мы научились автоматически собирать билд по коммиту, делать автотесты и деплоить по нажатию кнопки. То есть нам, чтобы доставить фичу на продуктив больше не нужно ждать конца спринта. Как только мы её закончили мы тут же можем показать её Владельцу Продукта, а он принять решение ставить ли её в этом виде на продуктив.
Здесь инспекция результатов происходит по запросу. У Обзора спринта начинает смещаться фокус от инспекции результатов к каким-то другим актуальным для команды вещам.
Примером же «Ри» — являются LeSS, Nexus… и больше всего новые редакции самого Scrum-фреймворка. Он же не всегда выглядел так как выглядит сейчас. Было бы забавным видеть, если бы «свидетели-последователи» разделились по историческим версиям фреймворка и воевали между собой за тот, который из них более правильный.
Это плохо или хорошо?
Что в статье есть хорошего?
Что можно улучшить? (она не отлита в камне, я могу внести изменения)
Чего не хватает?
И такое тоже бывает, но это плохой заход в сторону Скрама.
Лучше когда ребята сами идут в эту историю из любопытства и понимания, что на рынке ценится опыт и знания работы в гибких подходах, и если компания, в которой сейчас работаешь, даёт возможность поучиться, отправит на тренинги бесплатно и ещё за это деньги будет платить… выглядит хорошей возможностью повысить свою ценность.
Сами идут — это также подразумевает, что соглашаются присоединится к команде, которая будет работать по Скраму. Или когда их собеседуют с рынка и обозначают, что их ждёт и это сознательный выбор.
Если команде Скрам «спустили», а до этого они работали по другому, тут Скрам-мастер в этом не виноват. Он может разобраться подходит ли команде и продукту этот фреймворк, и если нет донести это до лица принимающего решение, а после делать выводы как и остальные члены команды.
«Настоящий» Скрам-мастер предпочтёт не тратить своё время впустую, а найдёт другую возможность где он будет полезен, вместо того чтобы что-то «насаждать» и получать за это зарплату.
Здесь инъекция это не принуждение к тому, чтобы продолжать делать то от чего команда отказывается. Инъекция это где-то совет и обсуждение почему что-то не получается, где-то это поход в соседнюю команду, чтобы обменяться с ними своими успехами и не успехами. Инъекция — это не щелчок кнутом «Не по скраму», а больше про поддержку и вдохновение.
Если команда не видит в каких-то элементах Скрама пользы это повод Скрам-Мастеру задуматься, что не так.
В конечном итоге мы не стремимся к карго-культу, а пытаемся извлечь пользу из нового способа работы, вместо того чтобы пилить софт хотим причинять пользу пользователям и делать это быстро, а не спустя полтора года разработки.
Как починить то, что не работает, от чего нет пользы?
Скрам-мастер может также пойти к другому Скрам-мастеру и с ним обсудить что не получается, позвать его в гости и попросить понаблюдать со стороны, дать обратную связь, если наш Скрам-Мастер сам не может понять в чём проблема.
Ссылку на колоду карточек дать не могу так как по правилам Хабра это считается рекламой/пиаром продукта/товара (ссылка ведёт на их страницу в интернет магазине).
Поэтому предлагаю вам погуглить вот этот текст «Карточки GPA компетенций и обратной связи»
Заметил, что ошибку поправили и «Честность» заняла своё место.
А благодарность была высказана 22 июля в 17:14.
Рад, что вы с нами на хабре, мы с удовольствием вкладываем своё время и силы в развитие коллег по цеху.