Comments 33
В самом начале вы сделали смелое утверждение про понятность термина методология. Попробуйте дать определение словам методология, методика, метод. А потом ещё и слову фреймворк.
Скрам называют фреймворком потому, что он не описывает полноту всех действий по выполнению задачи. В отличие от других методологий, которые могут описывать, кроме прочего, управление бюджетом, ресурсами (включая людей), рисками, закупками и т.д. Для скрама это всё данность, решённая за его рамками.
Прекрасное замечание, но...
1) Для большинства не-it-шнтков слово "фреймворк" несёт в себе примерно столько же информации, как для англоговорящего человека karkas - набор звуков да и только.
2) термин framework используется ещё и потому, что в английском нету отдельных слов для Методики и Методологии - там все methodology. Причем, ладно, если бы использовался перевод "каркас" - это было бы хотя бы понятно, а так какой смысл?
А по поводу "дать определения", есть у меня такая задумка - оформить небольшую статейку именно на эту тему
Короче, скрам - это за всё хорошее, против всего плохого, и ничего конкретного.
Дейлики - ритуал, на котором все скучают, пока каждый придумывает что бы сказать, чтобы не выглядеть лентяем. Либо потому, что и так знают, либо потому что не интересно.
Планирование - ритуал гадания на кофейной гуще, где команда либо комитится на то, что не потянет, либо перестраховывается и потом бездельничает, пока по шапке не надают и не заставят оверкомититься.
Ретро - ритуал обсуждения одних и тех же нерешаемых проблем и откладывания решаемых на конец спринта, чтобы потом отложить на конец следующего, ибо есть задачи поважнее.
Комитмент - ритуал легитимизации усреднённых посредственных решений, так как любые другие приводят к бесконечному срачу, ведь каждый голос одинаково важен.
Срам-команда - универсальные солдаты, одинаково не умеющие во всё, так как не имеют возможности достаточно глубоко и продолжительно раскопать хотя бы одну тему.
Короче, скрам - это за всё хорошее, против всего плохого, и ничего конкретного.
К сожалению, должен признать, что ваша точка зрения не то, чтобы справедлива (ваши выводы неверны), но она понятна и более того небезосновательна. Это существенный недостаток гайда: он слишком сфокусирован на философии. Настолько, что именно Руководством его назвать сложно, хотя я думаю любой, кому всё-таки доводилось участвовать в работающем Скраме, согласится, что в гайде написаны справедливые вещи: и про прозрачность-инспекцию-адаптацию, и про их связь с событиями, и даже про - не побоюсь это слова - ценности. Хотя я отлично понимаю, что абсолютное большинство людей, услышав словосочетание "ценности скрам", тут же подумают: "ну вот, сейчас опять будут с**ть в ищи". Так что я могу согласиться, что гайд слащавый, но суть скрама и взаимосвязи в нем там описаны действительно классно. Ну а эта статья и видео как раз являются кратким содержанием гайда.
Вы описали скрам для скрам-мастеров. Но не для бизнеса, не для инженеров, не для PO. Оперируя абстракциями «ценность», «доверие» и т.д. вы описываете концептуальную полноту философии, которая неразделима с agile, наследуя все.
Т.е. чтобы построить то, что вы описываете нужно проанализировать и перестроить все бизнес-процессы под принципы agile, постоянно заниматься их тюнингом, а все сотрудники компании должны поддерживать культуру agile и тем более не саботировать. Топ-менеджмент, средний менеджмент - все должны следовать общей культуре. И вот в этой ситуации получится скрам-комнада. Часто видим такие компании?)
Скрам, как фреймворк итеративной разработки - это лишь способ выстроить процесс взаимодействия разработки с бизнесом. Для большинства на этом все закончится. Меньшинство вспомнит про «гибкость» выкинет дейлики и будет успешно работать по схеме планинг-груминг-ретро, адаптируя свою процессы под бизнес, которому глубоко пофигу на agile. А скрам для большинства: это щит от бизнеса.
И вы обошли стороной вопрос применимости скрама с позиции бизнеса. Если нет продукта, на который можно посадить кросс-функциональную команду? Если нет ресурсов создать избыточность для этого?
Но, спасибо за философию. Это полезно.
Оперируя абстракциями «ценность», «доверие» и т.д. вы описываете концептуальную полноту философии, которая неразделима с 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 нужен).
Но, спасибо за философию. Это полезно.
Пожалуйста ?
... и даже про - не побоюсь это слова - ценности
Что-то подсказывает мне, что пять указанных ценностей можно легко дополнить, ну например непротивлением злу, или делу время потехе час. Ничего не изменится. А все потому, что ценности - это для человека, а у вас ценности - для технологии артельного производства, именуемой Скрам.
Опять же, много раз повторяется слово ответственность. И в чем она заключается? Выгнать за плохую работу Владельца продукта или Скрам-мастера? Лишить премии? Четвертовать? Или вы имеете ввиду социальную ответственность - обозвать бракоделом и отобрать звездочку?
Если нет возможности подобрать понятные для этого вашего скрама ясные и однозначные определения, то это не беда этих терминов, это порок самого этого искусственного явления.
«У вас, — сообщила ему машина, — классический случай фим‑мании, осложненной сильной дварк‑наклонностью.
— Неужели? Мне казалось, что у меня мания убийства.
— Этот термин не имеет смысла, — строго сказала машина. — Поэтому я отвергаю его как бессмысленный набор звуков. Теперь учтите: фим‑мания совершенно нормальна. Никогда этого не забывайте. Правда, в раннем возрасте она обычно уступает место ховендиш‑отвращению. Индивидуумы, не обладающие этой естественной реакцией на внешнюю среду...»
Роберт Шекли. Терапия
Скрам - он для бизнеса. Поэтому ценности - для бизнеса. И да, они могут быть не только для человека. И это не значит, что нет ценности для людей.
Центральное звено философии agile, без которого скрам как философия не существует - это люди, мотивированные профессионалы. Чем мотивированные и как - остается за скобками. От себя добавлю, что это разделяющие ценности agile люди.
Ответственность - это чувство. Оно не может заключаться в «наказании». Оно может им побуждаться. Но agile-философия наделяет фундаментальную единицу, команду, большой степенью свободы своего функционирования, что побуждает к ответствености. Если ты можешь менять внутри себя процессы, нанимать/увольнять, то ты естественным образом несешь за это ответственность у мотивированных профессионалов (а других не должно быть в командах исходя из философии agile)
Фундаментальность команды в том, что для бизнеса - это атомарная единица. Черный ящик с входом и выходом.
Скрам - он для бизнеса. Поэтому ценности - для бизнеса. И да, они могут быть не только для человека. И это не значит, что нет ценности для людей.
Бизнес (или то что под ним сейчас понимается) это процесс, движение, перемены, но никак не статичная икона. Ценность самого бизнеса - доля добавленной стоимости, остающейся после расчетов со всеми. Ценность для бизнеса - не представляю, у него же в отличии от людей нет своей нравственности, нет этики. Или может под ценностью для бизнеса вы полагаете качество исходного сырья, остроту лезвия инструмента?
Ответственность - это чувство. Оно не может заключаться в «наказании»
Да ладно. Посмотрю я как вы чувствовать ответственность будете, когда из-за вас акционеры потеряют деньги. То, что чувство для вас, может быть, вследствие вашей безответственности, бедой для окружающих. Это, кстати отличительная черта идей трансгуманизма, с которыми носятся либералы, - полное отсутствие ответственности.
Но agile-философия наделяет фундаментальную единицу, команду, большой степенью свободы своего функционирования, что побуждает к ответствености.
Оглянитесь по сторонам. Идеи все большей и большей свободы в обществе? Да они уже скомпрометировали себя полностью! Как раз они и порождают безответственность.
Насчет философии про agile конечно сильно сказано. Но философией там и не пахнет. Аналогии с черным ящиком смешат и ужасают, если вспомнить кота Шредингера.
Начните хоть с каких-то базовых вещей, которые можно коротко и ясно представить народу - для кого, зачем и с какой целью. Иначе так и будете между собой посвященными перебрасываться фразами.
Ну вот вы прямо конкретно, то что я слегка завуалированно.
А так в целом, поборники agile слова наши не воспримут, не царское дело. Для них это философия, хотя философия - это про фундаментальные, основные вопросы бытия. То, что они называют agile-философией это конечно всего лишь поведенческая психология, базой для которой является неуверенность в себе.
Поэтому наши конкретные, бытовые вопросы не находятся ответами в их "стройных" картинках и кружочках со множеством несвязанных и даже весьма заумных слов; и вот они их перебирают, компонуют по разному, выстраивают причинно-следственные связи, но каждый раз так, чтобы не давать ясного ответа и не нести ответственность.
Ответственность - это про конкретную подпись на конкретном документе. И эта ответственность может быть материальной, и даже уголовной
Не знаю как вы, но я живу в мире, где большинство людей хотят гордиться своей работой, и у них есть такая штука, как профессиональное самолюбие. И Ответственность тут как раз в первую очередь перед собой. Если человек понимает, что сделал свою работу хорошо и видит, что в итоге вся команда делает классные, полезные штуки, то это круто для всех, в том числе и для компании. Соответственно, если человек это понимает, то такой внутренней ответственности (сделал фигню - не будет классных штук, подвел команду) будет достаточно.
А подпись… В абсолютном большинстве (белых) компаний, если программисту зачем-то доверили что-то подписать, и из-за этого компания потеряла 100500 миллионов, то если бедолага хоть чуть-чуть знает ТК РФ, то ему скорее всего даже выговор не смогут впаять, который он потом не смог бы оспорить в суде, не говоря уже о какой-то большей ответственности.
Потому я и хочу понять, кто в Скрам/аджайл командах подписи на этих документах ставит?
В скраме не такого понятия как ТЗ. Это юридические тонкости, которые намеренно упущены. Вы можете работать вообще без ТЗ.
Единственный источник задач в скраме – это Бэклог Продукта – приоритезированный список того, что надо сделать. За его наполнение отвечает Владелец Продукта. Откуда он берет задачи – из ТЗ или из опроса клиентов, например, – не важно с точки зрения методологии.
Просто в случае работы по согласованному ТЗ исполнение роли Владельца Продукта будет требовать больше технических навыков, а в стартапе каком-нибудь, где нет ТЗ, а есть бизнес-гипотезы для проверки, нужно больше маркетинговых/продуктовых навыков. Это могут быть даже разные должности в разных компаниях, но скрам-роль – одна.
Соответственно, кто там что подписывает – это уже совсем за рамками интересов скрама.
Хотя, в принципе, подписи могут фигурировать в процессе. Например, в Определении Готовности вы можете прописать, что задача считается готовой только, когда есть подпись заказчика в акте. Но опять же, это зависит ваших конкретных целей.
Мунирулятивное жонглирование? Не, не это не я подписывался
Да ладно. Посмотрю я как вы чувствовать ответственность будете, когда из-за вас акционеры потеряют деньги. То, что чувство для вас, может быть, вследствие вашей безответственности, бедой для окружающих. Это, кстати отличительная черта идей трансгуманизма, с которыми носятся либералы, - полное отсутствие ответственности.
Я уже писал в одном из комментариев, что не люблю agile-манифест. И именно за это. Вот прямо первый принцип “Люди и взаимодействие важнее процессов и инструментов” в отсутствии критериев легко превращается именно в полное отсутствие ответственности, во всякие: “Я художник - я так вижу! Это современно, это Агил, а вы ничего не понимаете, отсталые!”. И поэтому я не люблю, когда agile рассматривают как некую философию. Термин Agile возник на основе нескольких уже сформировавшихся методик . Причем сформировались они при решении вполне конкретных проблем. А Agile – это просто общий бренд. Ни Скрам, ни XP, ни другие прародители не рождались как некая попытка воплотить agile-принципы на практике. Все ровно наоборот – сначала была практика, а потом ее накрыли “философией”.
Начните хоть с каких-то базовых вещей, которые можно коротко и ясно представить народу - для кого, зачем и с какой целью. Иначе так и будете между собой посвященными перебрасываться фразами.
Справедливое требование...
Именно про скрам не скажу, но есть несколько подходов определения применимости аджайла.
Часто вспоминают матрицу Стейси
Кто-то пытается натянуть сову на голус киневин-фреймворком
И ещё неплохой вариант предложил PMI а Agile practice guide
Аджайл/Скрам потому так популярен в ИТ, что обычно уровень потерь оценивается в категории "несущественные деньги" - десятки, сотни тысяч долларов. Там, где потери выше, или есть угроза жизни, возникают всякие гибридные схемы: разработка гибкая, а тестирование и сертификация - предиктивные и т.д.
Если правильно понял из последнего рисунка, то аджайл-подход целесообразно применять в простых проектах? В сложных разработках со множеством составных частей и в критически-важных сферах его лучше не использовать
Ну, видимо, из последнего рисунка вы все поняли правильно, но при этом последний рисунок противоречит первому - в нем наоборот указано, что предиктивное планирование уместно только в простых проектах, т.е. в тех, где мы хорошо знаем, что делать и как делать.
...и тут я ни на что не намекаю, но вдруг вспомнилось, что PMI - это авторы PMBook`а, т.е. люди, которые по идее должны быть апологетами предиктивного планирования, но тоже решили поразмышлять об Agile, и у них вдруг получилось, что agile применим только в маленьких фуфло-проектах... не знаю, к чему я это... просто ремарка "вслух" ;) )
Какой картинке верить - выбирать вам (не забывая про куликов в болоте), но первая картинка - это как раз иллюстрация одного из основных agile-тезисов о том, что требования могут (и скорее всего будут) меняться. По разным причинам: заказчик плохо понимал, что хочет, аналитик неправильно его понял, ситуация на рынке поменялась, разработчики неправильно оценили затраты - все что угодно, но в итоге даже наличие ТЗ не гарантирует, что бизнес-ценность результата будет такой, какой ее хотел видеть заказчик. Соответственно, agile-подходы предлагают рассматривать проект не как набор фиксированных требований, которые нужно декомпозировать, оценить, составить план на 2 года, и начать его исполнять, а как набор идей, объединенных общей целью, которые нужно приоритизировать и начать поскорее проверять, при этом внося в планы необходимые изменения. Соответственно, в "классическом" подходе вы делаете ставку на то, что сумеете на первоначальном этапе правильно определить требования, составит план и потом его исполнить. Проблема только в том, что при таком подходе цена ошибки на начальном этапе очень высока, так как скорее всего вы обнаружите ее слишком поздно, когда исправление обойдется вам очень дорого. В Agile же вы не пытаетесь зажать себя в рамки, а ищите путь, который позволит вам достичь наилучшего результата из возможных в текущих условиях, и апологеты agile будут утверждать, что результат такого поиска будет скорее всего лучше, чем то, что вы в реальности получите при "классическом" подходе. То есть речь идет о разном распределении рисков. Какой из подходов выбрать - это ваше по сути предпринимательское решение.
Ну и если вернуться к вашему изначальному вопросу об области применимости, то многое зависит не только от инженерной области, но и от других факторов. Например. Скрам (да и вообще Agile) придумали программисты, при этом я подозреваю, что большинство критиков - это как раз программисты с негативным опытом. С другой стороны Джефф Сазерленд (один из авторов Скрама) на своих курсах любит упоминать об успешных примерах применения методики в нефтяной геологоразведке и самолетостроении. Далее, Скрам придуман для маленьких команд (до 10 человек). Если команда больше, то сложность внедрения будет возрастать: понадобится выбрать еще и шаблон масштабирования. Для нескольких десятков человек есть варианты попроще. Больше - сложнее (хотя это справедливо для абсолютно любых изменений в организации). В совсем больших организациях частенько принцип "подстелить соломки" превалирует над всем остальным, поэтому пытаться внедрить там "какую-то там культуру доверия" может быть совсем сложной задачей.
Ну и наконец немаловажно, сможете ли вы сами перестроиться: если диаграмма Ганта уже прочно вошла в ваше подсознание, то переход на формат бэклога также может потребовать существенных усилий. Стоит ли оно того - вопрос бизнесовый, потому что, повторюсь, agile меняет распределение рисков.
Ну и последнее наверное тут замечание (и так уже много букв получается), это то, что большинство внутренних проектов - где и заказчик и исполнители внутри компании - изначально скорее agile`овские по своей сути: появляется идея, и ее нужно проверить и внедрить, если все ок. Пожалуй такие проекты наиболее подходящие кандидаты для тестирования agile-подходов. По крайней мере с точки зрения распределения рисков - они все равно остаются внутри компании.
А и ну да! для стартапов я бы конечно выбирал Agile )))
Нет, не только для внутренних.
Давайте попробую привести пример.
У вас есть подписанное ТЗ. Но в процессе его написания/согласования произошло недопонимание, и теперь у заказчика ожидания одни, а у разработчиков – другие. В классической модели (водопадной) сначала все пишется, потом тестируется, потом сдается заказчику. В итоге, спорную фичу заказчик увидит достаточно поздно. Пусть даже он признает свою вину, вынужден будет подписать акты “как есть”, заплатит вам денег, а потом за доработку. Но будет ли он счастлив? Обратится ли к вам в следующий раз?
Инкрементальность подразумевает, что вы каждую фичу готовы показывать сразу, а не через сколько-то месяцев сразу десяток. Соответственно, ошибку клиент обнаружит раньше, что может оказаться критичным.
Другой вариант. Если вы подписались под невыполнимой задачей – неправильно оценили. К оговоренной дате вы сделаете 80% работы. А дальше что лучше иметь, продукт в котором все недоделано, или полностью функционирующие 80% наиболее важных фич? Вполне возможно, что во втором случае клиент даже не сильно расстроится. И вот Agile как раз нацелен на то, чтобы если уж такая фигня произошла, то подойти в часу Х со вторым вариантом.
Не спешите с выводами, не ознакомившись с книжкой. Противоречий нет. Раздел про модель применимости небольшой, понятный, но весь его я копировать сюда не буду.
И PMI никогда не были апологетами "предиктивного планирования". Это всё пугалки от продавцов аджайла. Вот, например, что было написано в PMBoK 5, который вышел 10 лет назад.
Вместе с PMBoK 6 они выпустили в 2017 году упомянутый Agile practice guide, а затем в 2019 году купили Disciplined Agile и развивают это направление.
Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.
Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.
Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.
Напоминает скрам-гайд в альтернативной переводе. Он тоже читаем за 10 минут
Основы Scrum менее чем за 10 минут (Scrum Alliance)