Подробнее об agile методиках разработки программного обеспечения

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

Полное посвящение одному проекту

Мы, работая над проектом, на все 100% посвящаем себя только одному клиенту. Метод организации нашего рабочего процесса - парное программирование. Это означает, что в распоряжении клиента находятся одновременно четное количество человек (два, четыре или больше). Они не занимаются никакой другой работой во время пребывания в проекте и сосредоточены только на вопросах этого клиента. Основная причина — переключение между разными темами занимает много времени, а оно очень ценный ресурс в нашем мире.

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

Как гласит в Agile-манифест, «деловые люди и разработчики должны работать вместе каждый день на протяжении всего проекта».

Постоянное общение

На протяжении всего проекта мы находимся в постоянном контакте с клиентом: проводим еженедельные итеративные встречи, общаемся в Skype или в других средствах связи (Slack, Fleep и тд), обмениваемся электронной почтой. С нашими эстонскими клиентами итеративные встречи лицом к лицу проходят либо в офисе заказчика, либо у нас в конторе.

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

Итеративная встреча

Что мы делаем во время итеративных встреч? Во-первых, мы вживую демонстрируем работу, проделанную со времени последней встречи (обычно за неделю). Во-вторых, обсуждаем задачи для выполнения до следующей итеративной встречи и устанавливаем приоритеты.

В качестве основного информативного канала в рамках проекта мы используем Pivotal Tracker, куда записываем пользовательские истории (story), устанавливаем их приоритеты и отмечаем текущий статус (готово к тестированию, принято, отклонено и тд).

Пользовательские story формулируем на простом, понятном для всех языке, чтобы впоследствии облегчить проверку функциональности. Например, “пользователь может войти в систему” или “администратор может просматривать и изменять виды продукции” - легко проверить и подтвердить.

Storytelling

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

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

Изменения приветствуются

Благодаря итеративным встречам и ежедневному общению с клиентом, мы всегда готовы к изменению приоритетов. И практика показывает, что они могут часто меняться! Это может быть вызвано либо действиями конкурентов, либо генерацией лучших идей во время разработки или тестирования, либо обнаружением какой-то особенности в backend системе. Не важно, какая причина — мы всегда готовы к этому. Самое важное здесь — принимать решения совместно, с целью улучшения бизнеса клиента.

Непрерывное предоставление ПО

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

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

Быстрый запуск проекта

Одна из основных целей, к которой мы стремимся — выпустить продукт ограниченному числу пользователей и тестировать в реальной жизни то, что мы делаем. Например, для банковских клиентов мы предлагаем самим работникам (которых часто тысячи) самим начать пользоваться продуктом уже через четыре недели с начала разработки. Этот подход обеспечивает наиболее быструю и точную обратную связь. Ведь кто, как не работники банка, лучшие знатоки своего продукта? Более того, такой вид участия более тщательно готовит обслуживающий персонал для запуска продукта на рынок - ведь все уже с ним подробно ознакомлены.

MVP или минимальный жизнеспособный продукт

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

Передача знаний посредством сотрудничества

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

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

Agile-клиенты

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

• Владелец продукта, который знает потребности бизнеса в целом и организует контакты со специалистами для объяснения деталей продукта или бизнес-процесса. Является в максимально возможной доступности на протяжении всего проекта в качестве основной точки связи;

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

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

Обзор кода

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

Еженедельный TeX

Для регулярного обмена опытом внутри всего Codeborne, мы проводим еженедельный внутренний TeX или «technology exchange», где коллеги обмениваются информацией о веяниях в ИТ-мире, которые они либо уже использовали, либо просто где-то увидели и захотели изучить по-подробнее.

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

Ретроспектива

Для обучения по прошедшему и улучшения на будущих этапах, мы устраиваем в больших/долгих проектах ретроспективы, этакую разновидность «мозгового штурма». На этой встрече (лучше всего, вместе с клиентом) мы придерживаемся модели сохрани/измени/попробуй: сохрани то, что было хорошо, найди что изменить, чтобы принести пользу, попробуй претворить в жизнь новые идеи.

Для развития, в добавок к проектным ретроспективам, по крайней мере раз в год мы проводим подобные обзоры и для всей компании в целом