BoatmansHome: Требования/ЗачемНужныТребования ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Этот цикл заметок о требованиях задуман так, чтобы покрыть теоретическую часть одного из наиболее эффективных, по признанию заказчиков, тренингов в Москве по теме требований (по состоянию на 2013–2014 год). И выйти за пределы того, что мы успеваем обсудить и попробовать в узком формате однодневного тренинга.
Для тех, кто уже там был, это должно дополнить раздаточные материалы с тренинга. Для тех, кто думает об участии, это даст представление, о чем пойдет разговор. Для тех, кто не сможет поучаствовать, это даст хотя бы теоретическое представление о предмете.

Кому интересно, тренинг называется «Практика разработки требований к ПО», я его сделал в рамках Школы Системного Анализа, там сейчас его проводит Дмитрий Волгин. Так же для корпоративных заказчиков этот тренинг могу провести и я сам от имени своей компании Лаборатория системного анализа. Вот, например, отчет двухлетней, правда, давности – с тех пор тренинг было немножко доработан.

Зачем нужны требования


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

  1. средняя полнота требований, собранных методом обсуждения с заказчиком, составляет 25–50%, достигая в пике 70–80%. Это значит, что средний коэффициент ухудшения, учитывающий просрочку (перерасход бюджета) и падение качества результата составляет 2–4. Во столько раз затягиваются сроки при неизменном качестве или падает качество при жестких сроках, или пробел в финансировании затыкается переработками команды или использованием других резервов компании. Это обнаруживается, если мы смотрим на выходе валидации предмета поставки проекта, отвечающей за удовлетворение ожиданий заказчика в области эффекта от применения заказываемой системы.
  2. Практически всегда, если не думать об этом специально, между заказчиком и командой проекта стоит стена непонимания. Измерения в ходе тренингов (и наблюдения из жизни) показывают, что на одном языке стороны разговаривают от силы пятую часть времени общения.
  3. Небольшая фокусировка разработчиков требований на нескольких самых главных базовых принципах и применение самых простых и дешёвых техник анализа доводит полноту требований до 90–95%. И только оставшиеся 5–10% требуют сложных и дорогих практик, что делает актуальным выбор между заказом «автобуса аналитиков» и закладыванием резервного буфера на доделки.
  4. Если говорить об остальных девяти атрибутах качества требований, то без специального внимания к ним и постановки простого навыка проверки, они в среднем находятся между 50% и 90%. Это еще сильнее затягивает сроки, перерасходует бюджет и опускает качество результата итерации.

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


Об этом дальше в цикле заметок. Я пишу в свободное от работы время, и материалы могут задерживаться. Если вам важно их прочитать, прошу дергать меня напоминаниями (./Контакты)


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]