Agile-методологии в разработке программного обеспечения: как повысить эффективность и скорость проектов

Agile-методологии в разработке программного обеспечения: как повысить эффективность и скорость проектов

Agile — итеративная модель разработки, в которой программное обеспечение создают пошагово с самого начала проекта, в отличии от каскадных моделей, где код доставляется в конце рабочего цикла. Основа гибкой методологии — разбиение проектов на маленькие рабочие кусочки, называемые пользовательскими историями. Согласно приоритетности задачи решают в рамках коротких двухнедельных циклов (итераций).

Существует несколько Agile-методологий. Расскажем вам о некоторых, чтобы вы могли найти для себя подходящую.

Начнём со Scrum.

Scrum — это способ организации рабочего процесса. Он пришёл из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришёл из регби и в переводе с английского означает “схватка”.

Scrum принадлежит к Аgile — семейству “гибких” подходов к организации процессов. Он состоит из минимального количества элементов, которые помогают успешно организовать работу. При помощи метода Scrum можно быстро и эффективно разработать принципиально новый продукт, аналогов которому нет на рынке.

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

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

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

Kanban. 

Первоначально Kanban — это система организации работы на производстве, которая появилась в конце 50-х годов в Японии. Мастера, ответственные за разные этапы производства, крепили на общую доску карточки с работами, которые нужно было выполнить. Сейчас, говоря о Kanban, чаще подразумевают гибкую методологию для управления задачами в IT-сфере, например, в командах разработки, службы поддержки, производства контента.

Kanban помогает управлять непрерывным потоком задач, визуализировать рабочий процесс, контролировать соблюдение соглашений между заказчиком услуг и исполнителями (от англ. SLA, Service Level Agreement).

Обязательный элемент гибкой методологии (как Scrum, так и Kanban) — доска. Подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы вроде Trello. Kanban-доска подстраивается под любой процесс и применяется в любой области. Например, чтобы составить список дел. 

У каждого проекта есть план процесса работ. Сначала мы его анализируем и разделяем доску на столбцы, которые отражают этапы. Имена столбцов меняются в зависимости от проекта, но важно сохранять их последовательность ― это ключевая ценность Kanban, которую называют потоком. Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски. C помощью kanban-доски легко вести несколько проектов одновременно, используя карточки разных цветов: один цвет ― один проект.

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

Экстремальное программирование (XP). Говорят, оно не для слабонервных.

Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile-методологий, у нее есть особенные инструменты, процессы и роли. XP отличается от других гибких методологий тем, что применимо только в области разработки программного обеспечения. Оно не может быть использовано в другом бизнесе или повседневной жизни, как scrum или kanban. Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. Поэтому XP хорошо подходит для сложных и неопределенных проектов. 

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

В XP — 13 практик. 

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

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

Частые релизы версий. В XP версии выпускаются часто, но с небольшим функционалом.

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

Коллективное владение кодом. В XP любой разработчик может править любой кусок кода, т.к. код не закреплен за своим автором. Кодом владеет вся команда.

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

Когда кодом владеют все, важно принять единые стандарты оформления, чтобы код выглядел так, как будто он написан одним профессионалом. Можно выработать свои стандарты или принять готовые.

Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.

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

Разработка, основанная на тестировании. Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%.

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

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

Рефакторинг — это процесс постоянного улучшения дизайна системы, чтобы привести его в соответствие новым требованиям. Рефакторинг включает удаление дублей кода, повышение связности и снижение сопряжения. XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.

Для разработки программного обеспечения важно создать backlog — список требований к продукту. Чем он подробнее, тем эффективнее будет организована работа команды. 

Работу с бэклогом стоит начинать со “скелета” — базовых функций, которые должны присутствовать в продукте. Здесь будет полезен план развития — верхнеуровневый стратегический план, в котором отражено направление разработки вашего продукта. В идеале — со сроками реализации.. Детализировать задачи можно с помощью User Stories — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей. На основе User Stories строится Customer Journey Map — визуализированный опыт пользователя продукта с учётом его целей, эмоций, барьеров, мотивов. Карта составляется под определённую User Story, отражает путь клиента к продукту, показывает “узкие места”, даёт понять, над какими этапами и метриками нужно работать в первую очередь. 

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

Чтобы проще поделить одну большую задачу на серию маленьких, можно использовать скрам-покер или покер планирования. Это гибкая техника, которая позволяет на основе коллегиальности (консенсуса) чётко оценить сложность и объём задач, которые предстоит решить в ходе создания программного продукта. При этом к оценке привлекают всех: программистов, команду тестеров, инженеров баз данных, аналитиков, дизайнеров и всех других сотрудников, участвующих в проекте. Поскольку эти члены команды очень разнообразны, такой подход позволяет добиться действительно разносторонней и, по факту, объективной оценки.

Принципы Покер планирования: каждый из присутствующих получает набор карт, на которых есть цифры-баллы (либо числа Фибоначчи 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, либо альтернатива — 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, знак вопроса «?» (им обозначается неуверенность участника), иконка чашки или пивного бокала (намек на то, что надо сделать паузу). Ещё используется знак бесконечности (∞). При этом числа могут служить обозначением дней, часов и прочего.

Закономерность чисел на картах, независимо от того, какой ряд выбран, сводится к следующему: 0 — задача настолько проста или настолько близка к завершению, что нет смысла выделять ей место в плане, 1-3 — мелкие задачи, 5-13 — задачи средней сложности, 20-40 — крупные задачи, 100 — глобальная задача, ∞ — эпохальная по масштабности и важности задача.

Заказчик озвучивает вводные, при необходимости отвечает на уточняющие вопросы участников. После обдумывания все участники выбирают карту, соответствующую их оценке задачи, и кладут её на стол рубашкой вверх. Карты открываются, оценки становятся достоянием команды.

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

Ежедневно проводите митинги — Standup. Они важны для обмена информацией, устранения преград и поддержания взаимодействия. Стендап важен, потому что на нём команда определяет цель и план на день. Готовится к работе, подводит итоги прошедшего рабочего дня. Члены команды делятся рабочей информацией, которая может пригодиться каждому. 

У стендапа есть десять правил, которые важно неукоснительно соблюдать. В противном случае встреча превратится в болтологию и не принесёт полезного эффекта. Итак: 

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

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

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

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

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

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

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

Важно задавать цели себе на день — это очень хороший способ мотивировать себя.

На первых порах лучше всего иметь “тёмного модератора” — человека, который разрулит невыгодную или рискованную ситуацию.

После того, как последний человек рассказал всё, что хотел, следует модератору или последнему всех поблагодарить за стендап.

Используйте Kanban-доску для лучшего понимания последовательности и приоритетности задач. 

Её преимущества: 

- визуализация рабочего процесса;

- ограничение работы, которая находится в процессе;

- перемещение задач от колонки к колонке;

- мониторинг, адаптация и оптимизация.

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

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

Практика ретроспектив. Это активность, которую каждая agile-команда проводит, чтобы решать свои проблемы. Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет. В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к её окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. 

Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan. Задача ведущего – привести команду в процессе ретроспективы к конкретному плану. План – это одно из двух: либо действия, либо новая договорённость. Все, к чему ретроспектива сводится – это список действий, которые надо совершить, и договорённостей, которых нужно придерживаться.

Agile — подход к управлению проектами и разработке программного обеспечения, который помогает быстрее создавать качественные продукты и правильно развивать их. Такой результат становится возможным благодаря гибкости рабочих процессов и эффективному взаимодействию всех заинтересованных лиц: клиентов, заказчиков и команды проекта. Agile-подход позволяет более гибко реагировать на изменения в требованиях и обстоятельствах. Он позволяет быстрее проверять гипотезы и сверяться на промежуточных этапах с заказчиками. А если что-то меняется, то подстраивать под эти изменения планы и приоритеты. Гибкость и адаптивность, эффективность и простота — ключевые особенности Agile‑подхода. Включение заказчика в процесс разработки, постоянная обратная связь и демонстрации продукта способствуют высокому качеству. Но и темп тоже важен, ведь если слишком долго работать над проектом и постоянно переносить запуск, то может закончиться терпение заказчиков или финансирование.

Для управления Agile-проектами нужно правильно подобрать инструменты. Вот некоторые из них: 

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

Trello — простая альтернатива Asana. Здесь основное внимание уделяется доскам Канбан и, соответственно, управлению задачами. Если необходимо командное общение через платформу, можно интегрировать, например, программу Slack.

Jira. Метод управления проектами "Экстремальное программирование" нашел подходящий инструмент в Jira. Jira берёт свое начало в разработке программного обеспечения и в первую очередь делает акцент на пользовательском опыте для разработчиков. Набор функций велик, что может привести к длительному периоду ознакомления, но также открывает множество возможностей.

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