Несколько дней назад коллега-разработчик спросил в Twitter: «как снизить затраты в процессе разработки программного обеспечения?», этот вопрос заставил меня задуматься обо всех этапах производства программного обеспечения и предоставления его заказчику. Поразмыслив немного, я пришел к следующему ответу: «Лучшим способом должно быть проведение большого процесса инжиниринга требований», и сейчас я покажу всем вам, читатели, что заставило меня ответить на этот вопрос.
Во-первых, что такое инженерия требований?
В настоящее время движение Agile занимает большое место в культуре разработки программного обеспечения, с его многочисленными достижениями в поставке высококачественного программного обеспечения со временем выхода на рынок, запрашиваемым в сегменте клиентов. Но, как точно сказал Фред Брук в книге «Мифический человек-месяц»: «В программной инженерии не существует серебряного шарика». Точно так же, как он сказал, культура Agile является большим прогрессом в этой инженерии, но за ее преимущества приходится платить, многие инженеры-программисты, видя маневренность и давление времени на рынок, отводят процесс разработки требований на второй план. Какая большая ошибка!
Согласно Яну Соммервилю в его книге «Программная инженерия», этот процесс определяется как : «первый этап, который должен быть выполнен в процессе разработки программного обеспечения». На самом деле, этот шаг выполняется в основном в Scrum или Kaban с термином «техническая доработка», но многие просто пропускают шаг «функциональная доработка», потому что считают, что это шаг только для того, чтобы удовлетворить мысли заинтересованных сторон, и здесь кроется одна из больших ошибок в разработке программного обеспечения. Что ж, мы можем дорабатывать технически как можно больше, но если это не удовлетворит заинтересованных лиц, то не будет служить. Так и в обратном случае, если заинтересованные стороны думают о большом проекте, во многих случаях он будет просто непригоден для одного проекта и должен быть разбит на два или более. В любом случае, ошибка хорошо выполненной функциональной доработки приведет к более дорогому процессу, техническая доработка займет больше времени, чем ожидалось, и приведет к более сомнительным требованиям, что обяжет команду остановиться и пересмотреть их в будущем.
В свое время, запутанная и плохо выполненная техническая доработка приведет к плохому моделированию программного обеспечения и неэффективной архитектуре, суммируя все это вместе, мы получаем рецепт увеличения затрат на процесс разработки, и, как следствие, программное обеспечение, вероятно, будет потреблять больше памяти, чем должно, что в перспективе облачных вычислений означает больше денег, потраченных впустую.
Своими словами я обычно говорю следующее: «Процесс разработки требований является основой для того, чтобы тратить меньше денег на разработку программного обеспечения».
Итак, что же я должен сделать, чтобы добиться большего?
Честно говоря, рецепта пирога не существует, каждая компания, каждый отдел, каждая команда имеет свои отличия и динамику. Но вам стоит взять с собой следующие советы: Не бойтесь потратить на этот процесс значительное время. Видите, многие проекты, в которых я участвовал, фокусировали свое время на кодировании. Я хотел бы предложить вам в качестве эксперимента следующее: переверните это. Сосредоточьте большую часть времени на уточнении и отображении требований, обсудите это с заинтересованными сторонами, и в итоге вы напишете меньше кода, а заинтересованные стороны потратят меньше денег. Счастливый конец!
Шутки в сторону, мы знаем, что давление заинтересованных сторон во многих случаях является настоящей болью, поэтому если вам нужно делать ежедневные отчеты, я бы посоветовал вам потратить около 30% времени проекта на этот шаг. Четко и объективно определите нефункциональные и функциональные требования, бизнес-правила тоже, и прикрепите их к следующей истории, вы должны потратить около одной недели, чтобы уточнить одну-две истории и выявить все их требования и запросы.
По мере доработки параллельно создаются артефакты и документы об этом, UML-диаграммы, документы требований (не связывайте себя водопадной моделью, создайте шаблон, который должен взять только самое необходимое о требованиях), записывайте встречи и затем в финале создайте финальный отчет, который должен отображать пользовательский интерфейс с последующими требованиями, поговорите с другими необходимыми областями и затем проведите финальную встречу, после чего вы можете приступать к коду.
Принимая во внимание эти шаги, разработчики не только будут испытывать меньше стресса, но и сэкономят больше денег, а шансы проекта на успех значительно возрастут.
Спасибо!
Размышляя о программной инженерии, вы уже спрашивали себя: «Почему я все еще должен заботиться о коллеге»? Посмотрите эту статью!