Цитаты из книги «Софт за 30 дней. Как Scrum делает невозможное возможным»

Бэклог — это постоянно меняющийся список наших идей для этого продукта, мы можем добавлять, изменять и удалять из него пункты, когда захотим. В бэклоге продукта мы определяем порядок работы, поэтому наиболее важные требования должны быть вверху списка.

Ухудшение качества. «Мы знаем, что не должны давить на разработчиков, чтобы получать все, что запланировано, и с учетом изменений вовремя, но наш бизнес страдает от проблем планирования, срыва сроков и изменений. Мы требуем от разработчиков ужесточения работы для соблюдения сроков. Каждый раз после таких требований они со

Производительность разработчиков повышается, когда их не прерывают

Когда результат работы команды разработки признается правильным, мы выпускаем релиз программного обеспечения, и им начинают пользоваться.

Начальное планирование сводится к постановке цели и определению наиболее ценных функциональных возможностей, производительности и особенностей, необходимых для ее достижения

Итеративно-инкрементальный процесс. Это способ разработки программного обеспечения через последовательность итераций, каждая из которых генерирует полное приращение функционала, основанное на всех предыдущих приращениях. Итерации продолжаются до тех пор, пока цель не будет достигнута

Качество программного обеспечения, созданное в процессе разработки, определяет дальнейшие затраты на поддержку системы и затраты на дальнейшее улучшение. Программное обеспечение низкого качества труднее улучшить, чем высококачественное, оно оставляет наследство в виде увеличения затрат организации.

Стоимость владения. Программное обеспечение имеет три составляющие расходов для организации разработчика, которые определяют полную стоимость владения продуктом: разработка — средства, выделяемые на разработку продукта или системы; техническое обслуживание — затраты на поддержание, сохранение и развитие продукта; эксплуатационные затраты — средства, выделенные для запуска и управления продуктом, когда он доступен для использования по назначению.

количество дефектов подсчитывается со дня, когда единица функционала передается владельцу продукта, до трех месяцев его использования.

С помощью Scrum мы можем остановить финансирование дальнейших спринтов, как только оставшиеся требования будут признаны не очень ценными. В этой точке программное обеспечение выпускается, и мы начинаем получать обратную связь от пользователей. Дополнительный функционал, запрошенный пользователями, очень часто не совпадает с начальным видением, предполагаемым Scrum-командой. С этой обратной связью подготовка следующего релиза переформулируется, чтобы включить запрошенные пользователями требования и исключить те, которые остаются в списке, но не включены в первый релиз и не запрошены пользователями.