Меня часто спрашивают - раз мы работаем в Скраме в самоорганизованной команде, значит мы сами решаем что нам делать? Можем не ходить на Ретроспективу, можем пойти. Можем прийти на работу на два часа позже, а можем дома поработать не уведомив об этом команду и пр. ... Недавно было обсуждение на Общей ретроспективе и как пример такое суждение "раз все равны, все разработчики, значит можно кому-то сделать розовую кнопку вместо красной и будет норм!". Дальше я свое мнение изложу, можете с ним не соглашаться, но ... Вопросы эти, на мой взгляд, появляются от своеобразного понимания как Agile манифеста (http://agilemanifesto.org/iso/ru/manifesto.html), так и Скрам-гайда, который в главе про команды гласит "Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты." и "Команда Разработки самоорганизуется как во время Спринта, так и во время его Планирования при работе над Бэклогом Спринта.". Да, никто не может указывать команде КАК делать ее работу. И именно во время Спринта при работе над Бэклогом Спринта. Сейчас я для обсуждения таких вопросов все чаще использую инструмент по сути классического менеджмента - теорию требований и ограничений по Р.Стюарт (https://www.pocketbook.co.uk/blog/2016/10/11/rosemary-stewart-practical-management/). Это моя вольная его адаптация, я не претендую. Более того мне интересно мнение сообщества. Итак суть модели в следующем, что даже самоуправляемые команды (у автора менеджер) в своей деятельности всегда ограничены в своих решениях (альтернативах) различными требованиями и ограничениями. Чем шире эта область альтернативы(на картинке), тем большую свободу мы имеем в принятии решений и в своих действиях. И это здорово, когда она максимально объемная и прозрачная. Но! При этом требования это - требования организации (например, использование фреймворка Скрам), коллег (например, рабочие соглашения, принятые совместно), требования внешнего окружения (например, необходимость оформлять никому не нужные больничные листы, хотя ты работаешь и из дома во время болезни), системные требования (например, использовать общий для всей организации трекер задач, сообща выбранный инструментарий, гайды при оформлении дизайна и пр. ), собственные требования (ну как пример, стиль одежды). Что касается ограничений, то тут можно выделить правовые ограничения (например, курение только в ограниченных местах), ресурсные ограничения (например, мы не можем купить всем Макбуки), технологические ограничения (например, использование конкретной облачной платформы), расположение офиса и распределение сотрудников в нем, различные регламенты, правила организации (тот же дресс-код), различные общепринятые нормы (например, мат в общении). Альтернатива это в данном контексте как раз КАК делать работу - какие библиотеки использовать, выбор инструментария, архитектуры, языков программирования, алгоритмов, планирование внутри спринта, распределение ресурсов внутри команды, принятие решений внутри Спринта, и пр. Один из принципов манифеста "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.". И тут важно не перегнуть палку с требованиями и ограничениями, но и недооценивать их важность тоже не стоит. Что думаете?

Покритикуйте пож.

Критерии приемки и DoD

Покритикуйте пож.

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

все это покрывают

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

Спасибо. В фейсбук хотел плюнуть. Абзацы расставлю.

Критерии приемки и DoD

Ты про статью?

йеп

если возникают вопросы вроде "почему нельзя сделать розовую кнопку вместо красной" - то эт честно говоря крайне неправильное понимание самоорганизации :D

а почему нельзя-то? Обычно на этот вопрос есть вполне логичный ответ

йеп

Хороший пример требований, да.

если возникают вопросы вроде "почему нельзя сделать розовую кнопку вместо красной" - то эт честно говоря крайне неправильное понимание самоорганизации :D

Да, но многие понимают это именно так.

Да, но многие понимают это именно так.

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

в остальном полная свобода

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

Мне вообще хочется разделить термины самоорганизованная и самоуправляемая.

Мне вообще хочется разделить термины самоорганизованная и самоуправляемая.

это монописуально

если команда самоорганизованна и ей кто то управляет из вне - то она не самоорганизованная :D

Для меня самоорганизованная это когда она сама собралась. Это больше про разовый процесс организации команды.

самоорганизация это постоянный процесс который постоянно приходит на ретроспективу

когда команда сама собралась и решила что ей нужны общие часы

Еще раз в этом контексте. Двоеточие в русской версии (в оригинале точка). сливает понятия self-organizing к самоуправляемая. Смысл меняется, не? "Интересная штука. В оригинале "They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;" а в переводе "Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты." Найдите лишнее двоеточие. Смысл по моему меняется."

не надо читать русский срам гайд.

Меняется-меняется

Да знаю я! Но те кто ко мне приходит с глупыми вопросами читают именно его!

Меняется-меняется

Вот и хрен то.

После двоеточия идет описание самоорганизации. Хотя в оригинале самоорганизация и следующее предложение идут на одном уровне.

для таких людей специально можно расспечатать английскую версию :D

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

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

и я о том же

смысл изменился в переводе

скрам гайд переводили не лингвисты нифига. там смысл дофига чего потерян.

Ну его переводили грамотные люди. Они знают Скрам.

первую версию делали люди в контексте.

и они не считали что контекст стоит объяснить

Все три российских PST

В том числе @mihey911

и что?

они лингвисты?

Да может я чего не так понимаю :(

Миша @mihey911 , развей мои сомнения.

при переводе всегда важно передать контекст. особенно если язык сложный (как у нас)

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

так что требования - это такая же часть процесса как и все остальные фактефакы типа кода

имхо

при переводе всегда важно передать контекст. особенно если язык сложный (как у нас)

Да я знаю. Иногда так мозг ломает ...

они лингвисты?

Да, там был лингвист-переводчик в команде и литературный редактор. И да, там огромное поле для улучшений :)

они лингвисты?

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

Да, там был лингвист-переводчик в команде и литературный редактор. И да, там огромное поле для улучшений :)

Ты сам как понмаешь термин "самоорганизованная"?

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

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

на счет уважаемых лично людей - ну эт не значит что эти люди не могут ошибаться. :D не создавайте себе идолов.

Ты сам как понмаешь термин "самоорганизованная"?

Ох :) я сйчас развернуто не могу ответить - тренинг ведём)))

Да может я чего не так понимаю :(

Дело в том, что, как минимум, существует понятие "прагматика перевода". Если совсем на пальцах объяснять суть - переводчик обязан перевести не дословно, а так чтобы максимально полно передать смысл. К примеру манифест Agile и его последний пункт. "Responding to change over following a plan" "Responding to change" переведено как "Готовность к изменениям". Но если посмотреть на версию манифеста 2.1, то над "Responding to change" встаёт "Prepare for change", что гораздо больше соотносится с русским словом "готовность" (потому что готовность подразумевает подготовку). Поэтому "Responding to change" корректнее переводить, как "Реакция на изменения". Хотя данный перевод тоже передаёт не весь смысл - в русском языке нет такого слова, которое может в одиночку служить полным аналогом "Responding". И вот в таких мелочах могут теряться смыслы. Это людям в контексте все ясно после прочтения. А другим - нет. В результате половина страны искренне считает, что "на Продукт вообще не нужно писать документацию, главное чтобы он работал" и тому подобное.

Ох :) я сйчас развернуто не могу ответить - тренинг ведём)))

Ну вечер впереди.

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

А как кто работает с "сервисными" функциями? Вот есть человек, помогает всем командам делать задачи, но не всегда, да и свои задачи у него есть сервисные. Ну например дба.

А как кто работает с "сервисными" функциями? Вот есть человек, помогает всем командам делать задачи, но не всегда, да и свои задачи у него есть сервисные. Ну например дба.

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

В результате его дергают все меньше и несколько человек могут его заменить в случае болезни или отсутствия.

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

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

в остальном согласен, но вопрос скорее был, как организовать работу этого человека

а не команд с ним

в общем - вкидывать в команды на время

ок, спасибо

Автономные команды, все дела

Автономные команды, все дела

он один

а команд 4, например

он один

Всегда кто-то когда-то был один )

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

вопрос-то был, как жить в текущей ситуации

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

В пару и вперед. Закладывайте на это время в Спринте

Команды должны решить )

В пару и вперед. Закладывайте на это время в Спринте

ну это и есть путешественник, да. Про него я понял, спасибо )

Команды должны решить )

Однобоко. Команды решили, что норм, когда он решает задачи по приглашению

и параллельно учит, это да

А ты сркам мастер? 😕

Лисы Адкинс на тебя нет )

а что не так? )

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

так при чем тут это, я это все знаю и так и делаю )

Сори, я наконец понял