Система разработки Эджайл и ее применение в naimi.kz

0
729
kanban-board

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

     На сегодняшний день основными моделями разработки ПО являются:

  1. Каскадная (waterfall – водопад) – модель, при которой необходимо последовательно следовать алгоритму одного цикла.
  2. Эджайл – в данной модели алгоритм выполняется параллельно с анализом фидбэка и ошибок, что дает возможность вносить изменения во время цикла.

     Недостаток каскадной модели в том, что за время осуществления одного цикла, рынок может изменить ожидания к данному продукту. Однако, данная модель до сих пор используется в таких направлениях, как медицина, где нет возможности постоянно тестировать продукт. 
     В феврале 2001 года, 17 практиков разных методов программирования создали Эджайл Альянс. На этой же встрече участники Альянса разработали Эджайл Манифест – документ, описывающий ценности и принципы Эджайл мувмента. В Манифесте определены 4 ценности:

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

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


Нравится материал? Подпишись!

     Эджайл состоит из 5-ти этапов:
  1. Анализ требований – на этой стадии команды анализируют характер рынка, свой продукт и выявляют недостатки. Затем определяют, что от них требуется для усовершенствования.
  2. Разработка прототипа – на этой стадии формулируется техническое задание и команда приступает к проектированию.
  3. Демонстрация и фидбэк – после того, как первый прототип готов, его демонстрируют клиентам и получают конструктивный фидбэк
  4. Определение дефектов и исправление ошибок – полученный фидбэк задает направление дальнейшей разработке
  5. Производство и техническая поддержка – на этой стадии выпускается конечный продукт и разрабатывается план поддержки на случай возникновения ошибок в системе.
     Чтобы лучше понять применение Эджайл, мы поговорили с Уланом Каирбековым, со-основателем naimi.kz:

     “Разработка в Эджайл происходит пошагово, и по окончанию каждого шага мы получаем готовый, но не конечный, продукт. К примеру, нам нужно создать автомобиль. По эджайлу сначала будет создан самокат, затем велосипед, потом мотоцикл, и в конечном итоге, путем множества итераций мы создаем автомобиль. В каскадной же модели автомобиль будет собран по частям: колесо → кузов → интерьер(дизайн)→имплементация. То есть, в каскадной модели нет возможности сделать шаг назад и внести коррективы, придется переделывать с самого начала.
     Во время учебы в Сингапуре мы изучали Эджайл, но тогда я не придавал значения получаемой информацие. По приезде в Казахстан я начал работу в портале электронного правительства. Там же я и впервые столкнулся с Эджайлом на практике. Наша команда работала с одним из фрэймворков Эджайла – Скрам, в котором одна большая задача разбивается на временные рамки – Спринты. Каждое утро начиналось со стэнд-ап собрания продакт менеджера, где мы обсуждали:

  • Чем занимались вчера
  • Чем займемся сегодня
  • Какие возникли проблемы

     В самом начале команда naimi.kz состояла из 3-ех человек. Мы сразу решили, что будем заниматься продвижением по Скрам Эджайлу. Было трудно тренировать команду, т.к не все понимали важность данного метода. Однако, теперь Скрам является одной из составляющих нашей компании. Весь наш год расписан по 2-ух недельным Спринтам. Наши сотрудники даже в отпуск уходят согласно началу и концу Спринтов (смеется).
     Для реализации Скрама назначаются продакт оунер (это я), Скрам мастер (наш CTO) и команда. В начале каждого Спринта мы определяем задачи на 2 недели и по приоритетности назначаем баллы каждой из них. В течение этих 2-ух недель Скрам мастер и команда встречаются каждое утро на стэнд-ап митингах уже без моего участия. И если они понимают, что 2-ух недель не хватает для полной реализации Спринта, то задачи с наименьшим количеством баллов переносятся на следующий. Однако, такая нехватка времени говорит о том, что мы создали неправильный план с самого начала, ведь на Демо Дэй по окончанию 2-ух недель должен быть готов самостоятельный продукт. К примеру, мы хотели, чтобы наши юзеры могли авторизоваться на naimi.kz через соц. сети. После первого Спринта по соц.сетям у нас была разработана версия фэйсбук авторизации, которую мы сразу запустили на сайте и в приложении. После того, как продукт запущен, мы проводим ретроспективу, где каждый дает фидбэк о прошедшем Спринте. Таким образом, мы улучшаем эффективность работы команды”.
Scrum methodology at naimi.kz

     Бывает ли такое, что Эджайл не сработал?

     “Конечно, и это происходит из-за неправильной имплементации. К примеру, я как продакт оунер не должен вмешиваться в процесс реализации Спринта. Однако, бывает так, что так и хочется добавить пару новых задач. В такие моменты Скрам мастер должен оценить важность этих задач. Если они очень срочные и без их имплементации Спринт невозможен, то мы останавливаем процесс”.

     Как формируются задачи для каждого Спринта?

     “Мы формируем growth team, в которую входят все ключевые разработчики. На встречах с этой командой мы брэйнштормим новые идеи, отбираем топ 3 и проводим тесты. К примеру, мы заметили, что на нашей платформе появилось много специалистов, которые не ознакомлены с правилами нашего сервиса. Нашей гипотезой-решением стало внедрение тестов на знание правил naimi.kz. Но прежде, чем сразу устанавливать данную функцию на сайте и в приложении, мы протестировали ее по гугл документу и пришли к выводу, что это действительно эффективно. А уже после, функция тестирования вошла в нашу систему”.

“Скрам учит нас системности – мы наглядно видим все

изменения и  результат проделанной работы”.

     Вдобавок, к Скраму, Эджайл имеет еще один фрэймворк – Kanban(от японского карта).  Kanban используется в случаях необходимости наглядной информация о количестве инвентаря, производства, времени и сотрудников. Этот фрэймворк был впервые применен компанией Toyota в 1940 году, когда инженеры писали на доске в каком из складов есть свободное место для загрузки нового инвентаря. Сегодня же разработчики указывают на Kanban Board-е какая команда готова принять следующий поток работы.
     При правильной имплементации Эджайл является самым эффективным методом разработки ПО. Его можно “подогнать” под требования вашей компании, следуя подходящему фрэймворку. Эджайл позволяет не только производить итерации за короткие промежутки времени, но и отслеживать на каком моменте была допущена ошибка, что повышает эффективность работы команд.