Жанры
Популярные книги
Груз 209-А - Илья Слобожанский
Груз 209-А - Илья Слобожанский
Топ лучших книг, которые стоит прочесть каждому.
Топ лучших книг, которые стоит прочесть каждому.
Игроки из Гран-Кафе - Жорж Сименон
Игроки из Гран-Кафе - Жорж Сименон
Рейтинговые книги
libking.club » Справочная литература » Справочники » S(crum)-Light – Понятный путь управления проектами - Александр Базанов
S(crum)-Light – Понятный путь управления проектами - Александр Базанов

S(crum)-Light – Понятный путь управления проектами - Александр Базанов

Уважаемые читатели!

Возрастные ограничения: (18+) Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних просмотр данного контента СТРОГО ЗАПРЕЩЕН! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту для удаления материала.

0/0
Описание онлайн-книги S(crum)-Light – Понятный путь управления проектами - Александр Базанов:
Зачем нужен S(crum)-Light?Чтобы облегчить жизнь. S(crum)-Light не подразумевает сложной (да и вообще, какой-либо) философии. S-Light – это набор простых правил, выполнения большинство из которых не является обязательным. Любая команда, может взять минимальные элементы S-Light (список задач, разработчиков и дейли) и у них уже будет S-Light.Дальше, они могут, как конструктов, добавлять новые элементы, которые им подходят. Так же они могут регулярно проводить простую самооценку, чтобы понимать, как глубоко они внедрили S-Light и что еще они могут еще добавить, чтобы попробовать увеличить свою производительность и повысить качество разработки. А может быть, им это и не нужно.
Читем онлайн S(crum)-Light – Понятный путь управления проектами - Александр Базанов

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 2 3 4

Юрий Недре, Александр Базанов

S(crum)-Light – Понятный путь управления проектами

Что такое S-Light?

S-Ligth – это фреймворк/метод/инструкция/набор правил (называйте как хотите) по процессам разработки программного обеспечения.

Зачем это нужно

На сегодняшний день, 2023 год, самый распространенный метод ведения проектов по разработке программного обеспечения (SDLC), является фреймворк Scrum.

Он применяется, как в больших Enterprise компаниях, так и в стартапах. Его популярность обусловлена простотой инструментов и краткостью описания. Это вам не PMBoK.

Казалось бы, собирай команду каждый день на небольшие летучки (и прочие собрания), назначь Product Owner’а (который будет принимать решения), Scrum Master’а (который будет отвечать за процесс), ну а команда developers есть всегда по умолчанию. И все счастливы. Scrum внедрен, а нам осталось наслаждаться регулярной поставкой ценности клиентам.

На этом останавливается бо́льшая часть команд. Вроде всё по Scrum, но команды спрашивают: “А что изменилось? Мы всё так же перетаскиваем карточки по доске. От того что наш Project Manager стал называться Scrum Master ничего не поменялось. Наша производительность не изменилась. Зачем это было нужно?”

Это и есть главная проблема и недостаток Scrum. Его нельзя просто понять, а главное внедрить, прочитав Scrum Guide. Его надо постичь. Scrum это не 5 ритуалов, 3 роли и 3 артефакта. Его бо́льшую часть занимает философия. Философию Scrum многие не могут понять и за несколько лет работы как Scrum Master.

Вот два примера вопроса из экзамена по Скрам-гайду:

Что представляет собой выбранный Элемент Бэклога Продукта во время Планирования Спринта?

1) Цель

2) Прогноз

3) План

4) Обязательство

или

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

1) Поощряйте этот подход, поскольку Скрам-команда обладает самоуправлением и лучше знает, как выполнять работу.

2) Предупредите, что это не лучшая идея и научите Скрам-команду брать на себя ответственность за продукт, который они создают как команда.

3) Поощряйте подобный подход, так как он делает роли и обязанности в Скрам-команде более четкими.

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

Многие ошибочно думают, что Scrum это гибкий фреймворк.

"А разве не так?”, спросят многие: “Он ведь относится к Agile. А это про гибкость."

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

• Дейлики растягиваются до 30 минут – нет, это не Scrum.

• Решили скипнуть ретро, так как команда вымотана в конце спринта – нет, это не Scrum.

• РО решил сам погрумить задачи без команды – нет, это не Scrum.

• Нет Scrum master – нет, это не Scrum.

• Сделали шаг влево от гайда – нет, это не Скрам.

Соблюдать все обязательные пункты и следовать рекомендациям Scrum Guide 99 % командам сложно (а иногда просто и невозможно), но без этого Scrum Guide говорит: «У вас не Scrum».

Зачем нужен S-Light?

Чтобы облегчить жизнь. S-Light не подразумевает сложной (да и какой-либо) философии. S-Light – это набор простых правил, выполнения большинство из которых не является обязательным. Любая команда, может взять минимальные элементы S-Light (цель, список задач, разработчиков и дейли) и у них уже будет S(crum)-Light.

Дальше они могут, как конструктов добавлять новые элементы, которые им подходят. Так же они могут регулярно проводить простую самооценку, чтобы понимать, как глубоко они внедрили S-Light и что еще они могут еще добавить, чтобы попробовать увеличить свою производительность и повысить качество разработки. А может быть, им это и не нужно.

Артефакты

Бэклог

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

Все элементы бэклога необходимо иметь пять элементов: описание, приоритет, оценка (относительная или абсолютная), ответственный и критерии приемки.

За один элемент бэклога ответственный один участник команды разработки.

Оценку элементов бэклога делают сотрудники, которые причастны к его реализации и/или понимают специфику разработки этого элемента. Рекомендуется, что Front-End задачи оценивались Front-End разработчиками, Back-End разработчики оценивали свои задачи, дизайнеры – свои и так далее.

Если команда дошла до стадии, когда работа планируется спринтами, то бэклог разделяется на две части:

• бэклог продукта или проекта

• бэклог спринта

Бэклог спринта – набор задач, которые необходимо выполнить команде разработки за спринт, чтобы достичь цели спринта.

Инкремент

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

Инкремент может быть создан после выполнения и доставки на продакшен:

1) Новой Feature;

2) Завершенной User Story;

3) Устранение бага (когда баг блокировал работу какой-то функциональности);

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

Каждый поставленный Инкремент должен быть шагом к достижению цели продукта или проекта.

Рекомендуется определить командой Definition of Done для инкремента: набор признаков, когда элементы(ы) бэклога превращаются в инкремент доставленный на продакшен.

1. Definition of Ready (DoR) – критерий готовности задачи к тому, чтобы взять ее в работу. DoR будет одинаковым для всех задач. Для этого на старте надо договориться, что именно должно быть в задаче, чтобы ее можно было реализовать. К примеру: задача имеет описание, критерии приемки (АС), ответственного, оценку, связь с другими задачами, ссылка на документацию, макет UI.

2. Definition of Done (DoD) – критерий выполнения задачи. DoR одинаков для всех задач. Для этого нужно договориться, в каком случае мы считаем, что задача полностью выполнена. К примеру: разработка завершена, проведены все виды тестирования, выполнена поставка на продакшен, описание дополнено в документации.

3. Acceptance Criteria (AC) – критерий проверки того, что задача работает так, как планировалась. AC будут уникальными для каждой задачи, написанными специально для этой задачи. Обычно составляются в виде чек-листа к задаче. АС должны быть прописаны так, чтобы были понятны, как разработчикам, так и тестировщикам и чтобы не было их двойного толкования.

DoR и DoD могут быть свои в каждой команде, (их можно устанавливать единые

1 2 3 4
На этой странице вы можете бесплатно читать книгу S(crum)-Light – Понятный путь управления проектами - Александр Базанов бесплатно.
Похожие на S(crum)-Light – Понятный путь управления проектами - Александр Базанов книги

Оставить комментарий

Copyright libking © 2024 | Все права защищены.

Политика конфиденциальности
[email protected]