Зачем вообще нужен этот ваш agile?

Разработка собственного IT-проекта. Для кого-то в этих словах кроется азарт, новый интересный опыт, творческая реализация и самостоятельность. Все, что движет команду на созидание. Но у этого процесса есть и обратная сторона: чтобы ваш проект заработал как надо, придется вложить очень много сил и времени. Истории об удачливых новичках и гениях, которые добились всего и сразу, приукрашивают действительность, чтобы люди эти истории слушали. Это истории о Золушках, которые вышли замуж за принцев, станцевав на балу, или подростках, вложивших карманные деньги в акции, которые сделали их миллионерами за одну ночь. В жизни действительно бывает удача. Например, можно выиграть миллион в лотерею. Но, как показывает жизнь потом, эта удача ничего не меняет в ценностях и быте победителя. Поэтому, если хотите штурмовать вершины по-серьезному, придется планировать штурм. Agile (эджАйл) - это подход к разработке IT-проекта, который учитывает важные особенности процесса разработки. Начну с особенностей, иначе будет непонятно, зачем вообще нужен этот ваш agile.

Особенности процесса IT-разработки

На диаграмме слева показаны два вида процессов, которые требуют два разных вида управления: ориентированное на процесс и ориентированное на компетенцию. Конвейерный выпуск (синим слева внизу), например, пакетированного молока замечателен тем, что у него очень четкие требования к продукту. Если в пакете молока, на котором написано "1 литр" окажется 0,9 литра, то покупатель будет очень недоволен. Наоборот, найдя пачку с 1.1 литра по цене за 1 литр, покупатель обрадуется, но потеряет прибыль производитель. Также желательно, чтобы у молока был привычный цвет, вкус и запах. Стоит молоку без предупреждения начать пахнуть розами, потребитель снова будет недоволен. Каковы в таком случае требования к производству молока? Они должны быть направлены на унификацию процесса производства при помощи четких требований. Так, что, чем точнее производитель следует этим требованиям, тем лучше получается товар.

Строительство дома отличается от производства молока ценой итерации. Если мы на нашем молоке захотим нарисовать не Буренку, а зеленые луга, то мы немного заплатим дизайнеру и купим поменьше черной и побольше зеленой краски для принтера. Расходы есть, но они постижимые. Если же мы при строительстве дома заложим фундамент для пятиэтажки, а потом решим докинуть еще пару-тройку этажей, то наш долгострой вскоре будет возвышаться над всем городским центром и зиять пустыми окнами. Внесение изменений в производство домов обходится гораздо дороже.

Теперь посмотрим на IT-продукцию, будь то сайт, приложение или программа. Если речь не идет о разработке целого пакета инструментов или, не дай бог, новой операционной системы, то в плане ценника мы находимся примерно там же, где молоко. Сегодня сайты на конструкторах умеют делать все, кто пользуется Интернетом. Однако представим, что у нас есть две сыроварни, которые борются за лидерство в своем квартале: нужен ли этим сыроварням сайт, похожий на сайт конкурента, как одна пачка молока похожа на другую? Вот здесь и начинается неопределенность требований. Вы должны сделать продающий сайт.

А какой это, продающий? И тут вы записываетесь на вебинар о продающих сайтах, штудируете советы Дейла Карнеги и биографию Стива Джобса, дистанционно получаете степень Master of Business Administration (MBA), и в итоге вы становитесь специалистом по продающим сайтам, но все равно не можете выразить, что они такое, одним четким и емким определением. Это и есть неопределенность требований в случае IT-продукции. При этом, если вдруг клиент захочет, чтобы вы на своем продающем сайте сделали фон не желтеньким как сыр, а голубеньким как майское небо, один клик... и цвет изменился. Да, конечно, сначала нужно немного заплатить дизайнеру, чтобы тот нашел в палитре оттенков голубого тот самый продающий голубой (или красный). Но цена вопроса не так велика.

Как же управлять процессом производства в условиях такой неопределенности? Вот здесь и возникает компетентностный подход: первым делом нужно собрать команду, в которой каждой игрок ценится за свои уникальные компетенции и наравне с остальными отвечает за результат. Такая команда обычно не нуждается в постановке жестких требований, принуждении через санкции, штрафы и угрозы увольнения. Помните, как нужно стать специалистом в области "продающих сайтов"? Нужно впитывать мастерство других специалистов и в итоге сформировать в себе некую компетенцию, которую трудно выразить четким определением. Вы, как губка или сосуд, несете в себе авторское умение подбирать продающий цвет. За это вас ценят в команде и платят зарплату. Правда, скорее всего, зарплата тоже будет нечеткая - придется быть убедительным, уметь доказать, что это ваши дизайнерские цвета разорили соседнюю сыроварню.

А как же быть с Марсом? Тут все то же самое, что у сайтов, только придется прокачать степень убедительности до уровня Илона Маска.

Компетентностное управление по Agile

Итак, управлять командами по agile не то же самое, что управлять конвейером, но и такие команды нуждаются в управлении. Agile в переводе с английского означает "гибкий". Гибкая разработка основана на принципах, выраженных в Манифесте Agile:

Люди и взаимодействие важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа,

мы всё-таки больше ценим то, что слева.

Итак, справа у нас план, контракт, инструменты, документация. Это такие серьезные, важные штуки, которые носят в кожаных папках, на них ставят подписи и печати. Шаг влево, шаг вправо от намеченного приводит к судам, штрафам и расторжению договора. С ними продающий сайт не создать, но на что-то все равно нужно опираться. И тут на первый план выходят другие ценности - гибкие и расплывчатые soft skills: умение общаться и быть убедительным, навыки презентации, дипломатии, гибкое мышление и отсутствие страха перед изменениями. Серьезные и важные штуки, тем не менее, остались с нами, хоть и находятся теперь на втором месте. Потому что зарплату все-таки надо выразить целым положительным числом, а сайт все-таки должен заработать до того, как конкурент захватит рынок. Главное, подход к ним должен быть гибким.

Но как же планировать такую сложную деятельность, в которой многое зависит от soft skills? Во-первых, Agile не для больших команд: если вас человек 5-7, ну в крайнем случае 10-11, то как-нибудь вы успеете договориться к дедлайну. Должны успеть при достаточной мотивации и разумном дедлайне. Во-вторых, работы по Agile производятся в спринтах. Представьте, как на беговом круге все участники команды встают за линию и по сигналу стартуют. Спринт - это забег, который длится определенный промежуток времени. Обычно в IT спринты длятся от одной недели до месяца. Когда все добежали до финишной прямой, наступает этап подготовки к следующему забегу. Поэтому в Agile очень важны летучки, брифинги, собрания перед каждым спринтом, на которых озвучиваются три главных вопроса: Что было сделано? Что осталось сделать? Что делаем сейчас? Этот подход к планированию привел к популярности досок Kanban, которые в трех колонках систематизируют ответы на эти вопросы.

Кстати, "разумный" применительно к "дедлайн" это то же самое, что "продающий" применительно к "сайт". Никто вам со стопроцентной уверенностью не скажет, что ваш дедлайн разумный. Вы просто знаете это.

Пример доски канбан.

В-третьих, в Agile все являются исполнителями проекта и в одинаковой степени несут ответственность за результат. Обычно здесь нет смысла искать виноватого. Если при производстве молока можно просто уволить сотрудника, который из каждой пачки отпивал по 0.1 литра, так что в магазин поступали пакеты по 0.9 литра, то в Agile каждый участник проекта слишком ценен. Каждый привносит свои уникальные компетенции, которые никто другой заменить не может. Каждый вложился в проект одинаково со всеми и делает проект таким неповторимым. Следовательно, каждый стремится исправить, если что-то пошло не так. Поэтому в командах по Agile нет четких ролей, кроме двух: владелец и scrum-мастер.

Владелец заказа представляет в команде интересы заказчика. Он больше всего общается с заказчиком и стремится выразить конечный результат, основную идею проекта. Scrum-мастер - это менеджер с особыми свойствами. Термин scrum пришел из рэгби. Представьте толпу игроков, которая по свистку ринулась друг на друга в борьбе за мяч. В это время один игрок не участвует в схватке, а бежит куда-то в сторону ворот соперника. Вдруг из толпы вылетает мяч и летит прямо в руки этого игрока. Причем игрок бежит почти не оглядываясь, уверенный что поймает мяч в конкретной точке поля в то самое время. Ключевая задача scrum-мастера: так организовать команду, чтобы все игроки знали, что, где и когда произойдет во время спринта. Сыгранность команды - результат работы scrum-мастера.

Итак, как узнать, что у вас в команде Agile:

Вас немного, вы все в равной мере отвечаете за результат, и каждый из вас обладает уникальными компетенциями.
Вы активно задействуете soft skills, много общаетесь, пробуете разные варианты реализации и инструменты.
Вы работаете в четких временных промежутках и проводите собрания перед каждым из них.
Вы используете Kanban-доску.
Каждый из вас - исполнитель проекта.
В команде есть владелец заказа и scrum-мастер.

Благодарности. Хочу выразить огромное спасибо Вениамину Кизееву и Артему Чапцову за их мастер-классы по agile, сделанные на курсах повышения квалификации "Школа академического превосходства" (Тюменский государственный университет, осень-зима 2018-2019 гг.).

Почитать про Agile можно в книге Майка Кона "Agile: оценка и планирование проектов".

Page updated

Google Sites

Report abuse