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

На данной странице вы можете читать онлайн книгу "S(crum)-Light – Понятный путь управления проектами" авторов Александр Базанов, Юрий Недре. Общий объем текста составляет эквивалент 15 бумажных страниц. Произведение многоплановое и затрагивает разнообразные темы, однако его жанры наиболее вероятно можно определить как компьютерная справочная литература, проектирование. Книга была добавлена в библиотеку 08.12.2023, и с этой даты любой желающий может удобно читать ее без регистрации. Наша читалка адаптирована под разные размеры экранов, поэтому текст будет одинаково хорошо смотреться и на маленьком дисплее телефона, и на огромном телевизоре.

Краткое описание

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

Книга 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.