Связаться с редакцией
В этой статье я хочу остановиться на уместности применения этого подхода в больших проектах разработки и внедрения, которые интегратор делает для заказчика.
Плюсы гибких подходов в сравнении с классическим 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. И настоящее лидерство именно в том, чтобы в числе первых суметь воспользоваться этим набором возможностей в полной мере, не просто используя их, но и изменяя под них весь подход к работе.
