Философия рабочего процесса

4.1. Типы Agile-методологий и их распространенность

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

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

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

Рис. 4.1. Популярность Agile-практик, 2015 г.

Kanban

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

В основе Kanban лежат три базисных принципа:

• Визуализация (иероглиф "кан"). При иллюстрировании и моделировании процесса он разбивается на отдельные стадии (анализ, проектирование, разработка, тестирование и т. д.), упрощая таким образом его восприятие.
• Ограничение максимального количества задач на определенном этапе. Этот принцип позволяет свести потери к минимуму - максимальное сосредоточение на своих задачах.
• Оптимизация существующего процесса. Время на выполнение задачи отслеживается, анализируется, и вырабатываются предложения о том, как можно выполнить работу более совершенно. В процессе не должно быть простоев, равно как и не должна выполняться ненужная работа. Kanban характеризуется утверждением: "Уменьшение выполняющейся в данный момент работы". Данный тип методологии является, пожалуй, самым гибким. Это значит, что она является наиболее требовательной к условиям и ресурсам, в рамках которых предполагается ее эксплуатировать. Сотрудники, работающие по Kanban, должны быть готовы к экстремальной гибкости и при этом не должны ломаться.

Уникальность методологии Kanban, в сравнении с конкурентами по семейству Agile, состоит в:

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

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

Kanban ориентирована на задачи. Сотрудники работают над задачами с самого начала и до завершения. Рабочая команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени?

Lean

Этот тип методологии подразумевает создание продукта в условиях максимальной экономии ресурсов с целью устранения всех возможных потерь. Изначальный функционал продукта ограничивается до минимально полезного. Таким образом, функционал реализуется путем поэтапного наращивания функционала небольшими порциями, сродни инкрементальному принципу реализации информационных систем. Корни этого подхода относятся к принципам бережливого производства (Lean Manufacturing). Мэри и Том Поппендик, о которых было упомянуто в "Введение в Agile" курса, адаптировали эти принципы для разработки программного обеспечения:

• устранение потерь;
• повышение качества;
• создание знаний;
• отсроченные обязательства;
• быстрая поставка;
• уважение людей;
• полная оптимизация.

Lean постулирует отказ от всего, что не добавляет ценности создаваемой информационной системе. Разрабатывать необходимо только то, в чем есть абсолютная уверенность, что это нужно делать сейчас. Устранение потерь во всех аспектах работы (бесполезные собрания, избыточные задачи, документация, неэффективные способы работы и т. д.). Акцент на то, что называется "системным подходом", то есть сотрудники работают как единое целое, как команда. Необходимо верхнеуровневое осознание того, что выполняемая работа помогает повышать ценность создаваемого продукта, в сравнении с аналогами. Не нужно заставлять людей работать на 150% их рабочего времени. Не нужно кодировать то, что не нужно. Дополнительный функционал создает дополнительные обязательства для пользователей и руководства. Сотрудники нуждаются в уважении как личностном, так и профессиональном. Нужно давать им ту работу, которую они лучше всего знают, как надо сделать. Смысл программной разработки в постоянном обучении. Принятие управленческих решений нужно выполнять в последний возможный момент. К моменту реализации необходимого функционала сотрудники будут знать уже больше и лучше ориентироваться не только в создаваемой системе, но и в бизнес-процессах и данных организации.

Экстремальное программирование

Авторами этой методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер. Именно об этих людях мы говорили, когда в "Введение в Agile" делали историческое отступление об авторах Agile. Методология получила свое название благодаря воплощению идеи применить полезные классические методы и техники разработки программного обеспечения, подняв их на качественно новый "экстремальный" уровень. К примеру, этап ревизии кода, заключающийся в аудите одним программистом кода, написанного другим программистом, в "экстремальном" варианте представляет собой "парное программирование". Таким образом, мы получаем рабочий процесс, в ходе которого один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код. Через некоторое время они меняются ролями.

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

Последняя, оставшаяся к рассмотрению и, пожалуй, наиболее распространенная методология из семейства Agile - Scrum.

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

Scrum

В Scrum требования разбиваются на небольшие подгруппы, каждая из которых должна быть максимально независима от другой. Это делается для того, чтобы в течение каждого нового спринта (промежутка между выпуском новых версий продукта) команда разработчиков могла реализовать новый функционал. Scrum подразумевает постоянную коммуникацию - будь то планирование очередной итерации работ совместно с клиентом или ежедневный Scrum-митинг, в течение которого команда обсуждает ряд наиболее важных вопросов, ответы на которые непосредственно влияют на создаваемый программный продукт. Именно на примере описания и подробного рассмотрения Scrum в дальнейшем будет вестись речь о Agile.