Оглавление
Джефф Сазерленд. Софт за 30 дней. Как Scrum делает невозможное возможным
Информация от издательства
Введение
Раздел I. Почему любой бизнес в мире может создать программное обеспечение за 30 дней
1. Кризис в программном обеспечении: неправильный процесс разработки приводит к неправильным результатам
2. Scrum: правильный процесс приводит к правильному результату
3. Попробуй это сам: пилотный проект
4. Что могу сделать я?
Раздел II. Как создать программное обеспечение за 30 дней
5. Знакомство со Scrum
6. Scrum на уровне проекта
7. Развитие возможностей Scrum
8. Scrum на уровне организации
9. Преобразование организации: глубокое и устойчивое изменение
10. Скрамить Scrum
Приложение 1. Глоссарий
Приложение 2. Scrum-гайд
Статья I. Цель Scrum-гайда
Статья II. Общее представление о Scrum
Раздел 2.01. Фреймворк Scrum
Статья III. Теория Scrum
Статья IV. Scrum
Статья V. Scrum-команда
Раздел 5.01. Владелец продукта
Раздел 5.02. Команда разработки
Раздел 5.03. Scrum-мастер
Статья VI. События Scrum
Раздел 6.01. Спринт
Раздел 6.02. Планирование спринта
Раздел 6.03. Scrum-митинг
Раздел 6.04. Обзор спринта
Раздел 6.05. Ретроспектива спринта
Статья VII. Scrum-артефакты
Раздел 7.01. Бэклог продукта
Раздел 7.02. Бэклог спринта
Раздел 7.03. Инкремент
Статья VIII. Определение «законченности»
Статья IX. Заключение
Статья X. Благодарности
Раздел 10.01. Люди
Раздел 10.02. История
Приложение 3. Сценарий достижения гибкости организации
1.1. Введение
1.2. Обзор Scrum и гибкой разработки программного обеспечения
1.2.1. Принципы Scrum
1.2.2. Scrum и гибкость разработки программного обеспечения
1.3. Подготовка к Scrum
1.3.1. Скрамить сразу и процесс разработки программного обеспечения, и организацию
1.3.2. Роль высших руководителей как организационных Scrum-мастеров в процессе непрерывного улучшения
1.3.3. Предупреждение: изменение – трудная работа
1.4. Сценарий адаптации Scrum
1.4.1. Действие 0 – общее представление, оценка и предварительная подготовка
1.4.2. Действие 1 – пилотные проекты
1.4.3. Действие 2 – организационная экспансия
1.4.4. Действие 3 – достижение воздействия
1.4.5. Действие 4 – измерение, оценка и регулировка
1.4.6. Действие 5 – распространение до победного конца
1.5. Организационные препятствия при адаптации Scrum
1.5.1. Выявление препятствий при помощи Scrum
1.5.2. Описание препятствий
1.6. Масштабирование Scrum
1.6.1. Масштабирование организации: Scrum-команды из Scrum-команд
1.6.2. Координирование Scrum-команд из Scrum-команд
1.6.3. Инструментальная инфраструктура для гибкости предприятия
1.7. Выводы
Благодарности
Об авторах
Отрывок из книги
Мы, Джефф и Кен, работаем в индустрии программного обеспечения в общей сложности 70 лет.
Мы были разработчиками программного обеспечения, менеджерами в IT-организациях и компаниях программного обеспечения и владельцами компаний по девелопменту и сервисному обслуживанию софта. Более 20 лет назад мы создали процесс, который позволил сотням организаций делать программный продукт лучше. Наша работа распространилась шире, чем мы когда-либо могли себе представить, ее плодами воспользовались миллионы людей, и мы в восторге от результатов, которых они смогли добиться.
.....
3. Люди должны быть предсказуемы и надежны, как машины. План требует выполнения специфической сети задач, каждая из которых требует определенного количества часов от сотрудника, имеющего специальные навыки, которому даны четко определенные исходные данные. К сожалению, сеть задач меняется с каждым изменением требований. Еще большая проблема – то, что люди не машины. У них бывают хорошие и плохие дни, разный уровень профессионализма, отношение к делу и умственные способности. В итоге задачи выполняются не так, как изначально планировалось.
Индустрия разработки программного обеспечения понимает эти трудности и годами пыталась решить их путем наращивания усилий по планированию. Проект планирования мог занимать столько же времени, сколько и сам девелопмент. Подготовительный этап стал включать в себя сбор требований, определение архитектуры и детальную разработку планов.
.....
