Эджайл что: Что такое agile? | Atlassian — Независимое театральное объединение "Зрительские симпатии"

Содержание

Что такое agile, scrum, kanban и в чем разница?

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.

Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
(Из перевода колонки Forbes на Rusbase)

Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка.

На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский Директор по технологии в онлайн-кинотеатре ivi

Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей. Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им.

Г.В. Плеханова

Что почитать по теме?

Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
Дж. Сазерленд «Scrum. Революционный метод управления проектами»
Д. Андерсон «Канбан. Альтернативный путь в Agile»
Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
K. Schwaber, J. Sutherland “The Scrum Guide”
M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Cover photo by Daria Nepriakhina on Unsplash

Что такое agile. Объясняем простыми словами — Секрет фирмы

Процесс работы «по эджайлу» делится на итерации — короткие циклы по две-три недели. Каждый цикл решает серию задач. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, готовая к самостоятельному запуску.

Как правило, в agile-командах менеджеры, разработчики, дизайнеры, тестировщики и другие участники равноценны в иерархии и работают в одном пространстве. Вся команда регулярно получает обратную связь от заинтересованных сторон — пользователей, заказчиков, спонсоров и т. д. В команде есть специально выделенная роль — product owner, который фокусируется на ценности продукта, для клиентов, рынка и заказчиков, приоритизирует задачи и принимает решение, какой функционал необходим в первую очередь.

Agile-подходы используют разработчики Google, Netflix, Spotify и других компаний. В России об «agile-трансформации» объявил «Сбер».

В последнее время сфера использования agile расширилась и вышла за пределы IT. Теперь методику использует, например, компания Saab для производства новых истребителей.

Пример употребления на «Секрете»:

«Не работают жёсткие иерархии, изменения происходят слишком быстро, и от скорости зависит размер убытков. Работают гибкие agile-структуры и самоорганизованные команды, которым делегированы полномочия».

(Директор Школы новой экономики MACS Юрий Филатов — о трансформации бизнеса.)

Нюансы

Термином Agile называют и систему подходов к разработке, и целую философию, которая базируется на четырёх главных ценностях:

Люди и их взаимодействие важнее процессов и инструментов.
Работающий продукт важнее документации и отчётности.
Сотрудничество с заказчиком важнее соблюдения формальных условий.
Готовность к изменениям важнее, чем следование плану.

Факт

Agile-манифест написала группа энтузиастов-программистов в 2001 году. Сегодня это главный документ всех «гибких» разработчиков.

Статью проверила:

Итак, вы внедрили Agile: что теперь?

Опубликовано: 2021-09-04

mary1826 / Pixabay

Вы, наконец, взяли на себя обязательство внедрить гибкую методологию в своей компании. Что теперь?

Некоторые компании могут обнаружить, что они слабо следуют Agile, что приводит к менее эффективным результатам и разочарованию. Другие компании могут вернуться к своему старому способу управления проектами и развития.

Подумайте, хотите ли вы потратить месяцы на создание видеомагнитофона, когда рынок покупает Smart TV? Возможно нет. Вот почему вам нужно и нужно, чтобы Agile работал после того, как вы его внедрили. Вы не хотите тратить время и деньги на создание чего-то, что никому не нужно.

Итак, что вы и ваша команда можете сделать, чтобы Agile сохранилась после процесса внедрения? Давайте вникнем в это.

Какие системы нужно сразу ввести в действие?

После внедрения гибкой разработки обязательно учтите следующие четыре вещи:

Будь строгим

Старайтесь не отклоняться от основы Agile. Стремитесь стать экспертом на каком бы этапе вы ни находились, прежде чем переходить к следующему этапу. Знайте, что у Scrum есть множество этапов, поэтому вы определенно можете развиваться и адаптироваться к новым методам, но сделайте все возможное, чтобы освоиться, прежде чем переходить на более продвинутый уровень.

Решение для жизнеспособных показателей

Трудно добиться успеха без применения метрик в управлении проектами. Однако важно отметить, что метрики Agile больше ориентированы на желания и потребности клиента, а не на измерение того, что делает ваша команда. Ваша команда может захотеть рассмотреть три различных типа показателей:

Канбан-метрики:

Эта метрика фокусируется на том, как вы организуете свой рабочий процесс в целом. Что вы хотите больше всего ценить? Какая задача должна быть первой?

Бережливые показатели:

Используя бережливые метрики, вы уделяете больше внимания циклу и времени выполнения заказа. Вы постараетесь избавиться от бесполезных занятий, отнимающих время.

Здесь вас просят сосредоточиться на оценке того, когда вы доставите свой продукт клиентам.

Постоянное общение

Чтобы Agile работал, вам необходимо сотрудничать и общаться со всеми, от руководителей компании до клиентов. Убедитесь, что все верят в систему.

Генеральный директор Agile Worx и автор Metagility д-р Дэвид А. Бишоп говорит: «Руководители компании должны публично и постоянно выражать свою поддержку и участие в процессе. Поддержка на уровне руководства критически важна ».

Еще один аспект общения? Убедитесь, что все знают и понимают свою роль! Люди хотят чувствовать себя ключевым элементом процесса.

Кроме того, важно помнить, что общение с клиентами в процессе создания продукта является важной частью Agile. Постоянное общение с клиентами позволяет вам раскрывать свою работу небольшими партиями и вносить коррективы по ходу дела, что намного лучше, чем месяцы работы над проектом, который им даже не нравится.

Система управления требованиями

Тот факт, что Agile обеспечивает гибкость, не означает, что вы можете придерживаться вялого графика разработки продукта.

Некоторые компании считают, что вам не нужно оценивать, когда проект завершится после того, как вы внедрили Agile, но это не так. По-прежнему важно оценить, когда вы закончите более мелкие задачи в рамках всего проекта. Если вы не выполнили задачу к запланированной дате, потратьте некоторое время на разбиение проекта на более мелкие сегменты.

Не забывайте всегда стремиться выполнять задачи с наибольшей ценностью в первую очередь!

Что нужно для поддержания гибкой культуры?

Бишоп говорит: «Если культура Agile не поддерживается, это происходит потому, что команды не чувствуют себя комфортно с ней, что обычно происходит из-за непонимания». Что вы можете сделать, чтобы ваше рабочее место понимало Agile?

Чтобы Agile работал, все должны быть на одной волне. Вы не можете просто отправить своих сотрудников на мастер-класс по Scrum и надеяться, что он научит их всему, что им нужно знать.

Что ты можешь сделать? Ваша команда должна работать вместе, чтобы убедиться, что все понимают новую методологию. Просто помните, что большая часть Agile — это сотрудничество и общение, поэтому нет ничего плохого в том, чтобы практиковать эти две особенности в процессе реализации.

Обязательно уточните у своих сотрудников, что они знают основы и основы Agile, прежде чем двигаться дальше.

Что вам нужно сделать, чтобы найти фирму, которая помогает Agile придерживаться?

Перво-наперво — важно нанять подходящую консалтинговую фирму, которая поможет вам перейти на Agile. Вы хотите нанять специалистов известной и надежной компании. Попробуйте найти партнеров, которые проведут собственное исследование и сочинят жизнеспособные статьи. Настоящие специалисты будут постоянно публиковать статьи и рассказывать о своем деле. У вас может возникнуть соблазн нанять крупную фирму с известным логотипом, но они могут не уделить вам должного внимания или предоставить вам эффективный план, как это могла бы сделать небольшая компания.

Чаще всего крупные фирмы предоставляют вам список рекомендаций, а не разметку фактического плана по внедрению Agile. Имейте в виду, что с помощью Agile цель состоит в том, чтобы приносить реальную пользу вашим клиентам, общаясь и работая вместе в команде. Поэтому после того, как вы правильно внедрили Agile, вы должны стремиться к тому, чтобы все были в курсе — чтобы все понимали новую методологию.

Как скоро вы заметите разницу после внедрения Agile?

Вы заметите различия почти сразу — начиная с улучшения командной динамики. Agile позволяет каждому почувствовать себя более вовлеченным в процесс создания продукта, помогая повысить моральный дух команды. Если ваши сотрудники будут больше походить на роботов, чем на людей, желание добиться успеха исчезнет. Agile способствует обратному эффекту.

В целом вы заметите, что продукты или функции будут доступны в течение недель, а не месяцев. Помните, что эта методология возникла при разработке программного обеспечения, в которой следовали принципам, позволяющим командам работать над несколькими проектами одновременно. В результате команды разработчиков программного обеспечения могли выпускать продукты на рынок по эффективной ставке. И теперь эта методология адаптирована к различным рынкам.

Поэтому после внедрения Agile вы должны заметить сдвиг в том, как ваша команда взаимодействует друг с другом и с клиентом. После того, как вы приняли Agile, вам нужно убедиться, что он работает — вам нужно нанять подходящую фирму и уделить время, чтобы убедиться, что ваша команда понимает, верит и любит новую методологию. В результате вы обнаружите, что ваша продуктивность возрастет, что позволит вам оставаться впереди конкурентов.

Agile и DevOps: преимущества, совместное использование, сравнение

02.12.2020

Владимир Осокин

Появление первой модели процесса разработки программного обеспечения датируется 1970 годом. Методология waterfall (каскадная модель, «водопад») опиралась на линейные механики, игнорировала интуитивный подход к разработке и внесение изменений, а финальные ошибки и баги было сложно исправлять. Еще один камень в огород waterfall — незадействованный в проекте заказчик, который получал доступ к ПО только в финале. На выходе часто разворачивался совсем не тот продукт, который был нужен для решения проблемы заказчика.

На замену waterfall пришла методология Agile («гибкая разработка»). Ее официальная история начинается «Манифестом гибкой разработки программного обеспечения» в 2001 году в США. Популярность разработки по Agile способствовала развитию практик DevOps (DEVelopment OPeration). В этой статье мы расскажем об Agile и DevOps, сравним методологии и рассмотрим, как они работают вместе.

Немного об Agile

Гибкая методология разработки Agile — это итеративный подход к управлению проектами и разработке ПО. Команда выдает работу небольшими частями, спринтами — так Agile помогает исполнителям быстрее и качественнее выполнять свою работу. Требования, планы и результаты постоянно оцениваются, поэтому команда быстро реагирует на изменения.

Методология Agile опирается на 12 принципов:

В приоритете — потребности клиента.
Изменения приветствуются и вносятся на всех этапах разработки.
Регулярная поставка работающего ПО.
Заказчик — часть команды.
В команде — только заинтересованные, замотивированные специалисты.
Общение, обсуждение по ходу проекта должно быть ежедневными.
Работающее ПО — лучший индикатор прогресса.
Agile-процессы способствуют устойчивому развитию.
Работать над техническим совершенством и дизайном.
Не усложнять процессы.
Инновационные решения и идеи появляются у команд, которые способны к самоорганизации.
Команда регулярно обдумывает варианты повышения своей эффективности, и по итогу вносит правки в рабочий процесс.

Поскольку заказчик привлечен к проекту, команда может оперативно реагировать на правки, изменения и в финале выдать необходимое решение. Agile-проект не опирается на документацию и приветствует изменения, поэтому финальное решение может превосходить изначальные запросы и ожидания. Методология подразумевает, что пока ПО находится в стадии разработки, команда может показать заказчику MVP (минимально жизнеспособный продукт).

Немного о DevOps

DevOps — это методология, которая помогает наладить взаимодействие программистов и системных администраторов в команде. Как результат, специалисты начинают понимать, в чем суть работы друг друга, и это позволяет ускорить выпуск программного продукта. DevOps в процессе разработки ПО сокращает количество шагов, которые необходимы для вывода продукта на рынок. Более быстрые релизы и оптимизированные процессы способствуют получению быстрой обратной связи от пользователей. Также один из столпов DevOps — автоматизация процессов.

Принципы DevOps:

Принцип потока — ускорить доставку продукта от разработчиков к отделу эксплуатации.
Принцип обратной связи — своевременно реагировать на запросы.
Принцип перманентного обучения — создать благоприятные условия для организации высокой культуры производства; учитывать риски как составляющую ежедневной работы и минимизировать их.

Что касается применения. Если заказчику нужен MVP, чтобы, например, протестировать идею, без DevOps можно обойтись. Методология заточена под налаживание бизнес-процессов и ускорение выхода обновлений.

Методология DevOps помогает командам более оперативно принимать решения, которые касаются разработки приложений, сократить количество ошибок и багов в ПО, а также мотивирует сотрудников учиться новому.

Agile и DevOps — чем отличаются

Agile и DevOps — гибкие методологии разработки программных продуктов. Оба подхода способствуют быстрой разработке ПО без нанесения вреда клиенту или программным операциям. Что касается различий:

Чистый Agile предполагает, что после разработки, тестирования и развертывания программного обеспечения команда выполнила свою работу и может завершить процесс. А для DevOps характерны операции, которые не заканчиваются после сдачи проекта (мониторинг, модификации ПО).
В Agile за разработку, тестирование и развертывание программного обеспечения отвечают обычно разные специалисты. А в DevOps инженер отвечает за все: разработка, инфраструктура, координация.
Если Agile — это эмпирический подход (адаптация, прозрачность, тестирование — всё это в процессе), то для DevOps нужен хотя бы приблизительный прогноз конечного результата.

Методологии разные, но не взаимоисключающие. DevOps — это культура, которая ведет к совместной работе всех вовлеченных участников команды (разработчики, системные администраторы). В свою очередь Agile — поддержание производительности и обеспечение выпуска ПО с учетом новых запросов.

Через совместное применение Agile и DevOps можно добиться максимальной эффективности при разработке, выпуске и обновлении ПО.

Совместное применение Agile и DevOps

Говоря о неоспоримых преимуществах DevOps, мы не можем оставить без внимания, что система нацелена на проект в целом, а это может привести к слишком поверхностному взгляду на процессы, в отличие от Agile. Что касается Agile, система будто открещивается от проекта после его сдачи: страдает развертывание и автоматизация работы.

Чтобы нивелировать эти недостатки систем, можно совместить Agile и DevOps — динамичные спринты и интегрированную командную работу соответственно. По такой схеме постепенно получится оптимизировать жизненный цикл разработки и обслуживания продукта. Получится исправить дисбаланс без влияния на процессы, которые происходят во время непрерывной фазы развития.

Интеграция DevOps и Agile помогает при следующих задачах:

Упростить процесс выпуска и улучшения программных продуктов.
Повысить качество сотрудничества команд.
Повысить ценность спринтов, минимизировать риски.
Уменьшить количество ошибок, получить оперативное исправление багов.
Получить высокие показатели удовлетворенности пользователей.
Иметь представление о «видимости» проекта (возможность оценить будущие результаты, быть уверенными в прогнозах).

На что обратить внимание при интеграции DevOps и Agile

Посмотрим на «подводные камни», которые могут возникнуть во время внедрения DevOps в Agile и узнаем, как их избежать.

1. С внедрением DevOps команде достается больше оперативной работы в течение всего жизненного цикла — не только на этапе тестирования, развертывания и автоматизации. Поэтому будет оптимально, если внедрение принципов начнется в начале разработки.

2. Чтобы интеграция Agile-спринтов в DevOps прошла успешно, нужно следовать следующим рекомендациям:

Приглашать на обсуждения оперативный персонал, администраторов, инженеров, которые отвечают за инфраструктуру.
Обсуждать функциональные возможности продукта и его эксплуатационные характеристики. Включать это в актуальный спринт.
Вовлечь команду DevOps в ежедневные совещания, согласование планов и т. д.

3. Нужно внедрить QA (управление качеством продукта) на каждом этапе жизненного цикла разработки. Помимо функционального тестирования, которое применяется в Agile, подход DevOps требует тестирования производительности и нагрузки ПО. Постоянное тестирование так же важно, как и непрерывное развитие.

Итог

DevOps и Agile могут работать как независимо друг от друга, решая каждая свой спектр задач, так и вместе, чтобы получить больше профита. Одно из оптимальных решений, которое поможет выжать максимум пользы из обеих методологий, — услуга Managed DevOps.

Использование артефактов шаблона процесса Agile — Azure Boards

11/12/2021
Чтение занимает 9 мин

Были ли сведения на этой странице полезными?

Please rate your experience

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

В этой статье

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013

Гибкий процесс поддерживает следующие типы рабочих элементов (WIT) для планирования и наблюдения за работой, тестами, отзывами и проверкой кода. С разными Witами можно отвести различные типы работы, такие как функции, пользовательские истории и задачи. Эти артефакты создаются при создании проекта с помощью гибкого процесса. Они основаны на принципах и значениях Agile.

Наряду с WIT, группы имеют доступ к набору запросов рабочих элементов для отслеживания информации, анализа хода выполнения и принятия решений.

Примечание

Вы можете настроить систему отслеживания работы для проекта, создав и настроив наследуемый процесс и применяя этот процесс к проекту. Дополнительные сведения см. в разделе модель процесса наследования.

Примечание

Вы можете настроить систему отслеживания работы для проекта, настроив наследуемый процесс или локальный XML-процесс. Дополнительные сведения см. в разделе модель процесса наследования или Настройка локального процесса XML.

Последняя версия каждого процесса загружается автоматически при установке или обновлении до последней версии Azure DevOps Server. дополнительные артефакты, такие как SQL Server отчеты, доступны только при подключении к проекту. Применяются другие требования к ресурсам.

Примечание

Вы можете настроить систему отслеживания работы для проекта, настроив локальный XML-процесс. Дополнительные сведения см. в статье Настройка локального процесса XML.

Примечание

Последняя версия каждого процесса загружается автоматически при установке или обновлении до последней версии Azure DevOps Server. дополнительные артефакты, такие как SQL Server отчеты и панели мониторинга SharePoint, доступны только при подключении к проекту. Применяются другие требования к ресурсам.

Следующие WIT доступны следующим образом: «История», TFS 2015 и более поздних версий. Общие параметры, TFS 2013,2 и более поздние версии; и план тестирования и набор тестов, TFS 2013,3 и более поздние версии.

Планирование и отслеживание работы с помощью Agile

Вы создаете план проекта путем создания невыполненной работы пользовательских историй, представляющих работу, которую вы хотите разрабатывать и поставлять. Вы следите за ошибками, задачами и проблемами блокировки с помощью WIT ошибок, задач и проблем. Для поддержки управления портфелем команды создают функции и ситуаций для просмотра свертки пользовательских историй в группах или между ними. Дополнительные сведения об использовании Agile WIT см. в статье рабочие элементы рабочих элементов и рабочий процесс Agile.

Ниже показана основная последовательность для начала работы. Чтобы приступить к использованию методологии Scrum или канбана, см. статью Приступая к работе с гибкими инструментами для планирования и мониторинга работы.

Щелкните один из следующих образов, чтобы открыть связанную статью.

Примечание

Рабочий элемент — это запись базы данных, которая содержит определение, назначение, приоритет и состояние работы. Типы рабочих элементов определяют шаблоны полей, рабочих процессов и форму для каждого типа. Рабочие элементы можно связать друг с другом, чтобы поддерживать отслеживание зависимостей, сведение работ и отчеты.

Вывод списка рабочих элементов с помощью запросов

Вы можете более эффективно управлять рабочей нагрузкой, часто изучая состояние пользовательских историй и задач. С помощью запросов общих рабочих элементов можно получить список рабочих элементов для текущего спринта или невыполненной работы по продукту.

Примечание

Новые проекты больше не определяют набор общих запросов по умолчанию во время создания проекта. Определения общих запросов были удалены из шаблона процесса. Для локальных развертываний их можно добавить в пользовательский шаблон процесса, как описано в разделе Добавление запросов рабочих элементов в шаблон процесса.

Вы можете просматривать и запускать запросы с веб-портала или из подключаемого модуля Team Explorer для Visual Studio. Можно изменить запрос с помощью редактора запросов, чтобы применить другие условия фильтра. Кроме того, можно добавлять запросы на панели мониторинга команды.

Краткие советы по общим запросам

если вы не знакомы с Azure Boards, отслеживанием работы и общими запросами, ознакомьтесь со следующими советами, чтобы узнать, как можно более эффективно управлять работой.

Чтобы найти назначенные вам рабочие элементы, добавьте @Me в качестве значения поля Кому назначено в одном из предложений запроса.
Все допустимые пользователи со стандартным доступом могут создавать запросы и папки в области Мои запросы . Чтобы создать запросы и папки запросов в общих запросах, необходимо иметь набор разрешений «участие» и назначить им базовый доступ или более высокий. Дополнительные сведения см. в разделе Set permissions on Queries.
Можно изменить любой запрос, добавив критерии для фокусировки области продукта, итерации или другого поля. Чтобы изменить запрос, откройте редактор запросов.
можно открыть любой запрос в Excel , где можно обновить поля одного или нескольких рабочих элементов и опубликовать изменения в базе данных для отслеживания рабочих элементов.
Вы можете визуализировать состояние или ход выполнения , создав круговую диаграмму, гистограмму или диаграмму тренда для запросов с неструктурированными списками.

Важно!

начиная с Visual Studio 2019, подключаемый модуль Azure DevOps для Office имеет депрекатедсуппорт для Microsoft Project. интеграция Project и команда TFSFieldMapping не поддерживается для Azure DevOps Server 2019 и более поздних версий, включая Azure DevOps Services. Вы можете продолжить использовать Microsoft Excel.

Отслеживание хода выполнения

Все процессы — Agile, Scrum и CMMI — поддерживают Создание диаграмм состояния и тенденций и панелей мониторинга. Кроме того, на основе используемых гибких инструментов автоматически создаются несколько диаграмм. Эти диаграммы отображаются на веб-портале.

Создание неплотных диаграмм

Чтобы приступить к работе, можно определить общий плоский запрос и создать диаграмму на основе ваших интересов по отслеживанию. К типам диаграмм относятся сведения о состоянии — круговые, линейчатые, столбцы, линейчатые с накоплением, Сводная диаграмма и тенденция — диаграммы с накоплением, графику и областью.

отчеты SQL Server

если коллекция проектов и проект настроены с помощью SQL Server Analysis Services и Reporting Services, вы получите доступ к многим гибким отчетам. Чтобы эти отчеты были полезными, команды должны выполнить определенные действия, например определить процессы сборки, связать рабочие элементы и состояние обновления или оставшуюся работу.

Если необходимо добавить службы Reporting Services или отчеты об обновлениях в последние версии, см. раздел Добавление отчетов в проект.

панели мониторинга SharePoint портала

Вы можете получить доступ к панелям мониторинга гибких процессов, отображаемым с помощью SharePoint. Эти панели мониторинга отображают данные проекта, поддерживают задачи расследования и помогают группам быстро выполнять распространенные задачи. Эти панели мониторинга поддерживают отображение частей веб-доступа для перечисления рабочих элементов и отчетов, созданных в Analysis Servicesном Кубе.

чтобы использовать панели мониторинга SharePoint, в проекте должен быть настроен портал проекта, и портал проекта должен указывать на сайт SharePoint.

Локальная версия	Имя процесса Agile	Основной номер версии
Azure DevOps Server 2020 Azure DevOps Server 2019	Гибкая методика	17
TFS 2018	Гибкая методика	16
TFS 2017	Гибкая методика	15
TFS 2015	Гибкая методика	7
TFS 2013	MSF for Agile Software Development	7
TFS 2012	MSF for Agile Software Development 6,0	6
TFS 2008	MSF for Agile Software Development-v4. n

7 техник из Agile, которые помогут вам работать эффективнее – BYYD

Agile, или Гибкая методология разработки, — это свод техник и практик, которые нацелены на то, чтобы ускорить работу команды и сделать ее эффективнее. Почти все техники сводятся к тому, чтобы разбить большой объем работы на несколько подзадач или этапов (итераций). Согласно отчету VersionOne, 94% организаций из сферы разработки программного обеспечения придерживаются Agile. В этой статье дадим 7 техник, которые вы можете взять на вооружение для оптимизации работы своей команды.

1. Итеративное планирование

Ключом к повышению гибкости Agile является итеративный подход к планированию. По существу, это означает, что вместо того чтобы создавать всеобъемлющий план в самом начале проекта (когда понимание того, что вообще нужно сделать, находится на самом низком уровне), планирование происходит непрерывно, через процесс постоянного контроля и адаптации. Это позволяет проекту меняться и развиваться по мере роста понимания и появления дополнительных деталей и требований, а также подстраиваться под текущие рыночные условия, заинтересованные стороны и обратную связь с пользователями.

В контексте маркетинга существует несколько инициатив, которые выигрывают от итеративного планирования. Например, включив регулярные аналитические обзоры в текущую рекламную кампанию, вы сможете быстро отказаться от действий, которые не приносят результатов, и вместо этого реинвестировать средства в более продуктивные области. Вы также можете применить гибкий подход к предстоящему запуску продукта, анализируя приоритетность задач по мере появления новых требований.

2. Итеративное выполнение задач

Как и в случае планирования, подход в Agile к выполнению задач также является итеративным и фокусируется на завершении отдельных функций и задач — причем эти функции и задачи должны быть направлены на то, чтобы продуктом можно было пользоваться в любой момент, пусть и не в полном объеме. Есть также понятие минимально жизнеспособного продукта (MVP), которое тоже можно включить в этот пункт. Однако различные гибкие методологии предлагают разные типы итеративного выполнения задач. Чтобы решить, какой лучше всего подходит вам, оцените требования вашей компании и отрасли.

Так, например, если использовать подход Scrum, то работа должна выполняться в течение коротких стадий, известных как «спринты». Обычно в течение двух недель рабочие функции представляются и демонстрируются заинтересованным сторонам в конце каждого спринта, чтобы ускорить цикл обратной связи, свести к минимуму потери инвестиций и обеспечить больший контроль над бюджетом.

В рамках Канбана, напротив, составляется приоритетный список задач, чтобы гарантировать, что наиболее ценные элементы будут выполнены первыми, а узкие места будут выявлены и устранены на ранней стадии.

Также можно воспользоваться гибридной моделью, которая сочетает в себе эти два подхода — выбирая конкретные аспекты из каждого, чтобы создать что-то, что адаптировано к вашим потребностям.

3. Пользовательские истории

Пользовательские истории, хоть и не относятся исключительно к гибкой методологии, согласуются с ее принципами и могут помочь максимизировать ценность, получаемую с помощью ваших проектов.

Пользовательские истории формулируются по следующей модели: «Как [пользователь], я хочу [задача] для того, чтобы [мотивация]». Эта модель подразумевает, что требования выражаются прямо и соответствуют тому, что действительно хочет пользователь, а также такая модель упрощает передачу этих требований заинтересованным лицам в проекте и делает их понятными и простыми.

Формат можно корректировать. Пользовательские истории должны соответствовать следующим признакам:

Самостоятельность
Возможность обсуждения
Ценность
Возможность оценки
Небольшой объем
Возможность тестирования

4. Оценка и определение приоритетов

Разбивка ваших требований на четкие, содержательные пользовательские истории (или аналогичные задачи) значительно облегчит оценку усилий, необходимых для выполнения каждой задачи; а также поможет в поддержке и оптимизации любых последующих действий по оценке. Кроме того, agile продвигает целый ряд методов, помогающих гарантировать точность оценок, «Покер планирования» — одна из них.

Покер планирования — это гибкая методика оценки, основанная на договоренностях и консенсусе. Чтобы начать сеанс покера планирования, владелец продукта или клиент читает пользовательскую историю и описывает ее функцию оценщикам. Каждый оценщик держит в руках колоду карт со значениями 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Эти значения представляют собой количество дней или других единиц измерения, в которых оценивается работа команды.

Оценщики обсуждают функцию, задавая вопросы владельцу продукта по мере необходимости. Когда обсуждение окончено, каждый оценщик в частном порядке выбирает одну карту для представления своей оценки. Затем все карты раскрываются одновременно.

Если все оценщики выбрали одно и то же значение, то оно становится оценкой. Если нет, то оценщики обсуждают свои оценки. Высокие и низкие оценки должны обсуждаться в особенности. После дальнейшего обсуждения каждый оценщик повторно выбирает оценочную карту, и все карты снова раскрываются одновременно.

Процесс покера планирования повторяется до тех пор, пока не будет достигнут консенсус или пока оценщики не решат, что гибкую оценку и планирование конкретного элемента необходимо отложить до получения дополнительной информации.

После оценки расставляются приоритеты в соответствии с ценностями бизнеса, которые определяются конкретными целями и задачами. Однако, в соответствии с философией Agile, нужно регулярно просматривать свой список приоритетов по мере продвижения проекта.

Это позволит оценить успехи по приоритетным задачам и отстающие пункты и убедиться (или нет), что наиболее ценные функции работают и развиваются. Это также позволит вносить изменения в ответ на полученную обратную связь.

5. Демо, ретроспективы и стендапы

Возможность оценки прогресса членами команды и более широкой группой заинтересованных сторон — ключевые особенности Scrum. Для этого существуют демо, ретроспективы и стендапы.

Демо происходят в конце каждого спринта и вовлекают как основную проектную команду, так и заинтересованных в проекте сторон. Они дают возможность получить обратную связь, которую можно использовать в последующих итерациях. Также демо выступает в качестве контрольного пункта проекта.
Ретроспективы также происходят в конце каждого спринта, но сосредотачиваются уже не на результатах проекта, а на принципах работы и позволяют команде выделить области для улучшения.
Стендапы происходит ежедневно на протяжении всего спринта и нужны для того, чтобы команда делилась планами на день и достижениями прошедшего дня работы. Они нужны для оценки препятствий, с которыми может столкнуться команда, и для того, чтобы преодолеть их как можно быстрее и с лучшими результатами.

6. Коммуникация и сотрудничество

В то время как перечисленные выше методы, несомненно, представляют ценность для организаций как в рамках индустрии разработки программного обеспечения, так и за ее пределами, подлинное раскрытие силы Agile требует сдвигов в философии работы вашей команды или команд. Содействие эффективному сотрудничеству, в частности, является ключевым фактором, потому что способствуют поддержанию деятельности и соответствию этой деятельности целям компании.

Поэтому важно посмотреть, насколько хорошо ваша команда общается и работает вместе в настоящее время, и провести любые учебные мероприятия, чтобы убедиться, что у них есть понимание и навыки, необходимые для работы по гибкой методологии и работы вообще. Кроме того, такие инструменты, как системы мгновенного обмена сообщениями и решения для управления проектами, также могут поддерживать продуктивную коммуникацию.

7. Командные структуры и роли

Чтобы обеспечить максимально эффективное выполнение проектов, многие гибкие структуры рекомендуют ограничить размер основной команды до трех-шести человек; эта модель может помочь многим отраслям поддерживать фокус и скорость. Традиционно, конечно, эта «основная команда» относится к разработчикам, производящим веб- и программные решения, но может быть применена к чему угодно: от менеджеров продаж до контент-стратегов

Кроме того, как правило, существует несколько дополнительных функций, связанных с этой основной командой, которые может быть полезно ввести (вы даже можете назначить эти роли существующим членам команды, если они будут проинформированы о масштабах своих обязанностей):

Владелец продукта. Представляя голос пользователя, владелец продукта несет ответственность за обеспечение того, чтобы выполняемая работа приносила максимальную возможную пользу конечным пользователям, и поддерживает эту пользовательскую направленность на протяжении всего проекта.
Scrum Мастер. Это особенно актуально для спринтерских подходов, поскольку Scrum-мастера помогают оптимизировать производительность команды, устраняя те блоки, которые были выявлены в ежедневных стендапах, а также работая с другими заинтересованными сторонами, чтобы обеспечить надлежащую поддержку основной команды.

Однако наличие этих двух ролей не означает, что команда должна управляться на микроуровне. Цель должна состоять в том, чтобы создать команды, наделенные полномочиями брать на себя ответственность за задачи и принимать решения, сохраняя при этом непрерывную коммуникацию и сотрудничество, чтобы поддерживать проект в соответствии с вашими стратегическими целями.

Источник: smartinsights.com

Курсы и вебинары Agile Scrum/Product Owner в Специалисте

Главная > Курсы > IT-менеджмент ITIL/ITSM

IT-менеджмент

Почему Agile так популярен среди разработчиков и менеджеров продукта? Потому что Agile – это ускорение выпуска продукта на рынок, управление постоянно меняющимися приоритетами, уменьшение рисков, и многое-многое другое. Классические методы управления проектами (PMI) хороши для больших проектов и крупных компаний, но не всегда достаточно гибки и эффективны.

Так в IT-среде утвердилось управление проектами в стиле Agile — небольшие итерации, последовательное движение от одной задачи к другой, выпуск продукта с базовыми функциями и постепенное их дополнение.

Scrum — это фреймворк с методами Agile. Согласно методологии Agile, разработка производится в короткие отрезки времени небольшими проектными группами. Раз в 1-3 недели они выдают результат — новую рабочую версию ИТ-продукта. Гибкость подхода позволяет вносить изменения и правки на всех этапах развития проекта, причем корректироваться может и состав участников проектной команды, и даже сама цель проекта.

Вслед за передовыми зарубежными компаниями отечественный бизнес и госучреждения переходят на Agile:

«Все процессы должны быть перестроены. Те, кто не освоит Agile сегодня в текущих бизнес-процессах, будут лузерами завтра», — заявил президент Сбербанка Герман Греф на Гайдаровском форуме в 2016 году, рассказывая о планах по построению новой платформы банка.

«Специалист» — авторизованный учебный центр компании ScrumStudy, всемирной организации по аккредитации методологий Scrum и Agile. Наши преподаватели имеют все уровни сертификации и статус SCRUMstudy Certified Trainer (SCT) (аккредитованы ScrumStudy).
Обучение сотрудников в УЦ «Специалист» поможет руководителям отделов разработки, аналитикам и руководителям проектов быстрее внедрять новые продукты, оптимизировать затраченное время и ресурсы.

В условиях цифровой экономики большая часть жизненного цикла продуктов и услуг реализована в цифровом виде. На курсе «Обучение Product Owner (Владельца продукта). Как создать и продвигать успешные IT-продукты» Вы узнаете самые современные подходы по управлению полным циклом цифровых продуктов (digital), которые помогут Вам посредством организации их создания, вывода на рынок, продвижения, продаж, поддержки, развития и вывода с рынка достигнуть и поддерживать рост и развитие их успешности.

Yahoo News: «SCRUMstudy — уникальная возможность для профессионалов, которые хотят сделать следующий шаг в своей карьере и стать сертифицированными практиками Scrum, мастерами и экспертами.»

Сертификаты SCRUMstudy включают уровни:

Scrum Fundamentals Certified(SFC™)
Scrum Developer Certified (SDC™)
Scrum Master Certified (SMC™)
Agile Expert Certified (AEC™)
Scrum Product Owner Certified (SPOC™)
Expert Scrum Master Certified (ESMC™)

Изучите возможности SCRUM в «Специалисте» и выпускайте ваш продукт на рынок быстрее конкурентов!

Расписание по курсам agile Scrum/Product Owner

Заказ добавлен в Корзину.
Для завершения оформления, пожалуйста, перейдите в Корзину!

Главная > Курсы > IT-менеджмент ITIL/ITSM

Что такое AGILE? — Что такое SCRUM? — Agile FAQ’s

Три роли, определенные в Scrum, — это ScrumMaster, владелец продукта и команда (которая состоит из членов команды). Люди, выполняющие эти роли, ежедневно работают в тесном сотрудничестве, чтобы обеспечить бесперебойный поток информации и быстрое решение проблем.

Скрам-мастер

Скрам-мастер (иногда пишется «Скрам-мастер», хотя в официальном термине нет места после «Скрам») является хранителем процесса.Скрам-мастер отвечает за бесперебойную работу процесса, устранение препятствий, влияющих на производительность, а также за организацию и проведение важных встреч. В обязанности ScrumMasters входит

Научите владельца продукта, как максимизировать рентабельность инвестиций (ROI) и достичь его / ее целей с помощью Scrum.
Улучшите жизнь команды разработчиков, способствуя творчеству и расширению возможностей.
Повысьте продуктивность команды разработчиков любым возможным способом.
Усовершенствуйте инженерные практики и инструменты, чтобы каждый дополнительный функционал можно было отгрузить.
Держите информацию о прогрессе Команды в актуальном состоянии и видимой для всех сторон.

С практической точки зрения Скрам-мастер должен достаточно хорошо понимать Скрам, чтобы обучать и наставлять другие роли, а также обучать и помогать другим заинтересованным сторонам, участвующим в процессе. Скрам-мастер должен поддерживать постоянную осведомленность о статусе проекта (его прогрессе на сегодняшний день) относительно ожидаемого прогресса, исследовать и способствовать устранению любых препятствий, сдерживающих прогресс, и в целом быть достаточно гибким, чтобы выявлять и решать любые проблемы, которые возникают любым необходимым способом.Скрам-мастер должен защищать Команду от помех со стороны других людей, действуя как интерфейс между ними. Скрам-мастер не назначает задачи членам команды, так как назначение задач является обязанностью команды. Общий подход ScrumMaster к команде заключается в том, чтобы поощрять и облегчать их способность принимать решения и решать проблемы, чтобы они могли работать с большей эффективностью и уменьшая потребность в надзоре. Цель состоит в том, чтобы иметь команду, которая не только наделена полномочиями принимать важные решения, но и делает это хорошо и регулярно.

Загрузить шпаргалку по ролям Scrum Master

Владелец продукта

Владелец продукта отвечает за соблюдение требований. Владелец продукта обеспечивает «единый источник истины» для команды относительно требований и их запланированного порядка выполнения. На практике владелец продукта является связующим звеном между бизнесом, клиентами и их потребностями, связанными с продуктом, с одной стороны, и командой — с другой. Владелец продукта защищает команду от запросов функций и исправлений ошибок, которые поступают из многих источников, и является единственным контактным лицом по всем вопросам, касающимся требований к продукту.Владелец продукта работает в тесном сотрудничестве с командой для определения пользовательских и технических требований, документирования требований по мере необходимости и определения порядка их реализации. Владелец продукта ведет журнал отставания по продукту (который является хранилищем всей этой информации), поддерживая его в актуальном состоянии и на уровне детализации и качества, необходимом для команды. Владелец продукта также устанавливает график выпуска завершенной работы для клиентов и решает вопрос о том, обладают ли реализации функциями и качеством, необходимыми для выпуска.

Загрузить шпаргалку по роли владельца продукта

Команда

Команда — это самоорганизующаяся и многофункциональная группа людей, которые выполняют практическую работу по разработке и тестированию продукта. Поскольку Группа отвечает за производство продукта, она также должна иметь полномочия принимать решения о том, как выполнять работу. Таким образом, команда является самоорганизующейся: члены команды решают, как разбить работу на задачи и как распределить задачи между людьми на протяжении всего спринта.По возможности, размер команды должен быть от пяти до девяти человек. (Большее количество затрудняет общение, в то время как меньшее количество ведет к низкой производительности и хрупкости. ) Примечание: очень похожий термин «Scrum-команда» относится к команде плюс ScrumMaster и Product Owner.

Загрузить шпаргалку по Scrum Team

Интеграция Agile & Scrum разработки и методологии

Управление проектом гибридной модели

Шаян Алам, PMP

Методологии разработки

Waterfall, Agile и Scrum широко используются во всех организациях и по отдельности считаются проверенным подходом к разработке.Однако проблемы возникают по мере слияния и столкновения этих двух методологий. Вот несколько ключевых советов, которые помогут интегрировать обе методологии в вашу организацию разработки. Давайте сначала обсудим каждую методологию, ее уникальные характеристики и допущения.

Методология жизненного цикла разработки программного обеспечения «водопад» предполагает объединение всех участников и их вовлечение на ранних этапах процесса проектирования. Процесс проектирования более длительный и повторяющийся, поскольку команда проходит через требования высокого уровня, концептуальный подход, разработку решений, предварительный дизайн и критическое проектирование. Это предполагает, что мало что останется для открытия на этапах разработки и тестирования. Как правило, водопад эффективно работал с некоторыми типами продуктов — крупными усилиями по разработке в масштабе всего предприятия, когда пользователь проходит через стандартизованный процесс.

Однако Agile и Scrum предназначены для более изменчивого мира и обеспечивают итеративный подход. Например, в области мобильных приложений ландшафт постоянно меняется, поскольку новые телефоны, новые операционные системы и новые технологии для доставки данных конкурируют за то, чтобы заставить пользователя взаимодействовать как можно большим количеством способов.Кратковременная итеративная разработка позволяет «открывать» новые горизонты, поскольку заранее тратится меньше времени. В этом случае обнаружение включает в себя все: от функциональных недостатков до неэффективных пользовательских потоков и до концепции, которая в целом считается плохой идеей.

Основное различие между ними заключается в Agile, и Scrum предполагает, что будут недостатки, и поэтому перескакивает в кодирование, чтобы выявить их. Таким образом, успех команды разработчиков зависит от ее способности адаптироваться и быстро реагировать.Waterfall, напротив, принимает заблаговременные меры предосторожности, чтобы устранить любые недостатки.

Это, очевидно, вызывает конфликт между командами разработчиков, практикующими каждую из методологий разработки. Но можно предпринять определенные шаги, чтобы показать команде разработчиков преимущества другой методологии и, в идеале, сплотить команду.

5 советов по интеграции групп разработки agile и scrum с группами разработки водопада

Попытка внедрить Agile как итеративный водопад не сработает

Некоторые организации думают, что они могут быть более «гибкими», выполняя водопад меньшими итерациями.Проблема в том, что временную шкалу сложно сжать, когда после каждого раунда проверки ожидаются полностью проверенные артефакты. Слишком много накладных расходов при создании всего документа, что сокращает время, оставшееся на кодирование. Agile и scrum — это оптимизация процессов, а не их сжатие.

Разработка / контроль качества могут быть итеративными, в то время как проект и интеграция заказаны

Одна из стратегий перехода заключается в использовании гибкой разработки и схватки в циклах разработки и контроля качества.Меньшие циклы разработки с последующим контролем качества. Таким образом, заказчик видит эволюцию приложения и может по ходу комментировать. Вначале проект проверяется должным образом, и в конце для интеграции отводится достаточно времени.

Остерегайтесь ползучести прицела

Задача менеджера проекта при работе в быстро развивающейся группе Agile-разработки заключается в том, чтобы справиться с постепенным увеличением объема работ. Поскольку изменения могут быть реализованы быстро, все кажется возможным.Таким образом, необходимо проводить различие между тем, что считается исправлением, и тем, что считается изменением, чтобы спринты были напряженными и продвигались к согласованному конечному продукту.

Играйте спокойно с QA

QA всегда обременены приближением релиза, их график обычно скован стеной. В водопаде QA ожидает, что узкие варианты использования выведут свои тестовые примеры. Таким образом, в гибком мире код перебрасывается через стену. Вот почему в гибких командах иногда разработчики переключаются на роль QA и с самого начала становятся частью решения.

Будьте внимательны к конечному пользователю

Поскольку в конце каждого спринта доставляется полнофункциональное приложение, очень заманчиво выпустить его. Это может очень раздражать пользователей, если для этого требуется частое исправление или обновление. Это заставляет пользователя задуматься, не появится ли когда-нибудь на горизонте отполированный продукт. Если обновления проходят без проблем, может быть сложно не отставать от новых изменений. Поэтому опубликованный график выпуска или дорожная карта держит пользователя в курсе. Рекомендуются основные выпуски раз в полгода и / или функциональные выпуски ежеквартально.

Если вам нужна дополнительная информация по этой теме, отправьте электронное письмо по адресу [email protected]. Мы приветствуем ваши вопросы, комментарии и отзывы.

Другие часто просматриваемые статьи

Часто задаваемые вопросы по гибкой разработке программного обеспечения с использованием Scrum: узнайте об гибкой разработке программного обеспечения, Scrum, историях, ролях и многом другом…

Agile, Waterfall и неопределенность в управлении проектами: Agile Development vs. Waterfall

Введение в Scrum: преимущества и методы гибкой разработки программного обеспечения с помощью Scrum.

Scrum как управление проектами: сравнение и контрастирование Agile Development Scrum с традиционными методологиями управления проектами.

Agile Development & Scrum соответствует PMP: Agile Development, ее сравнение и отличие от методологии PMI.

ежедневных схваток в распределенном мире: формальное сотрудничество для сокращения накладных расходов.

Интеграция Waterfall и Agile Development: советы по интеграции методологий Waterfall и Agile Development.

Изучите Scrum с помощью Jira Software

Scrum tutorial

В этом руководстве мы дадим вам пошаговые инструкции о том, как управлять проектом Scrum, расставить приоритеты и организовать отставание в спринты, проводить церемонии Scrum и многое другое. , все в Jira Software.

Время:

10 минут чтения. Завершить за 2 недели

Аудитория:

Вы новичок в scrum, гибкой разработке программного обеспечения или Jira Software

Предварительное условие:

Вы создали учетную запись Jira Software

Получить бесплатно

Что такое scrum?

Scrum — один из самых популярных фреймворков для реализации гибкой разработки.С помощью Scrum продукт построен в виде серии итераций фиксированной длины, называемых спринтами, которые дают командам основу для регулярных поставок.

Шаг 1.

Создание проекта Scrum

После создания и входа в учетную запись в Jira Software вы можете выбрать шаблон из библиотеки. Выберите Scrum (вы можете узнать, как создать проект Kanban здесь).

Далее вам будет предложено выбрать тип проекта. Если ваша команда работает независимо и хочет контролировать свои рабочие процессы и практики в автономном пространстве, подумайте о том, чтобы попробовать наш управляемый командой шаблон Scrum.Дополнительные сведения см. В разделе «Начало работы с проектами, управляемыми командой» в сообществе Atlassian.

После того, как вы создали свой проект, вы попадете в пустой бэклог. Бэклог также известен как бэклог продукта и содержит текущий список потенциальных рабочих элементов вашей команды для проекта.

Шаг 2. Создание пользовательских историй или задач в журнале обработки

В Jira Software мы называем такие рабочие элементы, как пользовательские истории, задачи и ошибки, «проблемами». Создайте несколько пользовательских историй с опцией быстрого создания в бэклоге. Если у вас нет пользовательских историй, просто создайте образцы историй, чтобы начать работу и посмотреть, как работает процесс.

Что такое пользовательские истории?

Пользовательские истории используются для описания рабочих элементов на нетехническом языке и с точки зрения пользователя. . Как {тип пользователя} я хочу {цель}, чтобы {получать выгоду}.

Давайте использовать веб-сайт в качестве простого примера для создания пользовательской истории.

Как клиент, я хочу иметь возможность создать учетную запись, чтобы видеть свои предыдущие покупки.

Пользовательские истории обычно набрасываются и расставляются по приоритетам владельцем продукта, а затем группа разработчиков определяет подробные задачи, необходимые для завершения истории в предстоящем спринте. Команда разработчиков также отвечает за оценку относительных усилий, необходимых для завершения работы над историей.

После того, как вы создали несколько пользовательских историй, вы можете начать расставлять приоритеты в бэклоге. В Jira Software вы ранжируете или устанавливаете приоритеты своих историй, перетаскивая их в том порядке, в котором над ними нужно работать.

Это только начало вашего проекта. Вы будете продолжать создавать истории на протяжении всей жизни проекта. Это потому, что гибкость предполагает постоянное обучение и адаптацию.

Шаг 3. Создайте спринт

Создайте свой первый спринт в бэклоге, чтобы вы могли начать планирование спринта.

Что такое спринт?

В Scrum команды прогнозируют выполнение набора пользовательских историй или других рабочих элементов в течение фиксированного времени, известного как спринт.Вообще говоря, спринты длятся одну, две или четыре недели. Команда определяет продолжительность спринта — мы рекомендуем начинать с двух недель. Этого достаточно, чтобы добиться чего-то, но не настолько, чтобы команда не получала регулярных отзывов. Как только ритм спринта определен, команда постоянно работает с этим ритмом. Спринты фиксированной длины укрепляют навыки оценки и предсказывают будущую скорость для команды, поскольку она работает через невыполненное задание.

Шаг 4: Проведите собрание по планированию спринта

В начале спринта вы должны провести собрание по планированию спринта с остальной частью вашей команды.Встреча по планированию спринта — это церемония, которая настраивает всю команду на успех на протяжении всего спринта. На этой встрече вся команда обсуждает цель спринта и истории в приоритетном бэклоге продукта. Команда разработчиков создает подробные задачи и оценки для приоритетных историй. Затем команда разработчиков обязуется завершить определенное количество историй в спринте. Эти истории и план их завершения становятся так называемым бэклогом спринта.

Добавьте оценки сюжетных точек к своим историям, добавив число в поле Оценка сюжетных точек .Вы также можете добавить дополнительные сведения к историям или щелкнуть значок создать подзадачу , чтобы подробнее разбить работу над историей.

Когда вы будете готовы, перетащите истории, согласованные на собрании по планированию спринта, в только что созданный спринт. Это ваше отставание в спринте.

Что такое собрание по планированию спринта?

Участники: Требуются: команда разработчиков, мастер схватки, владелец продукта

Когда: В начале спринта.

Продолжительность: Обычно итерация два часа в неделю — например, двухнедельный спринт начинается с четырехчасового совещания по планированию. Встреча заканчивается, когда ее цель достигнута.

Цель: Спланировать работу спринта. Команда соглашается с целью спринта и отставанием в спринте.

Что такое цель спринта?

При создании спринта владелец продукта обычно определяет цель спринта. Это обеспечивает тему для работы, которая будет завершена в спринте.Цель спринта также обеспечивает некоторую гибкость в отношении количества историй, завершаемых в спринте. Спринт считается успешным, если цель спринта достигнута.

Что такое гибкая оценка?

Традиционные команды разработчиков программного обеспечения дают оценки в формате времени: дни, недели, месяцы.
Однако многие agile-команды уже перешли на очки истории. Story points оценивают относительное усилие работы, часто в формате, подобном Фибоначчи: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Оценки помогают вам определить, сколько работы вам следует добавить в следующий спринт в зависимости от количества членов вашей команды.После нескольких спринтов ваша команда научится лучше понимать, сколько работы они могут выполнить за каждый спринт, что поможет избежать чрезмерных усилий.

Шаг 5. Запустите спринт в Jira

Назовите спринт. Некоторые команды называют спринт на основе своей цели. Если между проблемами в спринте есть общие черты, назовите спринт вокруг этой темы. В противном случае вы можете назвать спринт как хотите.

Добавьте продолжительность спринта, а также даты начала и окончания.Даты начала и окончания должны соответствовать расписанию вашей команды. Например, некоторые команды начинают спринты в понедельник, а затем заканчивают в пятницу утром на следующей неделе. Другие команды решают начинать и заканчивать свои спринты в середине недели. Тебе решать! Если вы не уверены, какой длины должны быть ваши спринты, мы рекомендуем попробовать две недели.

Добавьте цель спринта, как было согласовано на собрании по планированию спринта.

После запуска спринта вы попадете на вкладку «Активные спринты» в проекте.

Здесь ваша команда будет работать над тем, чтобы собирать элементы из столбца дел и перемещать их в незавершенные и, в конце концов, готово!

Если вы используете шаблон командной схватки, он будет называться Board .

Шаг 6: Ежедневно проводите стандартные встречи

После того, как спринт начался, пусть ваша команда будет встречаться ежедневно, обычно утром, чтобы обсудить, над чем все работают. Это делается с целью увидеть, не сталкивается ли кто-либо в вашей команде с какими-либо препятствиями на пути к выполнению задач спринта.

Что такое ежедневная стендап-встреча?

Участники (в основном): команда разработчиков

Когда: Один раз в день, обычно утром

Продолжительность: Не более 15 минут. Не бронируйте конференц-зал и не проводите стендап сидя. Если встать, встреча будет короткой!

Цель: Ежедневная стойка предназначена для быстрого информирования всех о том, что происходит в команде, и для планирования работы дня.Это не полнофункциональная встреча. Тон должен быть легким и веселым, но информативным. Попросите каждого члена команды ответить на следующие вопросы:

Что я выполнил вчера?
Над чем я буду работать сегодня?
Я чем-нибудь заблокирован?

Существует неявная подотчетность в сообщении о том, какую работу вы выполнили вчера, перед своими коллегами. Никто не хочет быть членом команды, который постоянно делает одно и то же и не добивается прогресса.

ProTip: Некоторые команды используют таймеры, чтобы держать всех в курсе. Другие подбрасывают мяч через команду, чтобы убедиться, что все обращают внимание. Многие распределенные команды используют видеоконференцсвязь или групповой чат, чтобы сократить разрыв в расстоянии. Ваша команда уникальна — ваш стендап тоже должен быть!

Вы можете использовать активные спринты своей доски схватки во время ежедневного стендапа, чтобы каждый участник мог просматривать задачи, над которыми они работают.

Шаг 7: Просмотр диаграммы выгорания

Рекомендуется проверять диаграмму выгорания во время спринта.В Jira Software диаграмма Burndown Chart показывает фактический и предполагаемый объем работы, которую необходимо выполнить за спринт. Диаграмма выгорания автоматически обновляется Jira по мере выполнения рабочих элементов. Чтобы просмотреть эту диаграмму, нажмите «Отчеты» на боковой панели, а затем выберите «Burndown Chart» в раскрывающемся списке отчетов.

Что такое Burndown Chart и как вы его читаете

Burndown Chart показывает фактический и предполагаемый объем работы, которую необходимо выполнить за спринт. Горизонтальная ось X на диаграмме Burndown Chart указывает время, а вертикальная ось Y обычно указывает точки истории.

Используйте Burndown Chart, чтобы отслеживать общую работу, оставшуюся для спринта, и прогнозировать вероятность достижения цели спринта. Отслеживая оставшуюся работу на протяжении итерации, команда может управлять своим прогрессом и соответствующим образом реагировать.

Анти-паттерны, за которыми нужно следить

Команда заканчивает спринт за спринтом раньше, потому что не выполняет достаточного количества работы.
Команда пропускает прогнозируемый спринт за спринтом, потому что выполняет слишком много работы.
Линия выгорания дает крутые спады, а не более постепенное выгорание, потому что работа не была разбита на гранулы.
Владелец продукта добавляет или изменяет объем в середине спринта.

Шаг 8: Просмотр отчета о спринте

В любой момент во время или после спринта вы можете просмотреть отчет о спринте для отслеживания спринта.

Что такое отчет о спринте?

Отчет о спринте включает диаграмму сгорания и перечисляет выполненную работу, незавершенную работу и любую работу, добавленную после начала спринта.

Шаг 9: Проведите собрание по обзору спринта

Обзор спринта или демонстрация спринта — это собрание по обмену информацией, на котором команда показывает, что они реализовали в этом спринте. Каждый спринт обычно производит рабочую часть продукта, называемую инкрементом.

Это собрание с большим количеством отзывов о проекте, которое включает в себя мозговой штурм, чтобы помочь решить, что делать дальше.

Участники (в основном): команда разработчиков, мастер схватки, владелец продукта.
Дополнительно: заинтересованных сторон

Когда: Обычно в последний день спринта

Продолжительность: Обычно два часа для двухнедельного спринта

Цель: Проверить приращение и совместно обновлять список невыполненных работ по продукту.

Вопросы:

Выполнила ли команда прогноз на спринт?
Были ли работы добавлены или удалены в середине спринта?
Не удалось ли выполнить какую-либо работу в течение спринта?
Если да, то почему?

Шаг 10: Проведите ретроспективное собрание спринта

После завершения спринта попросите свою команду провести ретроспективу.Задокументируйте свою ретроспективу где-нибудь. Мы можем предложить Confluence?

Что такое ретроспективная встреча спринта?

Участники: команда разработчиков, scrum-мастер, product owner.

Когда: В конце итерации.

Продолжительность: Обычно 90 минут для двухнедельного спринта.

Цель: Команда проверяет себя, включая свои процессы, инструменты и взаимодействие в команде.Проблемы с улучшением часто добавляются в список невыполненных задач следующего спринта.

Ретроспективы — это не просто время для жалоб без каких-либо действий. Используйте ретроспективы, чтобы узнать, что работает, чтобы команда могла продолжать сосредоточиться на этих областях. Кроме того, выясните, что не работает, и используйте время, чтобы найти творческие решения и разработать план действий. Непрерывное совершенствование — это то, что поддерживает и стимулирует развитие в гибкой команде, и ретроспективы являются ключевой частью этого.

Вопросы, которые нужно задать:

Что у нас было хорошо во время спринта?
Что мы могли сделать лучше?
Что мы будем делать лучше в следующий раз?

ProTip: Даже если дела в команде идут хорошо, не прекращайте проводить ретроспективы.Ретроспективы служат постоянным ориентиром для команды, чтобы дела шли хорошо.

Шаг 11: Завершите спринт в Jira

В конце спринта вы должны его завершить.

Если в спринте есть неполные задачи, вы можете:

Переместить проблему (и) в очередь.
Перенести проблемы в будущий спринт.
Перенесите задачи в новый спринт, который Jira создаст для вас.

Шаг 12: Повторите с шага 2

На этом этапе у вас есть основы создания бэклога с пользовательскими историями, организации ваших пользовательских историй в спринты, запуска спринта и проведения церемоний Scrum.Вы можете решить, работает ли это для вашей команды или вы хотите перейти к более сложным темам.

После того, как вы и ваша команда выполнили описанные выше действия, переходите к расширенной статье: Как выполнять расширенные методы схватки с Jira Software.

Клэр Мейнард

Клэр — ветеран маркетинга Atlassian, которая на протяжении всего срока своего пребывания в должности занималась вопросами роста, производительности и маркетинга продуктов. В настоящее время она управляет брендом, контентом и маркетинговой стратегией для Confluence Cloud.Вне работы вы можете найти Клэр, занимающуюся серфингом, бегом или пробуя новые рестораны в Сан-Франциско или новых городах по всему миру.

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо от опыта

Многие люди связывают начало гибкой разработки программного обеспечения, и в некоторой степени, гибкой разработки в целом, со встречей, которая произошла в 2001 году, когда был придуман термин «гибкая разработка программного обеспечения».

Однако люди начали работать в стиле Agile еще до встречи 2001 года.Начиная с середины девяностых годов, были разные практики, либо люди, работающие внутри организаций, разрабатывающих программные продукты, либо консультанты, помогающие организациям создавать программное обеспечение, которые думали: «Знаете что? То, как мы создавали программное обеспечение, просто не работает для нас. Мы должны придумать что-то другое ».

Эти разработчики программного обеспечения начали смешивать старые и новые идеи, и когда они нашли комбинацию, которая работала, они создали методологию для своей команды, чтобы помочь им запомнить комбинацию идей, которые работали в данной ситуации.

Эти методологии подчеркивают тесное сотрудничество между командой разработчиков и заинтересованными сторонами; частое предоставление бизнес-ценности, сплоченные, самоорганизующиеся команды; и умные способы создания, подтверждения и доставки кода.

Люди, создавшие эти методологии, посчитали, что другие могут быть заинтересованы в получении некоторых из тех же преимуществ, что и они, поэтому они создали основы для распространения идей среди других команд в других организациях и контекстах. Именно здесь и начали появляться такие фреймворки, как Scrum, Extreme Programming, Feature-Driven Development (FDD) и Dynamic Systems Development Method (DSDM).

Распространение идей в то время было очень органичным, и все эти различные подходы начали развиваться очень массово. Люди заимствовали исходные рамки и настраивали их с помощью различных практик, чтобы сделать их подходящими для своего собственного контекста.

2001 — Автор манифеста Agile

Не существовало единого способа описания этих различных способов разработки программного обеспечения, пока группа из 17 человек не подумала: «Мы все применяем разные подходы к разработке программного обеспечения.Мы должны собраться вместе и посмотреть, есть ли общие черты в том, о чем мы думаем ». Результатом стала встреча на горнолыжном курорте в Сноуберд, штат Юта, в 2001 году.

Когда они собрались вместе, они немного покатались на лыжах, а также обсудили, в чем их подходы к разработке программного обеспечения имеют общие черты и различия.

Они не пришли к согласию по многим вещам, но было несколько вещей, о которых они смогли договориться, и это в конечном итоге стало Манифестом для гибкой разработки программного обеспечения.Две основные вещи, которые сделал Agile Manifesto, заключались в предоставлении набора заявлений о ценностях, которые формируют основу для Agile-разработки программного обеспечения, и в введении в употребление самого термина Agile-разработка программного обеспечения.

Спустя несколько месяцев авторы расширили идеи Agile-манифеста с помощью 12 принципов, лежащих в основе Agile-манифеста.

Некоторые авторы, в том числе Мартин Фаулер, Дэйв Томас, Джим Хайсмит и Боб Мартин, написали свои воспоминания о написании Agile Manifesto.16 из 17 авторов встретились на Agile2011 и поделились своими воспоминаниями о мероприятии и своими взглядами на состояние Agile на тот момент.

После 2001 г. — Принятие началось массово, стало мейнстримом

После того, как авторы вернулись из Snowbird, Уорд Каннингем опубликовал Agile Manifesto, а затем и 12 принципов на сайте AgileManifesto.org. Люди могли выйти в Интернет и подписать его, чтобы выразить свою поддержку.

Agile Alliance был официально образован в конце 2001 года как место для людей, которые разрабатывают программное обеспечение и помогают другим в разработке программного обеспечения для изучения и обмена идеями и опытом.

Команды и организации начали внедрять Agile, во главе с людьми, занимающимися разработкой в командах. Постепенно менеджеры этих команд также начали внедрять Agile-подходы в своих организациях.

По мере того, как Agile стала более известной, сформировалась экосистема, в которую вошли люди, которые занимались Agile-разработкой программного обеспечения, а также люди и организации, которые помогали им посредством консультаций, обучения, фреймворков и инструментов.

По мере того, как экосистема начала расти и идеи Agile начали распространяться, некоторые последователи упустили из виду ценности и принципы, закрепленные в манифесте и соответствующих принципах.Вместо того, чтобы следовать «гибкому» мышлению, они начали настаивать на том, чтобы определенные практики выполнялись точно определенным образом.

Организации, которые сосредоточены исключительно на практиках и ритуалах, испытывают трудности при работе в стиле Agile. Организации, которые серьезно относятся к соблюдению ценностей и принципов Agile, как правило, осознают выгоды, которые они искали, и обнаруживают, что работа в стиле Agile больше не является чем-то новым и другим. Вместо этого это просто становится их подходом к работе.

Agile Alliance продолжает курировать ресурсы, чтобы помочь вам внедрить методы Agile и улучшить ваши способности гибкой разработки программного обеспечения. Веб-сайт Agile Alliance предоставляет доступ к этим ресурсам, включая видеоролики и презентации с наших конференций, отчеты об опыте работы, глоссарий Agile, каталог групп местного сообщества и ряд других ресурсов.

Что такое Agile? Как бы вы дали определение Agile? Что означает Agile?

Как вы определяете Agile? Я видел много дискуссий, в которых люди пытались ответить на вопрос «Что такое Agile?» с очень разными ответами.

Вы действительно имеете в виду Scrum?

Во-первых, существует большая путаница в Agile и Scrum. Scrum настолько широко используется в качестве гибкого подхода, что, когда многие люди говорят «Agile», они на самом деле имеют в виду Scrum.

Agile — это общая философия
Scrum — это особый подход Agile

Ознакомьтесь с этой статьей о том, что такое Scrum? Что такое Agile? для получения дополнительной информации об этом.

Чувствуя слона

Я уверен, что в Интернете можно найти по крайней мере 100 определений того, что такое Agile.Это похоже на старую басню «Слепые чувствуют слона»:

«Это было шесть человек из Индостана
Очень склонных к обучению,
Кто пошел посмотреть на Слона
(Хотя все они были слепыми),
Каждый по наблюдению
Может удовлетворить его разум ^{[18] ”}

У каждого человека свое мнение в зависимости от того, к какой части слона он прикоснулся:

«Каждый, по своему мнению, заключает, что слон похож на стену, змею, копье, дерево, веер или веревку, в зависимости от того, где они коснулись»

Различные взгляды на Agile

То, как люди определяют Agile, в чем-то похоже.В зависимости от того, к какой части вы прикоснетесь, у вас может сложиться разное впечатление о том, что такое Agile:

Многие люди определяют Agile с точки зрения того, как это делается. Например, многие люди скажут, что это определено в Agile Manifesto. Вот несколько примеров:

«Agile — это набор методов и структур, которые воплощают принципы и ценности Agile Manifesto»

«Agile — это термин, используемый для описания подходов к разработке программного обеспечения с упором на поэтапную доставку, командное сотрудничество, непрерывное планирование и непрерывное обучение.Термин «Agile» был введен в обращение в 2001 году в Agile Manifesto ».

Некоторые люди скажут, что это просто образ мышления. Вот пример этого.

«Быть гибким — это образ мышления. Речь идет о поиске того, что нужно строить быстрее (а не просто строить быстрее) »

Некоторые люди определяют его, сравнивая его с «Водопадом», чтобы сказать вам, что это за , а не за . Вот пример этого:

«Agile — это ограниченный по времени итеративный подход к доставке программного обеспечения, при котором программное обеспечение создается постепенно с самого начала проекта, вместо того, чтобы пытаться доставить все сразу ближе к концу.”

Ни одно из этих определений не является неправильным, но это все равно что «почувствовать слона»; На мой взгляд, они не понимают истинной сути того, что такое «слон».

Как вы определяете Agile?

Лично мне нравится определение, опубликованное Agile Alliance:

«Способность создавать изменения и реагировать на них, чтобы добиться успеха в неопределенной и неспокойной среде».

Я думаю, что это лучшее определение, потому что оно раскрывает то, что я считаю реальной сущностью того, что такое Agile.

«Agile лучше всего подходит для ситуаций с некоторым уровнем неопределенности, где творческий подход и инновации важны для максимизации бизнес-ценности решения, в отличие от других ситуаций с более низким уровнем неопределенности, где более важны планирование и контроль для достижения предсказуемости. ” (Мое определение)

Какие проблемы решает Agile?

Мы должны признать, что Agile — это не решение всех проблем, которые могут у вас возникнуть.Один из способов определить это с точки зрения того, для каких проблем он полезен.

Если вы согласны с тем, что Agile — это не решение всех проблем, которые могут у вас возникнуть, первое, что вам нужно знать, это «для каких проблем он полезен?»
Вам не нужно слишком углубляться в механику того, как это сделать, пока вы не решите, что это полезное решение проблемы, которую вы пытаетесь решить.

Из этого можно сделать интересное наблюдение — люди очень погружаются в механику Agile и вот как они это определяют.Разве не важнее знать, для решения каких проблем он полезен, прежде чем вдаваться в подробности того, как его использовать?

Статьи по теме

Ознакомьтесь со следующими статьями по теме «Понимание Agile»:

Дополнительные ресурсы

Ресурсы для онлайн-обучения гибкому управлению проектами.

Нравится:

Нравится Загрузка …

Что такое Agile?

До недавнего времени Agile рассматривался как набор методов управления, относящихся к разработке программного обеспечения.Это связано с тем, что первыми сторонниками Agile были разработчики программного обеспечения, и его основополагающим документом был Манифест по разработке программного обеспечения 2001 года. Спустя пятнадцать лет, в 2016 году, после признания Harvard Business Review, McKinsey & Company и проекта Learning Consortium Project 2015 года Agile теперь быстро распространяется на все части и все типы организаций.

Возникновение Agile как огромного глобального движения, выходящего за рамки программного обеспечения, обусловлено открытием того, что единственный способ для организаций справиться с сегодняшним бурным рынком, ориентированным на клиентов, — это стать Agile.Agile позволяет организациям справляться с постоянными изменениями. Это позволяет компаниям процветать в мире, который становится все более нестабильным, неопределенным, сложным и неоднозначным.

Цели, принципы и методы гибкой разработки будут освещены на заседании форума Друкера с Гэри Хэмелом в качестве участника дискуссии.

Эволюция гибкости

Agile Manifesto 2001 года отражал взгляды дальновидных разработчиков программного обеспечения, которые считали, что «открытие лучших способов разработки программного обеспечения» потребует пересмотра некоторых фундаментальных предположений менеджмента 20-го века.Они ценили «людей и взаимодействие выше процессов и инструментов, работающее программное обеспечение важнее исчерпывающей документации, сотрудничество с клиентами выше переговоров по контракту и реагирование на изменения, а не следование плану».

Тем не менее, в Манифесте также подразумевается новый набор вопросов: «Что, если бы мы могли создавать рабочие места, в которых задействованы все таланты тех, кто выполняет работу? Что, если бы эти таланты были полностью сосредоточены на предоставлении исключительной ценности клиентам и другим заинтересованным сторонам, для которых выполняется работа? Что, если те, кто получает эту уникальную ценность, будут готовы предложить за нее щедрую компенсацию? Как бы выглядели эти рабочие места? Как бы они действовали? Как они будут согласованы с существующими целями, принципами и ценностями? Могут ли они работать в больших масштабах? Если да, будут ли ответы иметь значение для всех организаций, а не только для разработки программного обеспечения? »

В 2001 году никто не знал ответов на эти вопросы.Разработчики программного обеспечения начали пытаться выяснить это путем экспериментов. Как и все новое, все шло урывками, с частыми неудачами. Было исследовано множество вариантов практики. Даже когда практики были в основном одинаковыми, подходы часто имели разные названия.

Первоначальные эксперименты проводились с отдельными командами. По мере того, как некоторые из этих экспериментов были успешными, эксперименты расширились на группы команд и, в конечном итоге, на очень крупномасштабные внедрения, даже на целые организации и на другие сектора, такие как производство.Некоторые организации, которые были «рождены Agile», такие как Riot Games и Spotify, быстро росли и продолжали работать в соответствии с принципами и ценностями Agile.

В течение нескольких лет было трудно понять, что происходит. Даже некоторые из тех, кто принял Agile, считали, что он играет ограниченную роль, в основном в простых операциях с программным обеспечением в небольших подразделениях или организациях, где надежность не является проблемой. Многие команды и фирмы, претендующие на звание Agile, были Agile только по названию. Некоторые предполагали, что Agile, выходя за рамки отдельных команд разработчиков программного обеспечения, неизбежно трансформируется в традиционную иерархическую бюрократию, чтобы добиться эффективного и надежного управления в масштабе.

Однако со временем, что работало, а что не стало очевидным. В результате произошло поразительное сближение с целым семейством целей, принципов и ценностей, которые были явно более продуктивными и отвечающими потребностям клиентов, чем традиционное управление.

По мере того, как Agile все чаще применяется в крупномасштабных проектах, компании получают огромные выгоды, особенно способность обеспечивать мгновенную, удобную и персонализированную реакцию в любом масштабе, например Discover Weekly от Spotify.

Общее руководство принимает гибкость

Поскольку программное обеспечение само по себе становится критически важным фактором практически во всех сферах бизнеса, Agile теперь распространяется на все виды организаций и во все аспекты работы, что было признано в 2016 году цитаделью общего менеджмента — Harvard Business Review — в статье «Охват гибкости» »Даррелла К. Ригби, Джеффа Сазерленда и Хираката Такеучи.

«Теперь гибкие методологии, которые включают новые ценности, принципы, практики и преимущества и являются радикальной альтернативой командно-административному управлению, распространяются в широком диапазоне отраслей и функций и даже в топ-менеджеры.Национальное общественное радио использует гибкие методы для создания новых программ. John Deere использует их для разработки новых машин, а Saab — для производства новых истребителей. Intronis, лидер в сфере облачных сервисов резервного копирования, использует их в маркетинге. C.H. Робинсон, глобальный сторонний поставщик логистических услуг, применяет их в человеческих ресурсах. Винодельня Mission Bell использует их для всего, от производства вина до складирования и управления своей группой высшего руководства ».

Центральная роль Agile для общего управления была также признана в апреле 2016 года McKinsey & Company на глобальном хакатоне Agility Hackathon, в котором приняли участие около 1500 онлайн-участников:

« Становление гибкой организации становится все более насущной необходимостью для компаний в современной цифровой экономике, однако большинство компаний имеют глубоко укоренившуюся архитектуру и культуру командной организации.Это отражает, прежде всего, образ мышления и навыки индустриальной экономики их старших руководителей, что, возможно, является самым большим препятствием на пути к тому, чтобы стать гибкой организацией … Чтобы осуществить трансформацию, старшие руководители должны изучить и применить на практике целостный и полный набор новых мировоззрений и навыки и применить их для разработки совершенно новой, гибкой архитектуры и культуры организации ».

Обучающий консорциум и Agile

Появление Agile для общего управления было также подтверждено выводами проекта Learning Consortium Project 2015 г. Это была группа организаций, включая Microsoft, Ericsson, CH Robinson, Magna International, Riot Games и Scrum Alliance, которые решили посмотреть, что на самом деле происходит в компаниях, которые заявляют, что практикуют гибкое управление и связанные с ним методы управления, такие как бережливое производство.На фоне противоречивых заявлений о том, является ли Agile чем-то реальным или просто управленческой прихотью, это все разговоры, проект консорциума обучения стремился выяснить, что на самом деле происходит на местах.

Посещения объектов показали, что в некоторых случаях Agile действительно был не более чем разговором — все в шляпе, а не в скоте. Несмотря на то, что менеджеры в этих организациях утверждали, что они Agile и даже внедряли некоторые методы Agile, организация по-прежнему функционировала как бюрократия сверху вниз. Но в других случаях посещения сайтов показали, что некоторые крупные корпорации широко внедряют цели, принципы и ценности Agile.Фактически, как указывается в отчете, масштабная гибкая разработка уже реализуется.

Менталитет и людей в отношении инструментов и процессов

Об Agile написано очень много. Большая часть этих работ посвящена вещам, — инструментам, процессам, методологиям, технологиям, платформам, большим данным и тому подобному.

В то время как проект Консорциума обучения 2015 года обнаружил, что эти вещей, важны, человек важнее — цели, к которым люди стремятся, образ мышления, благодаря которому они понимают, как устроен мир, как они работают вместе, ценности, которые они делятся друг с другом и как они общаются друг с другом.Как сказано в самом Agile Manifesto, люди и взаимодействие ценятся больше, чем инструменты и процессы. Без гибкого мышления инструменты и процессы мало что могут сделать.

Другая концепция организации

Некоторым менеджерам сложно понять Agile, потому что это не просто методология или процесс, которые могут быть реализованы в рамках текущих предположений фирмы. Гибкий способ управления организацией переопределяет саму концепцию корпорации, которая преобладала последние сто лет.

Вместо корпорации, задуманной как эффективная машина устойчивого состояния, нацеленная на использование ее существующей бизнес-модели, Agile-организация представляет собой растущий, обучающийся, адаптирующийся живой организм, который находится в постоянном движении, чтобы использовать новые возможности и добавить новую ценность для клиентов.

Вместо того, чтобы течь сверху вниз, Agile признает, что будущее фирмы зависит от воодушевления тех, кто выполняет работу по ускорению инноваций и повышению реальной ценности для клиентов.Он признает, что повышение потенциала тех, кто выполняет работу, зависит от предоставления автономии самоорганизующимся командам в рамках широких параметров контроля. Он ценит прозрачность и постоянное улучшение, а не предсказуемость и эффективность. Он признает, что открытые интерактивные беседы более ценны, чем нисходящие директивы. Он перестает делать все, что не приносит пользы конечным клиентам. Он понимает, что ключ к успеху — не делать больше работать быстрее .Ключ в том, чтобы быть на умнее , создавая на больше стоимости из меньше работы и доставив раньше .

Agile стирает традиционное управленческое различие между эксплуатацией и разведкой. Когда Agile работает правильно, все подразделения организации постоянно изучают, как повысить ценность для клиентов. Это не только создает смысл для тех, кто выполняет работу, и радует тех, для кого эта работа выполняется: это приводит к щедрой прибыли для самой организации.

Для его сторонников Agile — это действительно лучший способ управлять компанией и экономикой — лучше для тех, кто выполняет работу, лучше для тех, для кого работа выполняется, лучше для самой организации. Вместо того, чтобы руководство извлекало ценность из фирмы, Agile создает ценность для клиентов и общества в целом.

Консорциум SD Learning

Являясь преемником проекта Learning Consortium Project 2015 года, SD Learning Consortium (SDLC) является некоммерческой организацией, членами которой являются организации, приверженные совместному открытию самых передовых мировых целей, принципов и практик, включая, но не ограничиваясь Agile, и распространять их по всему миру, чтобы помочь преобразовать мир труда.

SDLC посещает своих членов, синтезирует то, что они открыли вместе, и распространяет свои открытия через отчеты, публикации в Интернете, социальные сети и участие в конференциях. В настоящее время членами SDLC являются Barclays, Cerner, CH Robinson, Ericsson, hhpberlin, Microsoft, Riot Games и Scrum Alliance.

SDLC только что завершил восемь посещений объектов, включая Barclays, Cerner, CH Robinson, Ericsson, hhpberlin, Microsoft, Riot Games, BMW и Spotify.Члены встретятся в Нью-Йорке в середине сентября 2016 года, чтобы подвести итоги своих выводов.

По мере того, как Agile продолжает развиваться, члены SDLC видят себя первооткрывателями и исследователями, как средневековые картографы, чьи карты позволили открыть Новый Свет. Они представляют то, что они узнали, не как последнее слово, а как первое приближение к возникающим реальностям.

Консорциум SD Learning на форуме Друкера

Отчет SDLC будет представлен на форуме Drucker под названием «Крупномасштабные организационные преобразования, способствующие быстрым бизнес-инновациям.На встрече с двумя руководителями из членов Learning Consortium. Гэри Хэмел будет обсуждать.

Сессия представит отчет о необычных новых достижениях в области быстрых инноваций в широком масштабе, наблюдаемых во время посещений SDLC — разработках, которые были бы немыслимы даже несколько лет назад, включая продемонстрированные возможности:

• для мгновенной, простой и персонализированной реакции в любом масштабе.

• для создания рабочих мест, обеспечивающих непрерывные инновации с использованием высококачественных и устойчивых методов управления для тысяч сотрудников, которые стабильно работают в масштабах для миллионов клиентов.

• доставлять клиентам множество инноваций в день в рабочей среде с низким уровнем стресса и высокой вовлеченностью.

• для сбора, анализа и реагирования на отзывы миллионов клиентов, ежедневно получающих инновации.

Сессия будет посвящена последствиям такой практики и возможностей для предпринимательства и инноваций в 21 веке.

Раскрытие информации: я — бесплатный советник на общественных началах и директор SDLC.

И читайте также:

Объятия гибкости HBR

Почему менеджеры ненавидят Agile

Learning Consortium Project (ноябрь 2015 г.)

Самый хранимый секрет управления на планете: Agile

Доводы против Agile: десять постоянных возражений

___________________

Следите за сообщениями Стива Деннинга в Twitter: @stevedenning

Что такое Agile? И когда это использовать

Что такое Agile?

Agile — это подход к управлению проектами, основанный на постепенных и повторяющихся этапах выполнения проектов.Дополнительные части проекта выполняются в краткосрочных циклах разработки. Подход отдает приоритет быстрой доставке, адаптации к изменениям и сотрудничеству, а не управлению сверху вниз и следованию установленному плану.

В Agile-процессах существует постоянная обратная связь, позволяющая членам команды приспосабливаться к проблемам по мере их возникновения, а заинтересованным сторонам — возможность согласованно общаться. Хотя изначально Agile-подход был создан для разработки программного обеспечения, в настоящее время он широко используется при выполнении многих различных типов проектов и в действующих организациях.

Сравните это с более традиционными формами управления проектами. Традиционное управление проектами обычно развивается линейно. Переход от этапов планирования, проектирования, реализации и закрытия происходит после завершения предыдущего этапа.

Так что же такое методология Agile?

Agile — это техническая концепция, а не методология сама по себе, и ее лучше рассматривать как образ мышления при подходе к реализации проектов. Это не считается методологией, потому что Agile не указывает, какие именно инструменты и процессы следует использовать.

Agile, однако, является общим термином для многих типов методологий управления. Scrum, Kanban и Extreme Programming (XP) считаются разными методологиями Agile, хотя их гораздо больше.

Agile за и против

Хотя Agile набирает популярность и имеет множество преимуществ, у него есть свои проблемы. Ниже приведены некоторые из преимуществ и недостатков, с которыми сталкиваются гибкие пользователи, согласно опросу Digital.ai о состоянии гибкости за 2020 год [1].

/ Согласование ИТ

Преимущества Agile	Проблемы Agile
Способность управлять меняющимися приоритетами	Организации могут сопротивляться изменениям в процессе принятия
Повышенная видимость проекта	Команды могут использовать непоследовательные методы ведения бизнеса 90	Требуется поддержка руководства и управления
Скорость доставки / время выхода на рынок	Организационная культура может противоречить динамичным ценностям
Снижение рисков проекта
Предсказуемость проекта

Когда следует использовать гибкое управление проектами?

Принципы A gile — адаптируемость, итерация, непрерывная поставка и короткие сроки, среди прочего — делают его стилем управления проектами, который лучше подходит для текущих проектов и проектов, где некоторые детали не известны с самого начала.Это означает, что если у проекта нет четких ограничений, сроков или доступных ресурсов, он является хорошим кандидатом для гибкого подхода.

Например, разработка и запуск нового продукта может подтолкнуть команду к нескольким непредвиденным проблемам. Наличие гибкого подхода может означать, что в проекте уже есть методология, позволяющая тестировать продукты так часто, как это необходимо, быстро выполнять итерации и сообщать об изменениях заинтересованным сторонам.

Традиционные подходы к управлению проектами , такие как Waterfall, легче планировать, а прогресс легче измерять.Это может сделать проекты с четко обозначенными ограничениями (например, строгий бюджет или сроки) или проекты, в которых предполагается, что команды будут работать независимо от заинтересованных сторон, лучше подходящими для традиционных подходов.

Отрасли, в которых используются методы Agile

Agile выросли из умы группы менеджеров проектов по разработке программного обеспечения. С тех пор он продолжает оставаться популярным в разработке программного обеспечения, но распространился и на многие другие отрасли. К ним относятся финансы, информационные технологии, бизнес, мода, биотехнологии и даже строительство — среди многих других.

Использование методов Agile и Waterfall

Не все проекты точно подходят к той или иной категории. Для проектов, которые могут извлечь выгоду из элементов как традиционного подхода, так и итеративного подхода, гибридный подход Agile-Waterfall может иметь смысл. Это может означать, например, что планирование и дизайн выполняются в Waterfall, но разработка выполняется короткими циклами разработки в стиле Agile.

Подробнее: 12 Методологии управления проектами: ваше руководство

Методологии и фреймворки Agile

Существует несколько методологий и фреймворков Agile, каждая из которых имеет свои плюсы и минусы.Некоторые из них представляют собой гибриды нескольких методологий. Scrum — это, безусловно, наиболее часто используемая методология Agile; Digital.ai обнаружил, что 58% последователей Agile использовали Scrum, а следующей по популярности методологией является ScrumBan — 10% [2].

Популярные методологии Agile:

Scrum
Канбан
Lean
Crystal
Extreme Programming (XP)
Feature-Driven Development (FD
)
Domain-Driven Design (DDD)
Метод разработки динамических систем (DSDM)
ScrumBan
Agile-Waterfall / Hybrid Agile
Scrum XP Hybrid

Подробнее: Agile vs .Scrum: что использовать и почему?

Методы масштабирования

Методы масштабирования Agile используются для внедрения практик Agile в нескольких командах или целых организациях. Существует несколько методов масштабирования, включая следующие:

Scaled Agile Framework (SAFe)
Scrum of Scrum
Discipdered Agile Delivery (DAD)
Large Scrum Scrum (LSS или LeSS)
Enterprise Scrum
Lean Management
Agile Portfolio Management (APM)
Nexus

Ценности и принципы Agile

Управление проектами Agile основано на четырех ценностях и двенадцати принципах.Эти ценности и принципы уходят корнями в Agile Manifesto, который был создан в 2001 году семнадцатью менеджерами по разработке программного обеспечения [3]. Большая часть философии, лежащей в основе Agile Manifesto, возникла в результате реакции на то, что люди воспринимали как узкие места в процессах разработки программного обеспечения в то время.

Agile Values

Люди и взаимодействия важнее процессов и инструментов: Хотя инструменты и процессы важны, Agile Manifesto отдает приоритет людям, стоящим за ними.Наличие нужных людей и предоставление им возможности беспрепятственно взаимодействовать друг с другом может привести к успеху, на который инструменты сами по себе не способны.

Рабочее программное обеспечение важнее исчерпывающей документации: Создатели Agile считали, что важнее выполнить работу, чем увязнуть в этапах планирования и документирования.

Сотрудничество с клиентами в процессе переговоров по контракту: Вместо того, чтобы изолировать заинтересованные стороны от проекта, Agile стремится поддерживать с ними контакт на протяжении всего процесса создания.

Реагирование на изменения вместо следования плану: Следование плану, которому больше нет смысла следовать, может быть контрпродуктивным. Адаптация занимает центральное место в философии Agile.

Двенадцать принципов определяют раннюю и частую доставку, простоту, постоянную обратную связь, сотрудничество заинтересованных сторон и индивидуальную поддержку, среди других принципов, как столпов гибкого управления проектами [4].

Сертификаты Agile

Сертификаты в области управления проектами Agile могут подтвердить ваши знания Agile в целом или отдельных методологий Agile.Подумайте, какие навыки вы, вероятно, будете использовать на рабочем месте и в карьере, прежде чем принимать решение о том, какой сертификат получить.

Общие сертификаты Agile включают:

PMI-Agile Certified Practitioner (PMI-ACP)
ICAgile Certified Professional (ICP)
AgilePM Foundation — APMG

Популярные: Сертификация Agile в 2021 году

Вы также можете рассмотреть возможность сертификации в определенных рамках.Scrum — это наиболее часто используемый метод Agile, поэтому сертификация Scrum может быть хорошим началом. К ним относятся:

Certified ScrumMaster (CSM)
Professional Scrum Master (PSM)
Certified Scrum Product Owner (CSPO)

Подробнее: 7 In-Demand Scrum Master Certifications

Начало работы с Agile

Использование Agile на рабочем месте начинается с знакомства с основами.На Coursera есть несколько курсов, которые помогут вам начать работу.

Статьи по теме

Источники статей

1. Digital.ai. «15-е Ежегодное исследование состояния гибкой разработки, https://stateofagile.com/#». По состоянию на 29 марта 2021 г.

2. Digital.ai.

3. Манифест Agile. «Манифест для гибкой разработки программного обеспечения, https://agilemanifesto.org/». По состоянию на 29 сентября 2021 г.

4. Agile Manifesto. «Принципы Agile Manifesto, https: // agilemanifesto.

Что такое agile, scrum, kanban и в чем разница?

Определение

Примеры употребления

Слово экспертам

Что почитать по теме?

Что такое agile. Объясняем простыми словами — Секрет фирмы

Пример употребления на «Секрете»:

Нюансы

Факт

Статью проверила:

Итак, вы внедрили Agile: что теперь?

Agile и DevOps: преимущества, совместное использование, сравнение

Немного об Agile

Немного о DevOps

Agile и DevOps — чем отличаются

Совместное применение Agile и DevOps

На что обратить внимание при интеграции DevOps и Agile

Итог

Использование артефактов шаблона процесса Agile — Azure Boards

Please rate your experience

В этой статье

Планирование и отслеживание работы с помощью Agile

Вывод списка рабочих элементов с помощью запросов

Краткие советы по общим запросам

Отслеживание хода выполнения

Создание неплотных диаграмм

отчеты SQL Server

панели мониторинга SharePoint портала

Похожие статьи

Версии гибких процессов

Предопределенные запросы Agile Process

Невыполненная работа по продукту и запросы отзывов

Запросы планирования итераций

Поиск задач со сводными значениями

Workbooks

7 техник из Agile, которые помогут вам работать эффективнее – BYYD

1. Итеративное планирование

2. Итеративное выполнение задач

3. Пользовательские истории

4. Оценка и определение приоритетов

5. Демо, ретроспективы и стендапы

6. Коммуникация и сотрудничество

7. Командные структуры и роли

Курсы и вебинары Agile Scrum/Product Owner в Специалисте

IT-менеджмент

Расписание по курсам agile Scrum/Product Owner

Что такое AGILE? — Что такое SCRUM? — Agile FAQ’s

Скрам-мастер

Загрузить шпаргалку по ролям Scrum Master

Владелец продукта

Загрузить шпаргалку по роли владельца продукта

Команда

Загрузить шпаргалку по Scrum Team

Интеграция Agile & Scrum разработки и методологии

Управление проектом гибридной модели

5 советов по интеграции групп разработки agile и scrum с группами разработки водопада

Другие часто просматриваемые статьи

Изучите Scrum с помощью Jira Software

Scrum tutorial

Шаг 1.

Шаг 2. Создание пользовательских историй или задач в журнале обработки

Шаг 3. Создайте спринт

Шаг 4: Проведите собрание по планированию спринта

Шаг 5. Запустите спринт в Jira

Шаг 6: Ежедневно проводите стандартные встречи

Шаг 7: Просмотр диаграммы выгорания

Шаг 8: Просмотр отчета о спринте

Шаг 9: Проведите собрание по обзору спринта

Шаг 10: Проведите ретроспективное собрание спринта

Шаг 11: Завершите спринт в Jira

Шаг 12: Повторите с шага 2

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо от опыта

2001 — Автор манифеста Agile

После 2001 г. — Принятие началось массово, стало мейнстримом

Что такое Agile? Как бы вы дали определение Agile? Что означает Agile?

Вы действительно имеете в виду Scrum?

Чувствуя слона

Различные взгляды на Agile

Как вы определяете Agile?

Agile Values