Гибкий подход
9 ноября 2016

Гибкий подход

Как только российские банки всерьез заинтересовались темой Agile, это стало по-настоящему модно, и не только в банковской среде. Настолько модно, что в эфире «Первого канала» об Agile пытались говорить Владимир Познер и Герман Греф. Последний так впечатлился этой концепцией, что теперь внедряет ее в подразделениях Сбербанка и выступает с объяснениями, почему было принято такое решение.

Так что же такое этот Agile? Простые определения, разбросанные тут и там по Сети, говорят, что это методология, которую следует применять при разработке программного обеспечения. Звучит как-то слишком специализированно, не правда ли? Тренеры по Agile отвечают: «Это не методология». Практика применения добавляет: «И она не только для разработчиков».

Agile – это не формулы и не научные выкладки. Больше всего это похоже на то, чем занимались разные литературные школы в прошлом, когда единомышленники собирались и обсуждали, как им слагать стихи и прозу и каковы их взгляды на этот предмет. В результате бурных дебатов рождался манифест. Так произошло и тут, только вместе собрались не поэты, а ИТ-эксперты, у каждого из которых были идеи относительно разработки ПО и взаимодействия с конечным заказчиком ИТ-продукта. Встретившись в горах Юты (весьма романтично!), 17 человек определили свои ценности и образ мыслей на означенную тему, а результат записали. Так появился Agile Software Development Manifesto, или, если говорить по-русски, манифест о гибкой разработке программного обеспечения.

Однако вся эта романтика выглядит далекой от сферы бизнеса (если он не касается разработки) и в частности ритейла. Однако вместе с Agile и даже до него начали появляться методики работы, включающие в себя подходы Agile и призванные, как выразился один из авторов подобной методики – Scrum, помочь сделать двойную работу в два раза быстрее. А вот это уже выглядит привлекательно.

<…>

Вслед за ИТ-командами «гибкий подход» стали применять небольшие коллективы, которые хоть и не занимались ИТ-разработками, но все же производили некий интеллектуальный продукт, у которого есть конечный заказчик. Например, такими коллективами были анимационные студии. Потом многие корпорации, не связанные непосредственно с ИТ- бизнесом, открыли у себя собственные отделы разработки, чтобы писать обеспечение «под себя», – таким компаниям тоже были интересны новые подходы, особенно учитывая тот факт, что с приходом мобильных технологий все больше предприятий начали приобщаться к разработке ПО хотя бы в виде мобильных приложений. «Отделы разработки внутри компаний обычно создаются (в противовес внешним компаниям-разработчикам) как раз для того, чтобы более тесно работать с бизнесом и его потребностями, более динамично реагировать на изменения, свести к минимуму формализацию, когда есть подписанное ТЗ и протокол о том, что разработано именно то, что написано в ТЗ, но система не используется. Одной из причин появления гибкого подхода стали серьезные противоречия между динамичными потребностями бизнеса и абсолютной властью согласованного ТЗ, – рассказывает Сергей Осипов, вице-президент MAYKOR-GMCS. – Получалось, как в анекдоте: «Если врач сказал везти в морг, значит, поедем в морг!», пусть больной уже и очнулся».

Но даже если компания никак не связана с ПО, не имеет своего ИТ-отдела по разработке софта, не производит интеллектуальный продукт и не стремится стать Agile- компанией, принципы этой философии и даже основы некоторых конкретных методик работы знать недурственно. Хотя бы потому, что при заказе ИТ-продуктов у компании, которая работает по принципам Agile, заказчик, скорее всего, будет втянут в игру – исключительно для пользы общего дела.

<…>

Начав об Agile, мы заговорили о Scrum. Дело в том, что Agile – это список определенных ценностей и ориентиров, в то время как конкретный образ действий, тактика, описываются в таких системах, как Scrum, и другие. «Существует ряд методологий, реализующих гибкий подход: Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban, – перечисляет Сергей Осипов. – Scrum является наиболее распространенной методологией гибкой разработки, имеющей свои особенности».

<…>

Scrum в массы!

Если Scrum другое дело – рассмотрим его поподробнее. В то время как идеи Agile умещаются на одну страницу, о Scrum пишут целые книги. Книги получаются потому, что авторы подробно объясняют, что они попробовали, что получилось, а что не сработало. Все пересказывать не будем, но основная идея такова. Нужно реализовать продукт. Для этого продукта составляется один список задач и назначается один принимающий (product owner) – это как раз должен быть либо сам заказчик, либо его полномочный представитель, который будет принимать непосредственное участие в планировании, демонстрации, обсуждении итогов. Именно он ставит задачи (user story), которые вносятся в список (product backlog), а также назначает важность этих задач.

Итак, список готов, задачи там упорядочены в соответствии с их важностью. Далее команда, которая будет выполнять эти задачи, приглашается на планирование. Здесь они не сидят и слушают, что прикажет начальник, а сами оценивают трудозатраты и пытаются определить, сколько задач они сделают за определенный период, и составляют список (sprintlog) на этот период. Определенный период называется sprint. До момента окончания работ и создания полноценного продукта таких периодов может быть много, но при этом целью каждого периода является завершение определенного функционала, который можно – и обязательно нужно – показать принимающему.

Командно определяется, сколько задач может включить в себя 1 sprint и как будут продемонстрированы результаты. Затем команда решает, кто и что будет делать. Ответственность за принятые решения лежит на команде, самоорганизоваться им помогает Scrum-мастер. Таким образом, нет приказов сверху. Есть задача, и есть профессионалы, которые будут ее выполнять.

Вопросам планирования уделяется очень много времени. Сначала идет общее планирование (где каждый раз присутствует полномочный представитель заказчика), затем начинается sprint, в ходе которого проводятся ежедневные Scrum-пятиминутки. В ходе планирования и непосредственной работы особое место отводится визуализации: для этого нужна доска, графы в ней (например, «в планах», «в процессе», «готово», «цель (с графиком)»), и стикеры, которые по ходу дела перемещаются из графы в графу. Таким образом, в любой момент времени команда видит, как идет работа, кто что делает, сколько еще осталось и что мешает. Процесс планирования отчасти геймифицирован. Например, Хенрик Книберг в своей книге «Scrum и XP: заметки с передовой» рассказывает, как для оценки трудозатрат у них «играют» в специальный планировочный покер. Совещания длинные, но скучать там некогда: все вовлечены, все участвуют, голос каждого важен.

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

По окончании спринта проводится ретроспектива (и опять с участием заказчика): оценивается продуктивность (человеко-дни), верность прогнозов, которые давала команда в самом начале, обсуждается, что улучшить в следующем «забеге». Между спринтами делается короткий перерыв, а потом цикл повторяется.

Это что касается процесса работы. Основная же задача Scrum – помочь команде в частности и компании в целом быть гибкими, не бояться изменений техзадания от заказчика, непрерывно уточнять задачи и менять их по мере необходимости, «открыться» для заказчика, не выстраивая перед собой баррикад из регламентов, согласований, долгой разработки и долгого же утверждения.

<…>

Начнем забег с понедельника?

На словах Scrum вовсе не кажется чем-то слишком сложным. «Ключевая идея гибкого подхода достаточно проста, – подтверждает Сергей Осипов, – но эта внешняя простота обманчива. Эффективность и результативность любой методологии и технологии зависит от того, как организованы, как выполняются и контролируются конкретные процессы, от конкретных людей на конкретных позициях (дьявол в деталях). Именно поэтому прочитать книгу с условным названием «Agile для чайников» и начать работать по новой методологии «с понедельника» можно, но хороших результатов ожидать сложно. Чтобы не идти методом проб и ошибок, многие команды нанимают людей, имеющих практический опыт работы по соответствующей методологии, или привлекают внешних менторов. Хороший тренер – это тот, у которого есть не только теоретические знания, но и практический опыт».

<…>

Почему внезапно стать Agile-ориентированной компанией не получится, понятно на примере простейшего житейского опыта. Кто из нас не знает, что физкультура – это полезно, и хорошо бы начать бегать с понедельника? Но кто из нас действительно побежал, и не просто побежал, но и продолжил свои благие начинания?

<…>

Кому с Agile жить хорошо

С одной стороны, Agile стал проникать в самые разные сферы бизнеса. Принципы гибкого подхода теперь пытаются перенести даже на методы управления проектами или компаниями в целом.

<…>

По мнению Сергея Осипова, целесообразность применения Agile под вопросом в следующих случаях:

  • в инфраструктурных проектах, имеющих сложный процесс поддержки;
  • в проектах, где подтверждение технического задания требует очень длительного формального цикла;
  • если нет обратной связи с конечным пользователем системы, а также невозможно иным способом улучшать знания о предметной области у проектной команды;
  • если команда состоит из недостаточно квалифицированных специалистов, которые не готовы к изменениям и внедрению прогрессивных подходов.

Он обрисовывает конкретную ситуацию: «Максимальный эффект достигается в том случае, когда применяемая методология соответствует целям и задачам конкретного проекта. Например, компания-разработчик выиграла открытый конкурс на разработку системы для заказчика. При этом конкурсная документация содержала не только детальное техническое задание на разработку системы, но также определяла стадии и этапы реализации проекта, принципы документирования, порядок сдачи-приема и т.п. В этом случае не самой удачной идеей будет после заключения контракта предложить заказчику работать по какой-то из Agile-методологий. С другой стороны, можно привести следующий пример сочетания элементов различных методологий. Для заказчика выполнялась разработка комплексной информационной системы. Работы велись по техническому заданию, где все этапы были заранее определены. Одним из этапов была разработка серверной части. В процесс разработки серверной части весьма сложно вовлекать конечных пользователей на итерационной основе (как этого требуют методологии гибкого подхода), так как для пользователя серверная часть почти «невидима». Тогда было принято решение проводить регулярные итерации с привлечением двух сторонних компаний-разработчиков, которые в этом случае выступали в роли оппонентов. Это позволило значительно повысить качество разработки и избежать ряда рисков на самых ранних этапах».

Полная версия статьи из журнала «Мое дело. Магазин» доступна по ссылке.


Назад