В последнее время в сообществе выходило много статей, видео про Scrum. Смотрев одно из видео на данную тему в котором выступал Иван Белокаменцев и рассказывал про “казахский scrum” упомянул в своем докладе, что книга Джеффа Сазерланда «Scrum. Революционный метод управления проектами» является библией скрама.
Работая в 1С франчайзи и параллельно заканчивая магистратуру заочно я ни разу не слышал в этих местах о гибких методологиях разработки. Во франчайзи на вопросы про scrum можно услышать подобные выражения “что-то слышал о таком, вроде есть такая штука, не знаю, как это работает”. В универе нас несколько лет приучали к схеме «обследуем – рисуем куча диаграмм (IDEF0, IDEF3, DFD, ARIS) – пишем много “полезной” документации и только потом начинаем разрабатывать».
Воспользовавшись советом Ивана, я прочитал данную книгу. Во время прочтения книги делал пометки выбирая самое ценное для себя. По итогу сформировался список заметок, которые привел в данной статье. Порядок заметок расставил по важности, которые я выделил лично для себя. Самые заезженные заметки перенес в конец, а некоторые не стал включать.
-
Единая цель
-
Требования:
-
Многофункциональная (имеет набор специалистов, которые обладают всеми навыками, необходимые для завершения проекта)
-
Автономная
-
Свободная в принятии решения (лидер решает, что должно быть сделано и почему, команда решает каким образом достичь этого и кто будет это делать)
-
Совершенствующая свои возможности
-
Семь участников +-2 (малочисленные команды работают быстрее)
-
Разбейте вашу работу на спринты (короткий промежуток времени) от 1 недели до 4. Введя разработку короткими циклами это позволит наладить взаимосвязь с пользователем и незамедлительно избавляться от всего, что действительно мешает рабочему процессу. В конце каждого спринта должно быть что-то сделано – что-то, что можно использовать.
-
Все должны знать кто что делает. Информационная насыщенность ускоряет работу.
-
Собирайтесь ежедневно с командой на 15 минут. Обсуждайте, что можно сделать для увеличения скорости и качества и делайте это.
-
Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажитесь на финише (динамика * время = результат).
-
Не привязывайтесь к жесткому планированию, будьте готовы к переменам. В вашем плане должна быть возможность изменений и новых идей. Планируйте ровно столько, сколько нужно, чтобы ваши команды были всегда заняты.
-
Команда должна точно знать сколько она может выполнить за один спринт. Должна знать на сколько можно повысить производительность, работая разумнее и устраняя все, что встает на пути и тормозит ее работу.
-
Регулярно проверяйте ход работы и последовательно выясняйте: справляетесь ли вы с заданием: можете ли выполнить его лучше и интенсивнее.
-
Делая, несколько дел одновременно получится медленно и некачественно. Не введите проекты параллельно, расставьте приоритеты и идите пошагово один за другим, сконцентрируйтесь на одном.
-
Сделанное наполовину – не сделано.
-
Исправляйте ошибки сразу. Исправление спустя некоторое время займет больше времени.
-
Слишком усердный труд приводит к усталости, которая влечет за собой ошибки в работе. Вместо того чтобы работать допоздна и по выходным, лучше работать в будни в постоянном ритме.
-
Не ставьте недостижимых целей
-
Выбирайте самый легкий, самый простой путь к выполнению всех задач.
-
Оценивайте задачи относительно с помощью последовательности Фибоначчи (1,2,3,5,8,13) (вики).
-
Подумайте о клиенте, который получит пользу от вашей программы, зачем ему это нужно. Составляйте сценарии как X, я хочу Y, для того чтобы Z (x+y=z).
-
Используйте покер планирование, чтобы быстро оценить работу, которую нужно сделать (вики).
Планируйте то, что собираетесь выполнить. Сделайте. Проверьте, соответствует ли это тому, что вы хотели. Корректируйте и изменяйте методы работы на найденных ошибках. Ориентируйся на окружающую среду, ищи ответы вокруг себя.
-
Пусть вас знают за то, что вы делаете, а как к вам будут обращаться – не суть важно.
-
Обычно награждают только за результаты, но что больше всего нужно укреплять в людях – их стремление к величию.
-
Меняйте производительность команды, а не отдельного сотрудника.
-
Умейте осмыслять продукт, рынок, клиента. Превращайте идею проекта в бэклог. Составьте список всех задач, которые в принципе можно было бы сделать в рамках проекта. Поставьте вверху списка задачи с наивысшей ценностью и наименьшим риском.
-
Работа должна быть прозрачной. Сделайте доску, которая будет показывать, какую работу нужно выполнить, над чем вы сейчас работаете и что уже сделано. Должны видеть все и все должны обновлять информацию на ней.
-
Больше ценности за меньший процент функций. (80 к 20)
-
Создавайте новое только в том случае, если оно имеет ценность. Будьте готовы поменять его на то, что требует такого же усилия. То, что казалось вам нужным в самом начале, никогда не бывает тем, что важно на самом деле.
-
Выберите человека, который обладает видением того, что собираетесь делать. Он учитывает риски и выгоды, что нужно сделать, что может быть сделано. (Владелец продукта)
-
Выберите команду (команда).
-
В команде должен быть человек, которые помогает устранять мешающие ей препятствия (скрам- мастер).
-
Создайте бэклог продукта
-
Оцените бэклог. Оценивайте относительно (Фибоначчи), присвойте каждой задаче количество баллов.
-
Планирование спринта (время, планирование). С помощью баллов задач считайте динамику производительности. Нельзя добавлять новые задания.
-
Работа должна быть видимой. Скрам доска с колонками: нужно сделать, в работе, сделано.
-
Ежедневные обсуждения. Собирайтесь на 15минут и отвечайте на три вопроса:
-
Что ты делал вчера, чтобы помочь команде завершить спринт?
-
Что ты будешь делать сегодня, чтобы помочь завершить спринт?
-
Какие препятствия встают на пути к достижению цели спринта?
-
-
Обзор спринта. Встреча, где команда рассказывает, что сделано и демонстрирует готовый функционал сделаны за спринт.
-
Ретроспектива спринта. Обсудите след. вопросы: 1) что прошло хорошо 2) Что можно было сделать лучше? что можно сделать лучше в след. спринте? какое улучшение команда может внедрить немедленно?
-
Немедленно начинайте следующий спринт, учитывая возникающие препятствия и результаты непрерывного совершенствования.
В книге очень много делается акцент на то что scrum это “волшебная таблетка” (особенно последняя глава). Scrum спасает бедных африканцев, тащит политику, убивает Таноса в войне бесконечности. Во время прочтения данных заявлений представлял Джеффа и его команду примерно так:
Для первого знакомства с методологией книга и правда хорошо подходит, но с фильтром информации, чтобы не быть миньоном.
Как писал Джефф, что ценность любой программы заложена в двадцати процентах, так и я выделил для себя те двадцать процентов из книги.
"Для того чтобы люди были вдохновлены и вовлечены в свою работу, следует создать атмосферу содействия, когда с сотрудниками обращаются с уважением и восхищением."
Таблица основы Scrum:
Роли | Артефакты | События |
---|---|---|
Владелец продукта Команда разработки Scrum — мастер |
Инкременты Бэклог продукта Бэклог спринта |
Спринт Планирование спринта Scrum — митинг Обзор спринта Ретроспектива спринта |
Scrum в действии
Бэклог продукта включает:
- — функциональные требования
- — нефункциональные требования
- — инфраструктурные / инструментальные требования
Scrum словарь:
Scrum — команда состоит из владельца продукта, команды разработки и Scrum – мастера.
Scrum – мастер – методический лидер, который отвечает за то, чтобы Scrum процесс был понятен.
Scrum – митинг (Daily Scrum) – 15 минутное, ограниченное по времени совещание команды разработки для синхронизации действий и создания плана работы на следующие 24 часа. Проводится каждый день в одном месте и в одно время для уменьшения путаницы. Каждая команда/участник рассказывает следующее:
- Что было завершено со времени последнего совещания?
- Что будет сделано до следующего совещания?
- Какие есть препятствия на пути?
Scrum — команда состоит из владельца продукта, команды разработки и Scrum – мастера.
Бэклог продукта (Product Backlog) – упорядоченный список всего, что может потребоваться в продукте. За бэклог продукта отвечает владелец продукта.
Бэклог спринта (Sprint Backlog) – набор пунктов бэклога продукта, выбранных для спринта, а также план по созданию инкремента и реализации цели спринта. Определяет работу, которую сделаем команда, чтобы превратить пункты бэклога продукта в законченный инкремент.
Видение (Vision) – частично оформленная идея того, что функционирует определенным способом, может быть использовано для решения задач.
Владелец продукта отвечает за максимальное значение ценности продукта и производительности команды разработки.
Инкремент (Product Increment) – сумма всех пунктов бэклога продукта, законченных во время текущего спринта и всех предыдущих спринтов. В конце спринта новый инкремент должен быть “законченным”, что означает, что он должен быть готовым к использованию.
Итерация – повторяющееся действия, серия шагов или процессов.
Обзор спринта (Sprint Review) проводится в конце спринта для оценки инкремента и внесения, если необходимо, изменений в бэклог продукта. Во время обзора спринта обсуждается, что было сделано в спринте.
Планирование спринта (Sprint Planning) – мероприятия где планируется работа, которая должна быть выполнена в спринте. Планирование спринта отвечает на след вопросы:
- Что будет предоставлено в инкременте по завершении предстоящего спринта?
- Какая работа необходима, чтобы достигнуть этого приращения?
Ретроспектива спринта (Retrospective) – создание плана для улучшений, которые будут предприняты в следующем спринте. Происходит после обзора спринта и перед следующим планированием спринта.
Спринт – ограниченный промежуток времени, протяженностью один месяц или меньше, в течении которого производится законченный, пригодный к использованию и потенциально готовый к выпуску инкремента продукта. Цель спринта дать команде разработки некоторую гибкость касательно функциональных возможностей, выполняемых в пределах спринта.
Scrum не подлежит изменениям, и, хотя возможно использование только отдельных его частей, конечный результат уже не будет Scrum. Scrum существует только в своей целостности и может быть контейнером для дополнительных техник, методологий и практик.
По заголовку и аватару, уже испугался и подумал что статья одного знаменитого летописца, который стал с тревожной для многих частотой публиковать свои статьи, который одним нравятся, а других смущают местонахождением в разделе библиотека, ну разве нельзя сделать отдельный раздел для творчества ? с чем я отчасти согласен.
Что касательно статьи, вроде мало, но вроде по делу, но не по реальному опыту, а по итогам прочтения книги, по совету летописца) Поэтому, я бы просто прислушался, другое дело конечно, если бы выводы были подкреплены горьким опытом использования scruma.
Жирным шрифтом хотелось придать объема или внимания ? очень жирноватый и большой шрифт.
(1) У Вас весь текст жирным ? По оформлению старался сделать максимально удобно для чтения т.к многие статьи в сообществе идут сплошным текстом . Проверял на нескольких устройствах вроде все нормально отображается .
Agile, Scrum, kanban — и им подобное, ИМХО современный пересказ давно известных основ проектного управления.
Для молодых руководителей, которые только начинают грызть основы управления, — в принципе нормально.
Для людей с большим трудовым опытом, и вообще со стажем — вообще нет ни одного нового слова в этих книгах. Все эти истины — известны с бородатых времен. Все эти методы увеличения гибкости, клиентоориентированности и работу на результат — давным давно изложены в бизнес книгах. Да я могу уверять, что каждый найдет в своей работе элементы Scram, Kanban..только он об этом еще не знает.
ИМХО Преподнесение старого, под новым флагом, на который все почему-то молятся. Словечки эти иностранные. Только чудес не бывает. И закон треугольника — Быстро, Качественно, Недорого — никакой scram не изменит.
(2) Весь жирным, в любом случае спасибо за труд, есть к чему прислушаться и проанализировать, где-то вы правы. Даже если бы практикой был подкреплен, то всеравно есть с чем поспорить было бы, у всех разный опыт.
(4) да увидел с других браузеров, шрифт уменьшил. Спасибо за комментарий.
Похоже на краткое изложение учебника по скраму.
В книге очень много делается акцент на то что
Кто в курсе — с автором последнего комментария всё в порядке?
Спасибо, информативно.