Scrum: гибкость в жестких рамках Текст научной статьи по специальности «Экономика и бизнес»
Аннотация научной статьи по экономике и бизнесу, автор научной работы — Андреева Розалия Николаевна, Синяева Ольга Юрьевна
На сегодняшний день традиционные методы проектного управления устаре-вают, именно поэтому необходимо внедрять во многие сферы жизни современные гибкие методологии , одной из которых является Scrum , которая позволяет повысить эффектив-ность и продуктивность работы в целом. В данной статье представлены основные прин-ципы Scrum , исследование опыта внедрения данной методологии в Google, Информационной службе штата Вашингтон, Информационно-аналитическом центре Санкт-Петербурга, Администрации Главы Республики Саха (Якутия) и Правительства Республики Саха (Якутия), а также в одной из школ нидерландского города Алфен-ан-ден-Рейн.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Похожие темы научных работ по экономике и бизнесу , автор научной работы — Андреева Розалия Николаевна, Синяева Ольга Юрьевна
Методологии управления программными проектами в подготовке IT-специалистов
Методический инструментарий применения Scrum в реализации проектной деятельности
Технология управления проектами и проектными командами на основе методологии гибкого управления проектами Agile
Управление созданием образовательных продуктов с помощью метода Scrum
Границы применимости компонентов Scrum
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.
SCRUM: FLEXIBILITY WITHIN A RIGID FRAMEWORKS
Nowaday, traditional methods of project management are becoming obsolete, which is why it is necessary to introduce modern flexible methodologies into all spheres of life, one of which is Scrum , which improves the efficiency and productivity of the work as a whole. The article presents the basic principles of Scrum , a study of the experience of implementing this methodology in Google, the Washington Information Service, the Information and Analytical Center of St. Petersburg, the Administration of the Head of the Republic of Sakha (Yakutia) and the Government of the Republic of Sakha (Yakutia), and in one of the schools of the Dutch city Alphen-an-den-Rijn.
Текст научной работы на тему «Scrum: гибкость в жестких рамках»
SCRUM: ГИБКОСТЬ В ЖЕСТКИХ РАМКАХ
Аннотация. На сегодняшний день традиционные методы проектного управления устаревают, именно поэтому необходимо внедрять во многие сферы жизни современные гибкие методологии, одной из которых является Scrum, которая позволяет повысить эффективность и продуктивность работы в целом. В данной статье представлены основные принципы Scrum, исследование опыта внедрения данной методологии в Google, Информационной службе штата Вашингтон, Информационно-аналитическом центре Санкт-Петербурга, Администрации Главы Республики Саха (Якутия) и Правительства Республики Саха (Якутия), а также в одной из школ нидерландского города Алфен-ан-ден-Рейн.
Ключевые слова: менеджмент, управление проектами, гибкая методология, Agile, Scrum, эффективность.
SCRUM: FLEXIBILITY WITHIN A RIGID FRAMEWORKS
Abstract. Nowaday, traditional methods of project management are becoming obsolete, which is why it is necessary to introduce modern flexible methodologies into all spheres of life, one of which is Scrum, which improves the efficiency and productivity of the work as a whole. The article presents the basic principles of Scrum, a study of the experience of implementing this methodology in Google, the Washington Information Service, the Information and Analytical Center of St. Petersburg, the Administration of the Head of the Republic of Sakha (Yakutia) and the Government of the Republic of Sakha (Yakutia), and in one of the schools of the Dutch city Alphen-an-den-Rijn. Keywords: management, project management, flexible methodology, Scrum, Agile, efficiency.
В современном быстро развивающемся мире мы начали больше уделять внимания общению с людьми, чем выстраиванию жестких процессов. Мы стали сосредотачиваться на конечном продукте, а не зацикливаться на документации, которую редко кто внимательно читает. Мы предпочитаем выстраивать доверительные отношения с нашими заказчиками вместо предъявления требований и ограничений, прописанных условиями договора. И наконец, мы перестали бояться изменений, а наоборот открылись им, ведь мир не стоит на одном месте. Именно поэтому перед многими компаниями, связанными с проектной деятельностью, сейчас стоит нелегкий выбор: закрыться от всего, что их окружает, и придерживаться традиционных методов управления, или достигать любых вершин с внедрением гибких методологий управления проектами.
История гибких методологий начинается с февраля 2001 г., когда на лыжном курорте The Lodge at Snowbird в горах Юты встретились 17 успешных менеджеров по управлению проектами, чтобы выяснить, что есть общего между их подходами и выработать новую методологию. В результате появился набор ценностей, на которых базируется вся их работа. Так появился на свет Agile-манифест, который включал 4 главных идеи:
— люди и взаимодействие важнее процессов и инструментов;
— работающий продукт важнее исчерпывающей документации;
— сотрудничество с заказчиком важнее согласования условий контракта;
— готовность к изменениям важнее следования первоначальному плану [2].
Суть гибких методологий заключается в разделении задач проекта на итерации (части) с детально продуманным планированием и четко ограниченным временем выполнения (1-4 недели). Все решения принимаются в зависимости от промежуточных прозрачных результатов проекта, то есть каждый член команды в режиме реального времени следит за статусом работы по проекту, его изменениями и возникшими проблемами.
Если рассмотреть каскадную (водопадную) модель управления проектами (рис. 1), то можно заметить, что такая система не в состоянии быстро реагировать на изменения и адаптироваться под новые реалии времени, поскольку принцип данной модели подразумевает разделение рабочего процесса на поочередные задания, которые должны быть выполнены в строгой последовательности: перед началом новой задачи необходимо завершить пре-
© Андреева Р.Н., Синяева О.Ю., 2018
УДК 005.9 JEL M16 O22
Андреева Р.Н. Синяева О.Ю.
Andreeva Rozaliia Sinyaeva Olga
дыдущую. Более того, отношение каскадной модели к изменениям крайне негативное, так как любые изменения могут быть внесены только после завершения всего процесса разработки. В связи с этим возникает основной недостаток водопадной модели — ее немобильность. Agile, в свою очередь, славится своей гибкостью: возможностью быстрого реагирования и внесения корректировок в программный продукт. Именно поэтому многие компании делают свой выбор в пользу гибкого подхода.
Рис. 1. Каскадная (водопадная) модель управления проектами.
На данный момент существует огромное количество гибких методологий. Все они похожи друг на друга, однако каждая из них имеет свою особенность. Так, например, Lean добавляет к принципам Agile схему потока операций с целью выполнения всех итераций одинаково качественно. Это позволяет параллельно выполнять несколько задач на разных этапах, в результате чего повышается гибкость и увеличивается скорость исполнения проектов [12]. Kanban, созданный инженером Toyota Тайити Оно еще в 1953 г., охотно применяются в различных компаниях и сегодня. Данный подход похож на схему промышленного производства, чем и привлекателен для своих сторонников. Его особенностью является то, что в этом гибком методе разрешается оставить неоконченную задачу на одном из этапов, если появится что-то более важное, чей приоритет окажется выше. Более того, при этом подходе нет четкой структуры, поскольку нет ограничений во времени спринтов, и есть только одна роль — владелец продукта [1].
Тем не менее, самым известным и популярным среди гибких подходов управления проектами сегодня является Scrum, поскольку он более структурирован в своем семействе, так как сочетает элементы водопадного процесса и идеи гибкого подхода. Согласно результатам исследования Agile survey о популярности гибких методологий Scrum используется в несколько раз чаще, чем его аналоги [2] (см. рис. 2).
Методология Scrum впервые предложена Джефом Сазерлендом и Кеном Швабером в 1990-е гг. в виде четко формализованного документа, названного «Руководство по Scrum». Scrum — новый подход к решению вопросов, принципиально отличающийся от традиционных методов управления проектами. Его принцип аналогичен эволюционным, адаптивным, самокорректирующимся системам [9].
Если кратко охарактеризовать Scrum, то это один из процессов Agile, позволяющий сконцентрироваться на самых важных задачах в строго ограниченные сроки. В результате чего каждые 2-4 недели все желающие (заинтересованные лица) могут увидеть работающий функционал и решить: выпускать его или же улучшать в следующей итерации (спринте).
■ Scrum Scrum+XP ■ Kanban ■ Lean Другие
Рис. 2. Популярность гибких методологий.
Перед тем как начать работать, вовлеченные в проект люди выстраивают глобальные цели и стратегию, с помощью которой впоследствии будут достигать цели. После этого стороны (заказчик и исполнитель) обговаривают рамки проекта и дату начала первой итерации. Итерация в Scrum получила название спринт, который длится обычно 1-4 недели.
Scrum основывается на эмпирических процессах, то есть знание приходит лишь с опытом, а решения могут приниматься на основании известных действий. Scrum использует итеративно-инкрементальный подход для оптимизации прогнозируемости и управления рисками [11].
Scrum состоит из трех элементов: ролей, артефактов и процессов (табл. 1). Разберем каждый из компонентов более подробно.
Роли Артефакты Процессы
Владелец продукта Scrum-мастер Команда Беклог продукта Беклог спринта Инкремент продукта Планирование спринта Обзор спринта Ретроспектива Scrum-митинг Спринт
Составлено авторами по материалам исследования
В свою очередь, роли проекта подразделяют на владельца продукта, Scrum-мастера и команду.
1. Владелец продукта (product owner) в большинстве случаях является заказчиком. Он отвечает за беклог (backlog) продукта. Основной его задачей выступает предъявление четких требований к продукту, чтобы максимально дать понять разработчикам, что он хочет видеть в конце проекта. Именно он выставляет приоритеты: то, что является наиболее срочным и важным на данный момент.
2. Scrum-мастер играет ключевую роль в работе над проектом. Ведь именно в его руках лежит ответственность за понимание сущности всего процесса, поддержания благоприятной атмосферы в команде. Его основная
задача — обеспечение слаженной работы разработчиков и помоь при возникновении каких-либо проблем. В его компетенцияю также входит ежедневный контроль за происходящими событиями, чтобы они проводились регулярно и с высокой эффективностью.
3. Команда (team) — прежде всего разработчики, чье оптимальное количество составляет 7±2 человека. В соответствии с The Scrum guide команда должна быть самоорганизующейся (никто не вправе вмешиваться в их преобразование product backlog в продукт), многофункциональной, а также должна отвечать за совместное выполнение работы коллективно, а не индивидуально.
Рассмотрим артефакты в методологии Scrum. Принято выделять беклог продукта, беклог спринта и инкремент (increment) продукта. Рассмотрим каждый из них подробно.
Беклог продукта (product backlog) — список требований, расставленных по приоритету, с оценкой трудозатрат. Он создается, как сказано выше, владельцем продукта, или заказчиком, после проведения анализа потребностей рынка. Всем требованиям выставляются по степени важности (приоритеты). В ходе работы над проектом владелец продукта может корректировать беклог. Именно эта особенность делает подход гибким. Выбранные для спринта требования заносят в беклог спринта. Беклог продукта состоит из пользовательских историй (user stories). Они, в свою очередь, делятся на: идентификатор (порядковый номер), название, важность, предварительную оценку, метод демонстрации, примечания.
Беклог спринта (sprint backlog) — внесенные требования из беклога продукта с высокой степенью важности и суммарной оценкой, которые должны быть выполнены в текущем спринте. В отличие от беклога продукта, он не может быть изменен и подкорректирован в ходе работы над проектом, то есть остается фиксированным на время конкретной итерации. Задачи из беклога спринта могут быть исключены только в непредвиденных форс-мажорных ситуациях [8].
Более того, для ведения учета объема выполненной и предстоящей работы используется диаграмма сгорания. Перед любой итерацией команда оценивает количество усилий, времени, необходимых для выполнения задач из беклога спринта. После завершения каждой задачи Scrum-мастер пересчитывает количество невыполненных работ на данный спринт. Все эти оставшиеся задачи отмечают на графике, по оси абсцисс которого отмечена длительность спринта, а по оси ординат — количество оставшейся работы. Диаграмма сгорания выступает отличным вспомогательным инструментом, которая позволяет оценить траекторию работы команды: верно или неверно команда движется в рамках конкретного спринта.
Инкремент продукта — это необходимый результат работы каждого спринта. Иными словами, это объединенная версия продукта, которая поддерживается на высоком уровне качества, чтобы поставлять продукт пользователям, если владелец продукта решит, что это будет целесообразно.
Теперь перейдем к процессам методологии Scrum, которые состоят из Scrum-митинга планирования и обзора спринта, а также ретроспективы. Рассмотрим их более детально.
Все начинается с планирования спринта. В самом начале владелец продукта презентует беклог продукта, где собраны все требования к проекту со степенью важности (с расставленными приоритетами). Следует акцентировать внимание на том, что у каждого продукта должен быть только один беклог и один владелец продукта. Затем команда отбирает наиболее важные задачи и вносит их в беклог спринта с определением необходимого количества времени на выполнение данных задач. И только потом они приступают к обсуждению путей реализации требований заказчика. Планирование спринта обычно длится 3-4 часа, в результате чего достигается договоренность между владельцем продукта и командой по поводу уверенности правильного восприятия и понимания требований, количества задач, которые необходимо реализовать, дат демонстрации готового продукта и мест, времени проведения Scrum-митинга. Существуют еще тонкости планирования: фокус-фактор, то есть насколько разработчик сконцентрирован на задании; «все оценивают всё» — делается для распространения опыта; «покер-планирование» — разработчики играют в покер для того, чтобы индивидуально оценить, сколько дней, в идеале, они готовы потратить на решение той или иной задачи. Более того, в Scrum есть возможность парной работы (парного программирования), что обеспечивает распространение опыта, умений и навыков во всем коллективе.
После планирования организовывают так называемые Scrum-митинги (планерки) — общее собрание всех вовлеченных в проект людей для обсуждения работы и выявления проблем, которое обычно длится 15 минут. Каждый член команды должен ответить на следующие вопросы:
— Что было сделано вчера?
— Что я планирую сделать сегодня?
— С какими трудностями я столкнулся?
При выявлении проблем, Scrum-мастер должен сделать все от него зависящее для их устранения после окончания планерки. Scrum-митинги особо важны в Scrum, так как эта 15-минутная встреча позволяет всем членам команды быть в курсе дел, еще раз переоценить задачи, а также получить новые. При получении новых задач существуют некоторые тонкости: задачи достаются наименее компетентному исполнителю (для распределения опыта), проводится выстраивание объективного группового мнения работе конкретного исполнителя для исключения неправильного понимания требований («паучье чутье»).
Далее, проводится обзор спринта — показ владельцу продукта (или заинтересованным лицам) функциональности продукта. Основная цель данного процесса — получение обратной связи (feedback) (рис. 3). На встрече обзора спринта может присутствовать любой желающий.
Составлено авторами по материалам исследования
Рис. 3. Организация обратной связи в рамках обзора итогов спринта.
И наконец, после обзора спринта проводят ретроспективу, но, в отличие от обзора спринта, здесь могут присутствовать только члены команды, Scrum-мастер и владелец продукта. Длительность встречи зависит от количества обсуждаемых пунктов, обычно она варьируется от 15 минут до 3-х часов. В ходе ретроспективы разработчики делятся между собой проблемами, с которыми столкнулись в процессе работы над проектом, опытом, который получили в прошедшем спринте, или мнениями о том, как можно было бы улучшить процесс в следующем спринте.
На сегодняшний день многие крупные компании начинают внедрять в свой рабочий процесс гибкие методологии. Самым ярким примером среди компаний, которые придерживаются Scrum, является Google. Рассмотрим их методы, приемы более подробно.
Все началось с появления значимой личности в истории данной компании — Уэйна Розинга в 2001 г. До этого Google не применяла в своих технологиях методологию Scrum, возможно, поэтому сталкивалась с огромным количеством проблем при реализации продуктов. Одной из проблем выступала перегруженность членов команды в одном проекте и их некомпетентность, из-за чего решения принимались не так быстро, как хотелось бы, в результате сроки заканчивались, а продукты так и не разрабатывались до конца. Тогда Уэйн предложил заменить менеджеров на инженеров — профессионалов своего дела, затем разбил их по командам и назначил в каждой команде ответственное лицо — руководителя проекта. Ключевым изменением стало также то, что команда имела полное право корректировать продукт в процессе работы, никого об этом не спрашивая. Более того, Розинг говорил, что нельзя ни в коем случае допустить централизованность, при которой все приказы и команды будут диктоваться сверху. Напротив, он допускал, что нужно дать команде полную свободу действий, ведь именно она
хорошо знает, что нужно сделать и как работать. Все это совпало с 5, 9, 12 принципами Agile [3]. В результате правильно построенной работы был создан проект Google AdWords, который на сегодняшний день является основным доходом данной компании [10].
В государственном секторе также используют гибкую методологию Scrum. Президент и председатель Сбербанка России Г. О. Греф, побывав в Кремниевой долине, узнал, что правительство Норвегии два министерства США упорно начали изучать Agile, в том числе Scrum, в то время как Россия только начинает внедрять гибкие методологии в сфере бизнеса [5].
Обычно в систему государственного управления внедряют водопадную модель управления проектами, при которой необходимо четко следовать определенному набору шагов на протяжении жизненного цикла. Этот метод больше подходит государственной сфере, так как все идет постепенно, имеется под руками подробная документация, а требования всегда согласованы и утверждены. Но бывают ситуации, когда необходимо реализовать проект при отсутствии четкого плана и понимания, то есть действовать в условиях повышенной неопределенности. Обычно это бывает при создании государственных информационных систем, сайта, оптимизации процессов оказания государственных услуг и так далее. В данном случае Scrum может выступить эффективным средством.
Именно поэтому в свое время информационная служба штата Вашингтон внедрила в свою работу методику Scrum. Были сформированы Scrum-команды, а для максимальной прозрачности все единогласно пришли к решению снести стены в рабочем помещении. Более того, проводили ежедневные планерки (Scrum-митинги), еженедельно выводили новый готовый продукт и опробовали его на практике, в необходимых случаях прерывались на корректировку плана стратегии. Начав с себя в качестве примера, информационная служба штата в настоящее время активно занимается внедрением Scrum уже во все бюрократические системы штата [9].
Однако, каким бы эффективным на первый взгляд не казался Scrum, у него есть свои недостатки. Во-первых, это проблемы с заключением договоров. Как мы знаем, данная методология не подразумевает наличие фиксированного бюджета и фиксированного технического задания, что, в свою очередь, затрудняет процесс юридического оформления договоренностей. На данный момент в России многие заказчики пока не готовы идти на гибкость бюджета и технического задания, в то время как на западе все клиенты давно перешли на такую систему работы. Эту проблему можно решить следующим образом: заключать договоры на разработку не целого проекта, а его этапов и при этом устанавливать дополнительные соглашения на возникшие в ходе работы поправки и корректировки. И тогда вполне возможно, что через несколько лет Scrum заработает в нашей стране. Во-вторых, данная гибкая методология имеет огромное количество исключений: риск бесконечных изменений продукта, огромная зависимость от уровня квалификации и опыта работы команды проекта, невозможность точного подсчета итоговой стоимости проекта (по времени, по финансовым средствам). Ввиду этого, она неприменима для государственных заказов, а также при наличии некомпетентных специалистов, заниженных сроках или бюджете. При таком раскладе дел другие методологии хотя бы завершат проект, пусть и на низком уровне, в то время как Scrum априори не сработает. Напротив, во всех остальных случаях он превосходит традиционные методы управления проектами.
В настоящее время на российском рынке Scrum стал эффективно внедряться в большие корпоративные проекты с протяженностью год и более, особенно в банковском секторе, что неудивительно после выступления Г. О. Грефа на Гайдаровском форуме [4]. Более того, в нашей стране есть успешные практики внедрения Scrum в государственный сектор. Так, например, с 2009 г. в Информационно-аналитическом центре Санкт-Петербурга в ряде проектов по созданию и развитию государственных информационных систем успешно применяют гибкие подходы Scrum к управлению проектной деятельностью и ведению разработки. За это время у организации накопился опыт применения гибких методов для реализации государственных контрактов в существующей нормативно-правовой базе. Были достигнуты следующие результаты: кардинально сократились сроки создания новых продуктов, изменения и приоритеты оперативно управлялись, не происходили ситуации, при которых денежные ресурсы выходили за рамки бюджета, значительно повысилось качество продукта [7].
Некоторые государственные структуры внедряют Scrum, адаптировав их под свои условия. Так, например, Департамент проектного управления Администрации Главы Республики Саха (Якутия) и Правительства Республики Саха (Якутия) частично внедрил Scrum в свой рабочий процесс. С понедельника по четверг ровно в 9 часов 15 минут утра проводятся Scrum-митинги для того, чтобы каждый сотрудник департамента ответил на три клю-
чевых вопроса данной методологии. Итерации длятся в зависимости от сложности задач либо одну неделю, либо две. Соответственно, после окончания итерации, организовываются ретроспектива и планирование следующего спринта. Департамент проектного управления Якутии использует Scrum для реализации проекта по внедрению проектного управления в исполнительные органы государственной власти.
Если Scrum так успешен и популярен в частных и государственных структурах, может ли эта методология оказать такой же положительный эффект в социальной сфере? Для этого разберем опыт внедрения Scrum в образовательную сферу Голландии.
В одной из школ нидерландского города Алфен-ан-ден-Рейн учитель химии Вилли Вейнандс, ознакомившись с методологией Scrum, загорелся идеей попробовать внедрить его в образовательный процесс. Он повесил на доске бумажный плакат, который весь был усыпан стикерами и разделен на столбики: «все задачи», «необходимо выполнить», «в работе», «сделано». Под данными столбиками располагались еще четыре записи: «характеристики выполненного», «кривая» — диаграмма исполнения заданий, «взгляд в прошлое» — ретроспектива и «динамика» — наработанный объем баллов. Более того, мистер Вейнандс разделил учебный курс на четырехнедельные и пятинедельные спринты, после завершения которых сдается тест. Во время занятий Вейнандс ходил по классу и наблюдал за перемещением разноцветных стикеров на Scrum-доске, рассматривал графики и анализировал диаграммы выполнения задач. Если вдруг он заметил, что кто-то из учеников столкнулся с трудной задачей, которую он не в силах решить, то подходил к нему и помогал с трудной ситуацией. Что касается контроля правильного выполнения и понимания заданий, то Вилли наугад выбирал любую задачу из столбика «выполнено» и проверял знания каждого из присутствующих в классе. Если хотя бы один школьник не смог ответить на его вопросы, то он возвращал этот стикер в столбик «необходимо выполнить». Получается, у класса рождался командный дух. Такой подход получил название EduScrum [6].
А чем нам может помочь Scrum в бытовой жизни? Разберем эффективность внедрения Scrum на примере ремонта дома. Ни для кого не секрет, что ремонт дома — неприятное дело, поскольку в большинстве случаев он занимает вдвое больше времени, чем планировалось, и, соответственно, обходится вдвое дороже. Всего этого можно избежать, если вовремя отнестись с полным серьезом и внедрить Scrum. Приведем пример. Сосед Джефа Сазерленда однажды решил полностью отремонтировать свой дом: сменить дизайн всех комнат, заменить всю технику, провести новую проводку, обновить везде краску. При этом он поставил перед собой срок в 6 недель, который сначала кажется нереальным. В первую очередь, он решил разделить период ремонта на 6 итераций — получается, один спринт у него длился ровно неделю. После этого подготовил проекты на неделю, которые должны были привести в состояние «сделано», а в трейлере рабочих, стоявшем перед домом, повесил Scrum-доску. Каждое утро он проводил Scrum-митинги. В итоге все были в курсе того, кто чем был занят, и у кого какие проблемы возникали. Например, нехватку нужных материалов обнаруживали до того, как их отсутствие начинало влиять на процесс. Пожалуй, самым главным преимуществом ежедневных Scrum-митингов стало то, что работники были освобождены от зависимости. Обычно на любом строительном проекте огромное количество времени тратится на ожидания, когда будет завершена одна часть работы. В конце концов, он уложился в срок и остался довольным ремонтом.
Таким образом, благодаря постоянному анализу выполненной работы и возможностью вносить корректировки между спринтами Scrum является продуктивной гибкой методологией, позволяющей эффективно достигать результатов. Данная методология подразумевает, что члены команды вольны в своих действиях: отсутствует давление сверху, существует возможность самостоятельного определения и выбора приоритетных задач. Все это способствует тому, что участники проекта чувствуют себя не только полностью вовлеченными в процесс, но и наделенными ответственностью, ведь от них зависит качество продукта. А это, в свою очередь, стимулирует их активность и энтузиазм. Более того, самостоятельное определение объема работ и времени, которое понадобится на их выполнение, сводит на минимум риски отклонения от графика, в отличие от традиционного подхода управления, когда все диктуется сверху, ведь никто лучше самих членов команды не знает, за какой срок они справятся с данной работой. Немаловажным преимуществом также является возможность отслеживания в режиме реального времени процесса работы. Это позволяет быстро обнаруживать и исправлять возникшие ошибки на самых ранних этапах. При внедрении данной гибкой методологии в российских компаниях, государственном секторе, социальной сфере повысятся эффективность и продуктивность работы в целом.
1. Андерсон, Д. Канбан. Альтернативный путь в Agile / пер. с англ. А. Карабейников — М.: «Манн, Иванов и Фербер», 2017.- 350 с.
2. Вольфсон, Б. Гибкие методологии разработки, версия 1.2 [Электронный ресурс]. — СПб.: Питер, 2012. — 112 с. — 1 эл. опт. диск (CD-ROM).
3. Вольфсон, Б. Гибкое управление проектами и продуктами. — СПб.: Питер, 2015. — 144 с.: ил.
4. Выступление Германа Грефа на Гайдаровском форуме 2016 [Электронный ресурс]. — Режим доступа: http://tocpeople. com/2016/01/gref-gajdarovskij-forum-2016/ (дата обращения: 06.02.2018).
5. Греф: России требуется новая система управления [Электронный ресурс]. — Режим доступа: http://www.bbc.com/russian/ business/2016/05/160522_gref_skolkovo_lecture (дата обращения: 08.02.2018).
6. Методика Scrum в образовательной системе (EduScrum). [Электронный ресурс]. — Режим доступа: https://webformula. pro/article/metodika-scrum-v-obrazovatelnoy-sisteme-edu-scrum/ (дата обращения: 09.02.2018).
7. Первые результаты применения гибких подходов в государственном секторе РФ. [Электронный ресурс]. — Режим доступа: http://pmolimp.ru/files/content/1218/3-dubrovin-i-s-pervye-rezultaty-primeneniya-gibkih-podhodov-v-gosudarstvennom-sektore-pdf.pdf (дата обращения: 06.02.2018).
8. Родионов, В. В. Проблемы внедрения проектного управления, связанные с документированием и регламентированием деятельности / В. В. Родионов, Т. А. Суетина // Теоретические и прикладные аспекты современной науки. — 2015. — № 7 (7). -С. 126-128.
9. Сазерленд, Д. Scrum. Революционный метод управления проектами, 2-е изд. / пер. с англ. М. Гескина — М:. «Манн, Иванов и Фербер», 2017.- 288 с.
10. Agile Project Management: Lessons Learned at Google. [Электронный ресурс].- Режим доступа: https://www.infoq.com/ presentations/Agile-Management-Google-Jeff-Sutherland (дата обращения: 07.02.2018).
11. Schwaber, Ken, Sutherland, Jeff. The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game, 2016 — 23 p.
12. Scaling Agile to Work with Distributed Teams [Online] / auth. Cohn Mike. Режим доступа: http://www.mountaingoatsoftware. com/system/presentation/file/133/Scaling-Distributed- Agile-Cohn-NDC2010.pdf (дата обращения: 06.02.2018).
1. Anderson D. Kanban. Al’ternativnyj put’ v Agile [Kanban. An Alternative Path to Agility]. Moscow, 2017. 350 p.
2. Vol’fson B. Gibkie metodologii razrabotki, versija 1.2 [Flexible Product Development, version 1.2]. Saint Petersburg, 2012. 112 p.
3. Vol’fson B. Gibkoe upravlenie proektami i produktami [Flexible Project and Product Management]. Saint Petersburg, 2015. 144 p.
4. Vystuplenie Germana Grefa na Gajdarovskom forume 2016 [Speech by German Gref at the Gaidar Forum 2016]. Available at: http://www.bbc.com/russian/business/2016/05/160522_gref_skolkovo_lecture (accessed 06.02.2018).
5. Gref: Rossii trebuetsja novaja sistema upravlenija [Gref: Russia needs a new management system]. Available at: http://www.bbc. com/russian/business/2016/05/160522_gref_skolkovo_lecture (accessed 08.02.2018).
6. Metodika Scrum v obrazovatel’noj sisteme (EduScrum) [The Scrum method in the educational system (EduScrum)]. Available at: https://webformula.pro/article/metodika-scrum-v-obrazovatelnoy-sisteme-edu-scrum/ (accessed 09.02.2018).
7. Pervye rezul’taty primenenija gibkih podhodov v gosudarstvennom sektore RF [First results of applying flexible approaches in the public sector of the Russian Federation]. Available at: http://pmolimp.ru/files/content/1218/3-dubrovin-i-s-pervye-rezul-taty-primeneniya-gibkih-podhodov-v-gosudarstvennom-sektore-pdf.pdf (accessed 06.02.2018).
8. Rodionov V. V Problemy vnedrenija proektnogo upravlenija, svjazannye s dokumentirovaniem i reglamentirovaniem dejatel’nosti [Problems of implementing project management related to documenting and regulating activities] / V V. Rodionov, T. A. Suetina // Teoreticheskie i prikladnye aspekty sovremennoj nauki Theoretical and applied aspects of modern science, 2015, I. 7, pp. 126-128.
9. Sazerlend D. Scrum. Revoljucionnyj metod upravlenija proektami, 2-e izd. [Scrum. The Art of Doing Twice the Work in Half the Time, 2nd edition]. Moscow, 2017. 288 p.
10. Agile Project Management: Lessons Learned at Google. Available at: https://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland (accessed 07.02.2018).
11. Ken Schwaber, Jeff Sutherland. The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game, 2016. 23 p.
Agile — гибкая методология разработки
Основные проблемы при разработке программного обеспечения – нарушение сроков и превышение бюджета – не всегда возникают в результате низкого профессионализма программиста. Чаще всего причина их возникновения – ошибочный процесс разработки. В таких случаях просто необходима его оптимизация.
Что представляет собой Agile?
Agile — это ускоряющая методология создания проектов. Она минимизирует риски посредством коротких (2 – 3 недели)циклов, или итераций, разработки.
Отдельная итерация представляет собой миниатюрный программный проект. Она включает все необходимые для выдачи мини-прироста по фукциональности задачи, а именно:
- проектирование;
- анализ требований;
- кодирование;
- тестирование;
- документирование.
Обычно отдельной итерации недостаточно для выпуска новой версии продукта, но подразумевается, что в конце каждой итерации гибкий программный проект готов к выпуску. То есть проект можно разделить на маленькие части, приносящие прибыль уже сразу после разработки. Каждая итерация призвана решать приоритетные на момент итерации задачи. По окончании каждой итерации командой выполняется переоценка приорететных задач разработки.
Методы Agile
Методы Agile — это такие гибкие методологии, как Lean Development («Бережливая разработка ПО»), Scrum и др. Они были разработаны еще в начале 2000-х как альтернатива малоэффективным традиционным IT методам.
Практически все аgile-команды сконцентрированы в одном офисе (bullpen). Офис включает product owner – заказчика, который и определяет требования к продукту. В качестве заказчика может выступать бизнес-аналитик, менеджер проекта или клиент. Кроме того, в офис могут входить и дизайнеры интерфейса, тестировщики, технические писатели. То есть методы Agile направлены в первую очередь на непосредственное общение.
Принципы Agile
Принципы agile заключаются в широком спектре процессов разработки, определяемых Agile Manifesto и направленных на успех команд.
Главные преимущества Agile
Качество web-продукта
Вовлечение заказчика в процесс каждой итерации дает возможность корректировать процесс, что неизменно повышает качество.
Высокая скорость разработки
Итерация длится не более 3-х недель, к концу этого срока обязательно есть результат.
Минимизация рисков
Крупный проект дает возможность заказчику оплатить несколько итераций и в ходе работы понять, что он вовремя получит именно то, что хочет и за приемлемую цену. Водопадные модели (с применением спецификаций и технических заданий) таких возможностей не дают.
Заказчик всегда имеет возможность наблюдать за ходом разработки, корректировать фунуциональность проекта, тестировать или запускать его, даже может остановить его в любой момент.
Прозрачность оплаты
Оплачивается функциональность проекта, соответственно, чем больше функций, тем выше стоимость. Отсюда возможность управлять стоимостью проекта. Минимальное количество необходимых функций позволяет удешевить проект. Завершение каждой итерации дает возможность не только увидеть, за что были заплачены деньги, но и сразу же начать получать доход.
Смотрите также
- Сайт авторских расширений для CMS Joomla!®
- Разработка сайта фрилансера
- Как построить качественный сайт?
- Литература для сайтостроителя
- Делаем поисковую строку
- Современные тенденции в разработке веб-ресурсов: формирование цен
- Стоит ли придерживаться этапности при разработке сайтов?
- Сайтостроение: так ли уж необходимо заполнять бриф?
- Необходимость и элементы качественного договора на разработку сайта
- Кодинг сайта
Название короткой итерации которая длится 2 4 недели agile
Agile – это гибкая методология разработки (англ. Agile software development). Представляет собой революционную концепцию, в рамках которой выполняется разработка программного обеспечения.
Цель — минимизация рисков, достигаемая разработкой (проектированием) короткими итерациями.
Scrum – это конкретная технология (методы ведения проекта и роли участников процесса), реализующая принципы Agile, позволяет в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять заказчику работающее ПО с новыми возможностями, для которых определён наибольший приоритет
Скрам – Обзор
Agile стал одним из основных модных слов в индустрии разработки программного обеспечения. Но что такое гибкая разработка? Проще говоря, гибкая разработка – это другой способ выполнения команд и проектов по разработке программного обеспечения.
Чтобы понять, что нового, давайте вспомним традиционные методы. При обычной разработке программного обеспечения требования к продукту дорабатываются до начала разработки.
Модель водопада
Наиболее часто используемая модель разработки программного обеспечения с этой характеристикой – это модель водопада, как показано на следующей диаграмме. Однако в большинстве случаев добавляются новые функции, а также могут изменяться более ранние требования. Модель «Водопад» не структурирована для учета таких постоянных изменений требований. Кроме того, пользователь не будет иметь ясности в отношении функциональности продукта, пока продукт не станет доступным в полном объеме.
Итеративная инкрементная модель
В итерационной инкрементальной модели разработка начинается с ограниченного числа завершенных и приоритетных требований. Результат представляет собой рабочий прирост продукта. Набор действий от требований до разработки кода называется итерацией. На основе функциональных возможностей приращения и любых или всех новых измененных ожидающих требований следующая партия требований присваивается следующей итерации. Результатом последующей итерации является увеличение рабочего приращения продукта. Это повторяется до тех пор, пока продукт не выполнит необходимые функции.
Пользователь обычно не участвует в работе по разработке, и это может привести к разрывам связи, что приведет к неправильной функциональности. Участие положительно для команды разработчиков, но требует времени команды и может добавить задержки. Кроме того, любые неформальные изменения требований во время итерации могут привести к путанице и могут также привести к ползучести области. С этой предпосылкой возникла Agile-разработка.
Agile Development
Гибкая разработка основана на итеративной инкрементальной разработке, в которой требования и решения развиваются благодаря совместной работе команды. Он рекомендует использовать итеративный подход с учетом временных рамок и способствует быстрому и гибкому реагированию на изменения. Это теоретическая основа, которая не определяет какую-либо конкретную практику, которой должна следовать команда разработчиков. Scrum – это конкретная гибкая структура процесса, которая определяет методы, которые необходимо соблюдать.
Ранние реализации гибких методов включают Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), адаптивную разработку программного обеспечения, функционально-ориентированную разработку (1997) и метод разработки динамических систем (DSDM) (1995). Теперь они все вместе называются гибкими методологиями , после того как Agile Manifesto был опубликован в 2001 году.
Agile Manifesto
Agile Manifesto был опубликован командой разработчиков программного обеспечения в 2001 году, подчеркивая важность, которую необходимо уделить команде разработчиков, учитывая изменяющиеся требования, участие клиентов.
Agile Manifesto выглядит следующим образом:
«Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к оценке:
- Индивидуумы и взаимодействия над процессами и инструментами
- Рабочее программное обеспечение над всеобъемлющей документацией
- Сотрудничество с клиентом в процессе переговоров
- Реагирование на изменения после плана
То есть, хотя в пунктах справа есть значение, мы больше ценим элементы слева ».
… Манифест для гибкой разработки программного обеспечения, Авторы: Бек, Кент и др. (2001)
Определение проворных элементов манифеста
Пункты манифеста слева можно описать следующим образом:
- самоорганизация и самомотивация членов команды
- постоянное взаимодействие для работы, разъяснения, информация среди членов команды
Ключевым элементом Agile Manifesto является то, что мы должны доверять людям и их способности сотрудничать. По этой причине разработанные специальные гибкие методологии используют возможности членов команды, подчеркивая командную работу и сотрудничество на протяжении всего жизненного цикла проекта.
Ключевые принципы Agile
Agile Manifesto основан на следующих принципах:
Принцип | Описание |
---|---|
Удовлетворение и доставка | Удовлетворение потребностей клиентов благодаря раннему и непрерывному программному обеспечению. |
Приветствие перемен | Приветствуем меняющиеся требования даже на более поздних этапах разработки. |
Доставить часто | Поставляйте работающее программное обеспечение часто (еженедельно, а не ежемесячно). |
Коммуникация – это ключ | Обеспечить тесную связь разработчиков с деловыми людьми на ежедневной основе. |
Окружающая среда и доверие | Создавайте проекты вокруг мотивированных людей. Оказывайте им необходимую поддержку и доверяйте им. |
Личное общение | Поощряйте личную беседу, чтобы обеспечить эффективное и действенное общение. |
Программное обеспечение как мера прогресса | Рабочее программное обеспечение является основной мерой прогресса. |
Устойчивое развитие | Содействие устойчивому развитию с возможностью поддерживать постоянный темп на протяжении всего развития. |
Внимание к деталям | Постоянное внимание к техническому совершенству и хорошему дизайну. |
Сила Меньше | Простота необходима. |
Самоорганизующиеся Команды | Регулярное внимание команды к тому, чтобы стать эффективным в меняющихся обстоятельствах. |
Agile методологии
Методология динамического развития системы (DSDM)
Это гибкая структура для программных проектов. Он был использован для тонкой настройки традиционных подходов. Самая последняя версия DSDM называется DSDM Atern. Название Atern – сокращение от Arctic Tern – морской птицы, которая может путешествовать на огромные расстояния, что представляет многие особенности метода, такие как естественные способы работы, такие как расстановка приоритетов и сотрудничество.
Scrum
Это самая популярная гибкая среда, которая концентрируется, в частности, на том, как управлять задачами в командной среде разработки. Scrum использует модель итеративной и инкрементальной разработки с более короткой продолжительностью итераций. Scrum относительно прост в реализации и ориентирован на быстрые и частые поставки.
Экстремальное программирование (XP)
Это тип гибкой разработки программного обеспечения. Он поддерживает частые выпуски в короткие циклы разработки, которые предназначены для повышения производительности и введения контрольных точек, где могут быть приняты новые требования клиентов. Методология получила свое название от идеи, что полезные элементы традиционных практик разработки программного обеспечения выведены на экстремальные уровни. (Экстремальное программирование – это дисциплина в области разработки программного обеспечения, которая организует людей для более продуктивного производства высококачественного программного обеспечения.) В XP рассматриваются этапы анализа, разработки и тестирования с помощью новых подходов, которые существенно влияют на качество конечного продукта.
Разработка через тестирование (TDD)
Это процесс разработки программного обеспечения, который основан на повторении очень короткого цикла разработки: сначала разработчик пишет автоматизированный тестовый пример, который определяет желаемое улучшение или новую функцию, затем он производит наименьшее количество кода, чтобы пройти этот тест, и наконец, доводит новый код до приемлемых стандартов.
Опираться
Это производственная практика, при которой расходование ресурсов для любой цели, кроме создания ценности для конечного потребителя, является расточительным и, следовательно, является целью устранения. Работая с точки зрения потребителя, который потребляет продукт или услугу, термин «стоимость» определяется как любое действие или процесс, за которые клиент будет готов заплатить. Lean сосредоточен на сохранении ценности с меньшим количеством работы.
Kanban
Это система для улучшения и поддержания высокого уровня производства. Kanban – это один из методов, с помощью которого достигается Just-In-Time (JIT), стратегия, используемая организациями для контроля затрат на инвентаризацию. Kanban стал эффективным инструментом поддержки всей производственной системы, и это оказалось отличным способом для продвижения улучшений.
Заключение
За последние 10 лет постоянно растет количество историй успеха, в которых компании значительно улучшили успех и производительность своих групп по разработке ИТ и проектов с гибкими практиками. Это привело к тому, что Agile получил широкое распространение в различных отраслях, включая СМИ и технологии, крупные корпорации и даже правительство.
Agile Framework помогает командам извлечь выгоду из:
- Более быстрое время доставки / Рынок
- Уменьшить неопределенность и риск
- Увеличьте возврат инвестиций (ROI), сосредоточившись на потребительской ценности
Среди этих различных гибких методологий Scrum за последние 20 лет оказался чрезвычайно успешным во всем мире.
Скрам – Фреймворк
Scrum является основой для разработки и поддержки сложных продуктов. Кен Швабер и Джефф Сазерленд разработали Scrum. Вместе они стоят за Правилами Скрама.
Скрам Определение
Scrum – это структура, в рамках которой люди могут решать сложные адаптивные проблемы, одновременно производя и творчески поставляя продукты максимально возможной ценности.
Scrum – это структура процессов, которая используется для управления разработкой сложных продуктов с начала 1990-х годов. Скрам не является процессом или техникой для создания продуктов; скорее это структура, в которой вы можете использовать различные процессы и методы. Скрам проясняет относительную эффективность ваших методов управления и разработки продуктов, чтобы вы могли улучшить.
Скрам-фреймворк состоит из Скрам-команд и связанных с ними ролей, событий, артефактов и правил. Каждый компонент в рамках служит определенной цели и имеет важное значение для успеха и использования Scrum.
Правила Scrum связывают воедино события, роли и артефакты, регулируя отношения и взаимодействие между ними. Правила Scrum описаны в этом уроке.
Примечание. По всей отрасли существуют заблуждения, что Scrum означает отсутствие документации, команда scrum состоит только из разработчиков и так далее. Это не совсем так; мы дадим разъяснения по ним в следующих разделах.
Scrum Process Framework
В Scrum предписанные события используются для создания регулярности. Все события являются событиями с временными рамками, так что каждое событие имеет максимальную продолжительность. События описаны более подробно в последующих главах.
спринт
Сердцем Scrum является Sprint, временной интервал в две недели или один месяц, в течение которого создается потенциально высвобождаемый продукт. Новый Спринт начинается сразу после завершения предыдущего Спринта. Спринты состоят из планирования Спринта, ежедневных заданий, работы по разработке, обзора Спринта и ретроспективы Спринта.
- При планировании спринта работа, выполняемая в спринте, планируется совместно командой Scrum.
- Ежедневная встреча Scrum – это 15-минутное мероприятие для Scrum Team, которое позволяет синхронизировать действия и составить план на этот день.
- В конце Спринта проводится обзор Спринта, чтобы проверить Инкремент и внести изменения в Журнал ожидания продукта, если это необходимо.
- Ретроспектива Спринта происходит после Обзора Спринта и до следующего Планирования Спринта. На этой встрече Scrum Team должна проверить себя и составить план улучшений, которые будут приняты во время последующего спринта.
При планировании спринта работа, выполняемая в спринте, планируется совместно командой Scrum.
Ежедневная встреча Scrum – это 15-минутное мероприятие для Scrum Team, которое позволяет синхронизировать действия и составить план на этот день.
В конце Спринта проводится обзор Спринта, чтобы проверить Инкремент и внести изменения в Журнал ожидания продукта, если это необходимо.
Ретроспектива Спринта происходит после Обзора Спринта и до следующего Планирования Спринта. На этой встрече Scrum Team должна проверить себя и составить план улучшений, которые будут приняты во время последующего спринта.
Заключение
Scrum – это структура процесса, которая определяет определенные правила, события и роли, которые необходимо внести в регулярность. Тем не менее, он может быть адаптирован к любой организации, исходя из потребностей, при условии, что основные правила Scrum не нарушаются.
Скрам – Роли
Команда Scrum состоит из трех ролей, а именно: ScrumMaster, владелец продукта и команда.
ScrumMaster
ScrumMaster (иногда пишется как Scrum Master, хотя после «Scrum» в официальном термине нет пробела) является хранителем процесса scrum. Он / она несет ответственность за
- заставить процесс идти гладко
- устранение препятствий, влияющих на производительность
- организация и проведение критических встреч
Владелец продукта
Владелец продукта несет ответственность за максимизацию стоимости продукта и работу команды. Как это сделать, может сильно различаться в разных организациях, Скрам-командах и отдельных лицах.
Владелец продукта является единственным лицом, ответственным за управление бэклогом продукта. Управление бэклогом
- Четко выраженные позиции в продуктах.
- Заказ товаров из списка продуктов для наилучшего достижения целей и задач.
- Оптимизация ценности работы, которую выполняет Команда.
- Обеспечение того, чтобы журнал невыполненных работ был видимым, прозрачным и понятным для всех, и показывает, над чем команда будет работать дальше.
- Обеспечение того, чтобы команда понимала элементы в бэклоге продукта до необходимого уровня.
Четко выраженные позиции в продуктах.
Заказ товаров из списка продуктов для наилучшего достижения целей и задач.
Оптимизация ценности работы, которую выполняет Команда.
Обеспечение того, чтобы журнал невыполненных работ был видимым, прозрачным и понятным для всех, и показывает, над чем команда будет работать дальше.
Обеспечение того, чтобы команда понимала элементы в бэклоге продукта до необходимого уровня.
Владелец продукта может выполнить вышеуказанную работу или поручить команде. Тем не менее, владелец продукта несет ответственность за выполнение этих задач.
Владелец продукта – один человек, а не комитет. Владелец продукта может представлять пожелания комитета в Журнале незавершенного производства, но те, кто хочет изменить приоритет элемента Журнала незавершенного производства, должны обратиться к Владельцу продукта.
Чтобы владелец продукта добился успеха, вся организация должна уважать его или ее решения. Решения Владельца продукта видны в содержании и порядке заказа продукта. Никому не разрешается указывать Команде работать с другим набором требований, и Команде не разрешается действовать в соответствии с тем, что говорит кто-либо еще. Это обеспечивается ScrumMaster.
Команда
Команда самоорганизуется и кросс-функциональна. Это означает, что команда состоит из аналитиков, дизайнеров, разработчиков, тестировщиков и т. Д. В зависимости от ситуации и в зависимости от проекта.
Некоторые люди в отрасли называют эту команду командой разработчиков. Однако такая ссылка ведет к противоречию, что в команде могут быть только разработчики и никаких других ролей. Это очевидное понимание того, что это только заблуждение. Для разработки программного продукта нам нужны все роли, и в этом суть Scrum – команда будет работать в сотрудничестве. Кросс-функциональные команды обладают всеми компетенциями, необходимыми для выполнения работы, без зависимости от других, не являющихся частью команды, и, таким образом, можно сэкономить время и усилия. Командная модель в Scrum предназначена для оптимизации гибкости, креативности и производительности.
Оптимальный размер команды достаточно мал, чтобы оставаться гибким, и достаточно большим, чтобы выполнить значительную работу в Спринте. Размер команды должен быть в диапазоне от пяти до девяти человек, если это возможно. Менее пяти членов команды снижают взаимодействие и приводят к меньшему повышению производительности. Наличие более девяти членов требует слишком большой координации.
Команда Scrum ежедневно тесно сотрудничает, чтобы обеспечить бесперебойную передачу информации и быстрое решение проблем. Скрам-команда предоставляет продукт итеративно и постепенно, максимально расширяя возможности для обратной связи. Дополнительные поставки полного продукта гарантируют, что потенциально полезная версия рабочего продукта всегда доступна.
Скрам – СкрамМастер
ScrumMaster является обученным ответственным лицом, которое оказывает услуги, как описано ниже –
Услуги ScrumMaster для Владельца продукта
ScrumMaster обслуживает Владельца продукта несколькими способами, в том числе –
- Поиск методов эффективного управления бэклогом продуктов.
- Помочь команде Scrum понять необходимость в четких и кратких материалах, содержащихся в бэклоге продукта.
- Понимание планирования продукта в эмпирической среде.
- Обеспечение того, чтобы Владелец продукта знал, как организовать бэклог продукта для максимизации стоимости.
- Понимание и практика ловкости.
- Содействие Scrum событиям по мере необходимости.
Поиск методов эффективного управления бэклогом продуктов.
Помочь команде Scrum понять необходимость в четких и кратких материалах, содержащихся в бэклоге продукта.
Понимание планирования продукта в эмпирической среде.
Обеспечение того, чтобы Владелец продукта знал, как организовать бэклог продукта для максимизации стоимости.
Понимание и практика ловкости.
Содействие Scrum событиям по мере необходимости.
Услуги ScrumMaster для команды Scrum
ScrumMaster обслуживает Scrum Team несколькими способами, в том числе –
- Тренировка Скрам Команды по самоорганизации и кросс-функциональности.
- Помощь команде Scrum в создании ценных продуктов.
- Устранение препятствий на пути прогресса Скрам Команды.
- Содействие Scrum событиям по запросу или необходимости.
- Тренировка команды Scrum в организационной среде, в которой Scrum еще не полностью принят и не понят.
Тренировка Скрам Команды по самоорганизации и кросс-функциональности.
Помощь команде Scrum в создании ценных продуктов.
Устранение препятствий на пути прогресса Скрам Команды.
Содействие Scrum событиям по запросу или необходимости.
Тренировка команды Scrum в организационной среде, в которой Scrum еще не полностью принят и не понят.
СкрамМастер Услуги для организации
ScrumMaster обслуживает организацию несколькими способами, включая:
- Руководство и тренировка организации в принятии Scrum.
- Планирование внедрения Scrum в организации.
- Помогая сотрудникам и заинтересованным сторонам понять и принять Scrum и эмпирическую разработку продукта.
- Вызывает изменения, которые увеличивают производительность Scrum Team.
- Работа с другими ScrumMasters для повышения эффективности применения Scrum в организации.
Руководство и тренировка организации в принятии Scrum.
Планирование внедрения Scrum в организации.
Помогая сотрудникам и заинтересованным сторонам понять и принять Scrum и эмпирическую разработку продукта.
Вызывает изменения, которые увеличивают производительность Scrum Team.
Работа с другими ScrumMasters для повышения эффективности применения Scrum в организации.
Заключение
Scrum – это структура процесса, которая определяет определенные правила, события и роли, которые необходимо внести в регулярность. Тем не менее, он может быть адаптирован к любой организации, исходя из потребностей, при условии, что основные правила Scrum не нарушаются.
Scrum – События
Scrum Process Framework можно просматривать с помощью последовательности событий и соответствующих артефактов. События Scrum – это события с временными рамками. Это означает, что в проекте каждое событие Scrum имеет предопределенную максимальную продолжительность. Эти события обеспечивают прозрачность хода выполнения проекта для всех, кто участвует в проекте. Жизненные события схватки-
- Спринт
- Спринт Планирование
- Ежедневные встречи Scrum
- Обзор Спринта
- Ретроспектива Спринта
Спринт
Во время Спринта разрабатывается рабочий продукт Инкремент. Это обычно длится две недели или один месяц, и эта продолжительность остается постоянной для всех спринтов в проекте. У нас не может быть различной продолжительности для разных спринтов в проекте. Новый Спринт начинается сразу после завершения предыдущего Спринта.
Цель Спринта – это цель, поставленная перед Спринтом. Он дает руководству команду о том, почему он создает Приращение. Он создается во время встречи по планированию спринта. Сфера действия спринта уточняется и пересматривается между Владельцем продукта и Командой по мере ознакомления с требованиями. Таким образом, каждый Sprint связан с ним, определением того, что должно быть построено, дизайном и гибким планом, который будет направлять его построение, работу по разработке и результирующий прирост продукта.
Спринт должен быть отменен, если Цель Спринта устарела. Это может произойти, если организация меняет направление или меняются рыночные или технологические условия. Спринт может быть отменен только владельцем продукта, хотя другие могут повлиять на него.
Из-за краткосрочной природы Спринтов, отмена во время спринта редко имеет смысл. Поскольку отмена спринта потребляет ресурсы, для реорганизации в другой спринт они очень редки.
Если Спринт отменен, и часть работы, произведенной во время спринта, потенциально может быть выпущена, Владелец Продукта обычно принимает это. Все незавершенные элементы журнала невыполненных работ по спринту возвращаются в список продуктов.
Спринт Планирование
Работа, которая будет выполнена в Спринте, запланирована на Совещании по планированию Спринта. Совещание по планированию спринта длится не более четырех часов для двухнедельных спринтов и восьми часов для месячных спринтов. Ответственность за проведение собрания и за то, чтобы присутствовали все необходимые участники, понимали цель запланированного собрания. Scrum Master модерирует собрание, чтобы следить за своевременностью обсуждения и закрытием.
Планирование Спринта фокусируется на следующих двух вопросах –
- Что должно быть и что может быть доставлено в Приращении Спринта?
- Как будет достигнута работа, необходимая для выполнения Sprint?
Входные данные для этой встречи –
- Журнал ожидания продукта
- Последний продукт Инкремент
- Прогнозируемая мощность команды во время спринта
- Прошлые показатели команды
Scrum Team обсуждает функциональность, которая может быть разработана во время спринта. Владелец продукта дает разъяснения по пунктам журнала ожидания продукта. Команда выбирает элементы из журнала ожидания продукта для Sprint, так как они являются лучшими для оценки того, чего они могут достичь в Sprint. Команда состоит из аналитиков, дизайнеров, разработчиков и тестировщиков. Работа выполняется в духе сотрудничества, что сводит к минимуму повторные работы.
Скрам Команд затем придумывает Спринт Гол. Цель Спринта – это цель, которая дает руководству команду о том, почему он наращивает прирост продукта. Затем команда решает, как она будет встраивать выбранную функциональность в инкремент рабочего продукта во время спринта. Элементы журнала невыполненных работ, выбранные для этого Sprint, а также план их доставки, называются журналом ожидания Sprint.
Работа во время спринта оценивается во время планирования спринта и может иметь различные размеры и / или усилия. К концу встречи по планированию спринта работа делится на задачи продолжительностью один день или меньше. Это делается для облегчения распределения работы и отслеживания завершения. Если команда понимает, что у нее слишком много или слишком мало работы, она может пересмотреть выбранные позиции Бэклога продукта с Владельцем продукта.
Команда также может пригласить других (не входящих в Scrum Team) принять участие в собрании по планированию спринта, чтобы получить технические или предметные рекомендации или помощь в оценке.
Ежедневные встречи Scrum
Ежедневное совещание Scrum – это 15-минутное совещание для Группы, которое проводится ежедневно, чтобы быстро понять работу с момента последнего Ежедневного совещания Scrum и составить план на следующие 24 часа. Эта встреча также называется Ежедневная встреча.
Ежедневная встреча Scrum проводится в одно и то же время каждый день, чтобы уменьшить сложность.
Во время встречи каждый член команды объясняет:
- Что он сделал вчера, что помогло команде достичь цели в спринте?
- Что он сделает сегодня, чтобы помочь команде достичь цели спринта?
- Видит ли он какие-либо препятствия, мешающие ему или команде достичь цели спринта?
Что он сделал вчера, что помогло команде достичь цели в спринте?
Что он сделает сегодня, чтобы помочь команде достичь цели спринта?
Видит ли он какие-либо препятствия, мешающие ему или команде достичь цели спринта?
Daily Scrum ошибочно считается событием отслеживания статуса, хотя на самом деле это событие планирования.
Входными данными для собрания должны быть сведения о том, как команда продвигается к достижению Цели Спринта, а выходными данными должен быть новый или пересмотренный план, который оптимизирует усилия команды по достижению Цели Спринта.
Хотя Скрам Мастер координирует Ежедневное Скрам Собрание и обеспечивает достижение целей встречи, Собрание является обязанностью Команды.
При необходимости, команда может встретиться сразу после Ежедневного Скрам-Собрания, для каких-либо подробных обсуждений или для повторного планирования остальной части работы Спринта.
Ниже приведены преимущества ежедневных встреч Scrum –
- Улучшить коммуникацию в Команде.
- Определите препятствия, если таковые имеются, чтобы облегчить раннее удаление того же самого, чтобы минимизировать воздействие на Спринт.
- Выделите и способствуйте быстрому принятию решения.
- Повысить уровень знаний команды.
Улучшить коммуникацию в Команде.
Определите препятствия, если таковые имеются, чтобы облегчить раннее удаление того же самого, чтобы минимизировать воздействие на Спринт.
Выделите и способствуйте быстрому принятию решения.
Повысить уровень знаний команды.
Спринт Обзор
Обзор Спринта проводится в конце каждого Спринта. Во время обзора спринта просматривается презентация полученного приращения. На этой встрече Scrum Team и заинтересованные стороны сотрудничают, чтобы понять, что было сделано в Sprint. Исходя из этого и любых изменений в Журнале работы продукта во время Спринта, участники приходят к следующим необходимым шагам, которые могут оптимизировать ценность. Таким образом, целью Sprint Review является получение обратной связи и прогресса в совокупности.
Спринт-обзор обычно проводится в течение двух часов для двухнедельных спринтов и в течение четырех часов для месячных спринтов.
Scrum Master гарантирует, что –
- Встреча состоится.
- Участники понимают цель.
- Встреча сосредоточена на требуемой повестке дня и завершается в течение требуемого времени.
Участники понимают цель.
Встреча сосредоточена на требуемой повестке дня и завершается в течение требуемого времени.
Обзор Sprint включает в себя следующие аспекты –
- По приглашению Владельца продукта участники включают в себя команду Scrum и ключевые заинтересованные стороны.
- Владелец продукта объясняет, какие элементы журнала невыполненных работ были выполнены во время спринта, а какие еще не выполнены.
- Команда обсуждает, что прошло хорошо во время спринта, с какими проблемами он столкнулся и как эти проблемы были решены.
- Команда демонстрирует выполненную работу и отвечает на вопросы, если таковые имеются, о Приращении.
- Затем вся группа обсуждает, что делать дальше. Таким образом, обзор Sprint предоставляет ценный вклад в планирование Sprint последующего Sprint.
- Затем команда Scrum анализирует сроки, бюджет, потенциальные возможности и рынок для следующего ожидаемого выпуска продукта.
- Результатом обзора Спринта является обновленное Журнал незавершенного производства, который определяет вероятные элементы Журнала незавершенного производства для следующего Спринта.
По приглашению Владельца продукта участники включают в себя команду Scrum и ключевые заинтересованные стороны.
Владелец продукта объясняет, какие элементы журнала невыполненных работ были выполнены во время спринта, а какие еще не выполнены.
Команда обсуждает, что прошло хорошо во время спринта, с какими проблемами он столкнулся и как эти проблемы были решены.
Команда демонстрирует выполненную работу и отвечает на вопросы, если таковые имеются, о Приращении.
Затем вся группа обсуждает, что делать дальше. Таким образом, обзор Sprint предоставляет ценный вклад в планирование Sprint последующего Sprint.
Затем команда Scrum анализирует сроки, бюджет, потенциальные возможности и рынок для следующего ожидаемого выпуска продукта.
Результатом обзора Спринта является обновленное Журнал незавершенного производства, который определяет вероятные элементы Журнала незавершенного производства для следующего Спринта.
Спринт Ретроспектива
Ретроспектива Спринта происходит после Обзора Спринта и до следующего Планирования Спринта. Обычно это одночасовое собрание для двухнедельных спринтов и трехчасовое собрание для спринтов продолжительностью в один месяц.
Цель ретроспективы Спринта –
- Объедините уроки последнего спринта в отношении людей, отношений, процессов и инструментов.
- Определите основные пункты, которые прошли успешно и потенциальные улучшения.
- Создание плана по внедрению улучшений для повышения качества продукции.
Объедините уроки последнего спринта в отношении людей, отношений, процессов и инструментов.
Определите основные пункты, которые прошли успешно и потенциальные улучшения.
Создание плана по внедрению улучшений для повышения качества продукции.
Ретроспектива Sprint – это возможность для Scrum Team проанализировать и улучшить в рамках процесса Scrum, чтобы сделать следующий результат Sprint более эффективным.
Scrum Guide © 1991-2013 Кен Швабер и Джефф Сазерленд, Все права защищены.
Скрам – Артефакты
Скрам-артефакты предоставляют ключевую информацию, которую необходимо знать команде Scrum и заинтересованным сторонам для понимания разрабатываемого продукта, выполненных работ и планируемых мероприятий в проекте. Следующие артефакты определены в Scrum Process Framework –
- Резерв продукта
- Журнал Спринта
- Диаграмма выгорания
- инкремент
Это минимально необходимые артефакты в проекте Scrum, и артефакты проекта этим не ограничиваются.
Резерв продукта
Журнал ожидания продукта – это упорядоченный список функций, которые необходимы как часть конечного продукта, и он является единственным источником требований для любых изменений, вносимых в продукт.
Журнал ожидания продукта содержит список всех функций, функций, требований, улучшений и исправлений, которые представляют собой изменения, которые будут внесены в продукт в будущих выпусках. Элементы журнала незавершенного производства имеют атрибуты описания, заказа, оценки и стоимости. Эти элементы обычно называются пользовательскими историями. Владелец продукта несет ответственность за Журнал незавершенного производства, включая его содержание, доступность и порядок заказа.
Отставание продукта – это развивающийся артефакт. Самая ранняя версия может содержать только изначально известные и наиболее понятные требования. Журнал ожидания продукта разрабатывается как продукт, и среда, в которой он будет использоваться, прогрессирует. Журнал ожидания продукта постоянно изменяется, чтобы включить то, что требуется, чтобы сделать его эффективным. Пока продукт существует, его бэклог продукта также существует.
По мере того, как создаваемый продукт используется и приобретает все большую ценность, бэклог продукта становится все более обширным и исчерпывающим списком. Изменения в бизнес-требованиях, рыночных условиях или технологиях приводят к изменениям в Журнал ожидания продукта, превращая его в живой артефакт.
Уточнение журнала невыполненных работ означает добавление деталей, оценок и порядка приоритетов к элементам журнала невыполненных работ. Это постоянный процесс, выполняемый Владельцем продукта и Командой. Скрам-команда решает, как и когда нужно проводить доработку.
Элементы Журнала Продукта могут быть обновлены в любое время Владельцем Продукта или по усмотрению Владельца Продукта.
Предметы с более высоким уровнем упорядоченности продуктов, как правило, более четкие и подробные, чем элементы с низким порядком. Более точные оценки сделаны на основе большей ясности и повышенной детализации. Чем ниже порядок, тем меньше детали.
Элементы Журнала незавершенного производства, которые, вероятно, могут соответствовать требованиям кандидата для будущего Спринта, уточняются, чтобы эти элементы могли быть разработаны во время Спринта. Элементы Журнала работы продукта, которые могут быть разработаны Группой в рамках одного Спринта, считаются готовыми для выбора на совещании по планированию Спринта.
Журнал Спринта
Журнал ожидания для Sprint – это набор элементов Журнала работы с продуктом, выбранных для Sprint, а также план для увеличения продукта и реализации цели Sprint.
Журнал ожидания от Sprint – это прогноз Группы о том, какие функциональные возможности будут доступны в следующем Инкременте, и о работе, необходимой для предоставления этой функциональности в качестве инкремента рабочего продукта.
Журнал ожидания спринта – это план с достаточным количеством деталей, которые можно понять, но команда должна отслеживать «Ежедневные схватки». Команда изменяет Журнал Спринта во всем Спринте, а Журнал Спринта появляется во время Спринта. Это происходит, когда команда прорабатывает план и узнает больше о работе, необходимой для достижения цели спринта.
Поскольку новая работа требуется, Команда добавляет ее в Журнал ожидания Спринта. По мере того, как работа выполнена или завершена, предполагаемая оставшаяся работа обновляется Когда элементы плана считаются ненужными, они удаляются. Только Команда может изменить свой Журнал Спринта во время Спринта. Журнал ожидания Спринта – это хорошо видимая в реальном времени картина работы, которую Команда планирует выполнить во время Спринта, и она принадлежит исключительно Команде.
инкремент
Прирост – это сумма всех элементов Журнала Продуктов, выполненных во время Спринта, вместе с приращениями всех предыдущих Спринтов. В конце Спринта новый Инкремент должен быть рабочим продуктом, что означает, что он должен быть в пригодном для использования состоянии. Он должен быть в рабочем состоянии независимо от того, решит ли Владелец продукта его фактическую версию.
Команде Скрам необходимо достичь консенсуса в отношении того, что считается Приращением. Это значительно варьируется в зависимости от Скрам Команды, но члены команды должны иметь общее понимание того, что это значит для завершения работы. Это используется для оценки завершения работы над приращением продукта.
То же самое понимание помогает Группе узнать, сколько элементов Бэклога продукта она может выбрать во время Планирования Спринта. Целью каждого Sprint является предоставление Приращений потенциально высвобождаемой функциональности.
Команды обеспечивают увеличение функциональности продукта в каждом спринте. Этот прирост можно использовать, поэтому владелец продукта может немедленно выпустить его. Если понимание приращения является частью соглашений, стандартов или руководящих указаний организации-разработчика, все Скрам-команды должны следовать ему как минимум. Если это не соглашение организации-разработчика, команда Scrum должна определить определение приращения, подходящее для продукта.
Каждый Инкремент аддитивен ко всем предыдущим Инкрементам и тщательно протестирован, обеспечивая совместную работу всех Инкрементов.
По мере взросления Скрам-команд ожидается, что их определения Приращений будут расширены и будут включать более строгие критерии более высокого качества. Любой продукт должен иметь определение приращения, которое является стандартом для любой работы над ним.
Диаграмма выжигания спринта
В любой момент времени в Спринте общая работа, оставшаяся в Журнале Спринта, может суммироваться. Команда отслеживает эту общую работу, оставшуюся для каждой ежедневной схватки, чтобы спрогнозировать вероятность достижения цели спринта. Отслеживая оставшуюся работу по всему Спринту, Команда может управлять ее ходом.
Спринт Burn-Down Chart – это практика для отслеживания работы, затраченной Scrum Team. Было доказано, что это полезный метод для отслеживания прогресса Спринта в достижении Цели Спринта.
Владелец продукта отслеживает эту общую работу, оставаясь, по крайней мере, в каждом обзоре Sprint. Владелец продукта сравнивает эту сумму с работой, оставшейся в предыдущих Обзорах Спринта, чтобы оценить прогресс в выполнении запланированной работы к требуемому времени для достижения цели. Эта информация передается всем заинтересованным сторонам.
Заключение
Роли, события, артефакты и правила Скрама неизбежны. Если реализованы только некоторые части Scrum, результат не Scrum. Скрам должен быть реализован полностью и хорошо функционировать, если он согласован с другими методами, методологиями и практиками.
Scrum Guide © 1991-2013 Кен Швабер и Джефф Сазерленд, Все права защищены.
Scrum – Истории пользователей
Как вы уже поняли, пользовательские истории обычно используются для описания функций продукта и являются частью Скрам-артефактов – Журнал невыполненных работ по продукту и Журнал ожидания по спринту .
Пользовательские истории
В разработке программного обеспечения особенности продукта играют решающую роль. Это те функции, которые пользователь в конечном итоге любит использовать в конечном продукте. Они известны как Требования в общей терминологии. Успех проекта по разработке программного обеспечения заключается в точном и правильном понимании требований пользователя, а затем их внедрении в конечный продукт. Таким образом, требования или особенности продукта должны быть полностью известны команде разработчиков проекта.
В 1999 году Кент Бек предложил термин «Истории пользователей» для функций продукта. Он описал, что история пользователя рассказывается с точки зрения пользователя относительно того, что он или она хочет иметь, а не того, что система может сделать для него. Таким образом, представление полностью изменилось от продукта к пользователю, и пользовательские истории стали стандартом де-факто для требований во всех средах Agile.
В проектах Scrum Product Backlog – это список пользовательских историй. Эти пользовательские истории располагаются по приоритетам и заносятся в список невыполненных работ на совещании по планированию спринта.
Оценка также основана на пользовательских историях, а размер продукта оценивается в баллах пользователей.
Структура пользовательской истории
Структура User Story выглядит следующим образом:
Давайте посмотрим, как создается пользовательская история для сценария, когда Клиент Банка снимает наличные в банкомате.
История пользователя: снятие наличных с клиента
Как клиент ,
Я хочу снять наличные в банкомате ,
Чтобы мне не пришлось ждать в очереди в банке
Критерии принятия истории пользователя
В каждой пользовательской истории также определен критерий принятия, так что правильность реализации пользовательской истории подтверждается путем прохождения приемочного теста, основанного на критерии принятия.
Ниже приведен примерный критерий приемлемости для примера пользовательского рассказа «Снятие наличных».
Критерий принятия 1:
Учитывая, что аккаунт кредитоспособен
- И карта действительна
- И диспенсер содержит деньги,
Когда клиент запрашивает наличные
Затем убедитесь, что учетная запись списана
- И убедитесь, что деньги выдаются
- И убедитесь, что карта возвращается.
Критерий приемки 2:
С учетом того, что счет списан
- И карта действительна
Когда клиент запрашивает наличные
Затем убедитесь, что сообщение об отказе отображается
- И убедитесь, что деньги не выдаются
- И убедитесь, что карта возвращается.
Написание пользовательских историй
Владелец продукта отвечает за Журнал незавершенного производства и, следовательно, за Пользовательские истории. Однако это не значит, что только владелец продукта пишет пользовательские истории. Любой участник Scrum Team может написать пользовательские истории, и деятельность может быть распределена по проекту по мере уточнения требований и добавления новых функций.
Нефункциональные требования в пользовательских историях
Нефункциональные требования можно включить и в пользовательские истории. В данном примере банкомата, банкомат, который должен быть доступен пользователю 24X7, 365 дней, является нефункциональным требованием, которое можно описать с помощью варианта использования.
Управление пользовательскими историями
Пользовательские истории управляются в журнале незавершенного производства. Пользовательские истории упорядочены в соответствии с приоритетом. Наиболее приоритетные пользовательские истории уточняются до детального уровня, в то время как наименее приоритетные пользовательские истории хранятся на более низком уровне детализации. Для каждого спринта в журнал ожидания спринта включаются наиболее приоритетные и, следовательно, более детализированные пользовательские истории. Если пользовательский журнал должен быть добавлен в журнал невыполненных работ, сначала определяется его приоритет, и он размещается в соответствии с его местом в соответствии с приоритетом. Пользовательские истории могут быть переориентированы в любое время. Также возможно удалить любую из пользовательских историй, если требуется.
Преимущества с пользовательскими историями
- Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.
- Синтаксис самой пользовательской истории обеспечивает фиксацию цели, выгоды или ценности, которые пользователь хочет достичь.
- Поскольку критерии принятия являются частью самой пользовательской истории, это будет дополнительным преимуществом для Scrum Team.
- Можно внести изменения в пользовательскую историю в ходе выполнения проекта. Если область действия пользовательской истории становится большой, ее необходимо разделить на более мелкие пользовательские истории. Условия в критерии приемки также могут быть изменены.
- Поскольку приращения рабочего продукта доставляются пользователям в конце каждого спринта, команда Scrum может получать отзывы от пользователей на собрании по рассмотрению спринта. Это позволяет постоянно включать обратную связь в продукт.
Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.
Синтаксис самой пользовательской истории обеспечивает фиксацию цели, выгоды или ценности, которые пользователь хочет достичь.
Поскольку критерии принятия являются частью самой пользовательской истории, это будет дополнительным преимуществом для Scrum Team.
Можно внести изменения в пользовательскую историю в ходе выполнения проекта. Если область действия пользовательской истории становится большой, ее необходимо разделить на более мелкие пользовательские истории. Условия в критерии приемки также могут быть изменены.
Поскольку приращения рабочего продукта доставляются пользователям в конце каждого спринта, команда Scrum может получать отзывы от пользователей на собрании по рассмотрению спринта. Это позволяет постоянно включать обратную связь в продукт.
Заключение
Пользовательские истории Scrum приближают пользователей к команде Scrum и предотвращают сюрпризы в последнюю минуту.
Scrum – Графики выгорания
Отслеживание спринта обычно выполняется с использованием Burn-Down Chart. График выгорания показывает оставшееся усилие в дневное количество часов. Например, давайте рассмотрим 2-недельный спринт –
Спринт Продолжительность : 2 недели
Количество дней в неделю : 5
Количество часов в день : 6
Количество ресурсов : 6
Следовательно, общее оставшееся усилие в начале спринта составляет 2 * 5 * 6 * 6 = 360 часов.
Следовательно, в идеальном сценарии 36 часов работы сокращаются в оставшейся работе, и диаграмма выгорания выглядит следующим образом:
Если спринт выполняется ежедневно, как планировалось, ход схватки практически совпадает с идеальным баром.
Если работа по спринту задерживается, а временное обязательство не выполняется, диаграмма выгорания выглядит следующим образом:
Но, поскольку график выгорания составляется ежедневно, а проскальзывание известно заранее, можно предпринять корректирующие действия, чтобы уложиться в график спринта. Предположим, что команда растягивается, чтобы уложиться в сроки, график выгорания выглядит следующим образом:
Таким образом, в любой момент времени в Спринте можно визуализировать общую работу, оставшуюся в Спринте, и можно улучшить возможность соблюдения временной шкалы спринта.
Заключение
Графики выжигания помогают команде Scrum отслеживать свои успехи и то, что необходимо сделать для достижения цели спринта.
Скрам – Оценка
В Scrum Projects оценка выполняется всей командой во время совещания по планированию спринта. Целью Оценки будет рассмотрение пользовательских историй для спринта по приоритетам и по способности команды выполнить поставку в течение временного интервала спринта.
Владелец продукта гарантирует, что приоритетные пользовательские истории понятны, могут быть оценены и внесены в начало журнала невыполненных работ.
Поскольку Scrum Team в целом отвечает за доставку инкремента продукта, необходимо позаботиться о том, чтобы выбрать пользовательские истории для Sprint, основываясь на размере инкремента продукта и усилиях, необходимых для него.
Размер приращения продукта оценивается в терминах очков истории пользователя. Как только размер определен, усилия оцениваются с помощью прошлых данных, т. Е. Усилия на точку пользовательской истории, называемой продуктивностью.
Методы оценки Скрама
Оценка Scrum пользовательских историй в терминах степени сложности для каждой из пользовательских историй. Для оценки степени сложности используется конкретная шкала.
Существует несколько типов шкал, которые используются в Scrum Estimate. Ниже приведены некоторые примеры –
- Числовой размер (от 1 до 10)
- Размеры футболки (XS, S, M, L, XL XXL, XXXL)
- Последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34 и т. Д.)
- Породы собак (чихуахуа, ………, дог)
Техника оценки обычно выбирается таким образом, чтобы вся команда Scrum была знакома и довольна значениями шкалы. Наиболее часто используемый и самый популярный метод – это Покер планирования, основанный на последовательности Фибоначчи.
Планирование Техники Покера
В методике оценки покерного планирования оценки для пользовательских историй производятся путем игры в покер планирования. Вся Scrum Team вовлечена, и это приводит к быстрым, но надежным оценкам.
Планирование Покер играется с колодой карт. Поскольку используется последовательность Фибоначчи, карты имеют номера – 1, 2, 3, 5, 8, 13, 21, 34 и т. Д. Эти числа представляют Очки истории. У каждого оценщика есть колода карт. Числа на карточках должны быть достаточно большими, чтобы их могли видеть все члены команды, когда один из членов команды держит карточку.
Один из членов команды выбран модератором. Модератор читает описание пользовательской истории, для которой проводится оценка. Если у оценщиков есть какие-либо вопросы, владелец продукта отвечает на них.
Каждый оценщик в личном порядке выбирает карту, представляющую его или ее оценку. Карты не показываются, пока все оценщики не сделают выбор. В это время все карточки одновременно переворачиваются и удерживаются, чтобы все члены команды могли видеть каждую оценку.
В первом туре очень вероятно, что оценки меняются. Высокие и низкие оценки объясняют причину их оценок. Следует позаботиться о том, чтобы все дискуссии были предназначены только для понимания и ничего не принималось лично. Модератор должен обеспечить то же самое.
Команда может обсудить историю и их оценки в течение еще нескольких минут.
Модератор может делать заметки по обсуждению, которые будут полезны при разработке конкретной истории. После обсуждения каждый оценщик переоценивает, снова выбирая карточку. Карты снова остаются закрытыми, пока все не подсчитают, в какой момент они одновременно переворачиваются.
Повторяйте процесс, пока оценки не сойдутся в одну оценку, которая может быть использована для истории. Количество раундов оценки может варьироваться от одного пользовательского рассказа к другому.
Преимущества планирования оценки покера
Планирование покера сочетает в себе три метода оценки –
Мнение эксперта : В подходе оценки, основанном на мнении эксперта, эксперта спрашивают, сколько времени займет что-то или насколько оно будет большим. Эксперт дает оценку, опираясь на свой опыт, интуицию или интуицию.
Экспертная оценка мнения обычно не занимает много времени и является более точной по сравнению с некоторыми аналитическими методами.
Аналогия : Оценка аналогии использует сравнение пользовательских историй. Оцениваемая пользовательская история сравнивается с аналогичными пользовательскими историями, реализованными ранее. Это приводит к точным результатам, так как оценка основана на проверенных данных.
Дезагрегация . Оценка дезагрегации выполняется путем разделения пользовательской истории на более мелкие, более простые для оценки пользовательские истории. Пользовательские истории, которые будут включены в Sprint, обычно находятся в диапазоне от двух до пяти дней. Следовательно, пользовательские истории, которые, возможно, занимают больше времени, должны быть разбиты на более мелкие варианты использования. Этот подход также гарантирует, что будет много сопоставимых историй.
Заключение
Planning Poker – приятный, но продуктивный подход к оценке. Поскольку сессия открыта для обсуждений до получения окончательной оценки, команде было бы легко прийти к консенсусу, а также иметь широкое представление о реализации пользовательской истории под рукой.
Scrum – Инструменты
Инструменты Scrum облегчают планирование и отслеживание проектов Scrum. Они предоставляют единое место для управления невыполненными работами по продукту, спринтами, планирования и отслеживания спринтов, отображения графиков Burndown, проведения ежедневных собраний Scrum и проведения ретроспективных исследований Scrum.
Есть много различных типов инструментов Scrum. Некоторые из них бесплатны (с открытым исходным кодом), некоторые платные, а для некоторых вы получаете дистиллированную версию инструмента. Однако, чтобы получить все возможности и масштабируемость, вам нужно купить полную версию.
Доступные инструменты Scrum
Ниже приведен список некоторых инструментов Scrum, доступных на рынке по состоянию на день. Инструменты с открытым исходным кодом помечены звездочкой.
Axosoft | Airgile | Agile Cockpit | Джира (ГринХоппер) | Mingle |
Scrumwise | Agilo For Scrum | Банановый скрам | Kunagi | Сейчас |
Версия первая | AgileWrap | Ежедневное Scrum | Интервалы | Pango Scrum |
Acunote | Agile Tracking Tool * | Digaboard * | iMeta Agility | Pivotal Tracker |
Agile Agenda | Agile Task | EasyBacklog | Ice Scrum * | pmScrum |
Agile Bench | Agile Soup | Объяснить PMT | Hansoft | Prj Planner |
Agile Buddy | Проворный менеджер | Agile Express * | GravityDev | Карты проекта |
Agile Fant * | Agile Log | Fire Scrum * | Fulcrum * | Квантовый Шепот |
Quick Scrum | Retrospectiva * | Scrum’d | Скрам Фабрика * | Scrumpy |
Rally Dev | Scrinch * | Scrum Dashboard * | Scrum Edge | Scrum Pad |
Redmine Backlogs | Scrum 2 Go | Скрам Стол | Скрам До | Чирикать Scrum |
Scrumrf | Время схватки * | Scrumwise | Выбор фабрики решений | Снасти* |
Городская черепаха | ScrumTool | Скрам Работы | Timebox | Острый Оранжевый Скрам |
Заключение
Agile в целом, Scrum в частности не означает, что нет документации работы. Скрам-артефакты определены, Scrum-планирование и отслеживание хорошо известны.
Инструменты Scrum облегчают сбор и отслеживание информации о проектах Scrum. Выбор инструмента зависит от функций, требуемых организацией, в дополнение к потребностям любого другого инструмента.
Скрам – Преимущества
Scrum поддерживает постоянное сотрудничество между заказчиком, членами команды и соответствующими заинтересованными сторонами. Его ограниченный по времени подход и постоянная обратная связь с владельцем продукта гарантируют работоспособность продукта с необходимыми функциями. Кроме того, Scrum предоставляет различные преимущества для различных ролей в проекте.
Преимущества для клиента
Спринты имеют меньшую продолжительность, и приоритетные пользовательские истории рассматриваются при каждом спринте. Это гарантирует, что при каждой доставке спринта будут сразу включены функции, требуемые клиентом. Кроме того, если клиент вызывает какой-либо запрос на изменение, он будет включен в текущий спринт или включен в следующий спринт. Таким образом, команда разработчиков быстро реагирует на требования заказчика очень быстро.
Преимущества для организации
Организация может сосредоточиться на усилиях, необходимых для разработки приоритетных пользовательских историй и, таким образом, сократить накладные расходы и переработку. Благодаря особым преимуществам scrum для клиента, возможна повышенная эффективность команды разработчиков, удовлетворенность клиентов и, следовательно, удержание клиентов и отзывы клиентов. Это увеличивает рыночный потенциал организации.
Преимущества для менеджеров по продукту
Менеджер по продукту играет роль владельца продукта в проекте. Ответственность владельца продукта заключается в обеспечении удовлетворенности потребителя. Поскольку Scrum способствует быстрому реагированию, расстановке приоритетов работы, поглощению изменений, менеджер по продукту может легко обеспечить соответствие работы потребностям клиента, что, в свою очередь, обеспечивает удовлетворение клиента.
Преимущества для руководителей проектов
Менеджер проекта играет роль Scrum Master в проекте. Совместная природа Scrum способствует простому и конкретному планированию и отслеживанию. Использование Burndown Charts для понимания оставшейся работы, а также ежедневные встречи Scrum позволяют руководителю проекта постоянно узнавать о состоянии проекта. Эта осведомленность необходима для мониторинга проекта, а также для быстрого выявления и решения проблем.
Преимущества для команды разработчиков
Из-за ограниченного по времени характера спринтов и увеличения количества доставляемых рабочих продуктов в конце каждого спринта команда разработчиков с энтузиазмом видит, что их работа используется немедленно. Встроенное командное сотрудничество позволяет команде получать удовольствие от работы, которую они выполняют. Поскольку пользовательские истории для каждого спринта основаны на приоритетах клиентов, команда также понимает, что их работа ценится.
Скрам – Сертификаты
Scrum-сертификаты предлагаются Scrum Alliance. Предлагаются следующие сертификаты –
- Сертифицированный ScrumMaster (CSM)
- Сертифицированный владелец продукта Scrum (CSPO)
- Сертифицированный специалист по схватке (CSP)
- Сертифицированный Scrum Coach (CSC)
- Сертифицированный Scrum Trainer (CST)
Сертифицированный ScrumMaster (CSM)
Сертифицированный Scrum Master – это базовый сертификат, позволяющий стать членом Scrum Alliance, сыграть роль Scrum Master и получить право на получение других сертификатов. Сертификация требует посещения курса CSM. После этого кандидат получает электронное письмо с указанием деталей членства в Scrum и онлайн-экзамена CSM. После сдачи экзамена кандидат получает сертифицированную сертификацию ScrumMaster (CSM).
Сертифицированный владелец продукта Scrum (CSPO)
Сертифицированный владелец продукта Scrum – это базовая сертификация, позволяющая стать членом Scrum Alliance, играть роль владельца продукта и получить право на получение других сертификатов.
Сертифицированный специалист по схватке (CSP)
Certified Scrum Practitioner – это сертификат для опытных владельцев ScrumMasters и владельцев продуктов. Кандидат должен быть ScrumMaster или владельцем продукта в течение как минимум одного года. Кандидат должен подать заявление, содержащее подробное описание того, что он или она сделали в указанной роли.
Кандидат может получить сертификат CSP сразу после сертификации CSM или сертификации CSPO, при условии, что кандидат активно практикует роль ScrumMaster или роль Владельца продукта в течение требуемого периода времени.
Сертифицированный Scrum Coach (CSC)
Сертифицированный Scrum Coach – это сертификат для тех, кто занимается коучингом. Сертификация требует, чтобы кандидат обучал Скрам Команды через их принятие и овладение Скрамом в течение как минимум 1500 часов за последние 5 лет.
Сертифицированный Scrum Trainer (CST)
Сертифицированный Scrum Trainer – это сертификат для тех, кто хочет преподавать классы CSM или CSPO. Кандидаты должны иметь либо CSM, либо CSPO, и должны быть CSP не менее года, прежде чем подавать заявку.
Scrum – часто задаваемые вопросы
Ниже приведены некоторые часто задаваемые вопросы о Scrum –
Вопрос: В чем разница между Scrum и Agile Development?
Ответ : Agile Development – это методология программного обеспечения, в то время как Scrum – одна из структур процессов, которая следует за Agile.
Вопрос: Спринты и итерации одинаковы?
Ответ : И Спринты Scrum, и Итерации Итеративной Инкрементальной модели обеспечивают приращения рабочего продукта. Однако они отличаются тем, что:
- Жизненные циклы Sprint и Iteration разные.
- Спринты ограничены по времени, а итерации нет.
- Продолжительность Спринтов намного меньше по сравнению с продолжительностью Итераций.
Вопрос: Является ли Scrum Master названием должности или ролью, которую заполняет кто-то с существующим названием работы?
Ответ : Scrum Master – это роль, которую исполняет кто-то с должностью. Обычная практика заключается в том, что человек, играющий роль менеджера проекта, также играет роль ScrumMaster.
Вопрос: Могут ли роли Владельца продукта и ScrumMaster играть один и тот же человек?
Ответ : Нет, так как владение отличается. Владелец продукта заботится о бэклоге продукта, расстановке приоритетов пользовательских историй и проверке приращения рабочего продукта с пользовательскими историями, выделенными для Sprint.
Вопрос: Не требуется ли для Scrum Project никакой документации?
Ответ : Нет. Scrum-проекты, как и любые другие проекты, требуют документации, такой как пользовательские истории, дизайн, тестовые примеры и т. Д.
Заключение
Agile и Scrum – это не одно и то же. Scrum – это одна из сред, адаптирующих Agile. Scrum рекомендуется командам с опытными членами команды, так как Framework требует большого сотрудничества и самоорганизации. Если правила Scrum не соблюдаются строго, проект может привести к провалу. Следовательно, необходимо иметь правильное понимание концепций Scrum среди всей команды. Поскольку спринты имеют небольшую продолжительность и ограничены во времени, нет времени изучать особенности Scrum на работе, даже когда Scrum Master непрерывно контролирует проект.