Объем рутинной работы по разработке программного обеспечения и ее влияние на оценку

11

Я убежден, что объем рутинной работы по разработке программного обеспечения - и должен быть - относительно мал, если не пренебрежимо мал, и что это является фундаментальной проблемой оценки программного обеспечения.

Позвольте мне описать, как я пришел к такому выводу и сказать, есть ли в аргументации серьезные недостатки:

  1. Все, что можно оценить с высокой точностью, - это рутинная работа, то есть то, что было сделано раньше. Все другие виды работ, связанных с исследованиями и творчеством, не могут быть оценены, по крайней мере, с точностью, скажем, +/- 20 процентов.

  2. Разработка программного обеспечения заключается в том, чтобы избегать повторяющихся задач. Один из его основных принципов - СУХОЙ (не повторяйте себя). Всякий раз, когда программист обнаруживает, что делает повторяющиеся вещи, пришло время найти абстракцию, которая избегает этого повторения. Эти абстракции могут быть простыми вещами, такими как извлечение повторяющегося кода в функцию или зацикливание. Они также могут быть более сложными, как, например, создание предметно-ориентированного языка. В любом случае, их реализация потребует исследований (кто-нибудь делал это раньше?) Или творчества.

Из этих двух пунктов я делаю вышеприведенный вывод.

На самом деле, я довольно долго задавался вопросом, почему эти отношения не упоминаются ни в одном другом обсуждении, посте в блоге или статье об оценке программного обеспечения. Это слишком теоретически? Мои предположения неверны? Или это слишком тривиально - но почему большинство известных мне разработчиков считают, что они могут делать оценки с точностью +/- 20% или лучше?

Фрэнк Пуффер
источник
7
99% всей разработки программного обеспечения вне областей, таких как ядра, были выполнены тысячи раз раньше. Слишком много разработчиков просто хотят делать все по-новому, заново изобретать одни и те же старые проблемы.
Согнут
@Bent: То есть вы говорите, что разработка программного обеспечения в основном копируется и вставляется? Я знаю, что многие разработчики работают таким образом и часто находят, что это приводит к не поддерживаемому коду. Но это другая история. Даже если кто-то работает таким образом, он должен выяснить, что копировать и откуда. Это то, что я также считаю исследовательской работой.
Фрэнк Пуффер
1
@ rwong: Конечно, имеет смысл использовать библиотеки. Но найти правильную функцию в библиотеке и правильно ее использовать - это либо исследовательская работа (если lib - жалоба и / или вы плохо ее знаете), либо тривиальная (если вы уже знаете эту функцию). То, что вы называете «клеевым кодом», в моем опыте часто бывает сложным. Осуществление этого не является необходимой рутинной работой.
Фрэнк Пуффер
1
@ JohnR.Strohm: я не читал эти конкретные книги, но знаком с основами COCOMO - однако никогда не использовал его на практике. Также я прочитал две или три другие книги Демарко. Не могли бы вы дать подсказку о том, что конкретно связано с моим вопросом?
Фрэнк Пуффер
2
@FrankPuffer, «Экономика разработки программного обеспечения» Бома необходима для оценки программного обеспечения. Книга Демарко не сильно отстает. Краткий ответ таков: если вы достаточно знакомы с тем, что должно делать программное обеспечение, чтобы оценить его ВСЕ, вы достаточно знакомы, чтобы считать его относительно рутинным.
Джон Р. Штром,

Ответы:

11

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

Например, я много раз писал слои доступа к данным, и теперь я предпочитаю делать это «длинной рукой», а не использовать популярный ORM месяца. Мне легче и быстрее справляться с «рутинными проблемами» известных решений, чем находить и решать новые проблемы в сторонних компонентах.

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

Аналогично, по моему опыту, большинство программ - это автоматизация бизнес-процессов, и хотя каждому бизнесу нравится думать, что их процессы уникальны для них; На самом деле это не так.

Не сказать, что оценка проста! Это проще, но я считаю, что в наши дни проблема оценки связана с неадекватностью требований, а не с затратами времени на кодирование.

Требования имеют тенденцию делиться на три категории:

  1. Смутно, подробности оставлены разработчику.

«Сделай мне сайт, это должно быть круто и продавай мои виджеты»

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

  1. Очень специфичный

«Сделать цвет фона заголовка # ff1100»

Супер быстро, и, опять же, легко оценить. Но! требование обязательно изменится. «Хм, не задумывайся, попробуй этот красный» или «Подожди! Я имел в виду только на одной странице!» так что реальный промежуток времени «сколько времени я доволен цветом заголовка» не имеет ничего общего с оценками кодирования

  1. Смутно, детали предполагаются

«Сделай мне сайт, (так же, как Facebook)»

Здесь множество неустановленных предположений: «конечно, вам понадобится другой логотип», «он должен иметь бесконечную прокрутку», «должен быть масштабируемым до 1 миллиарда пользователей!» эффективно контролировать оценку. Либо разработчик думает обо всем и поднимает оценку за пределы ожиданий «1 человеко-часов», либо он думает / полагает, что требуются только базовые функции, и дает слишком низкую оценку. "О, через неделю или две, я полагаю, вы просто хотите поместить фейсбук в фрейм, верно?"

С опытом кодирование очень быстро, но требования к проектированию (как правило) трудны, и это все больше и больше отодвигается на некодеров. Благодаря гибким методологиям повышается скорость кодирования за счет передачи этой ответственности «бизнесу», а не разработчикам.

Ewan
источник
Я абсолютно согласен с тем, что вы написали о неадекватных требованиях, но это другая история. В первой части своего ответа вы говорите, что часто продолжаете использовать хорошо известные приемы, так что большая часть вашей работы становится рутиной. Вы сознательно обходитесь без дополнительных абстракций. Это, вероятно, хорошо работает в течение короткого периода времени, возможно, 2-5 лет, в зависимости от технологий, которые вы используете. Но тогда вы можете заметить, что вы не улучшили свой процесс так сильно, как некоторые из ваших конкурентов. Также у других разработчиков, которые будут поддерживать ваш код позже, могут возникнуть проблемы.
Фрэнк Пуффер
Очевидно, я не использую сторонние материалы. Дело в том, что если вы знаете, как сделать что-то с помощью инструмента X, оценка проста
Эван
В этом случае становится проще не только оценка, но и реализация. Если весь ваш проект такой, вам повезло. Но в моем опыте это происходит только в небольших проектах. Все крупные (> 10 дней) проекты, в которых я принимал участие, требовали новых концепций или технологий, и именно это и послужило причиной большей части работы, делая усилия по стандартным материалам незначительными.
Фрэнк Пуффер
Не давайте вступать в пламенную войну «кто лучший программист». Все, что я говорю, это то, что вы сделали больше, чем меньше новых вещей. Если все ваши проекты требуют использования новых технологий для большинства функций, хотя ... Это кажется странным
Ewan
@Ewan "концепции или технологии". Для меня первый имеет тенденцию касаться бизнес-правил и / или того, что хочет дизайнер. Это не только о новых технологиях.
Изката
6

почему большинство известных мне разработчиков считают, что они могут делать оценки с точностью +/- 20% или лучше?

Потому что мы оцениваем наше терпение в отношении проблемы гораздо больше, чем реальная проблема.

Если я собираюсь оживить подпрыгивающий мяч, я мог бы потратить на него день, неделю, месяц или год, и все равно просто получить анимацию прыгающего мяча. Надеюсь, это будет выглядеть лучше, чем больше я потрачу на это времени, но в какой-то момент я буду смешным.

Сколько усилий я приложил, чтобы отскочить от мяча, зависит от того, сколько времени разумно на него потратить. Если мой уровень мастерства не снижается, я могу получить мяч, который просто сидит там. Но когда наступает крайний срок, должен ли я пропустить этот крайний срок или хотя бы получить мяч на экране? Водопад настоял на том, чтобы мяч отскочил, и график поменялся. Ловкий говорит, просто достань мяч. По крайней мере, мы узнаем, насколько люди заботятся о подпрыгивании. Таким образом, качество снизилось.

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

candied_orange
источник
Хороший вопрос, так что в основном вы говорите, что оценка должна основываться на том, какое значение имеет определенная функция для клиента (или владельца продукта). Лично мне нравится этот подход, но по моему опыту это не то, как оценка программного обеспечения обычно понимается, даже в проворной обстановке. Один недостаток заключается в том, что часто у вас нет этой информации о потребительской ценности функции. Другим недостатком является то, что он не может обрабатывать рабочие пакеты, которые напрямую не приводят к возможности, видимой клиенту.
Фрэнк Пуффер
@FrankPuffer Я не согласен с тем, что гибкие методы не дают этого понять. В частности, SCRUM даже не просит разработчиков оценивать до тех пор, пока значение функции не станет настолько высоким, что его на самом деле планируется сделать, т. Е. Только во время оценки. Гибкие методы особенно подходят для этого: сначала определите функции с наивысшей ценностью для бизнеса, затем оцените их, затем ДЕЛАЙТЕ ИХ и посмотрите, сколько времени на самом деле это заняло. Пену промыть, повторить. После нескольких циклов вы получите очень хорошее представление об оценке и фактическом времени разработки.
Рибальд Эдди