Как понять слабые места при разработке ПО?

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

То этому есть, простое пояснение:

  • нет порядка с применением инженерных и управленческих ПРАКТИК
  • ПРОЦЕССЫ применения этих практик не установлены достаточно хорошо
  • ЛЮДИ недостаточно обучены какие практики, как и когда применять

 

ПРАКТИКИ

Независимо от того какую методологию вы применяете, просто должны быть, пусть и реализованы по-разному:

  • Планирование проекта
  • Проектирование
  • Анализ, документирование, утверждение требований
  • Инспекции кода и документов
  • Оценки работ и сроков
  • Кодирование
  • Юнит тестирование
  • Измерения качества, количества работы и т.п.
  • Управление конфигурациями
  • Непрерывная интеграция
  • Функциональное тестирование
  • Нагрузочное тестирование
  • Управление рисками
  • Управление людьми
  • И т.д.

 

ПРОЦЕССЫ

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

Соответственно напрашиваются такие составляющие:

  • Собственно наличие процессов
  • Входные артефакты и их Входной контроль
  • Применение такой-то практики достаточно квалифицированными исполнителями
  • Выходные артефакты и их выходной контроль

 

ЛЮДИ

Должны как минимум:

  • Быть обучены практикам и процессам
  • Быть достаточно квалифицированными выполнять практики и процессы

 

Отсюда напрашивается довольно простой чеклист, давайте рассмотрим на двух примерах. Шкалу оценок для простоты можно сделать качественную, например, «Да-Нет», или от 1 (хуже) до 3 (лучше). Такой чеклист можно расширять или сокращать в зависимости от ваших нужд. Приведенные примеры не претендуют на однозначную правоту и полноту, важен принцип. Реализация инженерных практик, приведенных в примерах зависит от вас, от вашего проекта, методологии, заказчика и т.п.

Пример 1. Инспекция кода

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

 

Пример 2. Тестирование

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

 

По существу, эти чеклисты являются элементами обеспечения качества (Quality Assurance), которое направлено на качество процессов. Для каждого чеклиста можно «подбивать» сумму ответов, таким образом получиться некоторый рейтинг процесса. А сделав такие рейтинги по всем процессам можно понять слабые места. Причем можно «ходить» как по всем процессам на одном проекте, так и по выбранным процессам на всех проектах в организации, понимая уровень зрелости как процесса, так и проекта.

Также рекомендую посмотреть слайдкаст «Quality Control и Quality Assurance:
как измерить и улучшать?»

Tags: , , ,

Comments are closed.