jonka ПИЧУ ПИЧУ 9 kuukautta sitten
103
Lisää tämän kaltaisia
SAFe
Scaled Agile Framework® (SAFe®) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности. Платформа SAFe применяется во множестве agile-команд, обеспечивая согласованность, помогая выполнять совместную работу и поставку. В ее основу легли три основных блока знаний: гибкая (agile) разработка программного обеспечения, «бережливая» (lean) разработка продукции и системное мышление.
Минусы
Противоречит Agile
Основатель аджайл Кен Швабер критически относится к некоторым стратегиям SAFe. Он упоминает продажу лицензий на использование фреймворка и создание специальных партнёрств с инструментами. Некоторые сторонники аджайла считают SAFe слишком “доведённым до ума”, чтобы помочь гибкой культуре компании развиваться, вне зависимости от её размера.
При этом, Scrum, удерживающий истинные ценности и принципы аджайла, остаётся намеренно “недоделанным”, чтобы дать пространство для принятия новых ценностей. В этом смысле SAFe может подорвать важность людей и их взаимодействия.
Не для стартапов
SAFe, как фреймворк, направлен на масштабирование гибкости в крупных предприятиях, что может делать его неподходящим для стартапов. Ситуация, когда в компании работает меньше 30-40 сотрудников, типична для стартапов. В этом контексте использование SAFe может снижать гибкость и способность быстро откликаться на переменчивые рыночные условия.
Спринт завершения разработки
В рамках фреймворка SAFe стадия, которую называют инновационным или IP-спринтом, вызывает много вопросов. Звучит заманчиво, но обычно она служит этапом завершения приращения. Здесь команды занимаются отладкой, стабилизацией конвейера, решением внезапно возникших проблем.
Люди, близкие к аджайлу, находят эту стадию противоречивой, отмечая свои сомнения относительно её настоящей необходимости. Некоторые подчёркивают, что она минует ключевое требование аджайла и Scrum – увеличение функциональности. Подобная ситуация возникает в компаниях, не имеющих чёткого определения завершённости на уровне команд и предприятия. Они пренебрегают этим, устремляясь к
Потеря гибкости
Несмотря на многослойность административного управления в SAFe, внедрение ролей на каждом уровне может лишить команду разработки свободы для экспериментов, что есть в Scrum. Это отнимает время у самоорганизованных команд и ограничивает их роль при принятии решений.
Проблема терминологии
В SAFe применяется множество терминов. Например, release trains, Program Increments, runways, guardrails, enablers, spikes и так далее. SAFe создаёт свою адаптацию Agile терминологии, подгоняя общепринятые термины и процессы под свой “фреймворк”. Например, спринт становится итерацией, story points становятся новыми рекомендациями, а spikes получают оценку.
Плюсы
Повышение гибкости компании
Конечная цель любого фреймворка масштабирования Agile – помощь организации в процветании в эру цифрового хаоса. Основные требования – оперативное реагирование на изменения рынка и работа с возникающими сложностями. SAFe, удостоверяясь в согласовании бизнеса и IT, создаёт иерархическую структуру, совмещённую с предпринимательской сетью. Этот клиенто-ориентированный фреймворк способствует эффективности, стабильности и открывает двери для инноваций.
Более тесное взаимодействие с бизнесом и его целями
Будучи мощным инструментом, SAFe умело борется с разделенностью бизнеса и технологий. Этот фреймворк с теплотой приветствует идеи, поощряя встречи участников бизнеса и IT-команд. Помимо этого, представители бизнеса активно участвуют в определении приоритетов, присваивая “бизнес-значение” каждому элементу.
Ориентация на конечного пользователя
SAFe предлагает исследовательский подход, ориентированный на клиента. Важно точно понимать, как каждое решение будет влиять на конечного пользователя. Это помогает организации лучше понять тренды рынка и оставаться впереди цикла гиперболы, осваивая важные неисследованные области и получая преимущество.
Сокращение времени до достижения ценности
В SAFe, все части организации – от команд Scrum и ART до исполнительных руководителей – движутся в ногу, стремясь к единому набору целей. Это позволяет достигать единообразного планирования и выполнения, повторяемости, включая своевременную обратную связь на всех уровнях и тем самым обеспечивать ускоренное достижение ценности.
Управление командами в крупных структурах
Огромные организации, много команд, каждая с своими задачами. SAFe на помощь. С помощью планирования PI, уже упомянутого, можно решить проблемы, связанные с координацией между командами. Зависимости между ними определяются заранее и постоянно согласовываются. Но это не ограничивается только планированием PI, фреймворк предлагает методику взаимодействия команд через scrum of scrums. Идеальным способом демонстрации зависимостей между командами является программная доска.
Планирование PI и контроль зависимостей
Планирование PI является важнейшей частью этого фреймворка. Здесь кроется весь шарм. Это и есть сердце подхода, позволяя видеть ясную картину программного прироста, понимать зависимости между командами и формировать устойчивость, необходимую для реализации стратегии. Несоблюдение правил планирования PI может привести к неясностям, проблемам в разработке и даже катастрофическим последствиям для продукта.
Но когда все проходит гладко, итерационный цикл помогает уточнить важные моменты плана, а процедуры обеспечивают согласие всех заинтересованных сторон. Обычное планирование PI — это двухдневное мероприятие, где встречаются разные команды ART. Однако, недавно было введено трехдневное распределенное планирование PI, что особенно актуально для команд, работающих из разных часовых поясов.
Масштабирование на разные уровни
SAFe предлагает вариации от Essential до Full, охватывающие нужды любого уровня организации, желающей применять Agile. В этом контексте, принцип гибкости пронизывает не только разработку, но и уровень топ-менеджмента, готовящегося к волнам неопределенности в бизнесе. Таким образом, SAFe дает топ-менеджерам ценные знания для преодоления любых рисков и неясностей.
Шаги внедрения
Поддерживать и улучшать
Расширить схему до уровня всего портфеля
Запустить больше ART и потоков создания ценности
Научиться реализации ART
Обучить команды и запустить ART
Подготовиться к запуску ART
Создать план реализации
Определить потоки создания ценности и поезда agile-релизов (ART)
Создать центр передовых технологий, соблюдающий принципы бережливости и гибкости
Обучить руководителей, менеджеров и ведущих специалистов
Обучить менеджеров по организационным изменениям, которые будут использовать принципы бережливости и agile
Достичь переломного момента
Децентрализуйте принятие решений
Раскройте внутреннюю мотивацию работников умственного труда
Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования
Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей
Контрольные точки должны основываться на объективной оценке работающих систем
Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс
Допускайте вариативность; сохраняйте варианты
Применяйте системное мышление
Смотрите с точки зрения экономики
Руководство
SAFe требует от руководителей поведения, в котором сочетаются принципы бережливости и гибкости, поскольку только руководители могут изменить систему и создать среду, необходимую для внедрения всех ключевых ценностей.
Выполнение программы
Выполнение программы лежит в основе SAFe и поддерживает все остальное на платформе. Команды и программы должны на регулярной основе доставлять качественное, работающее программное обеспечение и коммерческую ценность.
Прозрачность
SAFe поощряет поведение, способствующее построению доверительных отношений, в том числе разбиение работы на пакеты сокращенного объема при планировании, чтобы быстрее выявлять проблемы, обеспечение в бэклоге наглядного представления прогресса по всем уровням в режиме реального времени, а также проверку и адаптацию ритуалов.
Встроенное качество
В платформе SAFe гибкость никогда не должна достигаться за счет качества. SAFe требует, чтобы команды всех уровней определяли, в чем заключается «готовность» каждой задачи или проекта, и закрепляли качественные методы разработки в каждом соглашении о сотрудничестве. Согласно SAFe, существует пять основных показателей встроенного качества: процесс, качество архитектуры и дизайна, качество кода, качество системы и качество релиза.
Соответствие
Платформа SAFe требует, чтобы компании устанавливали на всех уровнях организации последовательность планирования и рефлексии. Благодаря этому каждый сотрудник понимает текущее состояние бизнеса, цели и направление движения для достижения таких целей. Регулярная синхронизация людей и действий позволяет поддерживать согласованность всех уровней портфеля. Потоки информации своевременно движутся как вверх, так и вниз, в отличие от традиционных структур управления, где информация спускается сверху вниз.
Iterative Development
Итеративный процесс — это циклическое повторение действий, направленных на быстрое создание прототипа продукта и получение обратной связи от клиентов и заинтересованных сторон. В следующем цикле команда совершенствует продукт с учетом полученных отзывов, а затем весь процесс повторяется сначала до достижения желаемого результата. Также можно сказать, чем итеративный процесс точно не является. Этот процесс не является линейным или последовательным. Это не шаблонный процесс, который повторяется из раза в раз без малейших изменений. Наоборот, он носит гибкий, циклический характер. Участники команды общими усилиями решают проблемы, улучшая продукт на основе выводов по результатам предыдущих циклов.
Гибкость и адаптивность
Еще один важный плюс итеративного процесса — его гибкость. В условиях меняющихся требований итеративные циклы позволяют командам по продуктам разрабатывать следующие версии с учетом отзывов клиентов, подстраиваясь под их потребности или рыночные тренды. В линейных, неитеративных процессах с фиксированным объемом задач такой адаптивности нет.
Сокращение расходов
Итеративная разработка довольно выгодна. Собирая отзывы клиентов по каждому прототипу, вы сможете на ранних стадиях выявлять дорогостоящие ошибки и вкладывать ресурсы в те функции, которые действительно нужны целевой аудитории.
Например, команда разработчиков мобильного приложения уже на первом прототипе может выяснить, что пользователи ждали не встроенную ленту постов в стиле социальных сетей, а корпоративные инструменты для совместной работы. Выявив эту потребность, команда сразу может посвятить время и ресурсы созданию именно этих инструментов.
Непрерывное совершенствование
Основным принципом итеративной работы является непрерывное совершенствование. Вы тестируете прототип и используете обратную связь для его улучшения в следующем цикле. Затем тестируете следующие прототипы, обучаясь с каждым циклом, пока не добьетесь желаемого результата: востребованного продукта, который будет хорошо продаваться. Последовательные процессы не дают такой возможности экспериментировать и быстро вносить необходимые улучшения, как итеративные.
Снижение рисков
При итеративном подходе команда может увидеть возможные риски в самом начале. Тестирование прототипа покажет, насколько ваш продукт вписывается в реалии рынка и отвечает потребностям клиентов. Если их отзывы окажутся отрицательными, вы сможете быстро перестроиться и снизить риски, не тратя ресурсы на разработку невостребованных функций.
Ускорение выхода на рынок
Возможность тестировать ранние версии продуктов и терпеть неудачи на начальных этапах имеет свои плюсы: вы быстрее понимаете, что работает, а что нет, а значит, можете быстрее выпустить новый продукт на рынок. Это, в свою очередь, позволяет команде применять итеративные процессы для более эффективной работы.
Трудности итеративного процесса
Сопротивление изменениям
Не все будут согласны на итеративный процесс, особенно если речь идет о новых участниках команды. Вам необходимо преодолеть это сопротивление изменениям, активно поясняя преимущества итеративного процесса и честно рассказывая об успехах и проблемах. Борьба с этим сопротивлением сводится к общению: при достаточном взаимодействии вы сможете привести людей к единому мнению.
Ожидания заинтересованных сторон
Заинтересованные стороны могут принимать участие в обсуждении прогресса продукта, поскольку являются конечными пользователями или владельцами проекта. Но часть этого процесса состоит в том, чтобы научиться работать с их ожиданиями, объясняя принципы итеративного процесса и определяя показатели успеха и сроки. Оставайтесь на связи и покажите заинтересованным сторонам, что вы слышите их отзывы — ведь их комментарии и предложения определяют будущее продукта.
Расширение области проекта
Поскольку команда постоянно экспериментирует и тестирует, область проекта может расти. Все новые требования могут привести к задержкам или непредвиденному росту бюджета и даже помешать завершению работы. Чтобы держать область проекта под контролем, убедитесь, что этап планирования каждой итерации включает определение области, которое поможет команде сосредоточиться на приоритетных заданиях каждого рабочего цикла.
Этапы итеративного процесса
Повторение и улучшение
Следующий этап подразумевает использование результатов тестов и отзывов от заинтересованных лиц, собранных на протяжении итерации, для планирования нового цикла работы. Критическая оценка предыдущей работы повлечет за собой корректировку плана, дизайна, целей и объема работ. Если справиться с этим успешно, после очередной итерации ваш продукт станет еще лучше.
Это последний этап итеративного процесса, но не финал вашей работы. Отсюда весь цикл повторяется с самого начала столько раз, сколько потребуется для достижения желаемого результата.
Оценка и тестирование
На этапе оценки и тестирования становится понятно, удалось ли достичь целей итерации. Соответствует ли продукт стандартам качества? Довольны ли клиенты? Как всегда, во время анализа определяются области, нуждающиеся в улучшении. Вам необходимо проверить качество и эффективность вашего решения. Если результат цикла отвечает вашим целям и стандартам, следующая итерация будет проще.
Внедряйте
Внедрение — это переход от замысла к практике и воплощению планов. Как правило, это подразумевает создание прототипа или разработку функции. На этом этапе ключом к непрерывному совершенствованию продукта является обратная связь от заинтересованных лиц. Впереди будет еще много циклов до успешного запуска, поэтому каждая крупица информации будет способствовать прогрессу.
Дизайн
На этапе дизайна разрабатывается решение для текущей итерации. Что нужно, чтобы достичь цели рабочего цикла, — создать прототип, провести исследование или улучшить имеющиеся функции? В рамках этого этапа также определяются показатели (KPI), с помощью которых будет измеряться успех итерации.
Планируйте
Начните с постановки целей и определения задач своего проекта. Чего вы хотите достичь, через какие контрольные точки пройти и к какому сроку?
Затем следует обозначить заинтересованные стороны — это все те, чьи решения будут влиять на работу. В ходе планирования сложный проект разбивается на небольшие итерации, для каждой из которых определяется область работы. В результате каждый участник команды четко понимает, что от него требуется.
Extreme Programming
Экстремальное программирование (XP) - это методология управления IT-проектами и разработкой программного обеспечения, разработанная Кентом Бэком и успешно применяемая им на крупных проектах. Основой этой методологии является тесное взаимодействие между участниками проекта, включая заказчиков, постоянную обратную связь, простоту внедрения и храбрость, необходимая для принятия ответственности.
затраты на разработку ниже, т.к. команда ориентирована на код, а не на документацию и собрания
снижаются риски, связанные с разработкой, т.к. ответственность за проект распределяется равномерно и уход/приход члена команды не разрушит процесс
высокое качество кода
быстрый темп разработки за счет парного программирования, отсутствия переработок, присутствия заказчика в команде
команда легко поддерживает код, т.к. он написан по единому стандарту и постоянно рефакторится
код всегда работает за счет постоянного тестирования и непрерывной интеграции
команда быстро вносит изменения в код и добавляет новую функциональность за счет простого дизайна кода, частого планирования и релизов
заказчик получает именно тот продукт, который ему нужен, даже если в начале разработки сам точно не представляет его конечный вид
т.к. гибкие методологии функционально-ориентированные, нефункциональные требования к качеству продукта сложно описать в виде пользовательских историй.
из-за недостатка структуры и документации не подходит для крупных проектов
требует слишком сильных культурных изменений, чтобы не контролировать каждую задачу
регулярные встречи с программистами дорого обходятся заказчикам
менеджмент негативно относится к парному программированию, не понимая, почему он должен оплачивать двух программистов вместо одного
успех XP сильно зависит от уровня программистов, методология работает только с senior специалистами
трудно предугадать затраты времени на проект, т.к. в начале никто не знает полного списка требований
успех проекта зависит от вовлеченности заказчика, которой не так просто добиться
Правила управления
Если какие-то процессы или правила XP не работают или мешают, их следует исправить.
Специалисты могут быть перемещены между задачами для повышения эффективности.
Регулярно измеряется скорость выполнения проекта.
Рабочий день начинается с общих встреч, так называемых стендапов.
Важно установить устойчивый ритм работы, основанный на правильно спланированных итерациях.
Команда должна работать в открытом пространстве, используя формат опенспейса.
Правила планирования
Проект должен быть разделен на итерации, и каждая новая итерация начинается с планирования.
Мы ставим на небольшие и частые релизы.
Планирование выпусков должно привести к составлению графика релизов.
Важно составить пользовательские истории, которые четко описывают требования.
Ценности
Храбрость: готовность принимать ответственность, пробовать новые идеи и решения, даже если они могут вызывать неопределенность или риск.
Уважение: уважение и доверие между членами команды, а также к заказчикам и другим заинтересованным сторонам.
Обратная связь: регулярная обратная связь и оценка продукта, чтобы улучшать его качество и соответствие требованиям.
Коммуникация: активное и открытое общение между всеми участниками проекта для обмена информацией и идей.
Простота: стремление к простому и понятному решению, избегая излишней сложности.
Lean
Lean – в переводе с английского «худой», «тощий», «скудный», в теории управления обычно используются такие значения, как «бережливый» и «экономный». Идеи бережливой концепции впервые были озвучены Тайити Оно, японским инженером, занимавшимся организацией производственной системы концерна Тойота в 1950-х годах. При этом сама концепция родилась на основе огромного количества выжимок и исследований советского опыта индустриализации. Что интересно, опыт японских корпораций позже исследовали уже конкуренты из США. И именно они ввели в обиход термин «Lean production» Сейчас lean-концепции активно применяются не только в промышленности, но и в других отраслях – от медицины до IT и проектов. Как раз о lean-принципах в проектном управлении и поговорим ниже.
Производительная и эффективная команда
Высокий дух команды, который поощряется Lean, – это не только о радугах и бабочках. Это также предвестник повышенной производительности и эффективности. Счастливые и мотивированные члены команды работают усерднее и быстрее, и им это нравится.
Повышенная мораль команды
В стремлении к бесконечному улучшению, сотрудники должны иметь возможность участвовать в процессах. С помощью Lean, они становятся активными участниками, что ведет к повышению морали. Это, в свою очередь, ведет к более преданным сотрудникам и качественной продукции.
Бесконечное совершенствование
Нет ничего хуже стагнации, кроме, конечно, упадка. Lean, с его акцентом на устранение потерь, внедряет культуру бесконечного улучшения, ориентированную на клиентов. Когда вы расшифровываете их потребности, становится возможным повышать ценность продуктов и доработать предложения для их удовлетворения.
Снижение количества ошибок в производстве
Каждый этап производства – это потенциальная ошибка. Поскольку Lean стремится устранить бесполезные этапы, количество ошибок сокращается. В результате – высококачественная продукция, которой рады ваши клиенты.
Применение “pull” стратегии вместо “push”
Вспоминая пример с салатом, “push” стратегия предполагает покупку большего количества салата, чем нужно. Согласитесь, это расточительство. В рамках Lean, уделяется внимание производству того, что реально нужно клиентам. Итог – меньше непроданного товара и больше денежных средств.
Улучшение взаимодействия с клиентами
Клиенты ценят внимание и желают быть услышанными. Lean способствует такому общению с клиентами, учитывая, что они формируют ценности. Этот диалог помогает вычленить избыточные процессы и настроить работу под конкретного клиента.
Сокращение издержек
Избегая потерь, вы сокращаете затраты. Влияние на некоторые факторы, как стоимость сырья, ограничено. Однако отказ от лишних этапов – залог сокращения расходов. Это, в свою очередь, увеличивает прибыль.
Риск избыточной структуризации
Lean предполагает разбиение процессов на отдельные части и устранение ненужных звеньев. Менеджеры, не привыкшие к Lean, могут переусердствовать, вводя слишком много стадий в процесс. Результат – избыточная структуризация, которая может увеличить потери, что противоречит философии Lean.
Начальные затраты
Для компаний, только осваивающих Lean, сопряжено с заменой программного обеспечения, оборудования и обучением персонала. Начальные затраты могут быть высокими, но экономия от устранения потерь со временем сможет компенсировать эти затраты.
Проблемы с переходом
Как и при любом крупном изменении, переход к принципам Lean может занять время и изначально привести к ошибкам. Сотрудники, которые не привыкли к Lean, могут не уделять достаточно внимания процессам, чтобы быстро определить и устранить потери. А сотрудники, которые долго работали по-другому, могут упорствовать и оставаться привязанными к старым методам.
Проблемы со складскими запасами
Lean идеология придает первостепенное значение устранению потерь, создавая сложный баланс между своевременным заказом у поставщиков и получением только необходимого количества товаров. Из-за этого, любая задержка поставки может привести к дефициту на складе, так как у вас нет готовых запасов, как у компаний, работающих не по принципам Lean
Упрощение
Эффективные коммуникации и сотрудничество
Применение системного мышления
Создание знаний и непрерывное совершенствование
Создание ценности и устранение потерь
Служение людям (имеются ввиду все стейкхолдеры проекта)
Scrumban
Методология Scrumban объединяет лучшие возможности Scrum и Kanban, создавая гибридную систему управления проектами. От Scrum в этом подходе используется стабильная структура спринтов, стендапов и ретроспектив. Она дополняется возможностями Kanban, обеспечивающими наглядное представление процессов и лимиты незавершенной работы. В результате команда получает действительно гибкий метод управления проектами любого размера. Изначально инструмент Scrumban применялся для того, чтобы команды могли легко переключаться между Scrum и Kanban, но теперь это развитая система, позволяющая справляться со сложными и длительными проектами. Он гибок, характеризуется гибридным подходом и предоставляет командам широкий спектр agile-инструментов.
Способность реализовывать крупные проекты
Поскольку суть Scrum и Kanban заключается в постоянном и постепенном улучшении, Scrumban позволяет командам работать над самыми сложными проектами.
Ускоренное решение задач
Размещение карточек на доске обеспечивает прозрачность, необходимую командам Scrumban для улучшения совместной работы и оперативного решения выявленных проблем.
Снижение нагрузки
Ограничение выполняемой работы в соответствии с возможностями команды позволяет продвигаться к цели без эмоционального выгорания
Непрерывная поставка
Работа представлена на доске, а процесс непрерывен, что позволяет командам поставлять функции по мере их завершения, не дожидаясь окончания спринта.
Повышенная гибкость
В Scrumban промежуточный продукт поставляется после каждого спринта. Такой подход позволяет вносить изменения в проект даже после его начала. При этом они не препятствуют прогрессу в реализации проекта.
Сложность
Использование элементов двух методологий может сбить с толку участников команды, которые пользовались не Agile, а другой системой.
Меньше контроля
Поскольку в Scrumban нет традиционных scrum-ролей, участники команды самостоятельно управляют спринтами. Отсутствие конкретного руководителя может привести к путанице в распределении обязанностей.
Неоднозначность
Scrumban — относительно новый подход, поэтому сведений по его реализации не так много. В связи с этим могут возникнуть трудности с поиском рекомендаций или передовой практики.
Компоненты Kanban
Ограничение выполняемой работы
Карточки
Компоненты Scrum
Ретроспективы
Ежедневные стендапы
Спринты
Kanban
Первоначально Kanban — это система организации работы на производстве, которая появилась в конце 50-х годов в Японии. Мастера, ответственные за разные этапы производства, крепили на общую доску карточки с работами, которые нужно было выполнить. Сейчас, говоря о Kanban, чаще подразумевают гибкую методологию для управления задачами в IT-сфере, например, в командах разработки, службы поддержки, производства контента.
обеспечение качества
быстрое понимание узких мест системы
визуализация потока предоставления ценности (визуализация всех этапов разработки продукта от грустного клиента к довольному)
рушит российский менталитет ТК РФ (человек быть не загружен на 100%, то есть не все восемь часов сотрудник должен что-то делать)
большой уровень гибкости, можно уйти не туда
Kanban-доска
KANBAN – ДОСКА это визуальное представление предстоящей и проделанной работы
Kanban - доска виртуальная
Kanban - доска в жизни
SCRUM
Scrum — это фреймворк для разработки проектов, который помогает командам правильно приоритизировать задачи и работу над продуктом. Его основа — итеративная разработка и получение регулярной обратной связи от заказчиков и пользователей.
подходит для всего (продукты, услуги, сервисы)
легко масштабируется
легко адаптировать продукт к рынку
самоорганизованные команды
работающий улучшенный продукт после каждой итерации
плохо подходит для больших команд (более десяти человек)
если заранее известны все требования продукта — нецелесообразно
требует дополнительной роли Scrum-мастера
страх руководителей отпустить вожжи
требуется экспертиза в команде
Основные артефакты в Scrum
Инкремент продукта
– сумма завершенных во время спринта задач и всех инкрементов предыдущих спринтов. То есть, это текущее состояние разрабатываемого продукта
Бэклог спринта
– это набор задач на ближайший спринт. В Бэклоге спринта формулируется цель спринта и план по достижению этой цели
Бэклог продукта
– список всех элементов продукта, требований к ним и любой связанной с продуктом информации. Бэклог продукта может дополняться, детализироваться или сокращаться на всем протяжении проекта .
Основные роли в Scrum
Скрам-мастер
Отвечает за эффективность работы в команде
Разработчики
Владелец продукта
Отвечает за видение и успех продукта, формирует бэклог
Спринт - это шаг жизненного цикла проекта
РЕЗУЛЬТАТ СПРИНТА: MVP (minimum viable product) - продукт, обладающий минимальными полезными функциями, но уже достаточными для того, чтобы получить от пользователей обратную связь. В следующем спринте процесс повторяется.
сложность подсчёта итоговой суммы работы
философский характер методологии Agile
повышенные требования к квалификации и опыту команды
стимулирование постоянных изменений проекта
минимизация рисков благодаря гибкой системе внесения изменений
во главе угла стоит рабочий продукт как основной показатель прогресса
высокая степень вовлечения исполнителей, организаторов и заказчиков проекта
короткие и понятные итерации
готовность к изменениям важнее следования первоначальному плану
сотрудничество с заказчиком важнее согласований условий контракта
работающий продукт важнее документации
люди и их взаимодействие важнее процессов и инструментов
Недостатки
повышенный риск
инерционность
«стойкость» к изменениям
лишенный гибкости процесс
Преимущества
оценка стоимости и сроков сдачи проекта
стабильность задач
удобная отчётность
простая структура процесса разработки
Принципы
заказчик не привлекается к непосредственному процессу разработки
фиксированная стоимость продукта проекта
переход к новому этапу — только после успешного завершения предыдущего
жёсткая последовательность этапов разработки
