Scrum методология
Практическое руководство.
Майк Кон «Scrum. Гибкая разработка ПО» Вильямс, 2013 год, 576 стр. (17,0 мб. pdf)
Scrum — методология гибкой разработки программного обеспечения. Она акцентируется на качественном контроле процесса разработки. Помимо управления проектами, Scrum может быть использован в командной работе по поддержке программного обеспечения. Представленная книга основывается на практическом опыте автора по быстрому освоению Scrum и гибкой методологии разработки программного обеспечения. В ней охвачены все стадии разработки проекта и даются рекомендации по планированию и эффективному решению Scrum-проектов. Данное практическое руководство рассчитано на специалистов в области разработки ПО, которые уже знакомы с Scrum но хотят получить ответы на некоторые возникающие трудные вопросы при разработке Scrum-проектов. Приводится описание всего процесса методологии, начиная от внедрения Scrum до получения полной гибкости в организации коллективной работы над разработкой и сопровождением ПО.
ISBN: 978-5-8459-1731-7
Об авторе.
Майк Кон является основателем компании Mountain Goat Software, занимающейся обучением и предоставляющей консалтинговые услуги в области гибкой Scrum методологии и разработки программного обеспечения. Майк специализируется на оказании помощи компаниям во внедрении Scrum и повышении их гибкости, позволяющей этим компаниям стать необычайно эффективными проектными организациями. Помимо данной книги, Майк Кон написал User Stories Applied for Agile Software Developmentи Agile Estimating and Planning, а также книги по программированию на Java и С++.
Часть I. Приступаем к освоению Scrum 35
Глава 1. Гибкая методология разработки: нелегко, но перспективно 37
Чем обусловлены трудности перехода к использованию Scrum 39
Успешное изменение не осуществляется исключительно по принципу "сверху вниз" или "снизу вверх" 40
Конечное состояние перехода к Scrum непредсказуемо 41
Scrum проникает буквально во все поры организации 42
Scrum — очень своеобразная методология 43
Перемены происходят быстрее, чем прежде 44
Передовые методы таят в себе опасность 45
Почему переход к использованию Scrum стоит затрачиваемых на него усилий 46
Повышение производительности и снижение издержек 47
Повышение заинтересованности работников в выполняемой ими работе и более высокая удовлетворенность ею 50
Сокращение времени вывода новых продуктов на рынок 51
Повышение качества 52
Повышение удовлетворенности всех, кто так или иначе связан с разработкой новых продуктов 53
Неудовлетворенность прежними методами работы 54
Что дальше 55
Дополнительная техническая литература 56
Глава 2. ADAPTация к Scrum 57
Осознание 59
Инструменты, способствующие осознанию 61
Желание 63
Инструменты, способствующие возникновению желания перейти к Scrum 64
Способность 68
Инструменты, позволяющие выработать способность 69
Продвижение 72
Инструменты продвижения Scrum 73
Распространение 76
Источники "организационной гравитации" 77
Взглянем на картину в целом 80
Scrum методология
Дополнительная техническая литература 81
Глава 3. Модели внедрения Scrum 83
Массовость: за и против 83
Почему следует отдать предпочтение постепенному переходу 85
Почему следует отдать предпочтение одновременному переходу 86
Выбор между одновременным и постепенным переходами 87
Открытый и скрытый варианты перехода 88
Причины, по которым предпочтение отдается открытому варианту перехода 89
Причины, по которым предпочтение отдается скрытому варианту перехода 90
Выбор между скрытым и открытым вариантами перехода
к использованию Scrum 91
Варианты распространения опыта использования Scrum 92
Метод "разделить и засеять" 92
Метод "нарастить и разделить" 93
Внутреннее наставничество 94
Преимущества метода "разделить и засеять" 94
Преимущества метода "нарастить и разделить" 95
Преимущества внутреннего наставничества 95
Выберите свой подход 96
Внедрение новых технических приемов 97
Причины раннего опробования новых приемов 98
Причины позднего опробования новых приемов 99
Последнее соображение 99
Дополнительная техническая литература 101
Глава 4. Движение в направлении гибкости 103
Журнал совершенствования 105
Сообщество в поддержку перехода к Scrum 107
Спринты ETC 108
Обязанности ETC 111
Сообщества в поддержку усовершенствований 114
Катализаторы усовершенствований 116
Спринт сообщества в поддержку усовершенствований 117
Сосредоточьтесь на целях, имеющих непосредственное отношение к практике 119
Члены сообщества в поддержку усовершенствований 120
Роспуск сообщества 122
Универсального рецепта не существует 123
Что дальше 123
Дополнительная техническая литература 124
Глава 5. Ваши первые проекты 127
Выбор пилотного проекта 128
Четыре характеристики идеального пилотного проекта 128
Выбор времени для внедрения Scrum 131
Когда приближается час расплаты 131
Выбор пилотной команды 133
Если пилотный проект неудачен 134
Формулировка ожиданий и управление ими 135
Ожидания, касающиеся прогресса 136
Ожидания, касающиеся предсказуемости 138
Ожидания, касающиеся отношения к Scrum 139
Ожидания, касающиеся участия всех заинтересованных сторон 139
Речь идет о пилотном проекте 140
Дополнительная техническая литература 140
Часть II. Люди 143
Глава 6. Преодоление сопротивления 145
Можно ли предвидеть возникновение сопротивления 146
Кто будет сопротивляться 146
Заблуждения и фобии 148
Информация о переменах 150
Послания лидеров 150
Мнение коллег 151
Тонкости индивидуального сопротивления 152
Скептики 155
Саботажники 158
Консерваторы 160
Последователи 162
Сопротивление как полезный предупреждающий сигнал 164
Scrum методология
Дополнительная техническая литература 165
Глава 7. Новые роли 167
Роль Scrum-мастера 167
Качества хорошего Scrum-мастера 168
Технические лидеры в качестве Scrum-мастеров 171
Scrum-мастера: собственные или приглашенные 173
Ротация Scrum-мастеров 173
Преодоление типичных проблем 174
Владелец продукта 176
Обязанности владельца продукта 176
Каждой команде нужен только один владелец продукта 179
Качества хорошего владельца продукта 182
Scrum-мастер как владелец продукта 183
Преодоление типичных проблем 184
Новые роли, прежние обязанности 187
Дополнительная техническая литература 187
Глава 8. Изменившиеся роли 189
Аналитики 190
Руководители проектов 192
Почему изменяется название должности 195
Архитекторы 196
Архитектор, не занимающийся кодированием 197
Функциональные менеджеры 197
Лидерская роль функционального менеджера 198
Обязанности, связанные с управлением кадрами 199
Программисты 200
Администраторы базы данных 202
Тестеры 202
Проектировщики пользовательского опыта 206
Три общие темы 208
Дополнительная техническая литература 209
Глава 9. Технические приемы 211
Стремление к техническому совершенству 212
Проектирование на основе тестирования 212
Рефакторинг 215
Коллективное владение 217
Непрерывная интеграция 219
Парное программирование 221
Проектирование: целенаправленное и спонтанное 224
Привыкайте к жизни без крупномасштабного проектирования 225
Управление проектированием 227
Обязательное совершенствование технических приемов 230
Дополнительная техническая литература 231
Часть III. Команды 235
Глава 10. Структура команды 237
Накормите команду двумя пиццами 238
Почему достаточно двух пицц 239
Производительность небольшой команды 241
Команды, специализирующиеся на определенных функциональных возможностях 244
Используйте компонентные команды экономно 246
Кто принимает эти решения 250
То, что правильно сегодня, может оказаться неправильным завтра 251
"Самоорганизующаяся" не означает "случайно сформированная" 251
Как подобрать подходящих членов команды 252
Один человек — один проект 254
Когда задач слишком много, время на их выполнение сокращается 256
Когда многозадачность является подходящим вариантом 257
Корпоративная форма многозадачности 258
Исключите однообразный механический труд 259
Рекомендации по выбору структуры команды 260
Что дальше 262
Дополнительная техническая литература 263
Глава 11. Организация коллективного труда 265
Воспитание чувства коллективной ответственности 266
Воспитание у команды чувства приверженности поставленной перед ней цели 268
Полагайтесь на специалистов, не злоупотребляя ими 269
Старайтесь понемногу выполнять разные работы 271
Чтобы завершить все работы, не нужно ожидать окончания спринта 273
Балансируйте размеры элементов журнала запросов 273
Способствуйте обучению команды 274
Позаботьтесь о создании условий для обучения 275
Избегайте потерь знаний 280
Стимулируйте сотрудничество, напоминая о совместной цели 282
А теперь все вместе 285
Дополнительная техническая литература htbook.ru 286
Глава 12. Управление самоорганизующимся коллективом 287
Влияние на самоорганизацию 288
Контейнеры, различия и обмены 289
Влияние на эволюцию команды или компании 296
Выбирайте внешнее окружение 297
Сформулируйте, что такое успешное функционирование 298
Управляйте смыслом 298
Внедряйте замещающие системы отбора 299
Подзаряжайте систему энергией 300
Лидерство — это не только покупка пиццы 302
Дополнительная техническая литература 303
Глава 13. Журнал запросов на выполнение работ 305
Переход от документов к обсуждениям 306
Не выплесните ребенка вместе с документацией 309
Используйте в журнале запросов на выполнение работ истории пользователей 309
Постепенное уточнение требований 312
Спонтанно возникающие требования 312
Айсберг журнала запросов на выполнение работ 314
Зачем нужно постепенно уточнять требования 316
Постепенное уточнение историй пользователя 317
Учитесь начинать без спецификации 321
Создание спецификаций на основе примеров 322
Межфункциональные команды снижают потребность в документации 325
Критерии DEEP для журнала запросов 326
Не забывайте обсуждать 327
Дополнительная техническая литература 327
Глава 14. Спринты 329
Каждый спринт должен заканчиваться созданием работоспособного
программного обеспечения 330
Определение понятия "потенциально готов" 331
Рекомендации по определению понятия "потенциально готов" 333
Создавайте к окончанию каждого спринта что-то значимое 336
Готовьтесь в текущем спринте к следующему 340
Спринты типа "бильярдный шар" 340
Включайте в спринт только реальный объем работы 341
Работайте вместе 343
Избегайте спринтов, посвященных определенным видам деятельности 345
Замените отношения "от окончания к началу" отношениями
"от окончания к окончанию" 346
Распараллеливание проектирования пользовательского опыта 347
Мыслите целостно, работайте инкрементно 349
Архитектура и проектирование баз данных 350
Временные рамки: неизменные и строгие 352
Никогда не продлевайте спринт 354
Не меняйте цель 356
Откажитесь от перенацеливания команды 359
Получайте отзывы, учитесь и приспосабливайтесь 360
Дополнительная техническая литература 361
Глава 15. Планирование 363
Постепенно уточняйте свои планы 364
Никаких сверхурочных для спасения плана 366
Обходиться без сверхурочной работы трудно 368
Как прийти к финишу с наилучшим результатом 369
Если не сверхурочные, то что? 371
По возможности предпочитайте изменение масштаба 372
Альтернативные варианты 373
Важность контекста конкретного проекта 376
Оценки и обязательства — это не одно и то же 378
Какими данными нужно располагать 378
Переход от оценки к обязательству 381
Исторически сложившаяся скорость создает основу для обязательств 383
Резюме 387
Scrum методология
Дополнительная техническая литература 388
Глава 16. Качество 389
Включайте тестирование в процесс разработки 390
Почему тестирование в конце не дает нужного результата 391
Как выглядит встраивание качества в процесс разработки на практике 392
Автоматизируйте на разных уровнях 394
Другие роли тестов пользовательского интерфейса 397
Роль тестирования вручную 397
Автоматизируйте во время спринта 398
Выгоды от автоматизации тестов 400
Выполняйте разработку на основе приемочных тестов 401
Наиболее подходящий уровень детализации 403
Выплатите технический долг 405
Выплата технического долга в три этапа 406
Качество зависит от команды 407
Дополнительная техническая литература 408
Часть IV. Организация 411
Глава 17. Изменение масштаба Scrum 413
Изменение масштаба роли владельца продукта 414
Совместная ответственность и разделение функциональности 415
Ведение большого журнала запросов на выполнение работ 416
Один продукт — один журнал 417
Поддерживайте разумный размер журнала 419
Упреждающий режим управления зависимостями 421
Планирование с накатом на несколько последующих спринтов 422
Проведение организационных совещаний, предваряющих
очередной релиз-цикл 425
Совместное использование специалистов командами 426
Использование специализированной команды интеграции 426
Координация работы команд 429
Объединенное Scrum-совещание 430
Синхронизация спринтов 433
Изменение масштаба совещания по планированию спринтов 435
Смещение на один день 435
Большая комната 436
Создание сообществ практиков 438
Формальные или неформальные 439
Создание условий для формирования и процветания сообществ практиков 440
Участие 442
Scrum и масштаб проекта 443
Дополнительная техническая литература 443
Глава 18. Рассредоточенные коллективы 445
Решите, как рассредоточить несколько команд 446
Добейтесь спаянности команды 449
Учитывайте культурные различия 450
Учитывайте незначительные культурные различия 452
Укрепляйте функциональную и командную субкультуры 453
Встречайтесь чаще 459
Визиты знакомства 459
Визиты с целью поддержания контактов 461
Путешествующие посланники 462
Измените способ своего общения 464
Объем документации растет htbook.ru 465
Добавление подробностей в журнал запросов на выполнение работ 466
Поощрение горизонтальных связей 466
Совещания 468
Советы общего характера 469
Совещание, посвященное планированию спринта 472
Ежедневное совещание разработчиков 475
Объединенные Scrum-совещания 479
Обзоры и ретроспективы спринтов 480
Действуйте с осторожностью 481
Дополнительная техническая литература 482
Глава 19. Сосуществование с другими подходами 485
Совмещение Scrum и последовательной разработки 486
Три сценария взаимодействия 486
Три сферы конфликта 487
Могут ли Scrum и последовательная разработка сосуществовать вечно 489
Надзор за выполнением проекта 490
Выполнение Scrum-проектов, когда надзор не связан с гибкой методологией разработки 492
Соответствие стандартам 494
ISO 9001 494
Интегрированная модель технологической зрелости организации (CMMI) 496
Обеспечение соответствия 498
Что дальше 500
Дополнительная техническая литература 500
Глава 20. Кадры, техническое обеспечение и отдел управления проектами 503
Отдел кадров 504
Структуры подчиненности 505
Периодические аттестации работников 506
Увольнение членов команды 509
Пути карьеры 510
Команда состоит из людей, а между людьми всегда возникают проблемы 511
Группа технического обеспечения 512
Физическое пространство 512
Мебель 516
О том, что должно быть хорошо видно в вашем рабочем пространстве 517
Отдел управления проектами 521
Люди 521
Проекты 522
Процесс 523
Переименование PMO 525
Подведем итоги 525
Дополнительная техническая литература 526
Часть V. Что дальше 529
Глава 21. Как далеко вы продвинулись в деле внедрения Scrum 531
Цель измерения 531
Универсальные оценки освоения гибкой методологии разработки 532
Опрос на соответствие уровню "шодан" 534
Схема оценки степени освоения командой гибкой Scrum методология разработки 535
Сравнительная оценка степени освоения командой гибкой методологии разработки 537
Разработка собственной оценки 540
Сбалансированная система показателей Scrum-команд 542
Построение сбалансированной системы показателей 543
Отдавайте предпочтение простым показателям 545
Должно ли это нас волновать 546
Дополнительная техническая литература 548
Глава 22. Впереди еще много работы 551
Scrum методология
Список технической литературы 553
Предметный указатель 565
Добавить комментарий