Карл Вигерс. Разработка требований к программному обеспечению

Ссылка на OZON.

Эта книга рассказывает нам о том, как именно собирать и обрабатывать тербования к программному обеспечению. Когда я ехала домой пару дней назад, моя коллега, увидев книгу, открыла ее на странице "Содержание" и сказала - "Ого! Как много тем тут раскрыто"...

Я задумалась над этими словами и поняла - очень емкое высказывание  Действительно, в книге раскрыто очень и очень много тем. Поэтому для начинающего аналитика она вообще mast-have, а для продвинутого - есть что почерпнуть.

Я выписывала оттуда интересные мысли и цитаты, все ссылки:

• Приоритеты проекта
• Компромиссы для атрибутов качества
• Работать рядом или удаленно - есть ли разница?
• Что такое прототип и для чего он нужен?
• Изменение не бесплатно - анализ влияния.
• Автоматизация - наше все?

Чем хороша книга - так это тем, что в конце каждой главы идет список вопросов для самоанализа. Вообще, как правильно заметила Наташа Руколь в комментариях к отзыву о книге "Бесцельная жизнь", книга-тренинг всегда намного круче, чем просто книга.

Говоря это, я вспоминаю, как готовилась поступать в МГТУ им. Баумана. Физика шла у меня не очень хорошо, поэтому я занималась с репетиторами из института. Первый репетитор говорил хорошо, объяснял доступно... Поэтому, сидя рядом с ним, я все занятие кивала, "конечно, понятно". А потом приходила домой и не могла решить сама ни одной (!) задачи. И куда девалось "все просто и понятно"?

Потом мы сменили репетитора. Второй дедушка меня дрючил только так. Особенно грустно мне было первые занятия, когда ты не знаешь, как решать задачу, а преподаватель не дает тебе готового решения, только задает наводящие вопросы из серии "вспомни то, чего никогда не знал". Поэтому и готовиться я стала к встречам с ним. И задачки дома уже получались - выстраданные на занятиях знания лучше усваиваются. И поступила я благодаря ему.

Так что могу на собственном опыте гордо сказать - все. что звучит легко, просто, понятно и красиво, перестает таким быть до первого столкновения на практике. Поэтому просто прочитать книгу / посетить тренинг - мало. Надо что-то сделать. Самому. Иначе - никак.

Поэтому жирный плюсище этой книги - задачки в конце каждой главы. Второй жирный плюсище - охват тем. Практически экнциклопедия для начинающего аналитика  Поэтому - читать!

А еще в конце книги есть приложения. Некоторые показывают на примере кратенько все то, что проходилось в предыдущих главах. Но меня особенно заинтересовало приложение А. "Самостоятельная оценка применяемых вами приемов работы с требованиями". Это такой тест, который, во-первых, показывает ваше текущее положение дел (правда, там не даны ответы, как оценивать, но долго ли умеючи? Поделить общее число баллов, которых 100, на 4 - и вот вам 4 категории, плохо, неплохо, хорошо, отлично)

Ну а еще в самих вопросах скрываются подсказки - наилучший вариант четвертый, третий тоже ничего. А если у вас не они, то сразу и направление, куда двигаться дальше. И очень здорово, что у меня по ответам почти все хорошо))) Ну, не все четверки, но меня по ответам и тройки устраивают.

Вот например, как вы считаете, какой ответ лучше:

• Мы записываем требования на структурированном естественном языке с последовательным уровнем детализации, в соответствии со стандартным шаблоном спецификации требований к ПО. Иногда мы дополняем эти требования графическими моделями анализа с применением стандартных пояснений.
• Мы храним свои требования в базе данных или коммерческом инструментальном средстве управления требованиями, а модели анализа - в коммерческом инструментальном средстве. Вместе с каждым требованием хранятся несколько его атрибутов.

Меня до сих пор терзает подозрение, что это какой-то прикол... Он, видимо, из серии "автоматизация - наше все". Если есть инструмент, то все, что перечислено в 3-ем пункте, уже не нужно? о_О

В целом ответы под номером 4 более-менее лучше выглядят, но данный пример меня поражает. И я понимаю, что 100 баллов в этом тесте никогда не наберу  По другим вопросам меня тоже мои немаксимальные ответы в принципе устраивают...

Из ложки дегтя - читала издание 2004 года. Не могу сказать что там прям уж "очепятка на очепятке и очепяткой погоняет", но их много. Надо было, наверное, помечать и выписывать, сделать доброе дело. Хотя я не в курсе, может, было переиздание, которое вычитали? В целом, конечно, не столь важно, 540 страниц - это вам не шуточки, хотя опечатки все-таки удручают...

Резюмируя - книга рекомендуется всем. кто собирается писать требования. И даже тем, кто собирается их тестировать. "Врага надо знать в лицо"

Шучу, требования нам не враг, а очень даже друг, что не раз обосновывается в этой книге, хотя я и предвижу холивары на тему "а нам и без них хорошо, у нас Заказчик такой". Бывает, да. Но, согласитесь, находить баги на этапе требований приятнее, так как исправляются они быстрее и дешевле!