lodisno

Вы много слышали про SCRUM, и даже читали много различной литературы и статей теоретической направленности, но так и не понимаете, как же применить все это на практике? Именно для таких Хенрик Книберг и написал, а различные коллективы переводчиков, перевели, данную книгу. Нужно отметить, что книга доступна совершенно бесплатно с сайта автора: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches На сайте есть как оригинал, так и переводы на различные языки, включая русский. Основным отличием книги является ее полностью практическая направленность. Но, как отмечает автор, это же и ее недостаток. Хенрик не приводит описаний значений терминов. Если вы читаете эту книгу, то наверняка знаете, чем product owner отличается от scrum master. А если нет - в книге приведены соответствующие ссылки. Автор описывает свой практический опыт работы над всеми этапами, входящими в SCRUM начиная от этапа формирования backlog и заканчивая ретроспективами. В каждом разделе описываются конкретные шаги, которые выполняла его команда. Важным является акцент на различных "тонких" моментах, которые не описаны в теоретических материалах по гибкой разработке. Например, как организовать взаимодействие с отделом тестирования? Ведь scrum подразумевает, что на выходе команда выдает полностью рабочий код. Но на практике это маловероятно, и в крупных компаниях всегда есть отделы тестирования или контроля качества. И после того, как вы начали новый спринт, отдел тестирования сваливает на вас список недоработок прошлого релиза, которые надо срочно исправить. Также типовая ситуация - поддержка существующего решения. Если ваш продукт уже на рынке, то однозначно к вам будут приходить запросы на устранение тех или иных ошибок в предыдущих версиях. Как это вписывается в идеологию гибкой разработки? Опять же, теория по этому поводу мало что говорит. А Хенрик предлагает свои методы начиная от официального выделения в спринте части времени на баг-фиксы, и заканчивая формированием специальных "пожарных команд", которые занимаются исключительно исправлением ошибок. Последнее особенно актуально для старых проектов, которые достались вам в наследство. Мне также понравились различные практические советы, связанные с проведением этапов планирования и демонстраций продукта. По классике например, на демонстрации присутствует команда и product owner. Но Хенрик рекомендует также приглашать как минимум, участников других команд, чтобы они были в курсе того, что делают другие. Конечно же, эта рекомендация вряд-ли подойдет для аутсорсера со штатом в 2000 человек, но для небольшой компании с 2-3 группами разработки - очень разумное предложение. Так что, если вы только собираетесь внедрять гибкие методы разработки, или уже их практикуете, данная небольшая (94 страницы) но очень практичная книга будет очень полезна для прочтения.