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