Цена отказа при разработке критически важных продуктов, по определению, очень высока. Применение гибких методов к разработке программного обеспечения и систем, которые их исполняют, помогает избежать ошибок, которые могут привести к отказу. Эти методы способствуют повышению качества продуктов, снижению затрат и сокращению времени их выпуска, а также большей предсказуемости результатов. Однако требуется некоторая настройка этих методов, чтобы они работали в этих сложных проектах с высокими требованиями. Гибкое управление, динамическое планирование, разработка, основанная на испытаниях, поэтапная разработка и эффективное управление рисками ― вот ключи к успешному применению методов гибкой разработки при создании критически важных систем.
Критически важные системы и гибкая разработка
От надежности критически важных системы зависит безопасность людей и материальных ценностей. Стоимость отказа таких систем может быть чрезвычайно высокой; они чреваты не только финансовыми потерями, но иногда и травмированием или даже гибелью людей. Применение и настройка гибких методов для целей их строгой и сложной разработки может способствовать предотвращению отказов, повышению качества, получению более предсказуемых результатов, сокращению времени выпуска и снижению стоимости. Предлагаемые пять советов можно использовать для совершенствования процессов гибкой разработки критически важных систем.
Под гибким управлением имеется в виду создание для группы разработчиков таких условий, в которых она может достигать своих целей, избегая препятствий, которые часто мешают при традиционном подходе к разработке. Идея в том, что группа определяет свои цели и способы их достижения. Однако наиболее важный шаг ― сделать так, чтобы проект действительно следовал этому решению. Затем нужно понять, что и как измерять и как реагировать на полученные результаты.
Многие регулируют не то, что действительно нужно, а то, что легко измерить. Гибкость не означает простоту; чтобы добиться успеха и избежать ошибок, нужно делать то, что имеет смысл. Нужно выбрать ключевые индикаторы производительности (KPI), которые коррелируют с вашем определением успеха, и затем последовательно использовать их для контроля качества и полноты. Одним из ключевых показателей эффективности может служить скорость реализации проекта , которая измеряет не только количество проделанной работы за единицу времени, но и количество полезной составляющей этой работы. Когда есть ключевые индикаторы производительности, их можно использовать для управления проектом . Таким образом, прозрачность и видимость хода работ чрезвычайно важны.
Совет 2: динамическое планирование
Гибкие методы ― это строгий, дисциплинированный подход к разработке систем и программного обеспечения. Как и при подходе "водопад", для этого требуется планирование. Однако разница в том, что для гибких методов планирование динамично. Основные постулаты: 1) планы должны постоянно корректироваться, исходя из лучшего знания проекта, и 2) планы могут быть детализированными лишь настолько, насколько глубока информация, доступная в настоящий момент. Гибкое управление обеспечивает "истинную картину", и вы должны быть готовы вносить коррективы, как минимум, после каждой итерации, но часто еженедельно или даже ежедневно. По ходу проекта вы получаете больше информации, и эту информацию нужно возвращать в свой план.
Я также рекомендую принять двухуровневый подход к динамическому планированию. Первый уровень - это общий план, основанный на наборе запланированных итераций по четыре-шесть недель, каждая из которых включает создание сборки и ее немедленное тестирование. Второй уровень - это более детальное планирование каждой итерации, или описание того, что должно происходить в течение этого месяца или полутора месяцев. В конце каждой итерации производится обзор проделанной работы и ее сравнение с планом. Если есть расхождения или если результаты не точно соответствуют плану, вернитесь назад и отрегулируйте план, чтобы он отражал реальность.
Совет 3: разработка, основанная на тестировании
Для исправления ошибок в готовом программном обеспечении требуется много усилий, и процесс может оказаться дорогостоящим. Исследования показывают, что 60% всех усилий по разработке программного обеспечения обычно расходуется на тестирование и исправление ошибок. Лучше сразу избежать ошибок в программном продукте. Это можно сделать с помощью разработки, основанной на тестировании . Тестирование производится параллельно с написанием программного обеспечения. В течение наноциклов по 20-60 минут вы пишите код и сразу же выполняете тест, который демонстрирует, что он работает. Эти наноциклы определяются выполняемым проектом. Например, когда я работал над космическим проектом, наноциклы составляли в среднем по 20 минут. В результате получился код очень высокого качества и с очень низкой интенсивностью дефектов, что уменьшило стоимость тестирования в конце проекта.
Другая практическая рекомендация по гибкому программированию ― использовать непрерывную интеграцию , сблизить работу группы и продемонстрировать правильность всей системы на функциональных потоках, использующих все компоненты. Непрерывная интеграция обычно выполняется ежедневно на протяжении всего проекта, хотя некоторые организации делают это еженедельно. В целом, чем раньше вы обнаружите дефект или проблему интеграции, тем дешевле и проще их исправить. В конце проекта не будет никаких проблем интеграции, характерных для традиционного подхода, когда объединяют сегменты программного обеспечения, разработанные по отдельности. Опять же, избегать ошибок всегда лучше, чем исправлять их (когда уже поздно).
Проекты критически важных систем сложны, и работать над ними трудно. Поэтому лучшим подходом будет такой, какой мы встречаем, когда сталкиваемся с большими проектами в жизни: разбить их на более мелкие части. Постройте свою систему как серию итераций ("бросков") по 4-6 недель каждый.
У каждой итерации должна быть своя декларация цели. Она должна фокусироваться на предъявляемых требованиях (обычно взятых из пользовательских историй или сценариев эксплуатации), но с учетом поддерживаемых платформ, архитектурных концепций, рисков и выявленных дефектов. В конце каждой итерации проводится тестирование в целях верификации и валидации.
В своих проектах в конце каждой итерации мы также практикуем то, что я называю "заключительным этапом" (party phase). Некоторые называют это "вскрытием", но предпочитаю считать это празднованием предстоящего успеха, а не анализом причин провала. Мы смотрим на декларацию цели, определяем, насколько хорошо мы ее выполнили и ищем способы совершенствования процесса. Мы всегда спрашиваем: "А как это можно было бы сделать лучше, быстрее, эффективнее"?
Совет 5: динамическое управление рисками
Риски ― это то, чего вы не знаете в ходе проекта. По моему опыту, охватывающему более 300 проектов, игнорирование рисков ― основная причина провалов проектов критически важных систем. Тем не менее, организации редко занимается каким-либо планированием риска, а те, кто это делает, однажды составляют план и больше никогда в него не заглядывают. Это рецепт катастрофы. При создании критически важных систем учитывать риски необходимо. Поэтому следует использовать план динамического управления рисками, или перечень рисков, и часто редактировать его.
В этом плане определяются риски, которые зависят от двух переменных: тяжесть последствий, которых вы желаете избежать, и вероятность этих последствий. Произведение этих двух значений дает количественную оценку риска, за которой можно следить. Затем принимаются меры по смягчению последствий, так называемые "уколы" ― плановые мероприятия, снижающие степень риска. Не все риски грозят настолько тяжелыми последствиями или имеют такую вероятность, что заслуживают особого внимания, и меры принимаются только в отношении тех из них, которые превышают некоторый пороговый уровень. Когда риск достаточно высок, планируются меры по смягчению последствий, которые включаются в план действий.
Гибкие методы, когда они надлежащим образом применяются к разработке критически важных систем, помогают предотвратить дорогостоящие ошибки. Гибкие методы могут также повысить качество разработки и уменьшить затрачиваемые усилия. Они привлекают внимание к рискам, которые становятся причиной неудач, когда их игнорируют, и исключают статическое, баллистическое планирование, которое также ведет к провалу. Хотя средства менее важны, чем методы, такие программные инструменты семейства IBM Rational, как Rational Team Concert, Rational DOORS, Rational Rhapsody, Rational Quality Manager и др., а также Jazz, помогают автоматизировать процессы и добиться прозрачности, необходимой для уменьшения количества ошибок и улучшения планирования. Добавьте к этому практические рекомендации по гибкой разработке вроде тех, которые включены в процесс Harmony, и вы получите выигрышную комбинацию.