Когда мы еще учились в университете один мой приятель утроился на работу в компанию, которая проектировала инфраструктуру зданий: сеть, пожарная и охранная сигнализации, проводка, освещение, кондиционирование и т.п. Он проектировал сети и электропроводку. Работали они в Автокаде и артефактом их отдела была документация, оформленная по всем необходимым стандартам.
Однажды, он рассказал мне, как он ездил на объект проверять сделанную монтажниками работу. Какого же было его разочарование, когда по совершенно точным чертежам, где сантиметр в сантиметр было прописано куда и какие розетки разводить и где делать отверстия в стене, было сделано все не правильно. У строителей-монтажников было свое мнение относительно того, где должна идти проводка и где должен писеть тот или иной щит.
Не смотря на то, что документация была очень подробна, не смотря на то, что эта документация являлась одним из артефактов, за которые платил заказчик — она не работала.
Вернее она работала, но не совсем так, как ожидал этого конструктор.
В чем была причина подобного поведения рабочих? Думаю, что их несколько:
- Отсутствие обратной связи от рабочих с конструкторами, в виду чего документация устаревала и утрачивала свою ценность после проведения работ.
- Возможная неосведомленность конструкторов о реальном положении вещей в построенном здании. (“Нельзя здесь сверлить, понимаешь! Тут арматура…”)
- Личные предпочтения рабочих, которые считали, что так для них будет лучше, удобнее, проще сделать.
- Корыстное желание сэкономить провода и розетки, чтобы их потом украсть.
За преобладание личных предпочтений и желание украсть часть чужой собственности людей обычно увольняют, а вот первые два пункта это, как говорится, “наши недоработки”.
Что было бы если бы документации не было вообще? Ответ: Хаос! Бардак! :)
Представьте если вы решили просверлить стенку спустя 3 года после проведения работ и вместе с кирпичом просверлили 2 медных кабеля. Думаю, что после вы припомните родню ваших строителей до пятого колена…
{Я сторонник правильных аналогий относительно разработки программного обеспечения, поэтому опасаюсь метафоры “строительства здания”. Но думаю, что вы найдете зерно мысли в рассказанной мною истории.}
Зачем же я потратил ваше время, рассказывая эту историю? К чему я веду?
Все чаще мне приходится сталкиваться со следующим мнением: “Вы применяете agile? Да вы просто не умеете писать требования и аналитиков у вас нет!” Я сам в прошлом аналитик, написал несколько десятков ТЗ и даже изложил ряд мыслей в известной статье про то, как надо писать ТЗ. А потом сам же дошел до жизни такой, когда сам же и внедрял agile в команде, которую собирал для одного из проектов.
Представление о том, что в agile нет документации, а также о том, что аналитика в agile никакая не нужна — заблуждение. Я ни один раз в дискуссиях пытался донести до оппонентов, что с моей точки зрения agile — это не только методика разработки, но также и методика управления требованиями. Медленно по слогам: Ме-то-ди-ка у-прав-ле-ния тре-бо-ва-ни-я-ми. Благо для фиксации требований есть несколько больше инструментов, нежелели только ТЗ.
Методология agile требует минимальное, но необходимое количество документации, в том числе и требований. В особенности это касается функциональной спецификации. Для примера можно почитать Джоеля о том, почему и как надо писать функциональную спецификацию. Я с ним полностью согласен.
Заглянем в сами принципы и ценности Agile:
- Принцип #3: Even late changes in requirements are welcomed
- Принцип #8: Continuous attention to technical excellence and good design
- И даже ценность: “Working software over comprehensive documentation” — не говорит о том, что документации не должно быть. Но мы смещаем фокус с идеальной документации на идеальное ПО. :)
Вот вам и ответы. Нигде не говорится про то, что документации быть не должно. Говорится о приоритетах. Те кто говорят, что документации не надо — пещерные люди.
А почему я убежден, что с самого начала невозможно описать все, что надо для написания приложения, выбить это в камне и обязать заказчика под страхом смертной казни ничего не менять — я расскажу отдельно.
