© 1995-2022 Компания «Инфосистемы Джет»
Когда Agile действительно работает
Программное обеспечение Программное обеспечение

Опираясь на свой богатый опыт разработки, мы описали те условия, при которых Agile подход будет успешно применяться

Главная>Программное обеспечение>Когда Agile действительно работает
Программное обеспечение Тренд

Когда Agile действительно работает

08.12.2016

Посетителей: 364

Просмотров: 315

Время просмотра: 2.1 мин.

Авторы

Автор
Владимир Молодых В прошлом - руководитель Дирекции по разработке и внедрению программного обеспечения компании "Инфосистемы Джет"
В последние несколько лет везде обсуждаются Agile-подходы к ведению проектов, причем как в разработке, так и в других сферах жизни. Я бы сказал, что термин «Agile» и смежные с ним, типа Scrum, FDD, DSDM и т.п., стали общеизвестными и множество людей старается применить их в проектной деятельности при любой возможности. Но важно понимать, что набор подходов Agile, как и любые другие подходы, имеет свои плюсы, минусы и область уместного применения.

 

 

В этой статье я хочу остановиться на уместности применения этого подхода в больших проектах разработки и внедрения, которые интегратор делает для заказчика.

 

Плюсы гибких подходов в сравнении с классическим Waterfall (каскадная модель) к разработке понятны: например, не нужно ждать полгода перед стартом разработки, пока пишется и согласуется техническое задание (ТЗ). Такой подход на выходе дает меньше писанины и времени, потраченного на согласование формальных документов, и больше наглядности вовлеченности заказчика в процесс, ведь он все время видит, что происходит, может участвовать в изменениях.

 

Я приведу только один пример. Итак, большой проект, на тысячи человеко-дней. Если в рамках Waterfall составлять и согласовывать техническое задание, часто бывает так, что в итоге на стороне заказчика какие-то ключевые вещи, может, и посмотрят ключевые участники, но итоговые 500 страниц в лучшем случае прочитает младший аналитик. Если в момент приемки готового решения выяснится, что что-то значимое в ТЗ не учтено, это, несомненно, вызовет конфликтную ситуацию и потенциальные переработки, несмотря на подпись заказчика на документе. А команда разработки может услышать: «Я ТЗ не читал, но мы же с вами договаривались. Конечно, в ТЗ мы что-то не указали, но вы ведь профессионалы и должны были все учесть. Без этого функционала мы запуститься не сможем». Конечно, от такой ситуации можно защититься, правильно проведя проект обследования, но 100-процентной защиты не бывает. В рамках итеративной разработки и постоянных показов такие ошибки проявятся существенно раньше.

 

Ограничения подхода Agile

 

Но у подхода Agile есть и минусы, которым часто не придают значения.

 

Традиционно на российском рынке большинство контрактов – это не Time&Material, а заказы на разработку/доработку/внедрение конкретной системы с конкретным функционалом.

 

И здесь классическая каскадная разработка страхует сразу две стороны. Интегратор, хоть и в ограниченной степени, защищен согласованным ТЗ от того, что заказчик будет выдвигать все новые и новые требования. Заказчик защищен тем, что исполнитель берет на себя обязательство сделать то, что написано в ТЗ, и если он этого не сделал, однозначно виноват именно он.

Опять же у нас в практике были случаи таких внедрений, когда на стороне заказчика в течение проекта внедрения менялся менеджмент, включая топов, трижды за проект. И каждая новая команда приходила со своим видением проекта. Подписанное ТЗ в таких случаях сильно помогает.

 

Но и с контрактами Time&Material не все так гладко. Что делать, если за выделенное время люди, отвечающие за это, не выполнили пул поставленных задач, как понять, кто виноват? В таких ситуациях обе стороны склонны обвинять друг друга.

 

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

 

А вот и пример, касающийся оценки работ. При составлении ТЗ я могу примерно представить, что непосредственная разработка займет 300 человеко-дней, тестирование – 150, доработка системы – 100 и т.д. Я могу прогнозировать, сколько этот проект займет времени у моей команды и сколько такая разработка может стоить. А в ситуации, когда каждая итерация так или иначе вынуждена учитывать меняющуюся ситуацию у заказчика, я не могу давать столь точные оценки и слабо защищен от риска, что придется переделывать одно и то же несколько раз.

 

Как работает Agile?

 

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

 

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

 

Дважды в моей практике был случай, когда на установочной встрече нам так удавалось заинтересовать методологией ключевое лицо, что в крупных компаниях Product Owner и ключевым стейкхолдером становился COO или профильный вице-президент. В итоге этот внутренний драйвер подстраивал работу команды заказчика и нашей команды под свой график и свой подход к работе, но своим энтузиазмом вытаскивал проект на совершенно иной уровень, где эффективность была в десятки раз выше. Наш Scrum Master только чуть-чуть корректировал этот энтузиазм.

 

На мой взгляд, самая значимая компетенция у директора проекта, работающего на стороне интегратора, – умение оценить свою команду, команду заказчика, ограничения (те же требования по ГОСТ и доступности бизнес-заказчиков) и из широкого вороха методологий, организационных инструментов и возможностей выбрать наиболее подходящий для этого проекта комплект, убедить в его оптимальности обе команды и воплотить его в жизнь.

 

Когда работает Agile?

 

Опираясь на свой опыт, я готов констатировать, что Agile в России успешно работает в крупных проектах, которые делает интегратор для заказчика в тех случаях, когда одновременно обе стороны (и заказчик, и исполнитель) достаточно технически и организационно компетентны, идут в проект без лукавства и секретов друг от другу и полностью доверяют друг другу.

 

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

 

 

В последние несколько лет Agile и все связанное с ним стало модным. Слова «Scrum», «Agile» и производные от них люди стали употреблять к месту и не к месту, часто оправдывая недостаточное планирование и качество тем, что так и необходимо в рамках Agile подхода. Одновременно с этим уже очень многие крупные компании пришли к тому, чтобы выдавать обновления раз в месяц. Без этого не выжить на рынке. Так что я думаю, что через совсем недолгое время слово «Agile» в широких массах перестанут воспринимать всерьез, оно обесценится.

 

Одновременно с этим время не стоит на месте. Легендарный Agile Manifesto был провозглашен 15 лет назад, в 2001 году, а за окном уже вот-вот наступит 2017. Если Agile философия говорила в первую очередь о том, как действуют люди, то сейчас все больше фокус дополняется тем, как организуются и автоматизируются процессы. Я говорю о автотестах, Jenkins, GitHub и подобных вещах, с помощью которых реализуется набор подходов Continuous Delivery. И настоящее лидерство именно в том, чтобы в числе первых суметь воспользоваться этим набором возможностей в полной мере, не просто используя их, но и изменяя под них весь подход к работе.

Уведомления об обновлении тем – в вашей почте

Как привить Agile-культуру на российской земле

В последнее время слово Agile стало очень популярным. Несмотря на то что Agile Manifesto («Манифест гибкой методологии разработки программного обеспечения») появился в 2001 году, многие специалисты до сих пор спорят, что такое Agile: методология или культура.Подробнее: http://old.jetinfo.ru/stati/?nid=718eb1d2110a4986492dff326d200620

«ИТ — это не конкурентное преимущество, а конкурентное требование»

Мы побеседовали с Максимом Белоусовым о том, какие задачи ставит перед ИТ-подразделением новый владелец Банка, почему ИТ не должно быть просто конкурентным преимуществом, а также какую угрозу в себе несет повальное увлечение Agile.

Не бизнес, а партнер: ИТ в УК «Альфа-Капитал»

Почему «Альфа-Капитал» не собирается полностью уходить в цифру? Когда «водопад» лучше Agile? Как компания пережила период самоизоляции? Как изменились ИТ-шники за последние 20 лет?

Кейсы AgileDays 2022: корпоративная культура, инновации «ВкусВилл» и экономия на разработчиках

Что такое «стратегия чайного пакетика»? Можно ли протестировать бизнес-гипотезу без разработчиков? Что мешало внедрению инноваций во «ВкусВилл»?

Когда и зачем внедрять Scrum и Kanban?

Какие задачи решает Scrum-мастер и почему его наличие в команде обязательно

Мы как саперы — не имеем права на ошибку

Как Сбербанк проверяет на производительность платежную систему для физических лиц

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня