Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным
- Название:Софт за 30 дней. Как Scrum делает невозможное возможным
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-768-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным краткое содержание
Эта книга поможет руководителям и менеджерам компаний, которые хотят покончить с дорогим и медленным циклом разработки ПО.
На русском языке публикуется впервые.
Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Каждый день в течение спринта разработчики проводят 15-минутные совещания, называемые Scrum-митингами, чтобы спланировать предстоящую работу, все время стремясь достигнуть того, что было договорено. Чтобы максимизировать продуктивность разработчиков, задачи спринта должны быть согласованы как разработчиками, так и владельцем продукта. Они соглашаются, что создадут столько требуемого функционала, сколько возможно, и могут быть переориентированы перед каждым новым спринтом. Владелец продукта соглашается, что требования, над которыми работает команда, не будут меняться в течение спринта. Все, что не было запланировано (включая, например, участие разработчиков во встречах с потребителями), может подождать до следующего спринта. Производительность разработчиков повышается, когда их не прерывают. Применение более коротких спринтов обычно обеспечивает внесение более частых изменений – об этом мы поговорим в следующей главе.
В конце спринта Scrum-мастер встречается с разработчиками для проведения обзора спринта. Эта встреча не должна продолжаться более четырех часов. Scrum-команда и ключевые заинтересованные стороны собираются и дают оценку результатам предыдущего спринта и прироста функционала. Обзор включает следующее: что было сделано, каков объем реализованных задач, насколько эффективна разработка и насколько полезен ее результат. Инкремент должен быть законченным фрагментом пригодного к применению программного обеспечения. Пункты бэклога продукта, которые выполнены не полностью, остаются в списке как «все еще требующие выполнения». Новые требования часто возникают в течение обзора спринта. Также часто появляются новые возможности и трудности. Иногда достаточно просто увидеть инкремент, чтобы зародились новые идеи.
Результаты обзора спринта могут включать один или несколько из следующих пунктов:
• начало использования разработанного функционала;
• решение, что делать в течение следующего спринта, и подготовка к нему;
• решение остановить работу.
В этом случае риск ограничен инвестициями в проведение одного спринта. Ценность достигается в конце каждого спринта, и формулируется новый спринт. Если вы собираетесь продолжить спринт для создания большего количества инкрементов программного обеспечения, проводится ретроспектива спринта.
Каждый участник Scrum-команды старается совершенствоваться спринт за спринтом. Ретроспектива спринта – мероприятие, где формулируются улучшения. Эта встреча ни в коем случае не должна длиться более четырех часов.
Ретроспектива спринта – естественный разрыв между спринтами, когда команда садится и обсуждает события предыдущего спринта, а также ищет пути улучшения своей работы и способов, которыми эта работа ведется.
Обсуждение может включать следующие вопросы:
• хорошо или плохо работают члены команды вместе и почему;
• больше или меньше работы, чем предполагалось, делает команда и почему;
• обладает ли команда всеми необходимыми навыками и обеспечением, требующимся для выполнения работы;
• понимают ли разработчики требования и почему;
• способна ли команда закончить спринт в соответствии с требованиями, и если нет, то почему;
• что можно добавить или выбросить из следующего инкремента функционала;
• что команда думает об использовании подхода Scrum.
Затем команда определяет несколько вещей, которые можно сделать по-другому в предстоящем спринте и которые могут повысить креативность, эффективность и продуктивность. В общем, Scrum-команда должна постоянно улучшаться. Это шанс для нее сделать свою работу и жизнь лучше.
Scrum-команда продолжает повторять шаги, описанные ранее, пока цели не будут достигнуты, возможности максимально использованы, возврат инвестиций достигнут или пока не столкнутся с непреодолимым препятствием (рис. 5.1).

Рис. 5.1. Scrum в действии
Scrum прост. Мы рассмотрели его и знаем его составные части. Мы знаем, как двигаться от планов к реализации. Теперь мы посмотрим, как заставить Scrum работать в вашей организации.
6. Scrum на уровне проекта
Использовать Scrum можно, когда это необходимо, например когда у вас есть безотлагательная возможность или очень важный проект. Эта глава поможет понять, как начать это делать немедленно, без суеты и затрат. Вы научитесь получать ценность каждые 30 дней.
Организационные воздействия не должны рассматриваться. В данном случае первостепенное значение имеют краткосрочные выгоды, а не долгосрочное улучшение организации. Преимущества будут получены быстро. Scrum-проект проводится в отрыве от традиционных методов и процессов, используется только то, что позволяет получить ценность для выполнения работы.
В течение предыдущих 20 лет многие Scrum-проекты проходили внизу организации, скрытые от взгляда. Команда, работающая над проектом, пробовала применить Scrum и создавала впечатляющие результаты. Затем другая команда пробовала его, и скоро команды внутри организации начинали разрабатывать программное обеспечение быстрее и чаще. Довольно скоро Scrum-проекты стали проявляться повсюду в организации. Мы называем такой Scrum PRN.
Как и в медицинском случае, PRN, когда применение лекарства оставлено на усмотрение медсестры или пациента сообразно возникающим обстоятельствам, Scrum-PRN необходим, когда возникает важная возможность или критическая трудность и программное обеспечение требуется быстро. Он может быть использован незамедлительно. Исключения в обычном подходе допускаются для разрешения кризиса или для того, чтобы не упустить возможность. Использование Scrum-PRN не требует разрешения. Разрешение для его применения – безотлагательная потребность в программном обеспечении.
Затраты на 30-дневный спринт могут варьироваться от 50 до 150 тысяч долларов в зависимости от размера Scrum-команды, заработной платы ее членов и других факторов. Каковы же преимущества метода?
Знание об уровне навыков разработчиков. Во время процесса разработки вы поймете, смогут ли ваши специалисты создать необходимый функционал программного обеспечения и сколько они смогут сделать в течение спринта.
Функционал. Возможности продукта, которые могут быть использованы по окончании каждого спринта, не важно, насколько мало это количество. Этот функционал добавляется к любому предыдущему инкременту.
Читать дальшеИнтервал:
Закладка: