Масштабированный скрам. Как организовать гибкую разработку в крупной компании

Масштабированный скрам. Как организовать гибкую разработку в крупной компании
Автор книги: id книги: 2469208     Оценка: 0.0     Голосов: 0     Отзывы, комментарии: 0 999 руб.     (9,8$) Читать книгу Купить и скачать книгу Купить бумажную книгу Электронная книга Жанр: Правообладатель и/или издательство: Альпина Диджитал Дата публикации, год издания: 2009 Дата добавления в каталог КнигаЛит: ISBN: 9785961483963 Скачать фрагмент в формате   fb2   fb2.zip Возрастное ограничение: 0+ Оглавление Отрывок из книги

Реклама. ООО «ЛитРес», ИНН: 7719571260.

Описание книги

Эксперты по масштабированному скраму (LeSS) Крэг Ларман и Бас Водде предлагают читателям своей книги полный инструментарий для использования скрама в больших и распределенных группах разработки. Опираясь на свой и чужой опыт внедрения гибкой разработки, авторы собрали под одной обложкой ответы на ключевые вопросы, которые могут возникнуть у агента изменений, решившего трансформировать свою команду и сделать ее непобедимой. Вы узнаете, как обеспечивать устойчивость кода, когда проводить тестирование, по каким метрикам оценивать эффективность процессов, устанавливать систему вознаграждений и определять требования к продукту на разных этапах разработки. Отдельный раздел посвящен разбору скрам-терминологии: прочитав его, вы усвоите, что такое спринт, чем занимается скрам-мастер и кто отвечает за бэклог продукта.

Оглавление

Бас Водде. Масштабированный скрам. Как организовать гибкую разработку в крупной компании

Предисловие

Условные обозначения в тексте

Об авторах

Благодарности

Глава 1. Введение

Инструменты мышления и организации

Инструменты действия

Эксперименты: «Попробуйте… Избегайте…»

Ограничения

Инструменты мышления. Глава 2. Системное мышление

Учимся видеть системную динамику

Учимся видеть ментальные модели

Пример: динамика «быстрее – значит медленнее»

Учимся видеть корневые причины

Учимся видеть (и слышать) локальную оптимизацию

Заключение

Рекомендуемая литература

Глава 3. Бережливый подход

Бережливый подход: общая картина

Предыстория

Дом бережливого подхода

Цель бережливого подхода: создавать ценность быстро и устойчиво

Фундамент бережливого подхода: менеджеры-учителя с бережливым мышлением

Столп первый: уважение к людям

Столп второй: непрерывное улучшение

14 принципов

Бережливая разработка продуктов

Кейс: анализ канбан-системы

Заключение

Рекомендуемая литература

Глава 4. Теория массового обслуживания

Попробуйте… конкурировать за счет укорачивания времени циклов

Управление очередями для сокращения длительности циклов

Теория массового обслуживания

Скрытые партии: развивайте чутье на партии

Скрытые очереди: развивайте чутье на очереди

Косвенные преимущества уменьшения размеров партий и времени циклов

Управление очередями в скраме

Теория ограничений систем

Заключение

Рекомендуемая литература

Глава 5. Ложные дихотомии

Вес метода и эмпирический процесс в скраме

Ложные дихотомии

Избегайте… крайнего релятивизма

Заблуждения

Глава 6. Будьте гибкими

Манифест гибкой разработки: четыре ценности

Скрам: пять ценностей

12 принципов гибкой разработки

Принципы гибкого управления

Заключение

Рекомендуемая литература

Инструменты организации. Глава 7. Фича-команды

Что такое фича-команды

Избегайте… использования монофункциональных команд

Избегайте… использования компонентных команд

Попробуйте… использовать фича-команды

Переход к использованию фича-команд

Заключение

Рекомендуемая литература

Глава 8. Команды

Попробуйте… использовать самоорганизующиеся команды

Попробуйте… ставить перед собой сложные, но реалистичные цели

Попробуйте… использовать кросс-функциональные команды

Попробуйте… использовать долгоживущие команды

Попробуйте… сделать команды владельцами процесса

Попробуйте… передать командам управление внешними зависимостями

Попробуйте… сконцентрировать усилия членов команд на одном проекте

Попробуйте… развивать многопрофильных специалистов

Попробуйте… передать командам принятие решений

Попробуйте… использовать открытый командный конфликт

Влияние на организацию

Заключение

Литература

Глава 9. Области требований

Попробуйте… использовать области требований

Переход к использованию областей требований

Инструменты

Заключение

Глава 10. Организация

10 ключевых организационных препятствий

Цель и стратегия

Задача

Структура

Процессы

Вознаграждение

Люди

Заключение

Рекомендуемая литература

Глава 11. Масштабированный скрам

Общий обзор

Попробуйте… масштабированный скрам фреймворк-1 для группы, насчитывающей до 10 команд

Попробуйте… масштабированный скрам фреймворк-2 для больших групп

Некоторые проблемы при масштабировании скрама

Заключение

Разное. Глава 12. Азбука скрама

Традиционная разработка программного обеспечения

Гибкая разработка и скрам

Обзор скрама

Роли

Запуск скрама

Планирование спринта

Ежедневный скрам

Обновление бэклога спринта и диаграмма сгорания спринта

Уточнение бэклога продукта

Завершение спринта

Обзор спринта

Ретроспектива спринта

Обновление бэклога релиза и диаграмма сгорания релиза

Начало следующего спринта

Релизный спринт

Планирование релиза и первичное уточнение бэклога продукта

Фокус на продукте или на приложении

Распространенные проблемы

Результаты скрама

Рекомендуемая литература

Библиография

Рекомендуем книги по теме

Отрывок из книги

Мы благодарим вас за то, что вы решили прочитать эту книгу! Мы постарались сделать ее полезной. Дополнительные материалы и рекомендации можно найти на сайтах www.craiglarman.com. и www.odd-e.com. Пожалуйста, свяжитесь с нами, если у вас возникнут вопросы.

Момент, который нужно подчеркнуть, или не очень существенный новый термин. Важная идея или важный новый термин. [Bob67] – ссылка на библиографию.

.....

Уже на этом этапе можно столкнуться с законом Вайнберга‒Брукса и ловушкой причинно-следственной связи. Нарисовать схему легко; совсем другое дело – построить ее с правильным пониманием. Например, рассмотрим взаимосвязь между количеством разработчиков и скоростью разработки.

Природа некоторых причинно-следственных связей не всегда очевидна. Но людям свойственно делать поспешные выводы, что рост числа разработчиков ведет к ускорению разработки. Однако увеличение команды, особенно на поздних стадиях разработки, способно, наоборот, уменьшить скорость (подпункт «Закона Брукса» [Brooks95]). Кроме того, большое число плохих программистов может существенно замедлить работу, и часто бывает, что их удаление из группы хорошо сказывается на общей скорости.

.....

Добавление нового отзыва

Комментарий Поле, отмеченное звёздочкой  — обязательно к заполнению

Отзывы и комментарии читателей

Нет рецензий. Будьте первым, кто напишет рецензию на книгу Масштабированный скрам. Как организовать гибкую разработку в крупной компании
Подняться наверх