Что такое scrum и как он работает

Team

The Team is a self-organizing and cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks, and how to allocate tasks to individuals, throughout the Sprint. The Team size should be kept in the range from five to nine people, if possible. (A larger number make communication difficult, while a smaller number leads to low productivity and fragility.) Note: A very similar term, “Scrum Team,” refers to the Team plus the ScrumMaster and Product Owner.

Для чего внедрять гибкие методологии

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

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

Плюсы методологии:

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

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

Маркетинг, продажи и Agile

А теперь, внимание. Моя любимая история

«Привет, мы теперь используем Scrum/Kanban/другое слово в ИТ, у нас наладились отношения между закачиком и технической командой, мы “быстрее бежим», и меньше делаем дорогих ошибок, но прибыль что-то у компании не растет».

А еще и затраты стали больше, правда ведь? Консультанты, агенты по трансформации, повышение зарплат (спецназ же) и так далее. А чего вы ждали-то? Вы разве к ИТ-отделу ходите за финотчетами?

Да, вы стали быстрее, вы стали делать меньше ошибок. И это только лишь фундамент. В маркетинге и продажах классические подходы тоже стремительно уходят в небытие, там появляются совершенно новые техники и новые иностранные слова:

• Growth hacking.
• Lean startup.
• Lean marketing / UX.

И с этими словами тоже нужно познакомиться, потому что там где заканчивается Agile, начинается Business Agility — а это уже история для отдельной статьи.

Внедрение в России

2017: Компании быстро осваивают Agile — исследование

В конце октября 2017 года компания ScrumTrek, специализирующаяся на внедрении agile-подходов, опубликовала результаты исследования, показавшие быстрое внедрение Agile в России. При этом технология выходит за пределы ИТ.

В ScrumTrek опросили почти 800 представителей малого, среднего и крупного бизнеса в 50 городах. 61% респондентов — это менеджеры проектов, миддл-менеджеры, скрам-мастера и другие руководители; 21 % от этого сегмента — топ-менеджеры и владельцы предприятий. 

Насколько Agile развита в России

Согласно опросу, 40% респондентов, начавших применять Agile не более 1,5 лет назад, уже внедрили гибкие методологии во всей или почти во всей компании. Лишь 20% организаций, применяющих Agile 2-3 года, продолжают пилотные проекты на уровне отдельных команд, но многие успели пойти дальше локальных экспериментов.

Около 50% компаний начали использовать Agile примерно назад. Около 41% организаций познакомились с гибкими методологиями около полутора лет назад.

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

Зачем российские компании внедряют Agile

Больше двух третей участников опроса (68%), работающих в компаниях с опытом внедрения Agile, либо представляют ИТ-бизнес, либо активно вовлечены в процесс разработки программного обеспечения. Вместе с тем доля респондентов, никак не связанных с информационными технологиями, достаточно велики и составляет 32%.

Почти половина этих опрошенных (40%) работают в страховых и финансовых компаниях, в том числе в банках, которые часто называют главным драйвером применения agile-подходов в последние несколько лет. 

Гибкость против жесткости: Agile vs Waterfall

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

Waterfall — водопадная (каскадная) модель разработки ПО

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

Гибкая разработка ПО серией итераций

Протестируем известные Agile практики

Регулярный рефакторинг кода

проясняет архитектуру, открывает путь к творчеству, обучению и совершенствованию

облегчает дальнейшее развитие продукта, ускоряет внесение изменений (eliminate waste)

замыкает петлю обратной связи: выявили проблемы – решаем их

Кросс-функциональные команды

нет потерь времени при передаче задач между командами

разносторонняя оценка, принятие решений, учитывающих все аспекты

быстрая обратная связь

прозрачность, взаимопомощь

Бэклог, user stories

наиболее ценные задачи делаем в первую очередь

механизм обратной связи заложен в приемку каждой user story; декомпозиция сторей до небольшого размера повышает оперативность обратной связи

Planning Poker (быстрая коллективная оценка задач)

предварительное обсуждение задач и плана работ, прозрачность

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

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

Планирование спринта

обсуждение задач непосредственно перед разработкой

наиболее ценные задачи делаем в первую очередь

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

Roles

The Product Owner

The product owner is a role team responsible for managing the product backlog in order to achieve the desired outcome that the team seeks to accomplish.

The product owner role exists in Scrum to address challenges that product development teams had with multiple, conflicting direction, or no direction at all with respect to what to build.

The Scrum Master

The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.

The name was initially intended to indicate someone who is an expert at Scrum and can therefore coach others.

The role does not generally have any actual authority. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.

The Development TeamThe development team consists of the people who deliver the product increment inside a Sprint.

The main responsibility of the development team is to deliver the increment that delivers value every Sprint. How the work is divided up to do that is left up to the team to determine based on the conditions at that time.

Резюме

Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и передаче заказчику готового продукта в конце проекта.

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

Оба подхода имеют свою зону эффективного применения. На основе своего опыта мы сформулировали ключевые различия подходов:

Характеристика	Классический подход	Agile
Поставка ценности (работающего результата)	Происходит в конце проекта	Осуществляется по мере реализации проекта в виде работающих элементов продукта. Используется итеративно-инкрементальный подход.
Проверка гипотез	Как правило, выполняется на предпроектной стадии, до старта проекта	Выполняется командой в ходе проекта для улучшения продукта. Часть гипотез может быть признана несостоятельными
Планирование	Детальное, до конца проекта. Для оценки сроков используется Метод критического пути. В проектах с высокой неопределенностью используется метод «набегающей волны».	Эмпирическое, на основе исторических данных о реализованных элементов продукта
Стиль менеджмента, руководства	Вертикаль управления: Управляющий комитет -> Куратор, Заказчик -> Руководитель проекта	Самоорганизация внутри команды. Плоская команда без внутренней иерархии.
Отношение к изменениям	Как правило имеет негативный характер – изменения как следствия реализации рисков и наступления проблем. Требует формального процесса по анализу последствий и пересчету критического пути проекта, анализа альтернатив.	Изменения являются частью процесса разработки. Источником изменений является в т.ч. более лучшее понимание продукта на основе опыта.
Тип мышления, отношений	Как правило определяется культурой организации, зачастую фиксированный mindset	Необходим гибкий mindset для успешной работы в среде с высокой неопределенностью
Метрики проекта	% реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта	Диаграмма сгорания задач (Burn down chart), Накопительная диаграмма реализованных функций (Burn Up Chart), Дата выхода на рынок (Time to market)
Наличие руководств, методик	Хорошо структурированы, детально описаны (PMBoK, PRINCE2). Отраслевые стандарты и практики.	Верхнеуровневые фреймворки (например, Скрам). Множество отдельных практик (ежедневное собрание, ретроспектива, спринт и др.)
Область эффективного применения	«Сложные системы» по модели Киневин (Cynefin) – много работ, агентов (стейкхолдеров). Продукт и требования к нему известны, состав работ может быть описан и зафиксирован. Границы проекта фиксированы.	«Запутанные системы» по модели Киневин (Cynefin) – не знаем продукт и/или процесс его создания. Состав работ проекта не определен. Границы проекта размыты

В следующей статье мы планируем рассказать о модели Киневин (Cynefin) для определения к какой группе относится ваш проект.

Scrum и Kanban – в чем отличия?

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

Чистый Scrum представляет собой более директивную методологию, в которой больше предписаний. А Kanban намного демократичнее и его проще внедрить. 

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

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

Также есть другие отличия:

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

Вызовы при переходе к Scrum

1. При отсутствии проектного менеджера, команда берет ответственность за то, как работает и решает затруднения.
2. Привыкнуть к новому режиму работы: планирование спринта и работа в его рамках вместо действий до дедлайна.
3. Разбивать процесс на мелкие задачи, чтобы они могли быть выполнены в ходе спринта. Если пользовательская история слишком большая, то разработчик подготовит проект слишком поздно, и тестировщик не успеет сделать свою работу до конца спринта. Даже если дефекты будут обнаружены, то времени останется очень мало, чтобы их исправить.
4. Использовать покер планирования, чтобы оценить сложность задачи и время, которое уйдет на ее выполнение. При начальном внедрении скрама потребуется несколько розыгрышей, чтобы участники команды сошлись в своих оценках.
5. Правильный выбор владельца продукта. Часто им назначается специалист, который уже имеет свои обязанности в компании. Поэтому он разрывается на два фронта. А если он не проходил обучение и плохо понимает, что ему предстоит дело в этой роли, то такой Product Owner лишь навредит проекту.
6. Добавлять новую пользовательскую историю в бэклог только с завершением уже имеющейся. Иначе список задач может стать невыполнимым в ходе спринта.Например, бэклог контент-плана блога в Worksection выглядит так. В спринт на месяц берется часть бэклога тем и раздаются авторам.
7. Соблюдать приоритетность пользовательских историй. Не менять их порядок, когда конец спринта близок.В Worksection каждой задаче, подзадаче и проекту можно присвоить приоритет и принимать решения о реализацции в соответствии с ним.
8. Когда решили перейти к скрам, то нужно следить, чтобы не вернуться к практикам и мышлению каскадной модели («Водопада»), где стадии реализуются строго последовательно.
9. Подобрать те инструменты Scrum, которые работают для данного проекта.
10. Не превратить ежедневные собрания в рутину или даже источник раздражения для команды.Простую коммуникацию можно оставить в комментариях к задачам, а на встрече обсуждать только важные аспекты спринта.

Practices

Events

Sprint

The Sprint is a timebox of one month or less during which the team produces a potentially shippable product Increment. Typical characteristics of Sprints:

• Maintain a consistent duration throughout a development effort
• A new Sprint immediately follows the conclusion of the previous Sprint
• Start date and end date of Sprint are fixed

Sprint Planning

A team starts out a Sprint with a discussion to determine which items from the product backlog they will work on during the Sprint.  The end result of Sprint Planning is the Sprint Backlog.

Sprint Planning typically occurs in two parts. In the first part, the product owner and the rest of the team agree on which product backlog items will be included in the Sprint.

In the Second Part of Sprint Planning, the team determines how they will successfully deliver the identified product backlog items as part of the potentially shippable product increment.  The team may identify specific tasks necessary to make that happen if that is one of their practices.  The product backlog items identified for delivery and tasks if applicable, makes up the Sprint Backlog.

Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint.

Daily Scrum

The Daily Scrum is a short (usually limited to 15 minutes) discussion where the team coordinates their activities for the following day. The Daily Scrum is not intended to be a status reporting meeting or a problem solving discussion.

Sprint Review

At the end of the Sprint, the entire team (including product owner) reviews the results of the sprint with stakeholders of the product. The purpose of this discussion is to discuss, demonstrate, and potentially give the stakeholders a chance to use, the increment in order to get feedback. The Sprint Review is not intended to provide a status report.  Feedback from the sprint review gets placed into the Product Backlog for future consideration.

Sprint Retrospective

At the end of the Sprint following the sprint review the team (including product owner) should reflect upon how things went during the previous sprint and identify adjustments they could make going forward. The result of this retrospective is at least one action item included on the following Sprint’s Sprint Backlog.

Artifacts

Product BacklogThe product backlog is an ordered list of all the possible changes that could be made to the product.  Items on the product backlog are options, not commitments in that just because they exist on the Product Backlog does not guarantee they will be delivered.

The Product Owner maintains the product backlog on an ongoing basis including its content, availability, and ordering.

Sprint BacklogThe Sprint Backlog is the collection of product backlog items selected for delivery in the Sprint, and if the team identifies tasks, the tasks necessary to deliver those product backlog items and achieve the Sprint Goal.

Increment

The increment is the collection of the Product Backlog Items that meet the team’s Definition of Done by the end of the Sprint.  The Product Owner may decide to release the increment or build upon it in future Sprints.

Definition of Done

The definition of done is a team’s shared agreement on the criteria that a Product Backlog Item must meet before it is considered done.

Что почитать, чтобы лучше разобраться в скраме

Скрам Гайд. Исчерпывающее руководство по Скраму: Правила Игры / Кен Швабер, Джефф Сазерленд

Руководство по применению скрама: описывает роли, мероприятия, артефакты скрама, и правила их использования. составлен и поддерживается соавторами скрам методологии.

Скрам. Революционный метод управления проектами / Джефф Сазерленд

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

Управление продуктом в Scrum. Agile-методы для вашего бизнеса / Роман Пихлер

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

Scrum и XP: заметки с передовой / Хенрик Книберг

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

Agile — про создание программных продуктов?!

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

Такой план невозможно составить, например, если у вас:

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

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

Погодите, погодите, то есть все эти практики и методики не имеет смысла применять в других областях, например — в продажах и маркетинге? Применять-то их можно, но нужно чётко понимать целесообразность этого процесса.

ScrumMaster

The ScrumMaster (sometimes written “Scrum Master,” although the official term has no space after “Scrum”) is the keeper of the process. The ScrumMaster is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. The ScrumMasters responsibilities include

• Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
• Improve the lives of the development Team by facilitating creativity and empowerment.
• Improve the productivity of the development Team in any way possible.
• Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
• Keep information about the Team’s progress up to date and visible to all parties.

In practical terms, the ScrumMaster needs to understand Scrum well enough to train and mentor the other roles, and educate and assist other stakeholders who are involved in the process. The ScrumMaster should maintain a constant awareness of the status of the project (its progress to date) relative to the expected progress, investigate and facilitate resolution of any roadblocks that hold back progress, and generally be flexible enough to identify and deal with any issues that arise, in any way that is required. The ScrumMaster must protect the Team from disturbance from other people by acting as the interface between the two. The ScrumMaster does not assign tasks to Team members, as task assignment is a Team responsibility. The ScrumMaster’s general approach towards the Team is to encourage and facilitate their decision-making and problem-solving capabilities, so that they can work with increasing efficiency and decreasing need for supervision. The goal is to have a team that is not only empowered to make important decisions, but does so well and routinely.

Что сделали

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owne

Расстались с руководителями

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

Важно!

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

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

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

Ввели обсуждение ретроспектив

Это дискуссия о том, что пошло не так и что можно улучшить

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

Договорились о процессах и технологиях

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

Все это влияет на скорость и слаженность работы команды.

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

Предложения стали оценивать в деньгах

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

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

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

Lifecycle

Scrum is a framework that allows development teams flexibility to respond to changing situations. This framework has sufficient control points in place to ensure the team does not stray from the desired outcome, and that issues can be identified and resolved and process adjustments made while the effort is still underway.

The Scrum Lifecycle starts with a prioritized backlog, but does not provide any guidance as to how that backlog is developed or prioritized.

The Scrum Lifecycle consists of a series of Sprints, where the end result is a potentially shippable product increment. Inside of these sprints, all of the activities necessary for the development of the product occur on a small subset of the overall product.  Below is a description of the key steps in the Scrum Lifecycle:

1. Establish the Product Backlog.
2. The product owner and development team conduct Sprint Planning. Determine the scope of the Sprint in the first part of Sprint Planning and the plan for delivering that scope in the second half of Sprint Planning.
3. As the Sprint progresses, development team perform the work necessary to deliver the selected product backlog items.
4. On a daily basis, the development team coordinate their work in a Daily Scrum.
5. At the end of the Sprint the development team delivers the Product Backlog Items selected during Sprint Planning. The development team holds a Sprint Review to show the customer the increment and get feedback.  The development team and product owner also reflect on how the Sprint has proceeded so far and adapting their processes accordingly during a retrospective.
6. The Team repeats steps 2–5 until the desired outcome of the product have been met.

Роли в процессе SCRUM

По методике Scrum в производственном процессе были определенные роли, разбитые на две группы «свиней» и «кур», с 2011 метафоры «свиней» и «кур» отсутствуют в Scrum, см. .. Эти названия были использованы из-за шутки[источник не указан 573 дня]

Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им все равно, будет ли проект удачным или нет, на них это мало отразится

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

Основные роли (Core roles) в методологии SCRUM(«Свиньи»)

«Свиньи» полностью включены в проект и в процесс SCRUM.

Менеджер-мастер SCRUM (SCRUM Manager) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов SCRUM, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения процесса SCRUM. Таким образом менеджер-мастер SCRUM есть сервант-лидер (Servant Leader) команды.

Главным инструментом менеджер-мастера SCRUM является чемодан фасилитатора, куда входят коробочки для карточек, для аксессуаров, для маркеров, клейкие карты, булавки, маркеры, канцелярский нож, клейкая лента.

Владелец продукта SCRUM (SCRUM Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

Команда разработчиков (SCRUM Development Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды составляет от 5 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме команды разработчиков, менеджер-мастера и владельца продукта не может вмешиваться в процесс разработки на протяжении спринта. кросс-функциональность команды позволяет максимально эффективно планировать затраты на реализацию бизнес-требований и в сжатые сроки поставлять реально работающие бизнес-приложения в полном соответствии с изменяющимися требованиями заказчика.

Команда SCRUM (SCRUM Team) – это, собственно, собирательный образ команды, состоящей из Development Team, SCRUM Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Дополнительные роли (Ancillary roles) в методологии SCRUM(«Куры»)

• Пользователи (Users)
• Стекхолдеры (Stakeholders) — лица, которые инициируют проект (бизнес-заказчики) и для кого проект SCRUM будет приносить выгоду. Они вовлечены в схватку только во время обзорного совещания по спринту (Sprint Review).

Начните с бэклога

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

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

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4

Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

Об этом курсе

Недавно просмотрено: 49,426

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

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

Курс включает не только видео и тесты. Наибольшую пользу вы получите, выполняя разнообразные задания: например, создавая свою скрам-доску или анализируя ситуации из вашей работы с точки зрения Agile-принципов.

Большое внимание в курсе уделяется практическим вопросам типа «Как “продать” Agile руководству и команде?», а также путям вашего профессионального и карьерного роста в гибких организациях. Курс полезен всем, кто хочет применять Agile и Scrum в своей работе, – от программиста до технического директора

Но максимальный объем знаний и навыков от курса получат тимлиды, менеджеры проектов и другие руководители: для них в курсе предусмотрены дополнительные задания, например, «Устранение пороков вашей команды», «Чек-лист правильного Скрама»

Курс полезен всем, кто хочет применять Agile и Scrum в своей работе, – от программиста до технического директора. Но максимальный объем знаний и навыков от курса получат тимлиды, менеджеры проектов и другие руководители: для них в курсе предусмотрены дополнительные задания, например, «Устранение пороков вашей команды», «Чек-лист правильного Скрама».

Сертификат, ссылками на который можно делиться с другими людьми

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

100% онлайн

100% онлайн
Начните сейчас и учитесь по собственному графику.

Гибкие сроки

Гибкие сроки
Назначьте сроки сдачи в соответствии со своим графиком.

Начальный уровень
Начальный уровень

Часов на завершение
Прибл. 13 часов на выполнение

Доступные языки

Русский
Субтитры: Русский