Что такое Agile?
Это методика ведения проектов, в основе которой лежит некая итеративность, поэтапное закрытие, приближение к результатам. Непосредственно имеется сам продукт, который мы хотим получить, и есть некие спринты – этапы. В среднем спринт длится 2-3 недели, но по многим проектам они бывают и недельными.
Что такое спринт? Это некий отрезок времени, за который надо получить определённый результат. Мы можем не получить всю систему в целом, но определенный результат должны показать. Причем это результат, который принимает заказчик.
Особенности заключения контрактов типа Agile
Отличительный момент проектов Agile – отсутствие перспектив на постановку технического задания и получения в целом какого-то решения. Здесь нет такого, что сначала мы пишем полгода техническое задание, потом 2 года программируем, а потом показываем заказчику продукт. Все сводится к тому, что мы определяем общие с заказчиком цели, которые хотим достигнуть. В договоры наша компания даже добавляет такой раздел, как «Цели», и прежде чем идти в проект, мы их прописываем.
Важно понимать, что цели из разряда «получить новую платформу» или «автоматизировать» – это не цели. Цели должны быть сформулированы конкретно. Например, получение структуры себестоимости или отчета по себестоимости с визуальным представлением. Это цель. Заказчик понимает, что когда он увидит такую-то формочку, пусть она даже в экселе нарисована, это достижение цели, это то, что нужно принимать. Какая-то обработка – это тоже может быть целью. Поэтому цели должны быть четко расставлены и должны быть визуальными/ощутимыми.
Следующий этап – надо четко расставить акценты. С заказчиком важно их проговорить, и важно понимать всем сторонам, как будет приниматься работа. Проект длится таким образом, что работу приходится принимать в полуфабрикатном виде, поскольку в Agile мы без всякого перфекционизма идем по короткому пути к результату.
Допустим, прошел двухнедельный спринт, и мы получили одну версию продукта, пусть это будет одна подсистема, блок согласования на оплату в казначействе. Это результат, и он подлежит приемке, внедрению и дальнейшей эксплуатации. Все эти моменты необходимо проговорить на стадии заключения договора.
В Agile нет определенного и четкого состава работ на проект, все может поменяться. Но образ результата нужно сразу определить, а заодно подумать про негатив и про все плохое: где может быть недопонимание со стороны заказчика, когда вы придете сдавать работы. Вполне вероятно, что когда вы придете, заказчик откажется принимать результат, потому что это не то, что он хотел получить в итоге. Поэтому при заключении контракта надо заранее проговорить, что должно стать результатом и что надо принимать.
Проектирование по Agile
В этой системе нет такого этапа, как постановка технического задания. Мы против этого этапа, потому что фактически онзаканчивается тонной макулатуры, которая потом мало применяется. Чаще всего с постановкой ТЗ приходится сталкиваться при работе по госконтрактам, когда техническое задание необходимо и является неотъемлемой частью.
Тем не менее, этап проектирования в Agile есть, от него никуда не уйти. Он представляет собой следующее: в 1С проектах на 99% всегда решение строится на базе другого готового решения. Если управленческий учет – это ERP или управление торговлей, есть много отраслевых решений. Это понятно на этапе предварительных переговоров с заказчиком. Наш проект строится на уже готовых решениях. На предпроектных работах мы берем готовую систему и наполняем ее рабочими данными – это входит в состав предпроектных работ. Если мы переходим с существующей системы, мы заранее будем готовить конвертацию, и будем заполнять сразу реальными данными. И все проектирование сводится не к получению какого-то документа, а к построению системы и ее запуску.
Очень хорошо, чтобы заказчик сам вводил справочники и документы, формировал отчеты, и сам проявлял инициативу, что надо доработать в системе, что неудобно, какие доработки необходимы в системе. Таким образом, результатом предпроектных работ является не какой-то документ, а, по сути,некая готовая система, которая является прототипомконечного результата.
При этом нельзя сказать, что документация вообще отсутствует. Потому что есть какие-то вещи, например, модель расчета себестоимости, которые даже заказчику еще непонятны, и их надо описать, чтобы в дальнейшем спроектировать, представить, как это будет выглядеть. В таком случае какой-то документ будет. Но если мы понимаем, что нужно сделать кнопку, которая уже существует, и ее надо просто перенести в новуюсистему, описывать это не надо. Достаточно указать, что необходимо сделать кнопку, которая должна работать таким же образом. И это есть результат, который войдет в результат какого-то спринта и будет сдан по аналогии с существующей системой.
Оценка работы
Спроектированный состав работ имеет вид задач, списка. Встает вопрос, как все это оценить. Методик оценки много, они разные и интересные. Где-то сидит эксперт, который говорит, сколько часов это займет, умножает их на стоимость нормо-часа. В другом месте сидит менеджер, который понимает, сколько можно «скормить» заказчику. В третьем придуман еще какой-то способ.
В нашей компании пользуются технологией, которая называется Agile Planning Poker. Ее, кстати, можно использовать в самых разных ситуациях, она применима не только для оценки, и не только в Agile.
Как работает эта технология? У каждого программиста, у каждого участника команды есть такая колода карт с цифрами. Рассчитываем, сколько часов именно на разработку необходимо потратить. Программисты берут карты рубашкой вверх и потом вскрывают их. Если количество часов не будет отличаться больше чем на 10-20 процентов, берётся максимальная оценка. Если один дал 2 часа, а другой – 10 часов, это значит, что оценка сильно отличается. Тогда начинается обсуждение, потому что вполне вероятно, что прав тот человек, который дал большую оценку, поскольку он понимает, что потребуется больше времени. Может быть и наоборот: тот, кто дал больше часов, чего-то не понимает, потому что уже где-то есть готовое решение, которое можно скачать и все быстро сделать. После обсуждения идет переоценка.
То есть мы получаем некий корсет прямых затратпрограммистов. Еще одно преимущество этой технологии в том, что команда сама дала оценку. Если оценили в 10 часов, а потратили 200 часов, обвинить какого-то одного человека будет очень сложно. Ребята вместе оценивали и смотрели на задачу.
Составление сметы
Смета формируется с помощью некого внутреннего инвойсного часа, который идет на разработку. В нашей компании есть такой документ – смета на проведение работ. В нем любой сотрудник может указать трудочасы, которые были получены при помощи покера, накрутить косвенные затраты – на тестирование, сдачу и иные задачи, и на выходе получить полноценную коммерческую стоимость на конкретные работы.
Формирование плана-графика
Планировать в Agile на длительный период никакого смысла нет.
Тем не менее, есть два вида плана. Первый – план движения по проекту, очень укрупненный. Дается только для того, чтобы дисциплинировать заказчика и подрядчика. Мы понимаем, какой у нас вектор, куда идем, поэтому все дается в укрупненном плане. Допустим, до сентября должны запустить продажи, в ноябре – закупки, и т.д.
Второй план более детальный, мелкий. Он называется спринты.
Спринт содержит в себе определённый состав задач на 1-2 недели, максимум на 4 недели. Спринт менять нежелательно, это список задач, которые фиксируются, и изменять их неправильно. У нас, например, к спринтам привязана система мотивации, и команда прекрасно понимает, что все поставленные задачи надо выполнить за короткий промежуток времени.
Но даже за 1-2 недели может что-то произойти. Может поменяться руководитель проекта, например. Тогда спринт может быть перепланирован.
Собираем хорошую команду
Проектная команда формируется для решения разных задач, и должна состоять обязательно из четырех частей. Притом обязательная часть представлена на картинке с левой части, а необязательная – справа. Разберемся, кто есть кто.
У нас должна быть проектная команда от заказчика. Если ее нет, то, скорее всего, ваш проект Agile завершится неудачей. Мы должны видеть и понимать тех людей, которые отвечают за приемку работ. Это должен быть владелец продукта, это может быть заказчик, может быть исполнитель или третье контактное лицо, которое понимает четко, что мы должны получить в итоге. Этот человек может поставить приоритеты, может закрыть или перенаправить проект. Ответственные люди со стороны заказчика, которые будут отвечать за приемку работ, должны быть обязательно.
Еще одна обязательная фигура – ведущий программист или, как его еще называют, архитектор. Это специалист проектной команды. Специфика Agile проектов в том, что команда исполнителя должна быть в очень тесном контакте с заказчиком. Любой продукт, который делается по технологии Agile, должен делаться совместно с заказчиком. Тестирование интерфейса, разработка – все совместно с ним. Идеальный Agile продукт – когда исполнитель сидит на территории заказчика.
Есть также Scrummaster. Это может быть некий руководитель проекта либо его организатор. Это может быть девушка обаятельная, которая будет заниматься организацией процесса. В принципе технология позволяет вести разработку и без руководителя. При этом команда должна быть автономна и должна постоянно взаимодействовать с заказчиком.
Кроме того, есть прочие исполнители. Дело в том, что программисты – такие люди, которые не всегда могут контактировать с заказчиками, поэтому в команде есть разработчики, которые на втором плане. Это не значит, что они совершенно не контактируют и не видели заказчика. Но программиста нужно показывать заказчику, ему нужно присутствовать при сдаче работ. Это заряжает некой атмосферой, и человек понимает, что одно дело – сдавать работу своему консультанту, с которым они вместе пьют кофе в офисе, и другое – когда работу принимает заказчик. И тогда человек понимает, что нужно заказчику, какие у него требования.
Как происходит закрытие спринта?
Есть такое понятие, как митинги или летучки. Они проводятся с определённой частотой – желательно каждый день или раз в два дня.
Когда стартует спринт, есть задачи в планах, которые надо сделать до окончания спринта. И задача проектной команды – сделать так, чтобы по окончании спринта все они были завершены. В нашей компании к этому привязана схема мотивации, и если к концу спринта завершены все задачи, проектная команда получает бонус. Если хотя бы один стикер завис, никто ничего не получает. Таким образом, участники заинтересованы помогать друг другу. Работают даже по пятницам и выходным, но закрывают все задачи. Только тогда все будут в выигрыше.
Цели митинга:
- разобрать новые задачи;
- распределить, кто и что делает;
- разобраться с зависшими стикерами, которые остались в процессе.
Идеальное время проведения митинга – не более 10-15 минут. Если митинг затягивается, что-то идет не так. Если полчаса или час – это уже нелепое совещание по непонятному вопросу. Если появилась какая-то проблема, которая требует обсуждения на проекте, например, техническая сложность, тогда надо отдельно садиться и обсуждать.
Очень важно – проектная команда должна быть разношёрстной. Не должно быть такого, что один отвечает толькоза конвертацию, другой – только за интерфейсы, третий – знает только SCD. Должна быть взаимозаменяемость, и очень важно контролировать, чтобы специалисту доставались всегда разные задачи. Да, он потратит на это больше времени, но если один человек уйдет в отпуск или уволится, всегда будет тот, кто сможет его заменить. Он будет реально в теме, будет понимать, что происходит в проекте и на техническом уровне. Это очень важно.
Самый прекрасный митинг – это когда на нем присутствует заказчик. Пусть не каждый день, но 1-2 раза в неделю он должен быть. Заказчик будет видеть, как идет процесс, он сможет оперативно и динамически влиять. Он также будет видеть, что есть какой-то результат, и команде будет удобно. Это могут быть встречи по скайпу, необязательно приезжать, но приглашать и настаивать на участии заказчика необходимо.
Как сдается спринт?
Спринт – это не просто набор незавершённого решения. Мы там что-то наделали, и это получился результат. Это определенный и совершенно конкретный результат, например, завершенный какой-то образ, какая-то обработка или половина обработки, где будет одна закладка и какая-то форма.
Спринт обязательно подлежит сдаче и оплате. И с заказчиком это согласовывается еще на стадии обсуждения и проектирования.
Как же мы сдаем работы? Кто является ключевыми фигурами?
Мы выделяем три ключевые роли со стороны заказчика:
- Лицо, которое будет эксплуатировать, конечный пользователь или его руководитель. Контакт с этими людьми должен быть постоянным.
- Лицо, которое отвечает за приемку работ. Когда вы беретесь за какую-то часть работы, важно понимать, как и кем она будет приниматься. С этим лицом надо контактировать хотя бы раз в 1-2 недели, потому что спринт надо сдавать ему, этот человек будет подписывать акт о выполнении этапа работ.
- Лицо, которое платит. Это может быть инвестор, акционер, человек, деньги которого непосредственно тратятся. Он может быть далек от проекта, но очень важно с ним поддерживать связь, пусть даже кофе попить. Ведь когда он платит, ему важно понимать, за что он платит. И на этом этапе всегда важно поддержать контакт. Зашли раз в полмесяца/месяц, рассказали, как идут дела на проекте. Обязательно надо сделать акцент на результат, что получили – подсистему, документ. Быстро и коротко. Чтобы человек знал, куда идут его деньги.
Учет рабочего времени
Поскольку мы говорим про 1С, а это сфера, где работают программисты и консультанты, нашим продуктом является наше время. Есть то время, которое мы получили при планировании задач, – это так называемое инвойсное время, инвойсные часы. И есть то, которое фактически потрачено.
Бывает, что оценили задачу в 10 часов, а потратили на нее 200 часов. Очень важно разобраться, почему это произошло: мы недооценили или эффективность сотрудников слишком низкая. Тайм-менеджмент в нашей компании сводится с детализацией отчетов до 15 минут. Мы заполняем ежедневно отчеты и понимаем, чем занимался человек. Кроме того, у нас есть отчеты по эффективности, которые позволяют оценить и каждый проект, и каждого сотрудника.
Мотивация в проектах Agile
Существует множество способов мотивации. Но программисты – не продавцы, мотивировать полной сдельщиной их не получается. У них мотивация внутри, они должны понимать, зачем что-то делают. Кроме того, если им интересно – они делают, неинтересно – не делают.
Но если вспомнить пирамиду Маслоу, то в основе всего лежит безопасность. То есть человек должен понимать, что он гарантированно получит свои минимальные необходимые деньги. У нас как при советском союзе: есть планы, есть категории сотрудников, которые делятся по уровням в отношении инвойсных часов.
Что такое план – это количество часов, закрываемых за календарный месяц по проектам или оценкам. Этот план зависит от количества рабочих часов в месяце и градации специалиста. Например, специалист 4 категории из 180 часов должен отработать 80 или 40 часов, а программист первой категории – например, 120.
Исходя из планов и отчетов сотрудников, мы можем посчитатьфактически отработанное время. Есть непосредственно окладная часть – она привязана к категории и составляет примерно 60% дохода. Остальная часть строится, исходя из закрытых часов. Если сотрудник выполняет план или перевыполняет, он получает премиальную часть. Таким образом, вся команда замотивирована и работает не только на процесс, но и на закрытие максимального количества задач за адекватное время.
В нашей компании еще есть схема мотивации, завязанная на своевременное закрытие спринтов. Таким образом, мы закрыли 2 проблемы: 1 – работоспособность и эффективность людей, которые понимают, на что они работают, а 2 – соблюдение сроков, которые очень часто срываются.
Гарантийные работы
Гарантийные работы есть непосредственно как у самой проектной команды, так и достаются ей в наследие. Что с ними делать? При нашей схеме разработки и мотивации делать гарантийные работы неинтересно никому, потому что за них не платят. Одно дело – баги, которые пришли к нам в результате наших деяний, а другое – которые пришли от прошлых команд программистов, которые, возможно, у нас даже не работают уже. Такие работы скидываются обычно на какого-нибудь новичка.
Но мы решили сделать иначе. Мы включили баги всех спринтов в состав спринта. Это такой же стикер. Если спринт не закрыт полностью, команда не получает ничего.
Кроме того, в нашей компании есть планы по гарантии. То есть каждый сотрудник должен, помимо плана по инвойсным часам, выполнять еще гарантийные работы. Допустим, Вася должен сделать 40 гарантийных часов и столько же Петя. Если они этого не сделают, это скажется на окладной части. Таким образом, сотрудник замотивирован решать и делать гарантийные работы.
Достоинства и недостатки технологии Agile
Достоинства:
- Минимальный риск за счет поэтапной приемки.
Цена риска – всегда один спринт. Когда мы делаем по какому-то договору большой проект по ТЗ, мы понимаем, что если вдруг не сдадим работы, что-то поменяется, заказчик обанкротится, появится новый руководитель, нам деньги не заплатят, и проект завалится. В нашем случае всегда цена риска – один спринт. Мы можем его оценить в денежном эквиваленте. Например, если наш риск 200 тысяч рублей, то мы точно знаем, что больше мы не потеряем. Многие компании любят брать аванс – 50% и дальше работать, делать проект, а по его окончании – получают вторую часть. Но если будут какие-то перемены, то они потеряют именно 50%. У нас риск минимизирован. Главное понимать конкретную сумму, и быть готовым к такой потере.
- Прозрачный результат для всех сторон.
Для заказчика преимущество – он платит не за документы, не за процесс, он получает результат. Он его видит и может его потрогать. Очень хорошо построена система тогда, когда ее можно запускать в эксплуатацию поэтапно. Допустим, у нас есть связанные блоки. Мы не можем запустить отдельно закупки, продажи и склад, поскольку цифры не будут складываться. А если есть возможность разработать технологию интеграции существующей системы, тогда можно запускать ее кусками. И таким образом один спринт может быть запуск блока продаж. Без каких-то бантиков и рюшечек, но получили сразу результат. Заказчик заплатил и получил. Получил через месяц, пусть без идеала, но уже работает.
Если говорить про долгосрочное планирование, зачастую любой бизнес развивается гораздо быстрее, и любое ТЗ устареет за то время, пока система выйдет в релиз и будет разработана. Поэтому система должна быть гибкой, легко настраиваемой и должна меняться вместе с заказчиком.
- Минимальные сроки.
Действительно, через месяц мы можем уже получить какое-то решение. На многих существующих проектах – что в принципе большое преимущество 1С – можно получить что-то очень быстро, например, какой-то отчет. Но тут еще технология запуска системы и ее ход такой, что мы можем получить существенно быстро результат, например, через месяц люди уже могут работать – документы делать, отчетность получать. Идем сразу на результат. И заказчик это видит. И сроки минимальные, а сроки – это деньги.
- Нацеленность команды на результат.
Команда видит короткий спринт. У них нет долгосрочной перспективы, например, через два года закрыть проект. И вообще, что значит «проект закрыт»? Когда заканчивается один этап, начинается другой. Или идет развитие системы, перестроение. Заказчики, у которых мы работали несколько лет назад, до сих пор системы развивают, делают новые блоки. В некоторых ситуациях заказчики спрашивают, когда ваша система заработает? Она никогда не заработает, потому что исполнитель все время ее дорабатывает. Иначе компания закроется, бизнеса больше не будет. Всегда будут придумываться новые блоки, новые процессы, новые виды. В нашем случае короткая итерация, команда видит, как закрывается итерация, и получает результат.
Недостатки:
- Отсутствие бюджета на полный проект.
Когда заказчик задает вопрос, сколько денег надо, чтобы полностью закрыть проект, ответа на этот вопрос нет. Это постоянная статья затрат для собственника, если он решил внедрить у себя новый продукт. Мы можем назвать порядок цен, мы понимаем границы, коридор – от и до. Мы понимаем, что позже будет развитие, поддержка, но далеко не всегда это понимает заказчик. И это является недостатком.
- Расход времени на проведение митингов.
Митинги, которые проводятся ежедневно, собирают всю команду. Даже если брать митинг длительностью 15 минут плюс кофе-брэйк, все равно команда тратит время. Иногда неэффективно. Трата времени есть, если например, сидим, объясняем задачу для одного человека, а слушают еще 4. Но в то же время это является плюсом, потому что члены команды взаимозаменяемы.
Резюме
Очень важно помнить: в Agile мы работаем на результат, а не на процесс. Результат виден с первых ступеней, и вся работа исполнителя завязана на то, чтобы как можно плотнее сотрудничать с заказчиком и быстро получить результат.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.
