Agile-технологии и их применение в проектах 1С

1C_ARENDA%20PROGRAMM_logo_v2_red.png

Цель нашей компании - предложение качественных локализованных ERP-решений и проектных услуг по внедрению управленческого, бухгалтерского и налогового учета

Наша статья расскажет, как используется методика ведения проектов Agile в 1С.

Agile: что это такое?

Agile – одна из методик ведения проектов, особенностями которой является интерактивность и поэтапное завершение. Процесс создания нужного нам продукта состоит из нескольких этапов – спринтов. Временной интервал, отведенный для каждого спринта, разный, в среднем это 2-3 недели.

Спринт – тот промежуток времени, отведенный на получение какого-либо результата, который предоставляем заказчику.

Заключение контрактов

Проекты Agile не предполагают постановку технического задания и определения каких-либо перспектив. Отношения с заказчиком построены на следующем принципе: есть общая цель, которую нужно достичь. Поэтому в договор вносится раздел «Цели», и прежде чем начинать работу над проектом, команда разработчиков их прописывает.

Формулировать цели нужно грамотно и конкретно. Например, «автоматизировать работу какого-либо подразделения» – неправильно сформулированная цель, а вот «получить структуру отчета по себестоимости» еще и с «визуальным представлением» – это грамотно поставленная цель. Клиент должен понимать и видеть, что в результате должно получиться, с чем ему дальше нужно будет работать. То есть цель должна быть не только правильно поставлена, но и визуально представлена заказчику.

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

Создание проекта по Agile

Методология Agile не предполагает написания технического задания. Объясняется это просто: нет смысла исписывать сотни листов бумаги, так как техническое задание как таковое нигде потом не применяется. Техническое задание требуют государственные учреждения, которым необходимо отчитываться за потраченные денежные средства.

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

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

Оценивание работы

Когда готов список задач, целей работы над предстоящим проектом, возникает необходимость это оценить. Но как, если методик определения стоимости работ много, какая из них будет оптимальной? Можно определить стоимость работы, исходя из количества часов, потраченных на реализацию проекта. Или, ориентируясь на запросы и возможности заказчика, попытаться «раскрутить» его на высокооплачиваемый заказ.

В Agile применяется технология Agile Planning Poker, которая, кстати, применяется не только в Agile, и не только для оценки.

https://infostart.ru/upload/iblock/0dd/0dd724f433f0a297b38fd3e54521777f.jpg

Поясним, как она работает. Каждый участник команды обеспечивается колодой карт с цифрами. Для начала подсчитывается, сколько часов необходимо потратить, чтобы выполнить работу. Затем карты кладут рубашкой вверх, программисты берут по одной и вскрывают. Максимальная оценка берется в том случае, если разбежка в количестве часов не превышает 10-20%. Если разница превышает 20%, значит, оценка сильно отличается. В этом случае необходимо организовать обсуждение, в ходе которого выясняется, кто из специалистов был прав. Как правило, этот тот, кто отвел на выполнение работы больше времени. Однако в некоторых случаях прав тот, кто запланировал мало часов. Эта ситуация вероятна тогда, когда программист знает, что есть готовое решение, которое значительно сэкономит время разработки. За этапом обсуждения следует переоценка.

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

Составление сметы

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

Составление плана-графика

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

Более мелкий план, в котором прорисованы детали, называется спринт.

Спринт

Спринты составляются на срок от 2 до 4 недель и представляют собой список задач, запланированных на этот период. Список задач фиксированный, менять их нежелательно. Так как команда должна понимать, что все поставленные задачи должны быть выполнены к определенному сроку. Это мотивирует и дисциплинирует разработчиков. Спринт может быть изменен лишь в форс-мажорных условиях, к примеру, при смене руководителя проекта.

Что главное в проекте? Хорошо подобранная команда

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

Команда состоит из четырех компонентов, два из которых являются обязательными, а два – нет. Без заказчика и ведущего программиста работа над проектом невозможна, а вот без руководителя проекта и исполнителей в лице программистов и консультантов – вполне. Расскажем подробнее о каждом из участников.

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

Еще одна незаменимая фигура – ведущий программист, или архитектор. Этот тот, кто непосредственно занимается разработкой проекта. Одна из его задач – тесное сотрудничество с командой заказчика по вопросам разработки продукта. Тестирование, внесение изменений должно быть согласовано с заказчиком и проводится совместно с ним. В идеальном варианте Agile исполнитель должен находиться на территории заказчика.

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

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

Как закрывается спринт

Спринт сопровождается летучками, которые проводятся раз в один-два дня. Главная задача спринта – к назначенному времени успеть выполнить все поставленные задачи. В некоторых компаниях к спринту привязана система мотивации, то есть, если к концу спринта были решены все задачи, команда получает премии. Если хотя бы один из разработчиков не справился, премии не получает никто, даже тот, кто работал безупречно. Таким образом, членам команды нужно помогать друг другу, чтобы в итоге все получили свои бонусы. Чтобы определить, кто оказался в отстающих и кому нужна помощь, проводятся митинги. Зачастую разработчики проводят вечера и выходные дни в офисе, чтобы выполнить в срок требуемые задачи.

Правила проведения митинга

  •  Митинг не должен превышать 10-15 минут. Следует четко ограничивать время, чтобы задавались конкретные вопросы. Если митинг затягивается больше чем на 20 минут, значит что-то идет не так. Если на митинге была обнаружена проблема, поиск решения которой займет много времени, нужно организовать отдельную встречу.
  •  Члены команды должны быть универсальными специалистами. Если разработчик умеет разрабатывать только интерфейсы, то он явно не подходит для работы с Agile. Для проекта важно, чтобы члены команды могли заменить друг друга в случае необходимости. Поэтому нужно поручать разработчикам выполнение разнообразных задач. Да, он потратит больше времени, чем профи в этой области. Но, если кто-то уйдет на больничный или уволится, работа над проектом будет продолжаться.
  •  Присутствие заказчика. Тесный контакт с заказчиком необходим, чтобы он был в курсе, как продвигается работа. Клиенту необязательно посещать офис, можно организовать встречи онлайн.

Презентация спринта

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

Спринт должен быть принят клиентом и оплачен. Об этом заказчик и исполнитель договариваются на стадии подписания договора.

Кто участвует в операции сдачи-приемки спринта?

Со стороны заказчика выступают три представителя.

  1.  Тот, кто будет непосредственно эксплуатировать продукт – конечный потребитель или руководитель. С этими лица должен быть налажен тесный контакт.
  2.  Тот, кто отвечает за приемку спринта. С этим человеком или командой также нужно налаживать контакт, так как именно они будут принимать работу и подписывать акт о выполненном этапе.
  3.  Тот, кто платит, – акционер, инвестор. С ним тоже нужно поддерживать связь, хотя бы изредка. Ведь на проект тратятся его деньги, и человек должен знать и понимать, за что он платит. Достаточно одной встречи в месяц, в ходе которой коротко и ясно рассказывается о результатах работы над проектом.

Учет рабочего времени

Что самое важное в работе программиста? Правильно, время. Время программистов можно условно разделить на инвойсное, которое получили при планировании, и реально потраченное.

И если при запланированных на работу 10 часах реально потраченных получилось 100, то стоит разобраться, была неправильно проведена оценка времени или эффективность сотрудников невелика. Важно каждый день проводить тайм-менеджменты. Они занимают не более 15 минут, зато позволяют проверить, чем заняты члены команды. А заполняемые каждый день отчеты позволяют контролировать эффективность каждого члена команды и проект в целом.

Мотивация

Для того чтобы что-то делать, человеку нужна мотивация, как внешняя, так и внутренняя. В основе пирамиды потребностей Маслоу – безопасность. То есть одним из способов мотивации будет оплата. В проектах Agile есть план – то количество часов, которая закрывается в конце месяца. План зависит как от количества рабочих часов, так и от градации сотрудника. К примеру, из 180 рабочих часов специалист 3 категории должен отработать 60 часов, а программист первой категории – 100. Благодаря отчетам, предоставляемым сотрудниками, считаем фактически отработанное каждым из них время. От заработной платы 60% составляет оклад, 40% – это премии, которые получает сотрудник в зависимости от того, как эффективно был выполнен план. То есть у сотрудника есть мотив – выполнить или перевыполнить план. В этом случае в выигрыше остается и компания, так как члены команды работают не только над процессом, но и стараются выполнить максимальное количество задач за минимальное время.

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

Работы по гарантии

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

Для того чтобы мотивировать работников, можно включить гарантийные работы в спринт. Если к концу спринта баги не будут закрыты, команда не получит премии. Кроме этого, можно ввести планы по гарантии, то есть включать в планы гарантийные работы. Каждый из членов команды обязан выполнить определенное количество часов гарантийных работ. Если они выполнены не будут, это отразится на заработной плате сотрудника. Отличная мотивация, верно?

Преимущества технологии Agile

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

Прозрачный результат

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

Преимущество спринтов перед долгосрочным планированием заключается в том, что требования, изначально предъявляемые к системе, устаревают за время разработки ТЗ. В Agile есть возможность корректировать и вносить изменения в систему после каждого спринта.

Сжатые сроки

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

Нацеленность членов команды на результат

В отсутствии долгосрочной перспективы есть свои плюсы. Команда видит цель на предстоящий спринт и идет к ней, зная, что работа будет оплачена. Кроме этого, в Agile нет такого понятия, как проект закрыт. Система постоянно дорабатывается, дополняется отдельными блоками. Бизнес и производство постоянно меняются и развиваются, понятно, что невозможно создать систему, которая будет актуальна всегда. Нужно постоянно следить за обновлениями, быть в курсе всех изменений и вносить корректировки в функционирующую систему.

Недостатки технологии Agile

Нет бюджета на полный проект

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

Затраченное на митинги время

Ежедневно команда собирается на митинги. Даже если они занимают 15 минут, тратится драгоценное время, иногда неэффективно.

Вывод

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


Вернуться к списку