Метка «оценка времени»

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

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

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

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

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

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

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

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

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Как две недели ?!Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?
Читать полностью »

Прочитал статью «Почему программисты ошибаются в оценке сроков?», которая вызвала у меня некоторое возмущение. К сожалению, не могу оставить комментарий, поэтому решил написать статью в песочницу.

Вообще-то, вопрос «Почему … ошибаются в оценке сроков?» применим к любой производственной деятельности. И вместо многоточия можно указать кого угодно (программисты, сантехники, плотники, слесари, кондитеры и т.д.).Читать полностью »

Всем известно, что сроки, названные программистами, нужно умножать на два. Ушлые проджект-менеджеры ещё добавляют — «и брать значение следующего порядка». Т.е. при оценке программистом требующегося времени в один час, в план пишем два дня. Но для заказчиков (как внешних, так и внутренних) такая ситуация выглядит, как минимум, странной — получается, что наши почти гениальные разработчики, способные решать сложнейшие задачи, не в состоянии сложить два и два, и составить даже простого плана. Как же такое получается? Давайте разберёмся, почему программисты ошибаются в оценке сроков.Читать полностью »

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


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