Если вы работаете в рамках некой научной теории, то да, вы, пожалуй, правы. Но на практике эти термины применяются не только в строгом научном смысле. И такое встречается сплошь и рядом в других сферах. Взять те же “вес” и “масса”: никто на вопрос “сколько ты весишь?” не ожидает услышать ответ в Ньютонах. Соответственно, я разбирался с практическим использованием, а не с научным.
Мне кажется, вы слишком формально подходите к вопросу. Никакие скрамы, канбаны и прочие, и прочие не описываются как формальные научные методы/методики/методологии, описанными в рамках некой формальной научной теории. Это практические рекомендации. Одно время было широко употребимо выражение “лучшие практики” (best practices), сейчас я уже и не помню, когда его слышал в последний раз, но по сути это то же самое. И ни одна эта самая “практическая методика/методология” не подразумевает абсолютной точности в реализации. И поэтому с научной точки зрения употребление этих терминов, скорее всего, необоснованно. Но на практике они широко используются. Я же пытался найти логику в этом самом практическом использовании. Такую, чтобы она не сильно противоречила научной практике.
При таком раскладе Методология получается совсем уж теоретическим термином. Что тогда из существующих сущностей можно назвать методологией?
Хотя это все равно не так уж сильно противоречит моей трактовке: методология - это описание, как создавать практические методики, которые можно было бы назвать Скрамом. Т.е. тут с какого масштаба посмотреть.
Ответственность за фиксированный скоуп и фокус: не только команда берёт на себя ответственность доставить задачи в срок, но и менеджер должен отвечать за то что в спринт не будет впихнуто "ну это же недолго? Оно очень горит"
Вы правы, и Сазерленд говорит о том же, хотя может и в менее явной форме, чем следовало бы:
В Scrum лидерство начинается с "самолидирства" (self-leading) команды: Scrum-мастер, который помогает команде, владелец продукта и руководство организации – все они должны понимать эту действительно фундаментальную динамику.
По поводу второго пункта. Скрам-гайд вообще весьма абстрактный, там оставили прям совсем верхнеуровневые идеи, но кроссфункциональность команд там осталась! А кроссфункциональная команда по определению – это команда, в которой есть ВСЕ необходимые для достижения цели спринта компетенции. Если у вас девопсы в отдельной команде – это уже не по фэншую. И тут я не даю оценку – оправданно это или нет – я констатирую факт. Вы идёте не по гайду, и у вас возникают ожидаемые проблемы. При этом и решать их описанная вами организация не особо стремится. Я конечно рискую быть обвинённым в банальности, но "ну они отдельно, мы на них влиять не можем" – это как раз и говорит о том, что ценности Скрама не являются ценностями организации. На практике. Декларироваться-то может все что угодно.
Так что видео как раз об этом: по-хорошему Скрам – это не только спринты и прочие ивенты – если нет уважения к коллегам, к их труду, и к общему результату, то… постоянного улучшения уж точно очень сложно будет добиться (если крайне политкорректно высказываться).
И это выдернутые слова альпиниста Мюррея, сказанные совершенно по другому поводу.
Сазерленд и не утверждает, что слова были сказаны по поводу скрама. Он исказил смысл слов Мюррея?
Всегда подозревал, что у всей этой крикливой братии язык - как помело… Теперь и местечковые коучи, скрам-мастера и прочие профессиональные балаболы будут говорить, что за ними - квантовая механика.
Меня тоже раздражают подобные пассажи: ты уж либо раскрой тему - при чем тут квантовая механика, - либо не бросайся терминами. С другой стороны, вы откажетесь от использования чего-то только из-за того, что в рекламном буклете упомянуты нанотехнологии или прочая модная дичь?
Да, хорошие идеи - они такие - имеют теньденцию витать в пространстве :)
Я и сам не отличаюсь особой стабильностью в написании статей - эту тоже достал из долгого ящика. Если б меня недавно ни пнули в комментарии к предыдущей статье (где я обозначил эту идею), то тоже непонятно, чья задумка материализовалось бы быстрее ;) Потому что эта хоть и находилась в шот-листе, но следующим по плану должен был стать перевод - но он "немножко" подвис...
У вас есть подписанное ТЗ. Но в процессе его написания/согласования произошло недопонимание, и теперь у заказчика ожидания одни, а у разработчиков – другие. В классической модели (водопадной) сначала все пишется, потом тестируется, потом сдается заказчику. В итоге, спорную фичу заказчик увидит достаточно поздно. Пусть даже он признает свою вину, вынужден будет подписать акты “как есть”, заплатит вам денег, а потом за доработку. Но будет ли он счастлив? Обратится ли к вам в следующий раз?
Инкрементальность подразумевает, что вы каждую фичу готовы показывать сразу, а не через сколько-то месяцев сразу десяток. Соответственно, ошибку клиент обнаружит раньше, что может оказаться критичным.
Другой вариант. Если вы подписались под невыполнимой задачей – неправильно оценили. К оговоренной дате вы сделаете 80% работы. А дальше что лучше иметь, продукт в котором все недоделано, или полностью функционирующие 80% наиболее важных фич? Вполне возможно, что во втором случае клиент даже не сильно расстроится. И вот Agile как раз нацелен на то, чтобы если уж такая фигня произошла, то подойти в часу Х со вторым вариантом.
Потому я и хочу понять, кто в Скрам/аджайл командах подписи на этих документах ставит?
В скраме не такого понятия как ТЗ. Это юридические тонкости, которые намеренно упущены. Вы можете работать вообще без ТЗ.
Единственный источник задач в скраме – это Бэклог Продукта – приоритезированный список того, что надо сделать. За его наполнение отвечает Владелец Продукта. Откуда он берет задачи – из ТЗ или из опроса клиентов, например, – не важно с точки зрения методологии.
Просто в случае работы по согласованному ТЗ исполнение роли Владельца Продукта будет требовать больше технических навыков, а в стартапе каком-нибудь, где нет ТЗ, а есть бизнес-гипотезы для проверки, нужно больше маркетинговых/продуктовых навыков. Это могут быть даже разные должности в разных компаниях, но скрам-роль – одна.
Соответственно, кто там что подписывает – это уже совсем за рамками интересов скрама.
Хотя, в принципе, подписи могут фигурировать в процессе. Например, в Определении Готовности вы можете прописать, что задача считается готовой только, когда есть подпись заказчика в акте. Но опять же, это зависит ваших конкретных целей.
Да ладно. Посмотрю я как вы чувствовать ответственность будете, когда из-за вас акционеры потеряют деньги. То, что чувство для вас, может быть, вследствие вашей безответственности, бедой для окружающих. Это, кстати отличительная черта идей трансгуманизма, с которыми носятся либералы, - полное отсутствие ответственности.
Я уже писал в одном из комментариев, что не люблю agile-манифест. И именно за это. Вот прямо первый принцип “Люди и взаимодействие важнее процессов и инструментов” в отсутствии критериев легко превращается именно в полное отсутствие ответственности, во всякие: “Я художник - я так вижу! Это современно, это Агил, а вы ничего не понимаете, отсталые!”. И поэтому я не люблю, когда agile рассматривают как некую философию. Термин Agile возник на основе нескольких уже сформировавшихся методик . Причем сформировались они при решении вполне конкретных проблем. А Agile – это просто общий бренд. Ни Скрам, ни XP, ни другие прародители не рождались как некая попытка воплотить agile-принципы на практике. Все ровно наоборот – сначала была практика, а потом ее накрыли “философией”.
Начните хоть с каких-то базовых вещей, которые можно коротко и ясно представить народу - для кого, зачем и с какой целью. Иначе так и будете между собой посвященными перебрасываться фразами.
Ответственность - это про конкретную подпись на конкретном документе. И эта ответственность может быть материальной, и даже уголовной
Не знаю как вы, но я живу в мире, где большинство людей хотят гордиться своей работой, и у них есть такая штука, как профессиональное самолюбие. И Ответственность тут как раз в первую очередь перед собой. Если человек понимает, что сделал свою работу хорошо и видит, что в итоге вся команда делает классные, полезные штуки, то это круто для всех, в том числе и для компании. Соответственно, если человек это понимает, то такой внутренней ответственности (сделал фигню - не будет классных штук, подвел команду) будет достаточно.
А подпись… В абсолютном большинстве (белых) компаний, если программисту зачем-то доверили что-то подписать, и из-за этого компания потеряла 100500 миллионов, то если бедолага хоть чуть-чуть знает ТК РФ, то ему скорее всего даже выговор не смогут впаять, который он потом не смог бы оспорить в суде, не говоря уже о какой-то большей ответственности.
Оперируя абстракциями «ценность», «доверие» и т.д. вы описываете концептуальную полноту философии, которая неразделима с agile, наследуя все.
Исключительно в свете полемического задора отмечу, что скрам может быть легко разделим с agile, так как не скрам наследует философию agile, а наоборот. Исторически agile возник как квинтэссенция XP (eXtreme Programming), Scrum, FDD (Feature Driven Development – разработка, управляемая функциональностью), DSDM (Dynamic Systems Development Method – Метод разработки динамических систем) и Crystal – именно авторы и последователи этих методик (+ еще несколько независимых, но близких по духу людей) собрались и договорились о принципах, которые и выразили в agile-манифесте.
Я вообще не большой фанат agile-манифеста. Возможно, в 2001 он и звучал как “вызов системе”, но сегодня… от него может даже больше вреда, чем пользы. Мне кажется, что самая большая заслуга манифеста – это как раз то, что авторы разных методик смогли собраться и создать этот зонтичный бренд, что позволило продвинуть концепцию, несмотря на внутренние войны сторонников разных веток.
Т.е. чтобы построить то, что вы описываете нужно проанализировать и перестроить все бизнес-процессы под принципы agile, постоянно заниматься их тюнингом, а все сотрудники компании должны поддерживать культуру agile и тем более не саботировать. Топ-менеджмент, средний менеджмент - все должны следовать общей культуре. И вот в этой ситуации получится скрам-комнада. Часто видим такие компании?)
Нет, не часто ? Но это не значит, что к этому не нужно стремиться ? Мне кажется, что усилия того стоят
Скрам, как фреймворк итеративной разработки - это лишь способ выстроить процесс взаимодействия разработки с бизнесом. Для большинства на этом все закончится. Меньшинство вспомнит про «гибкость» выкинет дейлики и будет успешно работать по схеме планинг-груминг-ретро, адаптируя свою процессы под бизнес, которому глубоко пофигу на agile. А скрам для большинства: это щит от бизнеса.
А вот тут в корне не согласен! Ну то есть можно, конечно, попробовать использовать agile как щит, но это как раз путь в никуда, имхо
И вы обошли стороной вопрос применимости скрама с позиции бизнеса.
Я не обошел, я просто иногда сплю ? и уже ответил.
Если нет продукта, на который можно посадить кросс-функциональную команду? Если нет ресурсов создать избыточность для этого?
Я и персональных проектиков использую скрам. Если проблема именно в кросс-функциональности, то если цепочка небольшая (например, дизайнеры работают отдельно от разрабов), то скрам тоже возможен, хотя могут возникать затруднения с синхронизацией и зависимостями спринтов. Если же у вас большая контора с глубоким разделение труда, и архитекторы, например, уже считают ниже своего достоинства кодить чего-то, то может тогда лучше посмотреть в сторону того же Канбана (если вообще agile нужен).
Если правильно понял из последнего рисунка, то аджайл-подход целесообразно применять в простых проектах? В сложных разработках со множеством составных частей и в критически-важных сферах его лучше не использовать
Ну, видимо, из последнего рисунка вы все поняли правильно, но при этом последний рисунок противоречит первому - в нем наоборот указано, что предиктивное планирование уместно только в простых проектах, т.е. в тех, где мы хорошо знаем, что делать и как делать.
...и тут я ни на что не намекаю, но вдруг вспомнилось, что PMI - это авторы PMBook`а, т.е. люди, которые по идее должны быть апологетами предиктивного планирования, но тоже решили поразмышлять об Agile, и у них вдруг получилось, что agile применим только в маленьких фуфло-проектах... не знаю, к чему я это... просто ремарка "вслух" ;) )
Какой картинке верить - выбирать вам (не забывая про куликов в болоте), но первая картинка - это как раз иллюстрация одного из основных agile-тезисов о том, что требования могут (и скорее всего будут) меняться. По разным причинам: заказчик плохо понимал, что хочет, аналитик неправильно его понял, ситуация на рынке поменялась, разработчики неправильно оценили затраты - все что угодно, но в итоге даже наличие ТЗ не гарантирует, что бизнес-ценность результата будет такой, какой ее хотел видеть заказчик. Соответственно, agile-подходы предлагают рассматривать проект не как набор фиксированных требований, которые нужно декомпозировать, оценить, составить план на 2 года, и начать его исполнять, а как набор идей, объединенных общей целью, которые нужно приоритизировать и начать поскорее проверять, при этом внося в планы необходимые изменения. Соответственно, в "классическом" подходе вы делаете ставку на то, что сумеете на первоначальном этапе правильно определить требования, составит план и потом его исполнить. Проблема только в том, что при таком подходе цена ошибки на начальном этапе очень высока, так как скорее всего вы обнаружите ее слишком поздно, когда исправление обойдется вам очень дорого. В Agile же вы не пытаетесь зажать себя в рамки, а ищите путь, который позволит вам достичь наилучшего результата из возможных в текущих условиях, и апологеты agile будут утверждать, что результат такого поиска будет скорее всего лучше, чем то, что вы в реальности получите при "классическом" подходе. То есть речь идет о разном распределении рисков. Какой из подходов выбрать - это ваше по сути предпринимательское решение.
Ну и если вернуться к вашему изначальному вопросу об области применимости, то многое зависит не только от инженерной области, но и от других факторов. Например. Скрам (да и вообще Agile) придумали программисты, при этом я подозреваю, что большинство критиков - это как раз программисты с негативным опытом. С другой стороны Джефф Сазерленд (один из авторов Скрама) на своих курсах любит упоминать об успешных примерах применения методики в нефтяной геологоразведке и самолетостроении. Далее, Скрам придуман для маленьких команд (до 10 человек). Если команда больше, то сложность внедрения будет возрастать: понадобится выбрать еще и шаблон масштабирования. Для нескольких десятков человек есть варианты попроще. Больше - сложнее (хотя это справедливо для абсолютно любых изменений в организации). В совсем больших организациях частенько принцип "подстелить соломки" превалирует над всем остальным, поэтому пытаться внедрить там "какую-то там культуру доверия" может быть совсем сложной задачей.
Ну и наконец немаловажно, сможете ли вы сами перестроиться: если диаграмма Ганта уже прочно вошла в ваше подсознание, то переход на формат бэклога также может потребовать существенных усилий. Стоит ли оно того - вопрос бизнесовый, потому что, повторюсь, agile меняет распределение рисков.
Ну и последнее наверное тут замечание (и так уже много букв получается), это то, что большинство внутренних проектов - где и заказчик и исполнители внутри компании - изначально скорее agile`овские по своей сути: появляется идея, и ее нужно проверить и внедрить, если все ок. Пожалуй такие проекты наиболее подходящие кандидаты для тестирования agile-подходов. По крайней мере с точки зрения распределения рисков - они все равно остаются внутри компании.
А и ну да! для стартапов я бы конечно выбирал Agile )))
Короче, скрам - это за всё хорошее, против всего плохого, и ничего конкретного.
К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про - не побоюсь это слова - ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание "ценности скрам", тут же подумают: "ну вот, сейчас опять будут с**ть в ищи". Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.
Если вы работаете в рамках некой научной теории, то да, вы, пожалуй, правы. Но на практике эти термины применяются не только в строгом научном смысле. И такое встречается сплошь и рядом в других сферах. Взять те же “вес” и “масса”: никто на вопрос “сколько ты весишь?” не ожидает услышать ответ в Ньютонах. Соответственно, я разбирался с практическим использованием, а не с научным.
Мне кажется, вы слишком формально подходите к вопросу. Никакие скрамы, канбаны и прочие, и прочие не описываются как формальные научные методы/методики/методологии, описанными в рамках некой формальной научной теории. Это практические рекомендации. Одно время было широко употребимо выражение “лучшие практики” (best practices), сейчас я уже и не помню, когда его слышал в последний раз, но по сути это то же самое. И ни одна эта самая “практическая методика/методология” не подразумевает абсолютной точности в реализации. И поэтому с научной точки зрения употребление этих терминов, скорее всего, необоснованно. Но на практике они широко используются. Я же пытался найти логику в этом самом практическом использовании. Такую, чтобы она не сильно противоречила научной практике.
Круг - это некий шаг, обведенная последовательность шагов - метод. Надпись "метод а" относится к прямоугольнику, а не к первому кругу.
При таком раскладе Методология получается совсем уж теоретическим термином. Что тогда из существующих сущностей можно назвать методологией?
Хотя это все равно не так уж сильно противоречит моей трактовке: методология - это описание, как создавать практические методики, которые можно было бы назвать Скрамом. Т.е. тут с какого масштаба посмотреть.
Вы правы, и Сазерленд говорит о том же, хотя может и в менее явной форме, чем следовало бы:
По поводу второго пункта. Скрам-гайд вообще весьма абстрактный, там оставили прям совсем верхнеуровневые идеи, но кроссфункциональность команд там осталась! А кроссфункциональная команда по определению – это команда, в которой есть ВСЕ необходимые для достижения цели спринта компетенции. Если у вас девопсы в отдельной команде – это уже не по фэншую. И тут я не даю оценку – оправданно это или нет – я констатирую факт. Вы идёте не по гайду, и у вас возникают ожидаемые проблемы. При этом и решать их описанная вами организация не особо стремится. Я конечно рискую быть обвинённым в банальности, но "ну они отдельно, мы на них влиять не можем" – это как раз и говорит о том, что ценности Скрама не являются ценностями организации. На практике. Декларироваться-то может все что угодно.
Так что видео как раз об этом: по-хорошему Скрам – это не только спринты и прочие ивенты – если нет уважения к коллегам, к их труду, и к общему результату, то… постоянного улучшения уж точно очень сложно будет добиться (если крайне политкорректно высказываться).
Сазерленд и не утверждает, что слова были сказаны по поводу скрама. Он исказил смысл слов Мюррея?
Меня тоже раздражают подобные пассажи: ты уж либо раскрой тему - при чем тут квантовая механика, - либо не бросайся терминами. С другой стороны, вы откажетесь от использования чего-то только из-за того, что в рекламном буклете упомянуты нанотехнологии или прочая модная дичь?
С этой точки зрения Скрам - это что? )
Пожалуйста 🤝
Да, хорошие идеи - они такие - имеют теньденцию витать в пространстве :)
Я и сам не отличаюсь особой стабильностью в написании статей - эту тоже достал из долгого ящика. Если б меня недавно ни пнули в комментарии к предыдущей статье (где я обозначил эту идею), то тоже непонятно, чья задумка материализовалось бы быстрее ;) Потому что эта хоть и находилась в шот-листе, но следующим по плану должен был стать перевод - но он "немножко" подвис...
Вот, попробовал дать определения :)
https://habr.com/ru/articles/825266/
Просили статейку? Их есть у меня :))
https://habr.com/ru/articles/825266/
Сделаем ;)
Скрам-гайд всё-таки по-длиннее. + Тут подача чуть иная - эдакий скрам-гайд в картинках. На мой взгляд это полезно для новичков.
Нет, не только для внутренних.
Давайте попробую привести пример.
У вас есть подписанное ТЗ. Но в процессе его написания/согласования произошло недопонимание, и теперь у заказчика ожидания одни, а у разработчиков – другие. В классической модели (водопадной) сначала все пишется, потом тестируется, потом сдается заказчику. В итоге, спорную фичу заказчик увидит достаточно поздно. Пусть даже он признает свою вину, вынужден будет подписать акты “как есть”, заплатит вам денег, а потом за доработку. Но будет ли он счастлив? Обратится ли к вам в следующий раз?
Инкрементальность подразумевает, что вы каждую фичу готовы показывать сразу, а не через сколько-то месяцев сразу десяток. Соответственно, ошибку клиент обнаружит раньше, что может оказаться критичным.
Другой вариант. Если вы подписались под невыполнимой задачей – неправильно оценили. К оговоренной дате вы сделаете 80% работы. А дальше что лучше иметь, продукт в котором все недоделано, или полностью функционирующие 80% наиболее важных фич? Вполне возможно, что во втором случае клиент даже не сильно расстроится. И вот Agile как раз нацелен на то, чтобы если уж такая фигня произошла, то подойти в часу Х со вторым вариантом.
В скраме не такого понятия как ТЗ. Это юридические тонкости, которые намеренно упущены. Вы можете работать вообще без ТЗ.
Единственный источник задач в скраме – это Бэклог Продукта – приоритезированный список того, что надо сделать. За его наполнение отвечает Владелец Продукта. Откуда он берет задачи – из ТЗ или из опроса клиентов, например, – не важно с точки зрения методологии.
Просто в случае работы по согласованному ТЗ исполнение роли Владельца Продукта будет требовать больше технических навыков, а в стартапе каком-нибудь, где нет ТЗ, а есть бизнес-гипотезы для проверки, нужно больше маркетинговых/продуктовых навыков. Это могут быть даже разные должности в разных компаниях, но скрам-роль – одна.
Соответственно, кто там что подписывает – это уже совсем за рамками интересов скрама.
Хотя, в принципе, подписи могут фигурировать в процессе. Например, в Определении Готовности вы можете прописать, что задача считается готовой только, когда есть подпись заказчика в акте. Но опять же, это зависит ваших конкретных целей.
Я уже писал в одном из комментариев, что не люблю agile-манифест. И именно за это. Вот прямо первый принцип “Люди и взаимодействие важнее процессов и инструментов” в отсутствии критериев легко превращается именно в полное отсутствие ответственности, во всякие: “Я художник - я так вижу! Это современно, это Агил, а вы ничего не понимаете, отсталые!”. И поэтому я не люблю, когда agile рассматривают как некую философию. Термин Agile возник на основе нескольких уже сформировавшихся методик . Причем сформировались они при решении вполне конкретных проблем. А Agile – это просто общий бренд. Ни Скрам, ни XP, ни другие прародители не рождались как некая попытка воплотить agile-принципы на практике. Все ровно наоборот – сначала была практика, а потом ее накрыли “философией”.
Справедливое требование...
Не знаю как вы, но я живу в мире, где большинство людей хотят гордиться своей работой, и у них есть такая штука, как профессиональное самолюбие. И Ответственность тут как раз в первую очередь перед собой. Если человек понимает, что сделал свою работу хорошо и видит, что в итоге вся команда делает классные, полезные штуки, то это круто для всех, в том числе и для компании. Соответственно, если человек это понимает, то такой внутренней ответственности (сделал фигню - не будет классных штук, подвел команду) будет достаточно.
А подпись… В абсолютном большинстве (белых) компаний, если программисту зачем-то доверили что-то подписать, и из-за этого компания потеряла 100500 миллионов, то если бедолага хоть чуть-чуть знает ТК РФ, то ему скорее всего даже выговор не смогут впаять, который он потом не смог бы оспорить в суде, не говоря уже о какой-то большей ответственности.
Исключительно в свете полемического задора отмечу, что скрам может быть легко разделим с agile, так как не скрам наследует философию agile, а наоборот. Исторически agile возник как квинтэссенция XP (eXtreme Programming), Scrum, FDD (Feature Driven Development – разработка, управляемая функциональностью), DSDM (Dynamic Systems Development Method – Метод разработки динамических систем) и Crystal – именно авторы и последователи этих методик (+ еще несколько независимых, но близких по духу людей) собрались и договорились о принципах, которые и выразили в agile-манифесте.
Я вообще не большой фанат agile-манифеста. Возможно, в 2001 он и звучал как “вызов системе”, но сегодня… от него может даже больше вреда, чем пользы. Мне кажется, что самая большая заслуга манифеста – это как раз то, что авторы разных методик смогли собраться и создать этот зонтичный бренд, что позволило продвинуть концепцию, несмотря на внутренние войны сторонников разных веток.
Нет, не часто ? Но это не значит, что к этому не нужно стремиться ? Мне кажется, что усилия того стоят
А вот тут в корне не согласен! Ну то есть можно, конечно, попробовать использовать agile как щит, но это как раз путь в никуда, имхо
Я не обошел, я просто иногда сплю ? и уже ответил.
Я и персональных проектиков использую скрам. Если проблема именно в кросс-функциональности, то если цепочка небольшая (например, дизайнеры работают отдельно от разрабов), то скрам тоже возможен, хотя могут возникать затруднения с синхронизацией и зависимостями спринтов. Если же у вас большая контора с глубоким разделение труда, и архитекторы, например, уже считают ниже своего достоинства кодить чего-то, то может тогда лучше посмотреть в сторону того же Канбана (если вообще agile нужен).
Пожалуйста ?
Ну, видимо, из последнего рисунка вы все поняли правильно, но при этом последний рисунок противоречит первому - в нем наоборот указано, что предиктивное планирование уместно только в простых проектах, т.е. в тех, где мы хорошо знаем, что делать и как делать.
...и тут я ни на что не намекаю, но вдруг вспомнилось, что PMI - это авторы PMBook`а, т.е. люди, которые по идее должны быть апологетами предиктивного планирования, но тоже решили поразмышлять об Agile, и у них вдруг получилось, что agile применим только в маленьких фуфло-проектах... не знаю, к чему я это... просто ремарка "вслух" ;) )
Какой картинке верить - выбирать вам (не забывая про куликов в болоте), но первая картинка - это как раз иллюстрация одного из основных agile-тезисов о том, что требования могут (и скорее всего будут) меняться. По разным причинам: заказчик плохо понимал, что хочет, аналитик неправильно его понял, ситуация на рынке поменялась, разработчики неправильно оценили затраты - все что угодно, но в итоге даже наличие ТЗ не гарантирует, что бизнес-ценность результата будет такой, какой ее хотел видеть заказчик. Соответственно, agile-подходы предлагают рассматривать проект не как набор фиксированных требований, которые нужно декомпозировать, оценить, составить план на 2 года, и начать его исполнять, а как набор идей, объединенных общей целью, которые нужно приоритизировать и начать поскорее проверять, при этом внося в планы необходимые изменения. Соответственно, в "классическом" подходе вы делаете ставку на то, что сумеете на первоначальном этапе правильно определить требования, составит план и потом его исполнить. Проблема только в том, что при таком подходе цена ошибки на начальном этапе очень высока, так как скорее всего вы обнаружите ее слишком поздно, когда исправление обойдется вам очень дорого. В Agile же вы не пытаетесь зажать себя в рамки, а ищите путь, который позволит вам достичь наилучшего результата из возможных в текущих условиях, и апологеты agile будут утверждать, что результат такого поиска будет скорее всего лучше, чем то, что вы в реальности получите при "классическом" подходе. То есть речь идет о разном распределении рисков. Какой из подходов выбрать - это ваше по сути предпринимательское решение.
Ну и если вернуться к вашему изначальному вопросу об области применимости, то многое зависит не только от инженерной области, но и от других факторов. Например. Скрам (да и вообще Agile) придумали программисты, при этом я подозреваю, что большинство критиков - это как раз программисты с негативным опытом. С другой стороны Джефф Сазерленд (один из авторов Скрама) на своих курсах любит упоминать об успешных примерах применения методики в нефтяной геологоразведке и самолетостроении. Далее, Скрам придуман для маленьких команд (до 10 человек). Если команда больше, то сложность внедрения будет возрастать: понадобится выбрать еще и шаблон масштабирования. Для нескольких десятков человек есть варианты попроще. Больше - сложнее (хотя это справедливо для абсолютно любых изменений в организации). В совсем больших организациях частенько принцип "подстелить соломки" превалирует над всем остальным, поэтому пытаться внедрить там "какую-то там культуру доверия" может быть совсем сложной задачей.
Ну и наконец немаловажно, сможете ли вы сами перестроиться: если диаграмма Ганта уже прочно вошла в ваше подсознание, то переход на формат бэклога также может потребовать существенных усилий. Стоит ли оно того - вопрос бизнесовый, потому что, повторюсь, agile меняет распределение рисков.
Ну и последнее наверное тут замечание (и так уже много букв получается), это то, что большинство внутренних проектов - где и заказчик и исполнители внутри компании - изначально скорее agile`овские по своей сути: появляется идея, и ее нужно проверить и внедрить, если все ок. Пожалуй такие проекты наиболее подходящие кандидаты для тестирования agile-подходов. По крайней мере с точки зрения распределения рисков - они все равно остаются внутри компании.
А и ну да! для стартапов я бы конечно выбирал Agile )))
К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про - не побоюсь это слова - ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание "ценности скрам", тут же подумают: "ну вот, сейчас опять будут с**ть в ищи". Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.
А по поводу "дать определения", есть у меня такая задумка - оформить небольшую статейку именно на эту тему