Я в субботу сдала экзамен на Scrum Master’а PSM I (96,3% правильных ответов из 100 - принимаются поздравления), который подтверждает, что я хорошо понимаю, что такое Scrum и как его применять (что позволяет мне с чистой совестью добавить в мой курс по управлению проектами по Agile рекомендации по подготовке к экзамену).
И этот факт и сподвиг меня написать статью под таким заголовком. Ирония судьбы, правда, в том, что мне никогда не приходилось работать в условиях Скрам в чистом виде.
Краткое введение для тех, кто не очень в теме
Подробно о том, что такое Agile я писала в предыдущих статьях (например, Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?).
Если кратко - то Agile - это подход к управлению проектами, основанный на сотрудничестве и готовности выполнять разработку маленькими порциями, часто собирая обратную связь.
А Скрам - это фреймворк (ну нет нормального перевода на русский язык этого слова, ну нет… Максимально близкое, на мой взгляд, слово - “каркас”), который предлагает определенные правила, по которым осуществлять ту самую гибкую разработку.
В первую очередь:
- Самоорганизующаяся команда от 3 до 9 человек плюс Скрам-мастер (лидер-слуга) и Владелец продукта (ответственный за развитие продукта) - другие роли запрещены
- Только Владелец продукта решает, что именно должно входить в продукт и в каком порядке
- Только команда делает прогнозы, сколько работ она может сделать за текущий спринт и делает оценки по трудоемкости
- Работа короткими промежутками (спринтами) от 1 недели до 1 месяца и выпуск потенциального готового к релизу продукта каждый спринт
- Постоянные инспекция и адаптация, в том числе при помощи мероприятий Скрама (Планирование спринта, ежедневный Скрам - летучка до 15 минут, Обзор Спринта с демонстрацией продукта заказчикам и Ретроспектива Спринта со сбором извлеченных уроков)
(Подробнее можно почитать в официальном “Путеводителе по Скрам”, доступном в том числе на русском языке)
Так вот, многие, в том числе мой коллега Иван Селиховкин, попрекают Скрам за его жесткость. Мол, авторы Скрама строго пишут: если вы отошли хоть от каких-нибудь правил, указанных в Путеводителе, то это уже не Скрам.
На мой взгляд, эта оговорка - очень ценная. Потому что это, на самом деле, способ защиты команды от менеджмента - в том числе требований в стиле “давайте вы за ближайшие две неделю проведете целиком внедрение Комплексной Автоматизации” или “давайте вы добавите вот такую фичу по требованию ген.директора, ну и что что она противоречит общей логике и архитектуре”.
Ну, и защита авторов от неуместных претензий из серии “У нас ничего не получилось, хотя мы делали всё почти, как у вас написано. Только результатом был “почти готовый продукт” вместо готового, в спринт не добавляли ничего в процессе кроме как по указаниям топов, и во главе самоорганизующейся команды поставили менеджера”... (подробнее эту тему я развиваю в своих статьях про Scream Guide - вот здесь и здесь).
Итак, почему Scrum плохо накладывается на проекты 1С
Вопреки стереотипам (и, в частности, Черной книге Скрам от Ивана Селиховкина, на которую я в свое время отвечала Белой и пушистой рецензией), под разработчиками в Scrum Guide понимаются вовсе не разработчики (простите за тавтологию).
В разделе “Применение Скрам” явным образом написано, что когда в Руководстве по Скраму используются слова "разрабатывать" и "разработка", они означают сложную работу, в том числе: исследование и выявление жизнеспособных рынков, технологий и возможностей продуктов, разработку и поддержку продуктов и облачных технологий и многое другое. То есть, на самом деле, в команду кроме разработчиков вполне могут входить бизнес-аналитики, тестировщики, технические писатели и так далее.
Какие ограничения Scrum представляются мне плохо совместимыми с работой по внедрению продуктов 1С?
- Владелец продукта как единая точка входа требований от пользователей плохо совмещается с работой по внедрению, когда настроек существенно больше, чем собственно программирования. В этой ситуации плотная работа с пользователями и уточнение, что именно требуется реализовать, часто занимает существенную часть времени команды. И возложить эту задачу на Владельца продукта - выглядит соблазнительным планом, но трудно реализуемым - ибо он только один, и при попытке выполнять все работы по бизнес-анализу может порваться на много маленьких медвежат.
- Скрам заостряет внимание на том, что Скрам команда должна быть кросс-функциональной и не зависеть от всех остальных, то есть быть способной самостоятельно выдать результат. Эта идея более чем неплоха, но, опять же, в моей практике я сталкиваюсь с тем, что задачи проектов 1С слишком завязаны на участие пользователей. Пользователи уточняют требования, только пользователи могут провести окончательное тестирование и убедиться, что программа выполняет все что требуется. Таким образом на смену независимости Скрам-команде как “боевой единице самой по себе” приходит плотное сотрудничество с будущими пользователями продукта и прочими заинтересованными сторонами. В этом месте говорить про то, что “только от команды зависит в течение спринта доведение задачи до конца” - это несколько самоуверенно, и, главное, чаще всего не соответствует действительности.
- Жестко фиксированные по времени спринты с запретом добавлять работу посередине плохо совместимы с поддержкой продукта, завязанного на регламентированную отчетность, когда требования выплывают в неожиданный момент и, очень часто, являются довольно срочными. В этой ситуации ограничение про спринты фиксированной длины, в течение которых команда не берет работы со стороны, вместо того, чтобы помогать работать, мешает работе. Ну а напомним, что инструменты и методологии, которые мы используем, все-таки направлены на то, чтобы делать нашу жизнь более удобной, а работу более плодотворной. А не наоборот.
- Скрам не признает титулов, в команде все разработчики равны, роль тимлида не уместна. Идея самоорганизующейся команды прекрасна, мало того, я в отличие от многих, верю в самоуправляемую команду и встречала их на своем пути. Когда люди сами решают, как им работать, они гораздо охотнее и увлеченнее реализуют принятые решения, чем когда им навязывают их сверху, поверьте мне! На всякий случай напомню, что речь идет только об ответе на вопрос, КАК работать. Ответ на вопросы К КАКИМ ЦЕЛЯМ мы стремимся и КАКИЕ ПРОДУКТЫ внедряем никто не предлагает отдавать на откуп команде, в конце концов, именно для определения стратегии и существует менеджмент не будем отбирать у него хлеб.
Но даже если оставить только вопрос Как делается работа, честно скажу, что самоорганизации хорошо работает начиная с определенного уровня компетенции и личной дисциплинированности сотрудников. То есть, когда люди находятся на уровне "Начинающий энтузиаст", если им выдать возможность самим принимать решения, они ею, скорее всего, с удовольствием воспользуются... Вот только результат может получится, мягко говоря, странным.
А в сфере 1С-проектов дефицит компетентных особенно заметен. Вот того, чтобы на одном проекте собралась команда, как этого требует Скрам, не менее чем из 3 мотивированных компетентных 1С разработчиков - в своей практике встречала такое довольно редко. Я уже вспоминала историю, как одна слушательница моих курсов в красках рассказывала, какое у них прекрасное взаимодействие и взаимопонимание в команде проекта, одна беда - команда состоит из одного человека, её самой..
- Скрам крайне негативно относится к многозначности. Кстати, честно скажу, внимательное изучение Путеводителя по Скрам привело меня к осознанию, что, вопреки стереотипам, Скрам не запрещает одному человеку участвовать в нескольких командах (или занимать несколько ролей в одной команде). Но, очевидно, что для достижения оптимального результата, важно, чтобы люди могли максимально сконцентрироваться на разработке и поддержке одного продукта. Это прекрасная идея, и я её всецело поддерживаю. Одна беда - не очень понятно, каким образом в реальных условиях 1С команд её можно реализовать на практике??
- В крупных проектах не реализуем принцип того, что результат каждого спринта должен быть потенциально поставляем (даже если реальной поставки и не происходит). Скажем, если вы внедряете ERP-систему, то тот самый “минимальный жизнеспособный продукт” (MVP), на который дальше можно наращивать дополнительный функционал, по факту приходится делать много месяцев (а вовсе не один спринт - то есть от одной недели до месяца). На самом деле, внедрить “маленький кусочек” ERP-системы тоже можно - но для этого придется интегрировать его с теми прикладными решениями (от 1С и не от 1С), которые используются в компании в настоящий момент. Возможно ли это? Если напрячься, то возможно. А целесообразно ли? По моим ощущениям, чаще всего нет - ибо трудозатраты на такую “временную интеграцию”, которая потеряет смысл когда система будет внедрена целиком, могут превысить затраты на само внедрение.
Краткое резюме
Следует ли из этого, что Скрам надо забыть? Никоим образом! Сами создатели Скрама признают, что во многих компаниях применяют так называемый ScrumBut (то есть, “Скрам, но… с некоторыми купюрами”). Существует масса гибридных подходов, я особенно люблю ScrumBan. Ну и вообще, важно использовать технологию не для галочки, а для удобства. Просто не стоит называть Скрамом то, что им не является ))).
Спасибо за внимание!
Тех, кто дочитал мою статью до конца, приглашаю на вебинар-воркшоп в понедельник 25 мая 2020 в 12:00 - где мы будем в Zoom при помощи общей доски строить карту компетенций руководителя ИТ-проектов.
И небольшой офф-топик: на Инфостарте сейчас открывается набор на следующий поток моих курсов по управлению ИТ-проектами, кто еще не учился - присоединяйтесь!
