Итак, начнем с начала. Почему, собственно я задумался об такой статье? Есть в Scum’е две вещи, которые меня конкретно нервируют.
— Как технарь и программист, я очень не люблю, когда мне говорят «делай только так, потому что так правильно» и при этом не объясняю почему именно так правильно, что будет если сделать не так. А все книги по SCRUM’у так и делают — выдают набор практик, артефактов, ролей и т.п., которые нужно использовать без малейшего объяснения для чего нужна каждая из этих деталей.
— Второе, что меня нервирует, это метод «Не думайте об обезьяне» . Пропагандисты практики Scrum, в случае если Scrum сработал в новой компании причисляют это к победам Scrum’а, если же он не сработал обвиняют исполнителей Scrum’а, в том что они не поняли дух и букву Scrum’а и все делали неправильно.
Собственно эти две вещи и заставили меня копнуться чуть глубже. Ну и плюс, за последние полтора-два года, которые я работал в нескольких модификация SCRUM’а у меня накопилось некоторое количество (отрицательного) опыта.
Сразу замечу, что в этой серии статей я не буду давать обзор SCRUM. Если вы с ним не знакомы, то загляните в описание на wikipedia, а еще лучше найдите и почитайте книжку.
Приступим.
1) Передел территорий
Большинство SCRUM книг начинается с того, что рассказывается о том, какие есть роли в SCRUM’е и как надо начинать работать над проектом (составить backlog, перетасовать его по приоритетам и т.п.). Я не видел еще фактически ни одного источника, которые предлагает как «продать» идею внутри компании. В лучшем случае там пишется: Вася, CTO компании, решил попробоывать SCRUM.
Ну да ладно, умный человек всегда может выбрать с десяток пунктов, по которым SCRUM лучше waterfall и залив их большим количеством меда протолкнуть идею попробовать SCRUM в компании. Хотя и это было бы как-то описать, так как зачастую Вася не CTO в компании, а программист/тим лид/менеджер и соотвественно ему таки приходится пропихивать идею наверх.
Интересное начинается дальше. До тех пор пока SCRUM не стартован или только стартуется, все идет мягко и хорошо. Но вот возникает момент когда обнаруживается что
а) Project manager со всем своим длинным послужным списком PMP сертификатов не нужен, а нужен человек который прочел одну книжку и прошел двухдневный семинар Scrum мастерства. И не дай бог роль Scrum Master’а отдадут не Project Manager.
б) QA manager не нужен, так как внезапно QA становятся Team и теперь являются частью самоорганизающийся команды.
в) Вместо кучи Product manager’ов, маркетологов, sales’ов, которые постоянно совали нос в разработку пытаясь поменять порядок задач, теперь нужен один человек — Product Owner, который имеет право тасовать все задачи как ему вздумается (тут я немного преувеличил, но тем не менее, product managerская работа становится более видимой и их становится нужно меньше).
г) Программисты теперь не имеют право кивать на QA, что те чего-то не сделали. QA не имеел право кивать на программистов, что те чего-то не сделали.
д) Новый Scrum Master должен иметь БОЛЬШИЕ полномочия, для того чтобы расчищать путь для команды и водворять все стороны SCRUM’а. (в целом он конечно может бегать к мендежру каждый раз, когда нужно купить пишущих ручек, но это не так, чтобы слишком эффективно).
е) Лестница технического менеджмента тоже становится вроде как-бы и не слишком нужно, так как по сути они больше ни должны руководить.
Итого. Мы, что мы имеем? Мы протопталисья буквально всем по любимым мазолям, мы пытаемся отнять власть у /одних, выдать ее другим, вскрыть то, что кто-то пинает, а не работает и т.п. Как вы считаете, будут ли все вышеперечесленные очень рады нововведениям?
Нет…Нет… Противостояние не начнется в тот момент, когда будет предложена идея SCRUM’а. Оно не будет открытое. Просто, тот человек, который будет пытаться вводить Scrum (особенно если он не находится на верху иерархии) в какой-то момент обнаружит, что люди не спешат расставаться с их бывшими полномочиями и властью и не сильно спешат все делать по новому.
2) Второе, о чем почему-то редко говориться в Scrum, это о том как переводить проект с классического waterfall (или вообще отсутствия методологии) на Scrum. Опять же в большинстве книг рассказывается о том, что вот мол решили начать новый проект и попробовать Scrum. Извините… секундочку… То есть 80% рынка управления уже существующими проектами — нафиг из описания, а вот лучше мы опишем, как делать для остальных 20%, так как там поменьше зацепочек.
В чем собственно отличие старого проекта от нового проекта? Отличий несколько. Одно отличие — это существующий status quo (по большему счету то, что я описал в пункте 1 насчет власти), второе — это то, что уже есть код, заказчики, баги и т.п. И существует гигантская разница между тем, чтобы красиво и итерративно работать над проектом для которого нету заказчиков, нету багов и код которого новый и хороший.
Коротенький пример по этому поводу. Представим себе, что у вас есть продукт который активно пользуют, и в течении 3 недель (вашего спринта) вам приходит 3-4 бага от заказчиков которые надо пофиксить как можно быстрее. Модель Scrum’а такое не поддерживает. Содержание текущего Sprint’а не может меняться. И в этом смысле, в новом проекте, легко сказать всем вовлеченным — если есть баг, то мы его кладем в Backlog и пофиксим в следующем Sprint’е, в старом проекте где всегда фиксилось в течении 2-3 дней, явно менеджмент и customer support не оценит идею пофикса через 2 недели.
Собственно, это две самые крупные (по моему мнению) проблемы о которых не говорится в книгах. В следующей статье я капну чуть глубже.
