Июнь 24, 2014
Большинство людей продолжает не понимать, что такое Scrum. Мы все что-то слышали про спринты, бэклоги, ретроспективы. Некоторые до сих пор играют в planning poker. Хвалят Scrum. Жалуются. Ненавидят. Но все равно надеются на него (вокруг нас столько проектов, где надеяться больше не на что). Ниже – 5 фактов про Scrum, которые надо знать каждому, кто хочет иметь неперевернутое представление о самом популярном в мире подходе к разработке софта.
Он используется для решения определенных типов проблем. Как и любой другой инструмент, он хорошо работает в одних случаях и плохо работает в других. В отличие от обычных инструментов а ля лопата или напильник, Scrum – процессный инструмент. Но сути это не меняет – он подходит для одних типов проектов и совершенно не нужен на других. Это нормально. Так задумано. Сделано «бай дизайн». В конце концов, ни у кого нет претензий к тому, что туфля не заменяет штопора. (Хотя некоторые не верят.)
Многие подходы к разработке софта описаны неоднозначно, по-разному определяются в разных книгах или статьях (попробуйте понять за 10 минут, что такое devops). В отличие от них у Scrum есть четкая и сжатая «спецификация» на 16 страниц - Scrum Guide. Не надо спорить, является ли планирование релиза обязательной частью Scrum, – просто загляните в Scrum Guide. Что приятно - эта спецификация поддерживается и постоянно обновляется авторами Scrum.
Постоянно слышу (в том числе от «опытных Agile тренеров») заявления из разряда «Scrum умалчивает о том, как же нам на практике составлять product backlog». Проблема в том, что если Scrum расскажет нам, как составлять бэклог в 178 возможных случаях, которые встречаются в жизни, то мы получим не легковесный подход, а что-то большое и трудноиспользуемое. Отличие фреймворка от методологии и состоит именно в том, что фреймворк не пытается определить все возможные шаги и элементы сложного процесса, признавая его вероятностную и малопредсказуемую природу. Scrum – это минимальный набор требований, нуждающихся в дополнении, исходя из конкретного контекста. Используя Scrum, мы вовсе не должны отбрасывать и забывать те процессные и инженерные навыки, которые получили до этого. Именно поэтому на практике говорят о подходе ScrumAnd - мы используем Scrum и дополняем его любыми другими практиками, полезными и применимыми в данном проекте и контексте.
(Рекомендуется повторять всем менеджерам много-много раз.) Почему-то от Scrum постоянно и непременно ждут чуда, а не дождавшись – источник проклятия. Как метко выразились в комментах к упомянутому выше посту: «Но все, похоже, верили, что Scrum им сделает счастье и даже геморрой всем в команде полечит…». На самом деле Scrum реализован так, что он создает множество возможностей для обратной связи и постоянно выносит на поверхность проблемы, мешающие более эффективной работе. Последовательно устраняя эти проблемы, вы сможете добиться значительного увеличения производительности, качества и удовольствия от работы. Но никто не решит эти проблемы за вас и никто не решит их без усилий, мужества и силы воли. Создатель Scrum Кен Швабер сравнивает Scrum с тещей, которая точно знает все недостатки зятя и осознает, как их исправить. Внедряя Scrum, вы приглашаете такую тещу пожить с вами. Сможете ли вы внять ее советам и улучшиться или вам проще остаться неидеальным – открытый вопрос.
Вы можете сделать отличный продукт с помощью Scrum, который не принесет прибыли вашей компании, после чего вашу команду расформируют, людей уволят, а компанию продадут кому-нибудь более хваткому. Широко используемая метафора гласит, что команда в Scrum – это автомобиль, Product Owner – водитель. Если водитель нетрезв или просто не знает, куда ехать, даже Tesla Model S не спасет его. Вот почему сейчас все говорят о критичности value в работе команды и компании. Evidence-based management - один из самых современных подходов, позволяющих распространить идею эмпирического управления, используемую в Scrum, на уровень предприятия и достичь оптимизации в масштабах компании в целом.
Scrum – не слишком серьезное слово, взятое из игры регби. Создатели Scrum намеренно назвали его именно так (а не, скажем, Scaled_Agile_и_еще_много_умных_слов) для того, чтобы всегда критически относиться к возможностям методологий, планирования и прочих вещей и не забывать про их ограничения. Вместо того, чтобы надувать губы и делать вид, что мы чем-то “управляем”, честнее признать, что мы скорее играем в игру, правят в которой во многом случайностьи эмпирика. Scrum опирается на эмпирику, что делает его лучшим способом управления в условиях неопределенности.
Источник: http://agile.by