Я убежден, что объем рутинной работы по разработке программного обеспечения - и должен быть - относительно мал, если не пренебрежимо мал, и что это является фундаментальной проблемой оценки программного обеспечения.
Позвольте мне описать, как я пришел к такому выводу и сказать, есть ли в аргументации серьезные недостатки:
Все, что можно оценить с высокой точностью, - это рутинная работа, то есть то, что было сделано раньше. Все другие виды работ, связанных с исследованиями и творчеством, не могут быть оценены, по крайней мере, с точностью, скажем, +/- 20 процентов.
Разработка программного обеспечения заключается в том, чтобы избегать повторяющихся задач. Один из его основных принципов - СУХОЙ (не повторяйте себя). Всякий раз, когда программист обнаруживает, что делает повторяющиеся вещи, пришло время найти абстракцию, которая избегает этого повторения. Эти абстракции могут быть простыми вещами, такими как извлечение повторяющегося кода в функцию или зацикливание. Они также могут быть более сложными, как, например, создание предметно-ориентированного языка. В любом случае, их реализация потребует исследований (кто-нибудь делал это раньше?) Или творчества.
Из этих двух пунктов я делаю вышеприведенный вывод.
На самом деле, я довольно долго задавался вопросом, почему эти отношения не упоминаются ни в одном другом обсуждении, посте в блоге или статье об оценке программного обеспечения. Это слишком теоретически? Мои предположения неверны? Или это слишком тривиально - но почему большинство известных мне разработчиков считают, что они могут делать оценки с точностью +/- 20% или лучше?
источник
Ответы:
В любом конкретном проекте это может быть правдой. Однако, если вы работаете над несколькими аналогичными проектами для разных компаний на протяжении многих лет, вы можете обнаружить, что «решаете» в основном одну и ту же проблему много раз с небольшими изменениями.
Например, я много раз писал слои доступа к данным, и теперь я предпочитаю делать это «длинной рукой», а не использовать популярный ORM месяца. Мне легче и быстрее справляться с «рутинными проблемами» известных решений, чем находить и решать новые проблемы в сторонних компонентах.
Очевидно, я мог бы написать свой собственный ORM, чтобы упростить повторяющийся код, не добавляя неизвестные причуды в чужой системе, но этот код принадлежал бы компании, в которой я работал в то время, и другие разработчики находили бы ее такой же странной, как любой другой сторонний ORM.
Аналогично, по моему опыту, большинство программ - это автоматизация бизнес-процессов, и хотя каждому бизнесу нравится думать, что их процессы уникальны для них; На самом деле это не так.
Не сказать, что оценка проста! Это проще, но я считаю, что в наши дни проблема оценки связана с неадекватностью требований, а не с затратами времени на кодирование.
Требования имеют тенденцию делиться на три категории:
Их, как правило, проще всего оценить, так как при возникновении сложной неожиданной проблемы вы можете просто изменить требования на что-то функционально эквивалентное и избежать проблемы.
Супер быстро, и, опять же, легко оценить. Но! требование обязательно изменится. «Хм, не задумывайся, попробуй этот красный» или «Подожди! Я имел в виду только на одной странице!» так что реальный промежуток времени «сколько времени я доволен цветом заголовка» не имеет ничего общего с оценками кодирования
Здесь множество неустановленных предположений: «конечно, вам понадобится другой логотип», «он должен иметь бесконечную прокрутку», «должен быть масштабируемым до 1 миллиарда пользователей!» эффективно контролировать оценку. Либо разработчик думает обо всем и поднимает оценку за пределы ожиданий «1 человеко-часов», либо он думает / полагает, что требуются только базовые функции, и дает слишком низкую оценку. "О, через неделю или две, я полагаю, вы просто хотите поместить фейсбук в фрейм, верно?"
С опытом кодирование очень быстро, но требования к проектированию (как правило) трудны, и это все больше и больше отодвигается на некодеров. Благодаря гибким методологиям повышается скорость кодирования за счет передачи этой ответственности «бизнесу», а не разработчикам.
источник
Потому что мы оцениваем наше терпение в отношении проблемы гораздо больше, чем реальная проблема.
Если я собираюсь оживить подпрыгивающий мяч, я мог бы потратить на него день, неделю, месяц или год, и все равно просто получить анимацию прыгающего мяча. Надеюсь, это будет выглядеть лучше, чем больше я потрачу на это времени, но в какой-то момент я буду смешным.
Сколько усилий я приложил, чтобы отскочить от мяча, зависит от того, сколько времени разумно на него потратить. Если мой уровень мастерства не снижается, я могу получить мяч, который просто сидит там. Но когда наступает крайний срок, должен ли я пропустить этот крайний срок или хотя бы получить мяч на экране? Водопад настоял на том, чтобы мяч отскочил, и график поменялся. Ловкий говорит, просто достань мяч. По крайней мере, мы узнаем, насколько люди заботятся о подпрыгивании. Таким образом, качество снизилось.
Я стараюсь быть уверенным, что мои шары отскакивают, но когда наступает крайний срок, лучше производить статический шар, чем вообще ничего. Поэтому я оцениваю время на основе того, что кажется разумным количеством времени, которое нужно потратить на проблему, прежде чем говорить об альтернативах. Иногда мяч просто не собирается подпрыгивать. Иногда это нормально. Исчезновение на месяц не в порядке.
источник