Рубрика «оценка трудозатрат» - 2

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

Разработка программного продукта — это процесс, в котором человеческий фактор играет очень важную роль. В статье поговорим о различных психологических и математических законах и принципах. Некоторые из этих принципов и законов вам хорошо известны, некоторые — не очень, а некоторые помогут объяснить ваше поведение или поведение ваших сотрудников и коллег.

Разработка ПО – нелинейный процесс

Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.).

imageЧитать полностью »

Подавляющая масса исследований и отчетов подтверждает тенденцию к превышению бюджетов и сроков программных проектов. В среднем, это превышение составляет порядка 30 процентов1. Более того, если мы сравним точность оценивания в 1980-х и ту, которая фигурирует в недавних исследованиях, мы не обнаружим существенной разницы (Единственный анализ, предполагающий существенное улучшение качества оценки, встречается в отчетах Chaos Reports от Standish Group. Однако, это «улучшение», вероятнее всего, проистекает из того факта, что исследователи улучшили качество своих данных, перейдя от излишне перегруженной проблемными проектами, к более репрезентативной выборке2). Методы оценки также существенно не изменились. Несмотря на интенсивные исследования в области формальных моделей оценки, доминирующим методом продолжает оставаться «экспертная оценка»3

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

Разработка ПО: факты против мифовМифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

За короткую историю в отрасли сложилось большое количество мифов, суеверий и религиозных заблуждения. Эти мифы, суеверия и заблуждения, порой очень похожи на правду. Они получили широкое распространение и пагубно влияют на руководителей, которые никогда сами профессионально не разрабатывали ПО. Следствием этого является применение неадекватных методов и подходов в управлении программистами, что гарантированно приводит проект к провалу.

Вот наиболее распространенные мифы и факты, которые их опровергают.
Читать полностью »

Сегодня я собираюсь рассказать о том, что происходит в головах разработчиков программ, в тот момент, когда они делают предварительные расчеты; о том, почему им так сложно зафиксировать все задумки в своей голове; а также о том, как лично я разрешил для себя эту ситуацию, узнал, как жить и писать ПО (для счастливых владельцев бизнеса), но, уверен, мои собственные оценки трудоемкости ненадежны как никогда.

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
Читать полностью »

Этот пост навеян оценкой большого технологического проекта, в которой мне довелось поучаствовать. Оценка началась катастрофически – после недель совещаний, сборов рабочих групп и размышлений тимлидов разработка представила оценку сроков разработки – с разбросом в 14 месяцев между минимальной и максимальной длительностью проекта.

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Читать полностью »

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js