В эпоху бурного развития цифрового бизнеса высшее ИТ-руководство сильно озадачено адекватной его поддержкой: традиционные методы управления проектами и разработкой не подходят. Организации всё больше и больше обращают внимание на гибкие методологии разработки для ускорения своих проектов и демонстрации их ценности.
Компания Gartner сформулировала 10 основных принципов гибкой разработки. Предлагаем с ними ознакомиться.
1. Гибкая разработка – это не что-то одно-единственное.
Методологии гибкой разработки – это множество подходов к разработке ПО, в основе которых заложена общая философия. Однако, они довольно сильно различаются на уровне реализации. Как правило, их можно адаптировать для решения проблем разных типов.
2. Гибкая разработка – это не "надёргай-и-используй-вперемешку".
Подходы гибкой разработки являются высокосистематизированными. Каждый элемент того или иного подхода является неотъемлемым и критически важным. Довольно распространённая ошибка организаций – научиться использовать "спринт" (итерация, жёстко ограниченная по времени, например 2-6 недель, в ходе которой создаётся прирост функциональности разрабатываемого ПО), но при этом начисто игнорировать или понижать значение других элементов, например управление "техническим долгом" (метафора, используемая для обозначения затрат, которые так или иначе придётся понести из-за ошибок в коде, непродуманности структуры и архитектуры системы и т. д.).
3. Принятие гибкой разработки требует объединённых усилий – как со стороны ИТ, так и со стороны бизнеса.
Все преимущества гибкой разработки не могут быть обеспечены без вовлечённости со стороны руководителей бизнес-подразделений, высшего руководства и пользователей. Если оставшаяся часть бизнеса не склонна к работе по-новому, потребуется аккуратное планирование и выработка особых стилей взаимодействия, чтобы остаться "в одной лодке".
4. В гибкой разработке очень важно сначала "научиться ходить", а уже потом "пробовать бегать".
Опытные практики могут взяться за масштабные разработки – это сродни покорению Эвереста. Конечно, на выработку необходимых навыков могут потребоваться годы. Организации, только-только выбравшие для себя гибкую разработку, должны понимать, что обучаться скалолазанию нужно на небольших высотах и предгорьях, а уже потом переходить к более серъёзным вещам.
5. Принятие гибкой разработки – это принятие постоянного обучения.
Применение гибкой разработки предполагает, что её участники несут обязательства по постоянному улучшению качества и минимизации издержек, что означает, что каждая разработка анализируется на предмет полученных уроков. Усвоенный опыт используется для улучшения политик и рабочих практик.
6. Гибкая разработка – это про команды и команды команд.
Основной организационной единицей в гибкой разработке является небольшая команда, описываемая формулой "7 ± 2 человека". Это и разработка, и контроль качества. С точки зрения HR, необходимо уметь выдерживать тонкий баланс между сохранением единой команды специалистов и движением отдельных специалистов в другие команды для обогащения их новыми идеями.
7. Документирование, управление и уменьшение "технического долга" – основная концепция всех методологий гибкой разработки.
Любая разработка создаёт и "технический долг". Особенностью методологий гибкой разработки является выявление "долга" и добавление его в бэклог, а не заметание под коврик. Каждая организация, выбравшая гибкую разработку, должна ввести в действие необходимые элементы выбранной методологии, направленные на планомерную переработку исходного кода и уменьшение "технического долга".
8. Заказная гибкая разработка требует особого внимания.
Для гибкой разработки соседство с бизнес-пользователями является аксимой. Поэтому необходимо продумать, как это будет обеспечено – например, в виде присутствия дополнительных специалистов подрядчика по месту.
9. Влияние гибкой разработки распространяется за пределы только команд разработки.
Общим элементом всех методологий гибкой разработки является идея "непрерывной поставки" новых и изменённых компонентов в продуктивную среду. Это ведёт к существенным изменениям в практике работы как бизнес-руководства и управления взаимоотношениями, так и отделов ИТ-инфраструктуры и эксплуатации.
10. Другим методологиям разработки тоже найдётся место.
Методологии гибкой разработки "не лучше". Они просто лучше всего подходят для решения определённых проблем, и не так хорошо – для решения других.
