При таком раскладе Методология получается совсем уж теоретическим термином. Что тогда из существующих сущностей можно назвать методологией?
Хотя это все равно не так уж сильно противоречит моей трактовке: методология - это описание, как создавать практические методики, которые можно было бы назвать Скрамом. Т.е. тут с какого масштаба посмотреть.
Ответственность за фиксированный скоуп и фокус: не только команда берёт на себя ответственность доставить задачи в срок, но и менеджер должен отвечать за то что в спринт не будет впихнуто "ну это же недолго? Оно очень горит"
Вы правы, и Сазерленд говорит о том же, хотя может и в менее явной форме, чем следовало бы:
В 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 )))
Короче, скрам - это за всё хорошее, против всего плохого, и ничего конкретного.
К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про - не побоюсь это слова - ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание "ценности скрам", тут же подумают: "ну вот, сейчас опять будут с**ть в ищи". Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.
1) Для большинства не-it-шнтков слово "фреймворк" несёт в себе примерно столько же информации, как для англоговорящего человека karkas - набор звуков да и только.
2) термин framework используется ещё и потому, что в английском нету отдельных слов для Методики и Методологии - там все methodology. Причем, ладно, если бы использовался перевод "каркас" - это было бы хотя бы понятно, а так какой смысл?
Непосредственно про Скрам уже вроде аргументы написаны, и повторяться не буду. Но даже если отвлечься от Скрам, то использование Owner/Владелец в роли не соответсвует и общей менеджерской практике. Так, например, существуют еще такие понятия как Project Owner и Process Owner – и в том и в другом случае речь идет о людях, которые Заинтересованы в Результе Вцелом, а не каких-то точечных показателях. В вашей же интерпритации Product Owner (ввиду отсутствия ответственности за сроки и бюджеты) больше похож на тех продажников, которые обещают заказчику какую-то дичь да еще и в неизвестно откуда взятые сроки – главное продать, а потом хоть потоп, – а инженеры должны все это разгребать. В Скраме же Владелец Продукта – это именно Владелец классическом (устоявшемся) понимании. В итоге, когда человек, который ничего не знает про Скрам и Agile, но знаком с теорией процессов или проектов, впервые услышит термин Product Owner, у него скорее всего возникнут ассоциации куда ближе к Скрамовсому определению, чем к вашему. Это, в свою очередь, помогает людям быстрее находить общий язык, что и является целю профессиональной терминологии. Когда же понятия используются произвольно, в угоду моде, это затрудняет общение, потому что приходится переспрашивать: “а что конкретно вы имеете в виду?”, ну или пытаться угадать из контекста… Так и что в этом хорошего?
Хотя я конечно должен признать, что хайп как правило все-таки побеждает прозрачность понятий (((
Круг - это некий шаг, обведенная последовательность шагов - метод. Надпись "метод а" относится к прямоугольнику, а не к первому кругу.
При таком раскладе Методология получается совсем уж теоретическим термином. Что тогда из существующих сущностей можно назвать методологией?
Хотя это все равно не так уж сильно противоречит моей трактовке: методология - это описание, как создавать практические методики, которые можно было бы назвать Скрамом. Т.е. тут с какого масштаба посмотреть.
Вы правы, и Сазерленд говорит о том же, хотя может и в менее явной форме, чем следовало бы:
По поводу второго пункта. Скрам-гайд вообще весьма абстрактный, там оставили прям совсем верхнеуровневые идеи, но кроссфункциональность команд там осталась! А кроссфункциональная команда по определению – это команда, в которой есть ВСЕ необходимые для достижения цели спринта компетенции. Если у вас девопсы в отдельной команде – это уже не по фэншую. И тут я не даю оценку – оправданно это или нет – я констатирую факт. Вы идёте не по гайду, и у вас возникают ожидаемые проблемы. При этом и решать их описанная вами организация не особо стремится. Я конечно рискую быть обвинённым в банальности, но "ну они отдельно, мы на них влиять не можем" – это как раз и говорит о том, что ценности Скрама не являются ценностями организации. На практике. Декларироваться-то может все что угодно.
Так что видео как раз об этом: по-хорошему Скрам – это не только спринты и прочие ивенты – если нет уважения к коллегам, к их труду, и к общему результату, то… постоянного улучшения уж точно очень сложно будет добиться (если крайне политкорректно высказываться).
Сазерленд и не утверждает, что слова были сказаны по поводу скрама. Он исказил смысл слов Мюррея?
Меня тоже раздражают подобные пассажи: ты уж либо раскрой тему - при чем тут квантовая механика, - либо не бросайся терминами. С другой стороны, вы откажетесь от использования чего-то только из-за того, что в рекламном буклете упомянуты нанотехнологии или прочая модная дичь?
С этой точки зрения Скрам - это что? )
Пожалуйста 🤝
Да, хорошие идеи - они такие - имеют теньденцию витать в пространстве :)
Я и сам не отличаюсь особой стабильностью в написании статей - эту тоже достал из долгого ящика. Если б меня недавно ни пнули в комментарии к предыдущей статье (где я обозначил эту идею), то тоже непонятно, чья задумка материализовалось бы быстрее ;) Потому что эта хоть и находилась в шот-листе, но следующим по плану должен был стать перевод - но он "немножко" подвис...
Вот, попробовал дать определения :)
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 )))
К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про - не побоюсь это слова - ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание "ценности скрам", тут же подумают: "ну вот, сейчас опять будут с**ть в ищи". Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.
А по поводу "дать определения", есть у меня такая задумка - оформить небольшую статейку именно на эту тему
Прекрасное замечание, но...
1) Для большинства не-it-шнтков слово "фреймворк" несёт в себе примерно столько же информации, как для англоговорящего человека karkas - набор звуков да и только.
2) термин framework используется ещё и потому, что в английском нету отдельных слов для Методики и Методологии - там все methodology. Причем, ладно, если бы использовался перевод "каркас" - это было бы хотя бы понятно, а так какой смысл?
Непосредственно про Скрам уже вроде аргументы написаны, и повторяться не буду. Но даже если отвлечься от Скрам, то использование Owner/Владелец в роли не соответсвует и общей менеджерской практике. Так, например, существуют еще такие понятия как Project Owner и Process Owner – и в том и в другом случае речь идет о людях, которые Заинтересованы в Результе Вцелом, а не каких-то точечных показателях. В вашей же интерпритации Product Owner (ввиду отсутствия ответственности за сроки и бюджеты) больше похож на тех продажников, которые обещают заказчику какую-то дичь да еще и в неизвестно откуда взятые сроки – главное продать, а потом хоть потоп, – а инженеры должны все это разгребать. В Скраме же Владелец Продукта – это именно Владелец классическом (устоявшемся) понимании. В итоге, когда человек, который ничего не знает про Скрам и Agile, но знаком с теорией процессов или проектов, впервые услышит термин Product Owner, у него скорее всего возникнут ассоциации куда ближе к Скрамовсому определению, чем к вашему. Это, в свою очередь, помогает людям быстрее находить общий язык, что и является целю профессиональной терминологии. Когда же понятия используются произвольно, в угоду моде, это затрудняет общение, потому что приходится переспрашивать: “а что конкретно вы имеете в виду?”, ну или пытаться угадать из контекста… Так и что в этом хорошего?
Хотя я конечно должен признать, что хайп как правило все-таки побеждает прозрачность понятий (((