Comments 10
Первая половина хорошая, даже очень: разложили по полочкам кентобековские рассусоливания про individual and interactions и прочую лабуду. Сделаем в срок, сделаем хорошо, но по дороге что-нибудь похерим и постараемся чтобы это "что-нибудь" было ненужным. И будем показывать промежуточные результаты.
про «в топку PMBoK» не совсем согласен. есть задачи, где agile не работает.
про то, что не понятно, что в скраме делать с архитектурой, согласен. команда мотивированных профессионалов может совершить много ошибок, которые потом будет очень дорого исправлять. пока, кажется, уже не стартапы стараются добавлять во все это роль архитектора, которая стоит над командами, что не вяжется с классическим пониманием фреймворков, а больше похоже на какой-нибудь SAFe. при этом сам SAFe сильно сложнее и запутаннее классических вариантов управления проектами.
В общем как и любой другой инструмент, эджайл надо применять, четко понимая, для чего это делается
Тут мы говорим про то как формируются принципы Agile. Это не значит, что Agile применим для всего. Более того не значит, что Agile в итоге лучше традиционных методов. Это означает, что Agile мы начинаем с чистого листа (например, 16 страниц Скрам вместо огромной книги). И по необходимости что-то добавляем, но помня, что в целом PMBoK приводит к провалу проектов.
Если в каком-то случае PMBoK работает лучше Agile, то лучше его использовать, т.к. он позволяет гораздо легче подписывать контракты.
Agile Manifesto был опубликован в 2001, в то время как гибкие методологии управления проектами уже существовали и применялись задолго до (тот же DSDM появился в 1994 году).
Похоже, Дядя Боб хорошо чувствовал запросы со стороны индустрии и был мастером трындетьформулировать ответы звучными тезисами (другое аналогичное творение с его участием это пресловутый SOLID). Но воспринимать все это на серьезных щщах, искать какой-то сакральный смысл, фреймворк или руководство к действию - реально большая глупость.
Agile Manifesto был опубликован в 2001, в то время как гибкие методологии управления проектами уже существовали и применялись задолго до (тот же DSDM появился в 1994 году).
Тут вы полностью правы. В 2001 году появился зонтичный бренд Agile для уже существовавших методик. Как любой бренд они отстраивались от "классических" методов.
Похоже, Дядя Боб хорошо чувствовал запросы со стороны индустрии и был мастером
трындетьформулировать ответы звучными тезисами (другое аналогичное творение с его участием это пресловутый SOLID).
И тут правы -- манифест крайне тяжело понимается.
Но воспринимать все это на серьезных щщах, искать какой-то сакральный смысл, фреймворк или руководство к действию - реально большая глупость.
Есть термин Agile. Судя по этому предложению для вас он ничего не обозначает. Я же предпринял попытку проинтерпретировать исходный манифест, чтобы было понятно о чем говорят люди. То, что они ни о чем не говорят -- не согласен. Идеально, если после прочтения статьи об Agile останется выжимка примерно как первый комментарий к этой статье. Остальное лишь пояснение как к этому пришли.
Есть термин Agile. Судя по этому предложению для вас он ничего не обозначает.
Варюсь во всей этой каше примерно с тех самых времен, а несколько последних лет работаю в кровавых энтерпрайзах. Есть методологии, которые реально помогают строить процессы от и до. AM это просто несколько тезисов формата заголовков желтой прессы или шумных блоггеров типа "10 рецептов" чего угодно. Единственное его достоинство это краткость, ну чтобы нормальные книжки не читать.
AM -- это определение термина Agile. Ни больше, ни меньше. Никаких книг определение не заменяет.
Agile -- это зонтичный бренд, а не какая-то конкретная методология, поэтому непосредственно Agile вообще не может быть применен. Можно только говорить является ли методология А Agile или нет.
По сути мы с вами говорим об одном и том же. Только само понятие (концепт) вам не нравится. Мне же кажется, что имеет смысл его растолковывать, если уж оно до сих пор употребляется.
Интересные формулировки, интересная точка зрения, 4й пункт первого списка забрал к себе в заметки :)
Однако размышляя над теми же напряжениями скрама я в итоге пришел чуть к иным аспектам:
- скрам мастер может быть, если нужен, но может и не быть если не нужен. может быть как full time роль или part time? как внешний или внутренний игрок? руководитель или зам или кто то из верхней команды если мы говорим про молекулярные команды на 100 чел? или внешний консультант если мы говорим про атомарные команды 5-10 чел.
- еще интересно провести аналогии с Канбан - где есть деливери менеджеры - отвечающие за снятие блокеров и помех на пути доставки ценности. на мой взгляд очень созвучно со скрам мастером. в этом случае роль конечно должна быть полноценная.
- но там еще образуется туча но и если - все очень зависит от контекста процессов и особенностей команды.
Работая с 20+ командами, я пришел к выводу что в этом мире не все всегда и везде, а кое что иногда и местами.
Где то все ок было даже с 1 руководителем проектов во главе, без всяких там скрамов, продукт овнеров и скрам мастеров. хотя в других кейсах та же схема оказывалась провальна.
Где то есть эджайл-помесь: скрама, канбана и социократии. Скрам мастер или эджайл коуч или консультант - парт тайм - просто приходит на некоторые встречи и если есть проблемы - помогает решать - но при этом он технически подкован.
А где то все по науке - продукт овнер от бизнеса, скрам мастер полу психолог не бум бум в ИТ, и все артефакты на месте - но там сплошной карго культ и на такую команду и их результаты сложно смотреть без слез.
А еще я думаю скрам стал популярен не потому что у него простые формулировки, а потому что он проприетарный, платный и у него огромные бюджеты на рекламу и маркетинг.
Например его аналог Социократия S3 - опенсорсная, сильно понятней для меня, но не так популярна потому что не так сильно рекламируется.
Рад, что было интересно).
Однако размышляя над теми же напряжениями скрама я в итоге пришел чуть к иным аспектам:
- скрам мастер может быть, если нужен, но может и не быть если не нужен. может быть как full time роль или part time? как внешний или внутренний игрок? руководитель или зам или кто то из верхней команды если мы говорим про молекулярные команды на 100 чел? или внешний консультант если мы говорим про атомарные команды 5-10 чел.- еще интересно провести аналогии с Канбан - где есть деливери менеджеры - отвечающие за снятие блокеров и помех на пути доставки ценности. на мой взгляд очень созвучно со скрам мастером. в этом случае роль конечно должна быть полноценная.
Если есть Скрам (т.е. в частности нет начальников отделов), то непонятно как получается без скрам-мастера: на основные события может он и не особо нужен, но проводить 1-1 и справляться с блокерами и другими конфликтами кто-то должен. Понятно, бывает, что один из разработчиков на себя это берет (и выполняет роль скрам-мастера, может быть даже не зная этого слова). Только это не системный подход: команда может "неожиданно" начать хуже работать, когда такой разработчик уйдет в другую команду или просто устанет выполнять дополнительную роль.
Работая с 20+ командами, я пришел к выводу что в этом мире не все всегда и везде, а кое что иногда и местами.
Согласен, что тут мы про теорию, а на практике по самым разным причинам разные вещи могут отличаться.
Например его аналог Социократия S3 - опенсорсная, сильно понятней для меня, но не так популярна потому что не так сильно рекламируется.
Спасибо, как-то это прошло мимо меня, почитаю.
Если есть Скрам (т.е. в частности нет начальников отделов), то непонятно как получается без скрам-мастера: на основные события может он и не особо нужен, но проводить 1-1 и справляться с блокерами и другими конфликтами кто-то должен.
Тут все просто - что такое команды? что такое отделы? а что такое домены? И еще - что такое холоны?
Чтобы ответить на этот вопрос - надо понимать все эти понятия и понимать как они связаны.
Там еще есть понятия про ко-лидерство.
Все это в целом сложно ) И если распутать тогда все становится по местам.
Условно чтобы уйти от старых понятий можно взять термины из Социократии - домены. Есть только домены и их поддомены. А у каждого домена могут быть лидеры, и они разные и может быть не один. Они могут заниматься чем угодно.
Домены могут взаимодействовать с любыми другими доменами в любых связях.
То что вы называете начальником отдела - это просто лидер домена. Его можно назвать руководителем, начальником отдела или департамента, или тим лидом, или лидом про что то - или как то еще.
Скрам это не про то что нет начальником отделов - они есть. Просто зовутся другими словами. Но суть всегда одна - если ты взял ответственность не только за себя, а еще и за какую то группу людей (команду, отдел, департамент ...) будь готов отвечать за всех.
Это сложно объяснить.
А еще сложнее объяснить что начальников или лидеров бывает много и они очень разные и зовутся по разному - можно почитать книги про ко-лидерство.
В одной команде даже атомарного уровня у одного сотрудника может быть 2-3-4 руководителя - и при грамотном балансе это тоже ок.
Но если это все переложить на карго культ и шаблоны - образуется ад. Что и бывает со скрамом )
В этом случае поможет только наличие грамотного консультанта или коуча который сможем навести баланс и объяснить как что работает ) так чтобы эти все типа лидеры не перегрызли себе глотки )
Беда бывает там где баланс нарушен и кто то из лидеров тащит одеяло на себя - например чел который отвечает за иерархию тащит одеяло на себя от человеков которые тащят ценность. Условно руководитель кодеров тащит одеяло на себя от руководителей проектов - вот там бывают взрывы и плохо.
Еще пара слов о Скраме и Agile-манифесте