Узнав, что освобождается то помещение, в котором Иван Селиховкин нашел свою уже ставшую известной в определенных кругах “Черную книгу Скрам”, я, разумеется, не могла удержаться от того, чтобы договориться о его аренде. И оказавшись на месте, сразу же принялась изучать самые укромные уголки - вдруг найдется еще что-нибудь интересное?... И моя интуиция меня не подвела - за шкафом мне удалось обнаружить неизвестным образом завалившийся туда документ “Соболезнования от Agile-коуча…”... Честно скажу, не смотря на то, что рукопись вряд ли предназначалась моему взору, прочитала ее на одном дыхании. Публикую рецензию как есть - свое имя автор, к сожалению, не написал. Перед прочтением настоятельно рекомендую перечитать еще раз “Чёрную книгу Скрам”, дабы стало понятно с чем полемизирует автор.
Достопочтенный коллега, я искренне соболезную твоей неудаче, и твоей загубленной карьере!..
Я попытался пообщаться с тобой при увольнении, но ты только бегал с горящими глазами кругами по офису, и твердил “Скрам! Больше никогда!!! Только через мой труп! Как можно было быть таким глупцом!" Поняв, что вызвать тебя на разговор не удастся, я решил записать свои размышления на бумаге, в тщетной надежде, что ты прочитаешь мой ответ и сможешь учесть его в дальнейшей работе…
Не ты первый, кто погнался за красивыми лозунгами, прочитал книжку, и попытался применить технологию без преобразований процессов в компании. Увы, многих наших соратников постигла та же участь.
Как известно, жизненный опыт - это знание о том, как надо было вести себя в ситуациях, которые никогда больше не повторятся. И коль скоро он у тебя теперь в избытке, давайте же попробуем разобраться, почему получилось так, как получилось, и что можно предпринять вашим последователям, чтобы их участь была более радужной… Я приведу ниже несколько цитат из твоей книги, чтобы четче озвучить мои мысли.
Цитаты из "Черной книги Скрам" будут выглядеть вот так
А то, что между ними - мои комментарии.
Помню то утро, когда ребята показали и рассказали про манифест. В нем все было стройно. Но уже первая строчка сигнализировала мне «Agile-манифест разработки ПРОГРАММНОГО обеспечения». Программного. И ничего другого.
Этот подход придумали для программистов. Причем, не для любых, а для особенных (об этом позже).
Да, совершенно верно. Придумали для программистов. А дальше адаптировали для самых разных сфер - одно сообщество в фейсбуке “Agile вне IT” насчитывает более 1600 участников!.. А мой коллега, пришедший на конференцию по Agile был шокирован количеством строительных компаний, проявляющих интерес к теме - а уж нам, сторонним наблюдателям, казалось бы, что дом построить дом можно исключительно по водопаду! А школьные учителя нынче пачками изучают придуманный в Голландии подход EduScrum - построение предметов в школе по гибким методологиям. В общем, практически любой подход был изначально придуман для кого-нибудь одного - например, для военных (модель водопада), для детей с отставанием в развитии (методика Монтессори) и т. п. - а потом уже, оказавшись удачным, был растиражирован.
Дальше в манифесте: « То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева». Вот так будет всегда, когда станешь иметь дело с agile. «Мягкие лапы», уход от ответственности, гимны-вместо внятных инструкций. Черт, он же все время был там! Прямо перед моими глазами! Абзац, делающий весь манифест не более чем набором благих пожеланий.
Ты правильно обращаешь внимание, что вряд ли кто-то здравомыслящий будет возражать против тезисов Agile манифеста. Эти тезисы использует большинство тех, кто практикует и водопад, и всё остальное. Вопрос в фокусах внимания. Вообще, советую почитать статьи Марии Темчиной на Инфостарте про Agile и Водопад, там приводятся жизненные примеры, как принципы манифеста выглядят на практике, если их неправильно готовить.
Роли, артефакты, правила менять нельзя. Нельзя менять правила! Черт! Иначе это уже не Cкрам. А как же “люди и их взаимодействие важнее процессов”? Вот что должно было меня насторожить. Самый популярный управленческий agile-фреймворк прямо так и говорит. Это Cкрам. Ничего менять нельзя! Даже не думайте называть это Cкрамом в противном случае! И да, это agile.
Дружище, что ты придираешься к деталям??? Есть умный мужик, Джефф Сазерленд, он описал технологию, придумал для неё имя. Написал книгу, проводил обучение, сделал имя и деньги. Ну и говорит, если искажаете - не называйте моим именем. По-моему, предельно логично! "Нам сказали, что глинтвейн - это горячее вино с фруктами и специями. Из вина у нас была только водка, из фруктов - лук, а из специй - черный перец"... Сазерленд так не хотел. Хочешь - переделай как угодно, называй просто - гибридный подход на основе скрам. Таких навалом - есть ScrumBan, есть EduScrum, есть InfoScrum, есть “Сберджайл” (вместо Эджайла)...
Как минимум в одном соглашусь с автором - ни я, ни мои коллеги, кого я спрашивала, не встречали в России работающего скрама в чистом виде. Все адаптировали под себя, так или иначе. Но - через некоторое время.
Когда, позднее, мы начали внедрять Скрам и сносить проектное управление - команда тыкала меня носом в этот абзац. “Ничего менять нельзя!”, говорили они.
Рекомендации экспертов западных, взятые не с потолка: ребята, начиная внедрять Agile, возьмите целиком готовый фреймворк (Scrum, или XP, или что ещё), и внедряйте "коробочную версию". Потом уже, когда освоитесь, подменяйте под себя. Ибо иначе у вас с большей вероятностью получится лажа, причем непонятно: из-за ваших переделок или из-за того, что подход не особо работает.
На старте, пока работа не началась - определить сроки невозможно. Скрам это прямо запрещает. Нет velocity - нет оценок. Вот тут надо остановиться и перечитать. Не отработал несколько спринтов - оценок нет.
Про оценку сроков. В ходе подготовки к сдаче экзамена Agile Certified Practitioner от PMI, я подробно изучил, что говорят эксперты Agile про планирование. Они говорят: в начале проекта используйте более классические подходы к планированию, а потом уже - инструменты Agile. Даже схемка есть в книжках, что в начале проекта мы больше используем традиционные инструменты планирования, а со временем всё больше начинаем использовать Agile-инструменты.
Вы скажете - но Скрам гайд этого не предлагает! Верно, не предлагает. Но там с самого начала написано, что Скрам - не исчерпывающее руководство, используйте чужие инструменты - не вместо, а кроме. Ну и да, если почитать только одну книжку - Scrum Guide, и другую литературу по Agile проигнорировать - придется самостоятельно набивать те шишки, которые другие уже набили.
Другими словами, заказчик интересуется: “Ребята, когда закончите?”. Ответ- “Подожди месяцок - другой, мы тебя сориентируем”.
Про то, что заказчик не готов к ответу "мы не знаем, когда будет готово" - знаю много прецедентов, когда заказчик готов к такому ответу. Как отмечали в комментариях к статьям про Agile на Инфостарте - чаще всего Заказчик готов к нему после одного или нескольких громких провалов проектов по Водопаду. Хотя да, не всегда.
Серьезно. Чтобы понять абсурдность ответа, достаточно поставить себя на место заказчика ремонта, покупателя дома абитуриента или поступающего в ВУЗ и слышащего что-то вроде: «ты сперва поступи, поучись, мы потом скажем сколько у нас курсов и во сколько тебе диплом выйдет». «Взамен получишь регулярные занятия, прирост знаний - ты же за ними, в первую очередь, пришел?» И да, и нет - пришел за знаниями, но и диплом, и звание, которое он дает- имеет значение.
А вы попробуйте представить пример не с ВУЗом, а с образовательным маршрутом сотрудника в компании. Так ли уж ему важен ответ на вопрос “ну и когда вы уже перестанете рекомендовать мне повышать квалификацию, и дадите спокойно поработать????”. Если и сотрудник, и система обучения адекватные - то не так уж и важен...
Проблема в том (черт, я должен был это предвидеть)- люди на проекте меняются. Одни уходят в отпуск, другие пропускают по болезни. Кто-то (да и такое бывает) - увольняется, в команду вливаются новички. Каждая такая перестановка как-то влияет на velocity. Никто не знает как. И это официально.
Я вас умоляю. Опять же, учим матчасть. Про расчет velocity - уход сотрудников в отпуск и на больничный легко считается, в Agile есть формулы. Я их честно курил в ходе всё той же подготовки к экзамену, и даже примерял на практике. Например, хорошее решение предлагает Хенрик Книберг (Автор книги Битва за Agile: Scrum и XP:Заметки с передовой - есть в открытом доступе на русском), который в отличие от безымянного автора “Черной книги Скрам” - смог - то есть построил работающую Скрам. Он вводит понятие “фокус-фактор” - насколько команда в течение спринта будет сфокусирована на имеющихся задачах. Если половину времени половина состава болеет/в отпуске - то он будет равен 50%, и так далее. Ну, смену состава тоже можем учесть при помощи коэффициентов.
И применять фреймворк только, если тот самый заказчик или директор с этим согласен. Иначе, огромный шанс привести именно к тому финалу, что вырисовывается у нас.
Золотые слова. Без этого не надо и начинать!
Минимум в 90% компаний каждый продукт делает созвездие специалистов. Люди разных профессий, способные дополнять, но не заменять друг друга. Программист рисовать не умеет, так что он не помощник дизайнеру, а тот (порой, гуманитарий) ничего не понимает в программировании.
Про кросс-функциональность - ну, тоже, ребята, читайте не только скрам-гайд, а ещё книжки. Например, тогда узнаете про I-специалистов и T-специалистов. I-специалист - кто хорошо умеет свою сферу - веб-дизайнера, аналитика, тестировщика и т.п. - и все. T-специалист - у него кроме большой вертикальной палочки, еще и небольшие палочки в сторону. Он хорошо знает свою зону компетенций, и немного знает другие. И наша задача стремиться, чтобы в команде было как можно больше T-специалистов. Чтобы разные члены команды могли говорить на одном языке, могли поддержать друг друга, если не заменить, могли помочь с какими-то задачами, если не со всеми и т. п. Надо ли вообще отказываться от I-специалистов? Нет, не всегда мы имеем такую возможность. Но чем больше у нас T-специалистов - тем слаженнее работает команда, тем меньше у нас рисков и незаменимости.
И тут у нас развалился Скрам. Мы обнаружили, что создали три команды, работающие параллельно (аналитики, разработчики, тестировщики). Друг за другом.
Бинго!!! Ребята, для описанной ситуации скрам не логичен. Логичен Канбан.
См. статью про Канбан, и см. видео Олега Фогеля как они в 1С от Скрама к Канбану перешли.
У нас были замечательные специалисты. Опытные и неравнодушные. Неопытные и неравнодушные были тоже. Но были и демотивированные. Уставшие от работы. Принцип командной ответственности не работает в токсичном коллективе.
Совершенно согласен. Одно из ограничений Agile - он работает в команде мотивированных профессионалов. Нет такой команды - не взлетит. Но это не повод отчаиваться, это повод такую команду постепенно создавать.
Опять же, идеологи Agile говорят - коллективная ответственность - это цель, а не стартовая точка. Не начинайте с самоуправления, если команда не готова. Идите к этому. Пусть сначала TeamLead руководит, потом консультирует, потом поддерживает, потом - делегирует.
Возможно, ты помнишь эту глупую картинку, где покупатель сперва получал скейт, потом велосипед, потом мотоцикл, а потом и авто. Вместо того чтобы сразу и долго ждать машину? Мы тоже ее помним. Мы с нее начинали. Почему глупая? А как можно из скейта сделать велосипед? Только выкинуть наработки и сделать заново, с нуля.
Коллега, опять вспоминаю матчасть! Например, Agile guide от PMI! Или хотя бы всё те же статьи на Инфостарте.
Agile предполагает итеративность+инкрементальность. Есть проекты, которыми можно управлять гибкими методами. Есть проекты, которыми нельзя. Нет хороших или плохих методологий. Есть подходящие и не подходящие. Если у вас нет возможности технической делать частые релизы - Agile в полной мере не применим.
Запомни. Скрам работает не везде. У нашего продукта не было большого количества пользовательской функциональности. И мы дробили на спринты задачки, которые волновали только нас (а заказчику на эти промежуточные варианты было плевать). Он ждал сразу автомобиль, потому что единственное что его волновало - не цвет кузова, а скорость на автобане.
Ура, наконец-то ты заметил! Хотя здесь я расскажу интересное. Scrum можно рассматривать в двух ипостасях. Подход первый - Scrum - это фреймворк в рамках Agile подхода. Тогда всё вот это должно быть верным - частые релизы, ценный для заказчика результат каждые несколько недель и т. п. Подход второй (на самом деле, его используют многие, в том числе в органах власти, сам Сазерленд тоже упоминал о таких проектах) - что у нас проект управляемый по классической методологии, но самим процессом мы управляем по Scrum - спринты, стэндап-совещания, демонстрации заказчику в конце каждого спринта - пусть не готового продукта, но хотя бы того, что мы тут не дурака валяли!.. И в таком варианте Scrum тоже может быть применимым и ценным (хотя это не совсем Agile).
Надо было сразу объяснить заказчику что его ждет и убедиться, что он действительно готов тратить время (и не объяснять его возможное нежелание боязнью перемен).
И снова золотые слова! Жму твою руку, не смотря на то, что тебя уволили.
Увы, быть agile для организации не означает перестать нуждаться в финансовом планировании. В балансировке портфеля. Скрам не умеет управляться с ограничениями внутри микрокоманды (5-7 человек). И вместо того, чтобы бороться с этим, предлагает масштабировать это на уровень организации в целом!
Не совсем так, коллега. Действительно, команде трудно работать по Scrum, когда в начале финансового года от нее требуют бюджет и сроки каждого проекта. Полноценное внедрение Scrum на уровне компании требует другой схемы управления портфелями. Например, я сторонник управления по потоками ценности (Value Streams) - подход SAFE (когда-нибудь напишу об этом статью на Инфостарте), есть подход LESS про Scrum на уровне организации.
Значит, потери на планирование каждую неделю составляют 30%! Тридцать проклятых процентов! Вот наш Скрам без планирования.
Послушай, тебя кто-то дезинформировал. Покажи мне его, я вызову его в курилке на мужской разговор. В Agile, конечно же, БОЛЬШЕ планирования, чем при водопаде (просто оно распределено по всему проекту). Потому что в водопаде мы планируем один раз, а дальше ломимся вперед под лозунгом “вижу цель не замечаю препятствий”. А при применении гибких методов нам приходится корректировать ранее запланированное с учетом вновь поступившей информации. И вообще, напомню, Agile рассчитан на проекты, которые слишком сложны, чтобы их сделать по водопаду - надо ли удивляться, что планирования и переделок там будет изрядно? Бывает ли методология в которой планирования меньше? Бывает, да. Называется “Do&Fix” или же “Тяп-ляп”. Обеспечит быстрый результат соответствующего качества.
Еще раз резюме - я же уже говорил, что не сталкивался с успешным применением Скрама в чистом виде в российской действительности?.. А с успешным применением адаптированного скрама - вполне. Все просто адаптируют, и не жужжат. И не наезжают на старину Джефа )))
Библиография:
1. Черная книга Скрам. Записал Иван Селиховкин
2. Кен Швабер и Джефф Сазерленд. Скрам Гайд. Исчерпывающее руководство по Скраму: Правила Игры.
4. Хенрик Книберг. Битва за Agile: Scrum и XP:Заметки с передовой
5. Видео. Олег Фогель рассказывает о гибкой методологии разработки
6. Мария Темчина. Можно ли объять необъятное или чем Agile отличается от водопада?
7. Мария Темчина.Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?
8. Мария Темчина.Канбан в условиях российской действительности
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
