Сергей Осипов, MAYKOR-GMCS, о целесообразности применения Agile при реализации проектов

1. ИНСТРУМЕНТЫ • aвтоматизация автоматизация • ИНСТРУМЕНТЫ
58 59www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016
а результат записали. Так появился
Agile Software Development Manifesto,
или, если говорить по-русски, мани-
фест о гибкой разработке программ-
ного обеспечения.
Однако вся эта романтика выгля-
дит далекой от сферы бизнеса (если
он не касается разработки) и в част-
ности ритейла. Однако вместе с Agile
и даже до него начали появляться
методики работы, включающие
в себя подходы Agile и призванные,
как выразился один из авторов по-
добной методики – Scrum, помочь
сделать двойную работу в два раза
быстрее. А вот это уже выглядит
привлекательно. «На мой взгляд,
использование Agile позволяет бы-
стрее повысить уровень ответствен-
ности всех членов проектной коман-
ды за общий результат, повышает
уровень взаимопомощи, позволяет
сотрудникам быстрее повышать
свою квалификацию, – делится мне-
нием Алексей Лапшин, генеральный
директор компании «АйТи. Бизнес
решения». Согласитесь, такие вещи
актуальны для любой компании.
Вслед за ИТ-командами «гибкий
подход»сталиприменятьнебольшие
коллективы, которые хоть и не за-
нимались ИТ-разработками, но все
же производили некий интеллекту-
альный продукт, у которого есть ко-
нечный заказчик. Например, такими
коллективами были анимационные
студии. Потом многие корпорации,
не связанные непосредственно с ИТ-
бизнесом, открыли у себя собствен-
ные отделы разработки, чтобы пи-
сать обеспечение «под себя», – таким
компаниям тоже были интересны
новые подходы, особенно учитывая
тот факт, что с приходом мобильных
технологий все больше предпри-
ятий начали приобщаться к разра-
ботке ПО хотя бы в виде мобильных
приложений. «Отделы разработки
внутри компаний обычно создаются
(в противовес внешним компаниям-
разработчикам) как раз для того,
чтобы более тесно работать с биз-
несом и его потребностями, более
Гибкий подход
Как только российские банки всерьез заинтересовались темой Agile, это стало по-
настоящему модно, и не только в банковской среде. Настолько модно, что в эфире Пер-
вого канала об Agile пытались говорить Владимир Познер и Герман Греф. Последний так
впечатлился этой концепцией, что теперь внедряет ее в подразделениях Сбербанка и вы-
ступает с объяснениями, почему было принято такое решение. Поветрие дошло и до ри-
тейла: в компании «ВкусВилл – Избенка» переходят к гибкому самоуправлению.
АВТОР: Наталья Николаева
динамично реагировать на изме-
нения, свести к минимуму форма-
лизацию, когда есть подписанное
ТЗ и протокол о том, что разрабо-
тано именно то, что написано в ТЗ,
но система не используется. Одной
из причин появления гибкого под-
хода стали серьезные противоречия
между динамичными потребностя-
ми бизнеса и абсолютной властью
согласованного ТЗ, – рассказыва-
ет Сергей Осипов, вице-президент
MAYKOR-GMCS. – Получалось, как
в анекдоте: «Если врач сказал везти
в морг, значит, поедем в морг!», пусть
больной уже и очнулся».
Но даже если компания никак
не связана с ПО, не имеет своего
ИТ-отдела по разработке софта,
не производит интеллектуальный
продукт и не стремится стать Agile-
компанией, принципы этой фило-
софии и даже основы некоторых
конкретных методик работы знать
недурственно. Хотя бы потому, что
при заказе ИТ-продуктов у компа-
нии, которая работает по принци-
пам Agile, заказчик, скорее всего,
будет втянут в игру – исключитель-
но для пользы общего дела. «В со-
ответствии с Agile-манифестом уча-
стие заказчика в проекте – это один
из основных принципов. Поэтому
если ему вся эта кухня неинтересна,
то это и не совсем Agile», – говорит
Сергей Стрелков, руководитель на-
правления собственных разработок
компании КРОК. «На протяжении
всего проекта разработчики и пред-
ставители бизнеса должны еже-
дневно работать вместе», – поясняет
Игорь Визгин, product owner марке-
тинга и веб-разработки компании
«Дримкас». – У нас при создании
продуктов происходит постоянное
общение разработки и заказчика
(представителей бизнеса или, точ-
нее, заинтересованных лиц). Наш
заказчик глубоко погружен в Agile,
и так сложилось, что вся команда
была знакома с методологиями.
Если клиент выразил желание вне-
дриться в процесс по полной, то луч-
ше не сворачивать с пути».
ак что же такое этот
Agile? Простые опреде-
ления,разбросанныетут
и там по Сети, говорят,
что это методология,
которую следует приме-
нять при разработке программного
обеспечения. Звучит как-то слиш-
ком специализированно, не правда
ли? Тренеры по Agile отвечают: «Это
не методология». Практика приме-
нения добавляет: «И она не только
для разработчиков».
Agile – это не формулы и не науч-
ные выкладки. Больше всего это по-
хоже на то, чем занимались разные
литературные школы в прошлом,
когда единомышленники собира-
лись и обсуждали, как им слагать
стихи и прозу и каковы их взгляды
на этот предмет. В результате бур-
ных дебатов рождался манифест.
Так произошло и тут, только вместе
собрались не поэты, а ИТ-эксперты,
у каждого из которых были идеи от-
носительно разработки ПО и взаи-
модействия с конечным заказчиком
ИТ-продукта. Встретившись в горах
Юты (весьма романтично!), 17 че-
ловек определили свои ценности
и образ мыслей на означенную тему,
Т
1. Наивысшим приоритетом для нас
является удовлетворение потребно-
стей заказчика благодаря регулярной
и ранней поставке ценного программ-
ного обеспечения.
2. Изменение требований приветствует-
ся даже на поздних стадиях разработки.
Agile-процессы позволяют использовать
изменения для обеспечения заказчику
конкурентного преимущества.
3. Работающий продукт следует выпу-
скать как можно чаще, с периодично-
стью от пары недель до пары месяцев.
4. На протяжении всего проекта разра-
ботчики и представители бизнеса долж-
ны ежедневно работать вместе.
5. Над проектом должны работать
мотивированные профессионалы.
Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и пол-
ностью доверьтесь им.
6. Непосредственное общение являет-
ся наиболее практичным и эффектив-
ным способом обмена информацией как
с самой командой, так и внутри команды.
7. Работающий продукт – основной пока-
затель прогресса.
8. Инвесторы, разработчики и пользова-
тели должны иметь возможность под-
держивать постоянный ритм бесконечно.
Agile помогает наладить такой устойчи-
вый процесс разработки.
9. Постоянное внимание к техническому
совершенству и качеству проектирования
повышает гибкость проекта.
10. Простота – искусство минимизации
лишней работы – крайне необходима.
11. Самые лучшие требования, архитек-
турные и технические решения рождают-
ся у самоорганизующихся команд.
12. Команда должна систематически ана-
лизировать возможные способы улучше-
ния эффективности и соответственно кор-
ректировать стиль своей работы.
Источник: сайт http://agilemanifesto.org/
Основополагающие принципы
Agile-манифеста

2. ИНСТРУМЕНТЫ • aвтоматизация автоматизация • ИНСТРУМЕНТЫ
60 61www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016
Впрочем, разработчики не слиш-
ком настойчивы в этом вопросе.
Если заказчик говорит «нет», то ему
не придетсяискатьсебедругогопод-
рядчика. «На мой взгляд, это вопрос
ваших отношений с заказчиком, –
комментирует Алексей Лапшин. –
Наш опыт показывает, что вовлече-
ние заказчика в Scrum-активности
повышает эффективность проекта.
Но если заказчик к этому не готов
или активно сопротивляется тако-
му вовлечению, а эффективность
проектов вас устраивает, то и ме-
нять ничего не нужно».
Начав об Agile, мы заговорили
о Scrum. Дело в том, что Agile – это
список определенных ценностей
и ориентиров, в то время как кон-
кретный образ действий, тактика,
описываются в таких системах, как
Scrum, и другие. «Существует ряд
методологий, реализующих гиб-
кий подход: Scrum, экстремальное
программирование (XP), DSDM,
Crystal, FDD, Kanban, – перечисляет
Сергей Осипов. – Scrum является
наиболее распространенной мето-
дологией гибкой разработки, име-
ющей свои особенности».
«Agile – это образ мышления, куль-
тура, опирающаяся на ценности,
описанные в манифесте. Agile – это
то, как люди думают. В то время как
Scrum – один из многих фреймвор-
ков, способов организации своей
работы. Scrum – это то, как люди
работают», – поясняет Сергей Дми-
триев, business agility coach, основа-
тель компании Unusual Concepts. –
При этом часто бывает так, что
говорим Agile – подразумеваем
Scrum. У большинства людей эти
понятия не разделяются, и они
пользуются ими попеременно.
Многие считают Agile и/или Scrum
методологией, что тоже неверно.
Методология – это рецепт, позво-
ляющий достичь определенных
результатов. Ни Agile, ни Scrum ме-
тодологией не являются. Почему
произошла путаница этих понятий,
мы можем только гадать, возмож-
но, потому, что, услышав что-то
новое, люди не удосуживаются под-
робно изучить детали, а собирают
информацию по слухам коллег, ко-
торые собирали ее по слухам дру-
гих коллег. Или, может быть, это
связано с широким распростране-
нием фреймворка Scrum: на сегод-
няшний день им пользуются более
80% agile-команд».
По словам Сергея Дмитриева,
внедрить Agile в компании нель-
зя по определению: «Внедрить
Agile» – очень странная фраза, ведь
мы обычно не говорим «внедрить
людям в нашей организации опре-
деленный образ мышления», ско-
рее, правильно говорить о «пере-
ходе к новому образу мышления».
При этом перейти на определенный
образ мышления в одном отделе
изолированно от остальной органи-
зации, – это тоже довольно странная
история. Представьте, что мы бы за-
хотели в русской ортодоксальной
церкви перевести хор на исповедо-
вание ислама. Agile это все-таки об-
раз мышления для всей организа-
ции, а не для какой-то ее части. Это
еще одна очень распространенная
ошибка в понимании смысла Agile.
Другое дело Scrum. Его как фрейм-
ворк можно применить изолиро-
ванно внутри какого-либо отдела.
Хотя, скорее всего, вы очень быстро
обнаружите, что Scrum, опираясь
на определенные ценности, будет
обнажать проблемы в других частях
организации, которые потребуют
вашего внимания и соответствую-
щего изменения образа мышления
людей вне того отдела, где Scrum
был внедрен изначально».
Scrum в массы!
Если Scrum другое дело – рассмо-
трим его поподробнее. В то время
как идеи Agile умещаются на одну
страницу, о Scrum пишут целые кни-
ги.Книгиполучаютсяпотому,чтоав-
торы подробно объясняют, что они
попробовали, что получилось, а что
не сработало. Все пересказывать
не будем, но основная идея такова.
Нужно реализовать продукт. Для
этого продукта составляется один
список задач и назначается один
принимающий (product owner) –
это как раз должен быть либо сам
заказчик, либо его полномочный
представитель, который будет при-
нимать непосредственное участие
в планировании, демонстрации, об-
суждении итогов. Именно он ставит
задачи (user story), которые вносят-
ся в список (product backlog), а так-
же назначает важность этих задач.
Итак, список готов, задачи там упо-
рядочены в соответствии с их важно-
стью. Далее команда, которая будет
выполнять эти задачи, приглашается
на планирование. Здесь они не сидят
и слушают, что прикажет началь-
ник, а сами оценивают трудозатраты
и пытаются определить, сколько за-
дач они сделают за определенный пе-
риод, и составляют список (sprintlog)
на этот период. Определенный пе-
риод называется sprint. До момента
окончания работ и создания полно-
ценного продукта таких периодов
может быть много, но при этом це-
льюкаждогопериодаявляетсязавер-
шение определенного функционала,
который можно – и обязательно нуж-
но – показать принимающему. «Еще
один ключевой принцип Agile – мак-
симально быстро доставить до заказ-
чика значимый результат, – делится
опытом Сергей Стрелков, – поэтому
в отделе разработки КРОК есть как
методологические принципы, так
и инструментальная поддержка, по-
зволяющая довольно быстро под-
готовить прототип системы, сгене-
рированный по модели предметной
области, и показать его заказчику
еще на начальных этапах проекта.
После чего мы стараемся выпускать
релизы системы с минимальными
временными интервалами, посте-
пенно наращивая начальный резуль-
тат и максимально адаптируя его под
потребности заказчика».
Командно определяется, сколь-
ко задач может включить в себя
1 sprint и как будут продемонстри-
рованы результаты. Затем команда
решает, кто что будет делать. Ответ-
ственность за принятые решения
лежат на команде, самоорганизо-
ваться им помогает Scrum-мастер.
Таким образом, нет приказов сверху.
Есть задачи и есть профессионалы,
которые будут ее выполнять.
Вопросам планирования уделяется
очень много времени. Сначала идет
общее планирование (где каждый
раз присутствует полномочный
представитель заказчика), затем
начинается sprint, в ходе которо-
го проводятся ежедневные Scrum-
пятиминутки. В ходе планирования
и непосредственной работы особое
место отводится визуализации:
для этого нужна доска, графы в ней
(например, «в планах», «в процес-
се», «готово», «цель (с графиком)»),
и стикеры, которые по ходу дела
перемещаются из графы в графу.
Таким образом, в любой момент
времени команда видит, как идет
работа, кто что делает, сколько еще
осталось и что мешает. Процесс
планирования отчасти геймифици-
рован. Например, Хенрик Книберг
в своей книге «Scrum и XP: заметки
с передовой» рассказывает, как для
оценки трудозатрат у них «играют»
в специальный планировочный по-
кер. Совещания длинные, но ску-
чать там некогда: все вовлечены, все
участвуют, голос каждого важен.
При этом качество выпускаемого
функционала даже не обсуждает-
ся – оно всегда должно быть макси-
мальным. Сляпать абы что, только
бы показать это заказчику – не вы-
йдет. Причина проста: по оконча-
нии спринта команда проводит
демонстрацию своих наработок:
то, что они сделали, должно на-
глядно функционировать. Помимо
заказчика на демонстрации при-
сутствуют другие отделы. Никому
не хочется тратить время на ерун-
ду, и если команда оплошала, то все
видят это, нет шансов. Коллеги
ворчат, заказчик понимает, что де-
монстрация пошла не туда, – в ито-
ге всем очевидно, что качество все-
таки страдать не должно.
По окончании спринта проводит-
ся ретроспектива (и опять с уча-
стием заказчика): оценивается
продуктивность (человеко-дни),
верность прогнозов, которые дава-
ла команда в самом начале, обсуж-
Agile в ритейле
Чтобы понять, насколько ритейл при-
близился к Agile и гибкому управле-
нию, мы взяли интервью у Валерия
Разгуляева, управляющего информа-
цией «ВкусВилл – Избенка». Эта тема
близка компании. Недавно Валерий
даже выступил в качестве докладчи-
ка в рамках Agile Business Conference
2016 в Москве.
– Agile кажется узкоспециализиро-
ванной методологией, направленной
исключительно на управление неболь-
шими командами, занимающимися
изготовлением интеллектуального
продукта. Однако банки с восторгом
отнеслись к новым принципам рабо-
ты и внедряют их у себя. Возможно
ли такое в ритейле?
– Если мы обратимся к манифесту гиб-
кого управления, то обнаружим, что его
принципы универсальны и применимы
не только к разработке программного
обеспечения, но и к любой сфере, в кото-
рой происходит управление. Разумеется,
все это применимо и к рознице. Более
того, в России уже сейчас есть рознич-
ные компании, которые живут по этим
принципам. Причем это как не очень
большие, узкоспециализированные ком-
пании, такие как «Альпиндустрия»; так
и «ВкусВилл – Избенка».
– Как выглядит Agile на практике?
– Если говорить про нас, то это ком-
пания, где нет бюджетов, дресс-
кода и спускаемых сверху приказов.
Любое нововведение проговаривается
с помощниками по рознице на пред-
мет удобства их использования для
продавцов-консультантов. Бухгалтерия
значит меньше, чем удовлетворение
клиента, и в случае конфликта инте-
ресов именно бухгалтерия думает, как
правильно оформить то, что было пра-
вильно с точки зрения наилучшего
обслуживания клиентов. Что касается
логистики, то товар доставляется с рас-
пределительного центра в магазины без
приемо-передач от склада транспорту
и от транспорта в магазины – води-
тель просто забирает товар на складе
и оставляет его в магазине ночью, когда
там может еще никого больше и не быть.
Наш покупатель может любой товар
вернуть без объяснения причин, чека
и паспорта; может любой товар бес-
платно попробовать, чтобы понять,
хочет он его покупать или нет. В целом
все друг другу по умолчанию доверяют.
Нет никаких штрафов, а если чело-
век не справляется со своей работой,
то его работу просто разделяют между
ним и еще одним сотрудником, чтобы
понять, субъективны или объективны
проблемы, с которыми он столкнулся.
А еще у нас есть форум, который изо-
билует таким количеством негативных
сообщений о работе магазинов, что любая
другая компания уже давно удалила
бы если и не весь форум, то все такие
сообщения. Но мы открыты.
– Что бы вы посоветовали ритейлеру,
который захочет попробовать Agile
в своей организации?
– Я руковожу проектом перехода на эво-
люционное управление в нашей компа-
нии. Кроме гибкого самоуправления оно
включает в себя еще последовательное
и повсеместное следование всеми сотруд-
никами эволюционной цели компании,
принятой и выработанной ими же. А также
их цельность на работе, то есть отсут-
ствие у сотрудников масок и лицемерия,
позволяющее им получать наслаждение
от своей работы и искренне радоваться
достижению компанией своих целей. Тем,
кто решится на подобное у себя, могу
сразу сказать, что ошибкой является ожи-
дание, будто самоуправление само возь-
мет верх, достаточно его декларативно
разрешить. Его придется кропотливо вне-
дрять сверху, сталкиваясь с сопротивле-
нием на всех уровнях иерархии, вклю-
чая и линейных сотрудников, которым
придется брать на себя дополнительную
ответственность, очень непривычную им.
Но игра стоит свеч, так как благодаря эво-
люционному управлению решения будут
приниматься там, где возникает пробле-
ма, и именно тогда, когда она возникает,
а руководители из надзирателей и карате-
лей превратятся в помощников и настав-
ников. Кстати, вопреки некоторым мне-
ниям, русский менталитет очень хорошо
подходит к самоуправлению, возможно,
даже лучше, чем любой другой.

3. ИНСТРУМЕНТЫ • aвтоматизация автоматизация • ИНСТРУМЕНТЫ
62 63www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016
дается, что улучшить в следующем
«забеге». Между спринтами дела-
ется короткий перерыв, а потом
цикл повторяется.
Это что касается процесса работы.
Основная же задача Scrum – помочь
команде в частности и компании
в целом быть гибкими, не бояться
изменений техзадания от заказчи-
ка, непрерывно уточнять задачи
и менять их по мере необходимо-
сти, «открыться» для заказчика,
не выстраивая перед собой барри-
кад из регламентов, согласований,
долгой разработки и долгого же ут-
верждения. «Самое плохое – это если
разработчик не контактирует с за-
казчиком в течение длительного
времени – полгода или год, – гово-
рит Сергей Стрелков. – За это время
у заказчика может все поменяться,
включая людей и бизнес-процессы».
Начнем забег
с понедельника?
На словах Scrum вовсе не кажется
чем-то слишком сложным. «Ключе-
вая идея гибкого подхода достаточ-
но проста, – подтверждает Сергей
Осипов, – но эта внешняя простота
обманчива. Эффективность и ре-
зультативность любой методологии
и технологии зависит от того, как ор-
ганизованы, как выполняются и кон-
тролируются конкретные процессы,
от конкретных людей на конкретных
позициях (дьявол в деталях). Именно
поэтому прочитать книгу с условным
названием «Agile для чайников» и на-
чать работать по новой методологии
«с понедельника» можно, но хороших
результатов ожидать сложно. Чтобы
не идти методом проб и ошибок, мно-
гие команды нанимают людей, име-
ющих практический опыт работы
по соответствующей методологии,
или привлекают внешних менторов.
Хороший тренер – это тот, у которого
есть не только теоретические зна-
ния, но и практический опыт».
«Scrum не внедряется быстро, –
добавляет Алексей Лапшин. – Это
серьезное изменение не только
в технологии, но и в отношении
к работе, проекту, ответственности,
своей роли. Легкость вовлечения за-
казчиказависитот вашихс нимотно-
шений, уровня доверия, вашей спо-
собности объяснить, что изменится
в проекте в связи с таким вовлече-
нием, как изменится производитель-
ность команды, удовлетворенность
заказчика результатом. Не надо
стремиться все сделать в один шаг,
даже если вы считаете, что готовы
к такому шагу. Начните с простых,
понятных, но эффективных изме-
нений. Внедрите итерационность
(sprint) в проект, организуйте де-
монстрации приращения продукта
в конце каждой итерации, настрой-
те отчетность исполнения в рамках
каждой итерации по исполнению
работ, по изменениям в требовани-
ях, по тестированию. Затем привле-
ките заказчика к приоритезации,
планированию. Демонстрируйте ему,
как меняется производительность
команды от итерации к итерации
за счет слаженности команды, полу-
чения обратной связи. Внедрение
Scrum не может завершиться, всегда
есть место для улучшений, но вы до-
бьетесь большего внимания со сто-
роны заказчика. Поиграйте с длиной
итерации. Чем короче итерация, тем
чаще вы обсуждаете результаты с за-
казчиком, но тем сложнее выделить
работы, которые можно успеть сде-
лать и при этом показать значимое
приращение продукта».
Участие заказчика – еще один
камень преткновения. Он должен
хотеть участвовать. «Если у за-
казчика нет времени на проект,
то, значит, нет и обратной связи,
что в итоге приводит к несоответ-
ствию разрабатываемой системы
с видением ее на стороне заказ-
чика, – рассуждает Сергей Стрел-
ков. – Например, в практике КРОК
принято еще на этапе предложения
описывать степень вовлеченности
заказчика в работу над проектом.
Так как мы работаем с крупными
компаниями, то с их стороны при-
нимают участие десятки людей:
от пользователей и финансистов
до инженеров и руководителей ИТ-
подразделений, все из них находят
время для проекта».
Почему внезапно стать Agile-ори-
ентированной компанией не по-
лучится, понятно на примере про-
стейшего житейского опыта. Кто
из нас не знает, что физкультура –
это полезно, и хорошо бы начать
бегать с понедельника? Но кто
из нас действительно побежал,
и не просто побежал, но и про-
должил свои благие начинания?
«Мы уже разобрались, что Agile –
это не методология, – объясняет
детали Сергей Дмитриев. – Про-
читать манифест и завтра же на-
чать работать с новым сознани-
ем в теории можно. На практике
вам будет мешать прошлый опыт.
На сегодняшний день наши орга-
низации не основаны на тех цен-
ностях, которые описаны в ма-
нифесте. И если вы прочитаете
сегодня в умной книге, что завтра
нужно действовать по-другому,
ваши реальные действия завтра,
скорее всего, не изменятся, потому
что действовать вы будете по при-
вычке. Именно поэтому и нужны
тренеры и коучи, которые будут
«держать зеркало» и давать орга-
низации обратную связь, показы-
вая нам наши собственные дей-
ствия со стороны и комментируя,
когда они будут расходиться с на-
шими новыми намерениями. Пере-
ход организации к новому образу
мышления завершится только
тогда, когда большинство людей
в компании начнет думать и дей-
ствовать по-другому. Это процесс
изменения сознания личности,
который не происходит за день,
неделю и даже месяц. Именно по-
этому процесс трансформации ор-
ганизации занимает многие годы,
иногда десятилетия».
Кому с Agile жить
хорошо
С одной стороны, Agile стал про-
никать в самые разные сферы биз-
неса. Принципы гибкого подхода
теперь пытаются перенести даже
на методы управления проекта-
ми или компаниями в целом. «Это
признает, в частности, и Project
Management Institute, который
уже сертифицирует специалистов-
практиков по методам Agile», – го-
ворит Сергей Стрелков.
С другой стороны, всегда ли при-
менимы эти принципы? «Подход
применим, когда есть люди, кото-
рые знают, как его использовать
в конкретной ситуации, – считает
Игорь Визгин. – Карго-культ – глав-
ная проблема при работе в Agile.
Слепое подражание не дает резуль-
татов и заканчивается разочарова-
нием. Если говорить про рабочую
ситуацию, то использование не-
скольких вариантов в работе одной
команды снижает эффективность.
Я бы не хотел оказаться в ситуации,
когда с одним заказчиком работаем
по скраму, с другим – по канбану,
с третьим – по уотерфолу, а потом
приходит еще один клиент, и на-
чинается классическое проектное
управление. На мой взгляд, глав-
ное – работать по одной методоло-
гии, а не устраивать микс, подстра-
иваясь под каждого заказчика».
«Принципы Agile сложно при-
менять только в случае госкон-
трактов, – считает Сергей Стрел-
ков, – так как Agile подразумевает
гибкость по отношению к техниче-
скому заданию в отличие от нашего
законодательства. Однако некото-
рые положения можно воплощать
и тут. Например, в ходе работы
техническое задание может быть
детализировано с порождением
частных ТЗ, функциональных спец-
ификаций и прочих документов, ко-
торые уточняют требования».
По мнению Сергея Осипова, целе-
сообразность применения Agile под
вопросом в следующих случаях:
• в инфраструктурных проектах,
имеющих сложный процесс под-
держки;
• в проектах, где подтверждение
технического задания требует очень
длительного формального цикла;
• если нет обратной связи с ко-
нечным пользователем системы,
а также невозможно иным спосо-
бом улучшать знания о предмет-
ной области у проектной команды;
• если команда состоит из недо-
статочно квалифицированных
специалистов, которые не готовы
к изменениям и внедрению про-
грессивных подходов.
Он обрисовывает конкретную
ситуацию: «Максимальный эф-
фект достигается в том случае,
когда применяемая методология
соответствует целям и задачам
конкретного проекта. Например,
компания-разработчик выиграла
открытый конкурс на разработку
системы для заказчика. При этом
конкурсная документация содер-
жала не только детальное тех-
ническое задание на разработку
системы, но также определяла ста-
дии и этапы реализации проекта,
принципы документирования, по-
рядок сдачи-приема и т.п. В этом
случае не самой удачной идеей бу-
дет после заключения контракта
предложить заказчику работать
по какой-то из Agile-методологий.
С другой стороны, можно приве-
сти следующий пример сочетания
элементов различных методоло-
гий. Для заказчика выполнялась
разработка комплексной инфор-
мационной системы. Работы ве-
лись по техническому заданию,
где все этапы были заранее опре-
делены. Одним из этапов была
разработка серверной части.
В процесс разработки серверной
части весьма сложно вовлекать ко-
нечных пользователей на итера-
ционной основе (как этого требу-
ют методологии гибкого подхода),
так как для пользователя сервер-
ная часть почти «невидима». Тогда
было принято решение проводить
регулярные итерации с привлече-
нием двух сторонних компаний-
разработчиков, которые в этом
случае выступали в роли оппонен-
тов. Это позволило значительно
повысить качество разработки
и избежать ряда рисков на самых
ранних этапах».