Добрый день.
Назрел такой вопрос: как оценить время написания какой-то части программы правильно?
На старой работе у меня было 2 отдела разработки. В одном отделе начальник говорил:
что программисты они теже самые инженеры и должны допустим за час написать N количество коду (норму),
так как допустим инженер должен нарисовать N количество чертежей. А в другой группе начальник считал,
что программысты они креативные личности и немогут знать сколько там они смогут написать,
вдруг муза сегодня не в настроении будит.
В первой группе было примерно так:
Н1: — за сколько напишешь?
П: — за неделю ! (с запасом,ну вдруг что-то криво пойдет)
Н1: =:-O !!!!! Какую неделю! 3 дня у тебя! и то один день резервный,если чёт не получиться!
Во второй группе:
Н2: — за сколько напишешь?
П: — за неделю ! (у меня дела, за 4 дня я их закончу, за день напишу)
Н2: Хм. Давай я тебе 2 поставлю. А то вдруг не напишешь.
Эти двое постоянно между собой спорили, переписывались с начальством чтобы то могло решить их споры.
В сроки успевали оба. скажу сразу к Н1 люди не шли и он набрал студентов, 2 набрал людей со стажем.
В итоге пришол кризис и решили что 2 начальника сильно жирно. И высшее начальство сдалало выбор в пользу Н1.
сроки у него меньше, студенты просят меньше, студенты работают в выходные.
Вот еще сталкивался как делают другие:
3 фирмы им был задан вопрос сколько станет срок разработки отчета для их программы.
Ф1: Присылаете нам шаблон отчета , через день мы вам высылаем отчет.
Тк вы у нас на поддержке отчет бесплатный.
Ф2: Наш специалист садиться с вашими сотрудниками и начальниками отдела обсуждает отчет.
Пишеться ТЗ. Директор ставит визу. Потом мы делаем. И уже нет притензий, если чтото не так в отчете.
Разработка отчета 3 дня. отчет стоит 150$ Есть возможность ускорить. Допустим 3 человек за отчет садят и за один день делают.
стоимость возрастает.
Ф3: Садимся с вашими сотрудниками обсуждаем отчет пишем. Показываем.
Если не удовлетворяет снова садимся. И так пока не получиться нормальный отчет.Срок месяц. Стоимость 1000$
Как это выглядит в реальности:
Ф1. Юзер стряпает на скорую руку шаблон. шлет. сроки не горят. звонят в Ф1. получили? да.. смотрим.
через день ответа нету. звонят. человека нету, который этим занимается. вызванивают неделю. грит ТЗ ваше потерялось, шлите заново.
потом его опять неделю нету. Потом он присылает. нехрена не работает. Ну и так тыкается мыкаются пока не доведут отчет до конца.
Замечу что это все далает узер, начальство на него только давит: когда, когда. короче бардак.
Ф2. Отрывают от работы всех юзеров и начальников отделов. Те жутко недовольны, поскольку надо еще и свою работу делать.
Сидят неделю. потом неделю юзеры бегают подписывают, начальник в отпуске, на разьездах и тд. потом они даже меньше чем за 3 дня делают. притензий нет.
Ф3. Утверждают тех.задание. Уходят. неделю хрен пойми что делают. через неделю приходить отчет. нехрена естественно не работает.
посколько присылали шаблон, его не кто не смотрел, там всё криво да косо. недяля переписки по почте. потом через неделю специалист. опят садится.
На отчет действительно уходит месяц. Спец. сидит за ручку с юзером и пишет отчет. по 300 раз проверяют. В итоге так и стоит
Вывод: в книгах конечно пишут там надо планировать, а в реале щас кризис и не кто не дает этого делать.
Ты говоришь что скажем сдашь, проект за 3 месяца, а тебе говорят что это невозможно,
если мы поставим такой срок мы потеряем заказчика, мы поставили месяц, так что начинай писать пока он там утвердит.
сроки конечно утрированы, но я думаю щас не кто раздувает сроков. особенно когда есть реальный заказ, а не под ключ.
под ключ конечно хорошо, но щас модно стало, типа заточите систему под нас.
А как у вас? Как вы оцениваете свое время? Как вам его режут/увиличивают?
Отчитываетесь ли вы за свое время? Пишите ли вы отчеты скажем ежемесячно, ежеднедельно, ежедневно?
На старой фирме пытались внедрить что-то типа отчета времени. что сделал. но не прижилось поскольку заставляли писать каждый день.
и человек говорил что я допустим щас базу заполняю, что мне каждый день писать заполняю базу,заполняю базу.
или же раз в неделю тоже было, человек не помнит что делал. а за месяц вообще труба.
Стоят ли у вас системы отчетности какие нить? Сделал — отчитался -закрыл. Баг тракинг? CVS,Subversion или другие подобные системы?
Есть ли тестинг? Или там дали студенту потыкал, потыкал и "а пойдет!". Говорили про фирму в которой проводилось планирование вплодь до параметров методов. Но не прижился отдел поскольку программисты постоянно спорили с этим отделом как писать.
Здравствуйте, AC1D, Вы писали:
ACD>Эти двое постоянно между собой спорили, переписывались с начальством чтобы то могло решить их споры. ACD>В сроки успевали оба. скажу сразу к Н1 люди не шли и он набрал студентов, 2 набрал людей со стажем.
ACD>В итоге пришол кризис и решили что 2 начальника сильно жирно. И высшее начальство сдалало выбор в пользу Н1. ACD>сроки у него меньше, студенты просят меньше, студенты работают в выходные.
Кончится большой текучкой кадров. Раньше, я так понял, была возможность перейти к H2. А теперь только уволиться.
Если Н1 мегамозг, который держит весь проект в голове, то может и получится у него. Но сомневаюсь.
ACD>Вот еще сталкивался как делают другие: ACD>Вывод: в книгах конечно пишут там надо планировать, а в реале щас кризис и не кто не дает этого делать.
Вообщето это и до кризиса было. Куча книжек от том, как планировать, но почему то большинство ошибаются со строками.
ACD>Ты говоришь что скажем сдашь, проект за 3 месяца, а тебе говорят что это невозможно, ACD>если мы поставим такой срок мы потеряем заказчика, мы поставили месяц, так что начинай писать пока он там утвердит. ACD>сроки конечно утрированы, но я думаю щас не кто раздувает сроков. особенно когда есть реальный заказ, а не под ключ. ACD>под ключ конечно хорошо, но щас модно стало, типа заточите систему под нас.
Ага, именно все так. И так было и раньше. Это не только у программистов такое.
ACD>А как у вас? Как вы оцениваете свое время?
На скрам-митингах. ACD>Как вам его режут/увиличивают?
Скрам. Голосованием с помошью карт, на картах числа. У кого отличается в минус и в плюс объясняют свое решение. Приходим в результате к общему числу.
ACD>Отчитываетесь ли вы за свое время?
Да
ACD>Пишите ли вы отчеты скажем ежемесячно, ежеднедельно, ежедневно?
Ежедневный стенд-ап митинг (все стоят, по кругу рассказывают за пару минут, что сделал, что планирует, каккие пролемы). Делальное обсуждение отдельно, если надо.
ACD>На старой фирме пытались внедрить что-то типа отчета времени. что сделал. но не прижилось поскольку заставляли писать каждый день.
Такие вещи надо автоматизировать.
ACD>и человек говорил что я допустим щас базу заполняю, что мне каждый день писать заполняю базу,заполняю базу.
"База" это такое аморфное нечто, а он туда незнамо что пихает? Работу нужно разбивать на понятные, кототкие куски не более чем в полдня каждый. Но это ИМХО.
ACD> или же раз в неделю тоже было, человек не помнит что делал. а за месяц вообще труба.
По-этому надо автоматизировать.
ACD>Стоят ли у вас системы отчетности какие нить? Сделал — отчитался -закрыл.
Отчетность есть. Используем TFS и для скрам митингов сводные отчеты простенькие в Excel.
ACD>Баг тракинг?
Багтрекинг есть конечно, но какое отношение это имеет к пларированию? Разве что в плане закладывания в стратегические сроки рисков.
ACD>CVS,Subversion или другие подобные системы?
А это то тут при чем?
ACD>Есть ли тестинг?
У нас на каждого разработчика в среднем по тестировщику.
ACD>Или там дали студенту потыкал, потыкал и "а пойдет!".
Тестирование само по себе не улучшает качество. Оно его оценивает. Если тестирование некачественное, то и оценка качества некачественная.
А вот улучшают качество все равно девелоперы, но на основании результатов тестирования. Так что если "давать студенту потыкать", то лучше уж не давать вообще.
ACD>Говорили про фирму в которой проводилось планирование вплодь до параметров методов. Но не прижился отдел поскольку программисты постоянно спорили с этим отделом как писать.
Планировать все до точки с запятой?
До параметры методов не планируем. Делаем предварительные версии. Делаем код ревью друг другу.
ACD>>Пишите ли вы отчеты скажем ежемесячно, ежеднедельно, ежедневно? SE>Ежедневный стенд-ап митинг (все стоят, по кругу рассказывают за пару минут, что сделал, что планирует, каккие пролемы). Делальное обсуждение отдельно, если надо.
Что-то это мне напоминает сборища анонимных алкоголииков
Здравствуйте, Dog, Вы писали:
ACD>>>Пишите ли вы отчеты скажем ежемесячно, ежеднедельно, ежедневно? SE>>Ежедневный стенд-ап митинг (все стоят, по кругу рассказывают за пару минут, что сделал, что планирует, каккие пролемы). Делальное обсуждение отдельно, если надо. Dog>Что-то это мне напоминает сборища анонимных алкоголииков
AC1D пишет: > > > В итоге пришол кризис и решили что 2 начальника сильно жирно. И высшее > начальство сдалало выбор в пользу Н1. > сроки у него меньше, студенты просят меньше, студенты работают в выходные.
Что-то странное ты описываешь. Такое может быть в одном случае, выход
продукта должен быть нулевой (контора пилит бабло?)
Здравствуйте, AC1D, Вы писали:
ACD>В первой группе было примерно так: ACD>Н1: — за сколько напишешь? ACD>П: — за неделю ! (с запасом,ну вдруг что-то криво пойдет) ACD>Н1: =:-O !!!!! Какую неделю! 3 дня у тебя! и то один день резервный,если чёт не получиться!
Неделя — это слишком большой срок. Оценить за несколько секунд время для такой объём кода невозможно.
Нужно разбивать задачу.
Вначале понять, что надо сделать, затем представить примерный алгоритм, что нужно будет добавить в существующую систему (или написать для новой программы), что можно использовать. Насколько тривиальная задача? Если сложная, то увеличить вилку.
После такой оценки (на неё может уйти несколько часов, а то и день) уже готов план действий, накидана архитектура, представляешь себе прототипы интерфейсов. Берёшь и считаешь по часам каждый пунктик, очень грубо, но примерное время будет известно.
Все по разному пишут, кто-то быстрее напишет, кто-то медленнее при одинаковом качестве. Кто-то что-то наваяет, и потом надо будет месяц разгребать другому программисту. Так что лучше, чтобы время оценивали сами разработчики. А ответственный человек может это время ещё и увеличить, если считает, что программист может не успеть так быстро сделать, или считает, что тот недооценил задачу.
Если же сроки, выдаваемые программистом не устраивают руководство — искать замену. Но не ускорять. Ведь в этом случае будет страдать качество. Бывают ситуации, когда лучше сделать быстро, чем правильно, но постоянно так делать, на мой взгляд, не нормально.
Факт 8
Чаще всего одной из причин неуправляемости проекта является плохая оценка (второй причине посвящен Факт 23)
Обсуждение
Неуправляемые проекты — это проекты, которые выходят из-под контроля. Слишком часто их не удается завершить выдачей хоть какого-то продукта. А если все же удается, то с большим отставанием от графика и превышением бюджета. Их выполнение сопровождается массой потерь, как корпоративных, так и людских. Некоторые проекты известны как "путь камикадзе".1 {Первые слова названия перевода широко известной книги Э.Йордона (Е.Jordon) "Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects", упоминаемой ниже среди источников данного факта. — Примеч. перев.} Другие проходят, что называется, в "авральном режиме".2 {crunch mode — название книги Джона Бодди, также упоминаемой в разделе "Источники" данного факта. — Примеч. перев.} Как бы они ни назывались, какими бы ни были результаты, неуправляемые проекты — это невеселое зрелище.
Вопрос о том, почему проекты становятся неуправляемыми, часто возникает в программистской среде. Те, кто на него отвечают, часто опираются на личные пристрастия. Кто-то говорит, что дело в отсутствии подходящей методологии (нередко этот кто-то продает какую-либо методологию). А кто-то, — что в недостатке хороших инструментов (угадайте, чем эти люди зарабатывают на жизнь). Другие утверждают, что виноват недостаток дисциплинированности и строгости среди программистов (обычно методологии, поддерживаемые и нередко продаваемые ими, основаны на изрядных дозах навязываемой дисциплины). Назовите любую пропагандируемую концепцию, и найдется кто-то, кто будет утверждать, что проекты становятся неуправляемыми именно потому, что она мало применяется.
Среди этого шума и беспорядка, к счастью, можно услышать по-настоящему объективные ответы, от которых обычно никто не получает коммерческой выгоды независимо от того, к чему они приводят. И эти ответы поразительным образом согласуются между собой. В них фигурируют две причины, по важности стоящие на голову выше остальных, — слабая (как правило, слишком оптимистичная) оценка и нестабильные требования. Первая преобладает в одних исследованиях, вторая — в других.
В этом разделе я хочу сосредоточиться на оценке. (Черед нестабильных требований настанет позже.) Оценка, как вы понимаете, представляет собой процесс, в ходе которого мы определяем, сколько продлится проект и какими будут расходы. В индустрии ПО дело с оценками обстоит очень плохо. В большинстве случаев наши оценки скорее напоминают желания, чем реалистичные цели. Еще хуже, что мы, похоже, вообще не представляем, как улучшить эту пагубную практику В результате все гонятся за недостижимыми целями, поставленными в ходе оценки, отчаянно срезая углы и игнорируя хорошие практические приемы, и неизбежное отставание от графика превращается в отставание всей технологии.
Пытаясь сделать наши оценки совершеннее, мы испробовали все виды подходов, кажущихся разумными. Сначала мы полагались на "экспертов", разработчиков ПО, которые "были здесь и делали это". Изъян этого подхода заключается в его крайней субъективности. Разные люди, имеющие разный опыт "был здесь и делал это", дают разные оценки. Действительно, где бы эти люди ни оказывались и что бы они ни делали, маловероятно, что эти обстоятельства будут в достаточной мере соответствовать текущей задаче, чтобы экстраполяция оказалась корректной. (Среди факторов, характеризующих программные проекты, одним из важнейших является обширность различий между задачами, которые они решают. Эту мысль мы подробно разберем позже.)
Затем мы проверили алгоритмические подходы. Компьютерные специалисты тяготеют душой к математике, и, очевидно, стоило попытаться вывести тщательно продуманные параметризованные уравнения (обычно на основе предыдущих проектов), которые могли бы дать ответы в виде оценок Подайте на вход данные, специфичные для данного проекта, как сказали бы разработчики алгоритмов, поверните алгоритмический рычаг, и на свет появятся надежные оценки. Ничего не получилось. Исследователи один за другим (например, Моханти [Mohanty, 1981] показали, что, если взять гипотетический проект и заложить его данные в совокупность предложенных алгоритмических приемов, эти алгоритмы генерируют радикально отличные (с коэффициентом от двух до восьми) результаты. Алгоритмы давали не более согласованные оценки, чем до них это делали эксперты. Последующие исследования с новой силой подтвердили это неутешительное открытие.
Если задачу нельзя решить с помощью сложных алгоритмов, размышляли некоторые, то, может быть, помогут более простые алгоритмические приемы. Многие специалисты отрасли отталкиваются от оценки, основанной на одной из нескольких ключевых единиц информации, например на строчках кода (lines of code, LOC). Они говорят, что, если можно предсказать ожидаемое количество строчек кода, который надо написать для создания системы, то можно преобразовать "строчки кода" в сроки и трудозатраты. (Над этой идеей можно было бы от души посмеяться — в том смысле, что, пожалуй, труднее узнать, сколько строчек кода будет содержать система, чем каким будет срок выполнения и сколько она будет стоить, если бы ею не оперировало такое количество ярких во всем остальном компьютерных специалистов.) Согласно методике функциональных точек (function points, FF), оценка дается на основе анализа ключевых параметров, таких как количество входов и выходов в системе. Не все гладко и с этим подходом, здесь целых две неувязки. Во-первых, эксперты расходятся во мнениях, что именно и как следует подсчитывать. Во-вторых, для одних приложений "функциональные точки" могут иметь смысл, а для других, где, например, количество входов и выходов намного меньше, чем сложность логики внутри программы, они не имеют никакого смысла. (Некоторые эксперты дополняют "функциональные точки" характерными (feature points) — для тех применений, когда "функций" очевидно не хватает. Однако без ответа остается вопрос, на который, похоже, к настоящему времени не ответил никто: "А сколько же всего видов приложений, требующих неизвестно какого количества схем подсчета, основанных на типах "точек"?")
Получается, что сейчас, в первом десятилетии двадцать первого века, мы не знаем, что есть правильный метод, способный дать приличные оценки и уверенность, что они действительно предсказывают, когда проект завершится и какими будут затраты. Ничего себе итог. На фоне всей шумихи об искоренении авральных режимов работы и "путей камикадзе" он свидетельствует о том, что, пока ошибочные оценки сроков и затрат играют роль ведущих факторов административного управления программными проектами, мы не увидим больших улучшений.
Важно заметить, что неуправляемость проекта — как минимум та, что обусловлена неправильной оценкой, — обычно не имеет никакого отношения к качеству работы программистов. Эти проекты теряют управление из-за того, что цели, которые были определены в результате оценки, и к которым их вели менеджеры, были прежде всего чрезвычайно нереалистичны. Это обстоятельство мы рассмотрим в нескольких последующих фактах.
Полемика
Мало кто спорит, что с оценками в индустрии ПО дело обстоит плохо. Но немало спорят о том, как улучшить качество оценки. Приверженцы алгоритмических подходов, например, предпочитают поддерживать собственные алгоритмы и очернять изобретения других. Сторонники функциональных точек часто говорят ужасные вещи о тех, кто выступает за оценку на основе количества строчек кода. Последнюю Джонс [Jones, 1994] считает причиной двух из самых страшных "болезней" программистской профессии и даже квалифицирует ее применение как "должностное преступление менеджмента".
Есть, к счастью, некий способ устранить это противостояние, если не саму проблему точности оценки. Большинство тех, кто изучает методы оценки, постепенно приходят к выводу, что лучшим компромиссом перед лицом этой грандиозной проблемы является подход "береженого бог бережет". Они говорят, что оценка должна состоять из а) мнения эксперта, знающего проблемную область, и б) результата алгоритма, уже показавшего при данных параметрах ответы приемлемой точности. Эти две оценки ограничивают пространство оценки рассматриваемого проекта. Маловероятно, что эти оценки совпадут, но лучше видеть диапазон, чем не видеть ничего.
Результаты некоторых недавних исследований свидетельствуют, что "посредничество человека может способствовать довольно точным оценкам", гораздо лучшим, чем "простые алгоритмические модели" [Kitchen-ham et al., 2002]. Это хорошее свидетельство в пользу экспертных методик Надо посмотреть, можно ли воспроизвести эти результаты.
Источники
В нескольких исследованиях делается вывод, что оценка — это одна из двух главных причин неуправляемости проектов. Вот две таких работы, а еще три приведены в разделе ссылок.
— Cole, Andy. 1995. "Runaway Projects — Causes and Effects". Software World (UK) 26, no.3. Это наилучшее предметное исследование неуправляемых проектов, их причин, следствий и поведения их участников. Исследователи делают вывод, что "плохое планирование и оценка" были первыми по важности факторами в 48% проектов, вышедших из-под контроля.
— Van Genuchten, Michiel. 1991. "Why Is Software Late?" IEEE Transactions on Software Engineering, June. Данное исследование приходит к выводу, что "оптимистичная оценка" является главной причиной нарушения сроков выполнения в 51% проектов. Несколько книг посвящены описанию проектов, вышедших из-под контроля из-за неправильного определения сроков.
— Boddie, John. 1987. Crunch Mode. Englewood Cliffs, NJ: Yourdon Press.
— Yourdon, Ed. 1997. Death March. Englewood Cliffs, NJ: Prentice Hall.1 {Эдвард Йордон "Путь камикадзе". 2-е издание, дополненное. — М.: Лори, 2005.}
Ссылки
— Jones, Capers. 1994. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Yourdon Press. В этой весьма субъективной книге неточные метрики, полученные на основе количества строк кода, названы "самым серьезным риском для проектов ПО" и вместе с четырьмя другими опасностями, которые связаны с оценками (в том числе с "чрезмерным давлением сроков" и "неверной оценкой затрат"), включены в первую пятерку факторов риска.
— Kitchenham, Barbara, Shari Lawrence Pfleeger, Beth McCall, and Suzanne Eagan. 2002. "An Empirical Study of Maintenance and Development Estimation Accuracy". Journal of Systems and Software, Sept.
— Mohanty, S.N.1981. "Software Cost Estimation: Present and Future". In Software Practice andExperience, Vol.11, pp.103-21.
Следующий факт достаточно интересный, хотя зачастую о нем почему-то не думают или забывают:
Факт 9
Большинство оценок в проектах ПО делается в начале жизненного цикла. И это не смущает нас, пока мы не понимаем, что оценки полученны раньше, чем определены требования, и соответственно раньше, чем задача изучена. Следовательно оценка обчно делается не вовремя.
Обсуждение
Как же получилось, что в программных проектах делаются настолько плохие ценки? Мы начинаем серию фактов, которые способны прояснить ситуацию.
Данный факт посвящен выбору времени оценки. Обычно мы оцениваем все в самом начале. Звучит неплохо, правда? А когда же еще и оценивать? Все хорошо, кроме одного. Чтобы сделать осмысленную оценку, необходимо знать о рассматриваемом проекте достаточно много. Как минимум надо знать, какую задачу предстоит решить. Но первая фаза жизненного цикла, в самом начале проекта, заключается в определении требований. То есть в первой фазе мы устанавливаем требования, которым должно удовлетворять решение. Иначе говоря, чтобы определить требования к решению задачи, надо осознать, какая это задача. Можно ли оценить время и затраты на решение задачи, не имея о ней представления?
Ситуация настолько абсурдна, что я, рассказывая на различных компьютерных форумах об этом факте, спрашиваю аудиторию, может ли кто-нибудь опровергнуть только что сказанное Все-таки этот парадокс скорее всего относится к разряду софизмов. Тем не менее до сих пор никто этого не сделал. Наоборот, все кивают, демонстрируя понимание и согласие.
Полемика
Странно, но никакой полемики по данному конкретному факту, похоже, нет. То есть, как я только что сказал, налицо общее согласие с его истинностью. Но практика, которую он описывает, абсурдна. Кто-то должен сказать об этом во всеуслышание, чтобы изменить положение вещей Но все молчат.
Источники
Подозреваю, что проследить истоки описания этого факта так же трудно, как истоки баек и сплетен. Но вот тем не менее пара мест, где о проблеме "неправильного выбора времени" было сказано ясно:
— В разделе вопросов и ответов своей статьи Роджер Прессман (Roger Pressman) цитирует автора вопроса: "Беда в том, что сроки поставки и бюджет утверждаются до того, как мы начинаем проект. Единственный вопрос, который задает мое руководство, звучит так: "Мы можем получить этот продукт к 1 июня?" Какой смысл производить детальные оценки проекта, когда сроки и бюджет заранее заданы?" (1992).
— В тексте рекламного листка к инструменту алгоритмической оценки [SPC, 1998] есть такой типичный, к сожалению, диалог: Менеджер по маркетингу (ММ)?: "Так сколько же времени, по вашему мнению, займет этот проект?" Вы (руководитель проекта): "Примерно девять месяцев". ММ: "Отлично, мы планируем отгрузить продукт через шесть месяцев". Вы: "Шесть месяцев? Невозможно". ММ: "Похоже, вы не понимаете... мы уже анонсировали дату его выпуска".
Заметьте, что в этих примерах оценку делают не только не вовремя, но можно также ручаться, что и не те люди. Но к этому вопросу мы еще вернемся.
Ссылки
— Pressman, Roger S. 1992. "Software Project Management: Q and A". American Programmer (теперь Cutter PPJournal), Dec.
— SPC. 1998. Flyer for the tool Estimate Professional. Software Productivity Centre (Canada).
Это тоже верно:
Факт 10
Большинство оценок в проектах ПО делают либо топ-менеджеры, либо сотрудники, занимающиеся маркетингом, а вовсе не те, кто будет создавать ПО, или их руководители. Таким образом, оценку делают не те люди.
Обсуждение
Это второй факт, объясняющий, почему программные оценки действительно плохи. В нем говорится о тех, кто делает оценку.
Здравый смысл подсказывает, что сотрудники, оценивающие программные проекты, должны кое-что знать о создании ПО. Разработчики. Лидеры их проекта. Их менеджеры. Но здравый смысл в данном случае отступает под натиском политики. Чаще всего оценки в проектах ПО делают те, кто хочет получить программный продукт. Топ-менеджеры. Отдел маркетинга. Клиенты и пользователи.
Другими словами, оценка сейчас больше отражает желания, а не реальность. Менеджмент и отдел маркетинга хотят, чтобы программный продукт был готов в первом квартале следующего года. Следовательно, это и есть срок, в который надо уложиться. Учтите, что "оценка" в данных обстоятельствах проводится в малом объеме или ее вообще нет в действительности. Сроки и бюджет, полученные в результате некоего невидимого процесса, просто навязываются.
Расскажу одну историю. Я работал в аэрокосмической промышленности под руководством, пожалуй, самого выдающегося менеджера, какого я когда-либо видел. Он заключал контракт на создание программного продукта с другой аэрокосмической фирмой. В переговорах, которые определяли контракт на создание ПО, он назвал подрядчику желаемые сроки, и они ответили, что не успеют. Угадайте, какая дата вошла в контракт. Прошло время, миновала и эта дата. Продукт был в конечном итоге поставлен — в срок, который называл подрядчик. Но не в тот, который был указан в контракте (я подозреваю, что вы правильно угадали дату), и подрядчику пришлось заплатить неустойку.
Из этого рассказа можно сделать пару выводов. Даже самые блестящие менеджеры верхнего звена способны принимать очень глупые решения, когда в дело замешана политика. И почти всегда за назначение нереалистичных сроков приходится расплачиваться. Чаще всего страдают люди (их репутация, здоровье — как физическое, так и психическое и т. д.), но, как следует из этой истории, можно потерять и деньги.
Оценку в проектах ПО, как показывает данный факт, делают не те люди. Индустрии программирования этим наносится серьезный урон.
Полемика
Это еще один факт, где полемика гарантирована и полностью отсутствует. Почти каждый согласится, что такое положение вещей совершенно обычно. А вот о том, хотим ли мы, чтобы это было так, говорят редко. Но этот факт поднимает вопрос о серьезном недостатке взаимопонимания между теми, кто что-то знает о программировании, и теми, кто не знает. А может быть, данный факт обязан своим существованием этому разобщению, которое существовало и раньше.
Тут я должен кое-что объяснить. Дело в том, что разработчики ПО могут и не знать, что можно делать в процессе оценки проекта, но они почти всегда знают, что невозможно. И когда высшее руководство (или отдел маркетинга) отказывается слушать подобные предостережения, основанные на знании, программисты обычно перестают доверять тем, кто дает им указания. Кроме того, они теряют изрядную долю мотивации.
Приходится также иметь в виду, что контакт между разработчиками и их высшим руководством и так уже давно утерян. Длинная цепь разбитых надежд вынудила высший менеджмент в свою очередь потерять доверие к разработчикам. Когда последние говорят, что не могут уложиться в рамки, создаваемые оценкой списка требований, руководство их просто игнорирует. В конце концов, на чем может основываться их вера при условии, что разработчики так редко выполняют то, что обещают?
Все это свидетельствует, что в индустрии ПО назрело нешуточное взаимонепонимание. Полемика по поводу данного факта не так касается его истинности, как причин, которые сделали его истинным. И пока это противоречие ждет своего решения, программирование будет испытывать большие проблемы.
Источники
Есть научная работа, в которой рассматривается именно данный вопрос и демонстрируется данный факт. Ледерер [Lederer, 1990] разбирает вопрос, сформулированный им так: "Практика оценки: политика против разума". (Выбор слов здесь очарователен: политическая оценка, как вы понимаете, принадлежит менеджерам верхнего звена и специалистам по маркетингу, а разумная оценка — эти слова мне особенно нравятся — разработчикам. И в данном исследовании политическая оценка оказалась нормой.)
Авторы другого официального исследования [CASE, 1991] обнаружили, что большинство оценок (70%) делается кем-то, кто связан с отделом по работе с пользователями, а наименьшая их доля (4%) приходится на проектную команду. Отдел по работе с пользователями может и не быть синонимом высшего руководства или отдела маркетинга, но его сотрудники, безусловно, не подходят для того, чтобы оценивать перспективы проекта ПО.
Похожие исследования были проведены и в других предметных областях (заметьте, что эти исследования были связаны с информационными системами). Кроме того, в разделе "Источники" предыдущего факта две цитаты также показывают, что оценку делают не только не в то время, но и не те люди.
Ссылки
— CASE. 1991 "CASE/CASM Industry Survey Report". HCS, Inc., P.O. Box 40770, Portland, OR 97240.
— Lederer, Albert. 1990. "Information System Cost Estimating". MIS Quarter -/у, June.
Факт 11
Оценки в проектах ПО редко уточняются впоследствии. Другими словами, оценки, сделанные не теми людьми и не в то время, как правило, не корректируются.
Обсуждение
Обратимся опять к здравому смыслу. Раз оценки в проектах ПО настолько плохи, то не логично ли было бы уточнять их, приводя в соответствие с действительностью, по мере развития проекта, опираясь на возрастающее знание его участников о том, каков будет его итог? Здравый смысл опять терпит неудачу. Разработчики пытаются во что бы то ни стало буквально следовать этим изначально неверным оценкам. Высшее руководство просто не заинтересовано в их изменении. Ведь оно так часто выдает свои пожелания за реалистичные оценки — так с какой стати оно позволит эти желания игнорировать?
Ну да, участники проекта могут отслеживать его продвижение и решать, какие контрольные сроки надо передвинуть, и, пожалуй, даже насколько надо передвинуть окончательные контрольные сроки. Но когда дело доходит до подведения итогов проекта, его успешность обычно оценивается по все тем же первоначальным цифрам. Вы помните цифры, сфабрикованные не теми людьми и не в то время?
Полемика
Конечно, плохо, когда первоначальные оценки не пересматриваются. Но мало кто борется с этим явлением хоть сколько-нибудь согласованно. (Впрочем, было проведено одно исследование [NASA, 1990], в котором отстаивалась повторная оценка и даже определялись временные точки жизненного цикла, в которых она должна проводиться. Но я не знаю никого, кто следовал бы этому совету.) Таким образом, хотя этот факт и должен вызывать оглушительную полемику, я ничего такого не слышал. Разработчики просто мирятся с тем, что им не дано право пересматривать оценки, согласно которым они работают.
И как только проект со свистом нарушает срок, назначенный в результате оценки, общественность поднимает возмущенный крик, требуя назвать наконец дату появления продукта. Сразу вспоминается система оформления и обработки багажа в международном аэропорту Денвера. А также каждая новая поставка продукта от Microsoft. Так что столкновение мнений есть, и касается оно взаимного соответствия политических оценок и действительных результатов. Но почти всегда дело ограничивается обвинениями в адрес разработчиков. В очередной раз все закончивается поиском "стрелочников", а здравый смысл оказывается в проигрыше.
Источники
О научных исследованиях на эту тему я ничего не слышал. Но как в популярной компьютерной прессе, так и в книгах по менеджменту в программировании публикуется масса историй о том, что повторные оценки не делаются. Так что я подкреплю этот факт, опираясь на:
1. Примеры, подобные приведенным выше (аэропорт Денвера и продукты от Microsoft).
2. Свой личный 40-летний опыт в программировании.
3. Полдесятка книг, в которых я рассказывал о неудавшихся программных проектах.
4. То, что, когда я рассказываю об этом факте на публичных форумах и приглашаю аудиторию опровергнуть меня (нельзя сформулировать условия задачи, ничего не зная о ней, и решить ее нельзя, т. к. нет условий), никто этого не делает.
Ссылка
— NASA, 1990, Manager's Handbook for Software Development. NASA-Goddard.
Гениально:
Факт 12
Раз оценки настолько неправильны, то не так уж много причин беспокоиться о том, что программные проекты не завершаются в сроки, задаваемые оценками. Однако всех это беспокоит.
Обсуждение
Наш последний шанс — здравый смысл. Можно подумать, что раз оценки настолько плохи — и время не то, и люди не те, и (о чем мы только что говорили) никто оценки не пересматривает, — то и относиться к оценкам будут как сравнительно маловажным? Правильно? Нет! Управление программными проектами практически всегда ведется в соответствии с планом. Из-за этого план рассматривается (по крайней мере, высшим руководством) как самый важный фактор в индустрии ПО.
Сделаем некоторые уточнения Для того чтобы управлять по плану, надо установить оперативные и долгосрочные контрольные точки (в MS Project они называются вехами) и определять успешность выполнения проекта по тому, что происходит в этих контрольных точках. Вы отстали от графика в точке 26? Плохо дело.
А как иначе руководить программными проектами? Приведу несколько примеров, чтобы показать, что управление по плану — это не единственный способ.
— Можно ориентироваться на продукт. Об успешности или неуспешности проекта можно судить по тому, какая часть конечного продукта создана и работоспособна
— В управлении проектом можно ориентироваться на возникающие проблемы. Успех или неудача определяются в зависимости от того, как хорошо и как быстро разрешаются проблемные моменты, которые всегда возникают в ходе выполнения проекта
— Можно руководить, ориентируясь на риск Критерием успеха или неудачи могла бы стать демонстрация того, как преодолеваются риски, определенные в начале проекта.
— Мы могли бы руководить, ориентируясь на бизнес-цели. Об успешности можно судить по тому, насколько хорошо программный продукт улучшает ведение дел.
— Мы даже могли бы руководить (удивительно!), ориентируясь на качество. Об успешности можно судить по тому, сколько показателей качества продукта благополучно достигнуто.
Так и слышу: "Какая наивность! В мире, где все меняется молниеносно, план значит гораздо больше, чем все остальное." Ну, пожалуй. Но не кажется ли вам странным, что управление основывается на оценке — самом неуправляемом, самом некорректном, самом сомнительном факторе, которым располагают менеджеры?
Полемика
Все, в том числе и разработчики ПО, просто мирятся с тем, что именно по плану делаются все дела. Результаты управления по графику породили волну недовольства, но никто, похоже, и палец о палец не ударит, чтобы как-то изменить ситуацию.
Некоторые новые идеи, однако, способны изменить сложившийся status quo. Сторонники экстремального программирования [Beck, 2000] предлагают, чтобы из четырех факторов — бюджета, временного графика, характеристик и качества — разработчики, после того как клиент или пользователь выберут какие-то три, выбирали четвертый. Это позволяет четко обозначить, что поставлено на карту в программном проекте, и нетрудно видеть, что только два пункта из четырех имеют отношение к оценкам. Также предлагается изменить властную структуру, которая вносит наибольший вклад в плохую оценку проекта.
Источник
Мне не известно о научных исследованиях по данному вопросу. Но на программистских семинарах я проводил маленькие эксперименты, которые могут проиллюстрировать эту проблему. Один из них я здесь и опишу.
Я прошу присутствующих поработать над маленькой задачей. Задание я сознательно даю слишком большое, а времени на его выполнение отвожу заведомо недостаточно. Я ожидаю, что они попытаются сделать всю работу, сделать ее безошибочно, и потому выдадут незаконченный результат, т.к. им не хватит времени. Как бы не так Все до одного усердно стараются уложиться в мой нереальный срок И создают схематичный и некачественный продукт, который похож на завершенный, но совершенно неработоспособен.
И о чем же это мне говорит? Что в нашей современной культуре принято во что бы то ни стало укладываться в сроки (невозможные), жертвуя ради этого завершенностью и качеством. Что успешно прошел процесс приспособления к имеющимся условиям, в результате чего люди стали делать неправильные вещи по неправильным соображениям. И наконец, что волнует больше всего, все это будет очень тяжело изменить.
Экстремальное программирование лучше всего описано в книге, ссылка на которую дана в следующем разделе.
Факт 13
Между менеджерами и программистами нет контакта. В одном исследовании, посвященном проекту, в котором не были соблюдены параметры, заданные на основании оценки, и который рассматривался руководством как неудачный, говорится, что технические исполнители отозвались о нем как о самом удачном проекте, над которым они когда-либо работали.
Обсуждение
Вполне естественно. Принимая во внимание все неувязки, свойственные оценке, о которых сказано выше, совсем не удивительно, что многие технические специалисты делают все возможное, чтобы не замечать оценок и временных сроков. Им не всегда это удается, что доказывает мой эксперимент, описанный в Факте 12. Но те, кто понимает, насколько нереальны большинство наших оценок, мечтают найти какой-то другой фактор, кроме оценки, который бы позволил судить об успешности проектов
Одно научное исследование погоды не делает. Просто я не мог устоять перед искушением упомянуть здесь именно это (в качестве кандидата в Факты и как иллюстрацию того, что может получить распространение) -настолько впечатляют и настолько важны его результаты.
Я говорю об исследовательском проекте, описанном Линбергом [Linberg, 1999]. Он изучал реальный программный проект, который руководство объявило провальным и в котором пределы, обозначенные оценкой, были нарушены очень сильно. Он попросил технических специалистов, занятых в нем, рассказать о самом успешном проекте, над которым они когда-либо работали. Внимание! Специалисты (по крайней мере, пять из восьми) определили этот последний проект как свой самый успешный. Проект, провальный по мнению руководства, согласно мнению его участников оказался великим успехом. Вот это недопонимание!
И что же это был за проект, в конце концов? Вот некоторые подробности. Бюджет превышен на 419%. Сроки на 193% (27 месяцев против 14). Размеры, по сравнению с изначальной оценкой, были превышены на 130% и на 800% (ПО и программно-аппаратные средства соответственно). Но проект завершился успехом. Продукт делал то, что предполагалось (управлял медицинским инструментом). Он удовлетворял требованию "отсутствия программных дефектов после выпуска".
Так вот они, причины разобщения. Проект не подошел даже близко к выполнению целей, поставленных оценкой. Но программный продукт, как только он был готов, выполнял то, что от него требовалось, и делал это хорошо.
И все-таки не кажется ли вам невероятным, что, растрезвонив о работающем, полезном продукте, можно сделать проект "самым успешным"? Не кажется ли вам, что этим специалистам неоднократно приходилось попадать в аналогичные ситуации? Если говорить о рассматриваемом исследовании, то ответом на эти вопросы было ожидаемое "да". Было кое-что еще, что сделало данный проект успешным для этих специалистов, даже несколько таких "кое-что":
— Продукт работал должным образом (здесь ничего нового).
— Разработка этого продукта была технически сложной задачей. (Многочисленные данные показывают, что больше всего технические специалисты обожают решать трудные задачи.)
— Команда была малочисленной, работала с высокой отдачей.
— Команда менеджеров была "лучшей, с какой я когда-либо работал". Почему? "Поскольку команде была дана свобода на разработку хорошей архитектуры", поскольку не было "расползания проекта" (scope creep) и поскольку "не давили сроки".
И участники добавили кое-что еще. Линберг поинтересовался, что они думают о причинах нарушения сроков. Они назвали такие:
— Назначенные по результатам оценки сроки были нереалистичными (ага!).
— Было недостаточно ресурсов, в частности не хватало консультаций экспертов.
— Когда проект начинался, мы плохо представляли себе его масштаб.
— Проект поздно стартовал.
Во всем этом есть кое-что особенное. Все эти параметры были справедливы на начало проекта. Не в середине проекта, а в его начале. Другими словами, жребий проекта был предрешен с первого дня. Как бы хорошо и как бы упорно эти специалисты ни работали, едва ли они оправдали бы ожидания руководства. В этих условиях они делали то, что с их точки зрения было лучшим, что им оставалось делать. Они с пользой провели время, создав пригодный продукт.
Зияющую пропасть выявляют и другие исследования, посвященные мнениям менеджмента и технических специалистов. Например, в одном из них [Colter, Cougar, 1983] менеджеров и специалистов опрашивали о некоторых характеристиках сопровождения ПО. Менеджеры полагали, что изменения были, как правило, большими и затрагивали более 200 строк кода. Технические специалисты сообщили, что изменения в действительности касались лишь от 50 до 100 строк кода. Менеджеры считали, что количество измененных строк кода связано с временем выполнения задания; специалисты заявили, что подобной корреляции нет.
Что касается неуправляемости проектов, то есть свидетельство, что технические специалисты замечают грядущие проблемы гораздо раньше своего руководства (на 72%) [Cole, 1995]. Это означает, что до менеджмента не доходит то, что замечают специалисты, т. е. взаимодействие утрачено совершенно.
Пожалуй, самые впечатляющие комментарии по этому вопросу содержатся в двух статьях, посвященных управлению проектами. Джеффри и Лоуренс [Jeffery, Lawrence, 1985] обнаружили, что "проекты, в которых оценка не делалась вовсе, были лучшими в смысле продуктивности" (за ними шли проекты, в которых оценки делали технические специалисты, а наихудшие показатели были у проектов, оцениваемых менеджерами). Ландсбаум и Гласе [Landsbaum, Glass, 1992] установили "очень сильную корреляцию между уровнем продуктивности и чувством контроля" (т. е когда программисты чувствовали, что распоряжаются собственной судьбой, они были гораздо более продуктивными). Другими словами, управление, сосредоточенное на контроле, не обязательно делает проект лучшим или даже более производительным.
Полемика
По сути у данного факта два аспекта: неясно, что составляет успех проекта, и не удается наладить контакт между менеджментом и техническими специалистами.
Что касается успешности проекта, то данные, полученные Линбергом, не были воспроизведены на момент написания данной книги, поэтому полемика по данному факту начаться не успела. Я думаю, что менеджеры, прочитав эту историю и познакомившись с размышлениями над данным фактом, будут шокированы, что "очевидно" неудачный проект может рассматриваться специалистами как успешный. Еще я думаю, что большинство технических специалистов, сделав то же самое, что и менеджеры, найдут данный факт вполне справедливым. Если я прав, то тема, к которой обращается данный факт, аккумулировала значительный полемический потенциал, который проявится в споре о том, что составляет успех проекта. Если мы не можем договориться по поводу определения успешного проекта, значит, в нашей области назрели большие проблемы, которые необходимо уладить. Полагаю, что вы никак не могли слышать ничего нового о данном факте.
Отсутствие взаимодействия также почти не комментируется в литературе. Цитаты, подобные взятым из работ Джеффри и Ландсбаума, похоже, рассматриваются как традиционные жалобы тех, кто находится на дне служебной иерархии, на тех, кто стоит над ними, а вовсе не как информация, имеющая реальное значение.
Источники
Вот еще один важный документ в дополнение к тем, что содержатся в разделе ССЫЛОК:
— Procaccino, J.Drew, and J.M.Verner. 2001. "Practitioner's Perceptions of Project Success: A Pilot Study". IEEE International Journal of Computer and Engineering Management.
Ссылки
— Cole, Andy. 1995. "Runaway Projects — Causes and Effects". Software World (UK) 26, no. 3.
— Colter, Mel, and Dan Couger. 1983. Из материалов исследования, опубликованных в Software Maintenance Workshop Record. Dec. 6.
— Jeffery, D.R., and М.J.Lawrence. 1985. "Managing Programmer Producti-vity" Journal of Systems and Software, Jan.
— Landsbaum, Jerome В., and Robert L. Glass. 1992. Measuring and Motivating Maintenance Programmers Englewood Cliffs, NJ: Prentice-Hall.
— Linberg, К.R. 1999. "Software Developer Perceptions about Software Project Failure: A Case Study" Journal of Systems and Software 49, nos. 2/3, Dec. 30.
Факт 14
Анализ осуществимости проекта почти всегда дает ответ "да". [b]
[b]Обсуждение
Индустрия ПО испытывает на себе весьма разнообразные проявления действия "феномена новичка". Одно из проявлений заключается в том, что "нас не уважают". Люди, привыкшие работать по старинке в отраслях, для которых мы решаем прикладные задачи, считают, что раз они обходились без программных продуктов десятилетиями, то — большое спасибо — они прекрасно обойдутся без них и сейчас.
Эта сцена была поставлена в "театре абсурда" несколько лет назад, когда такую точку зрения принял технический менеджер проекта беспилотного самолета. Беспилотный самолет просто не может функционировать без компьютеров и программ, но это было неважно. Малый хотел продолжать проект, выбросив к чертям всю эту хлопотную технологию.
Феномен новичка наносит нам удар и еще с одной стороны, — дело в том, что мы, кажется, слишком часто страдаем неисправимым оптимизмом. Выглядит это примерно так раз мы можем сделать то, что до нас не удавалось сделать никому, то мы уверены, что такой задачи, которую мы не могли бы решить, нет вообще. И что самое удивительное, часто это так и есть. Бывает, однако, что оптимизм приводит нас в западню. Когда мы полагаем, что закончим проект завтра или, по крайней мере, не позже чем через день. Когда мы думаем, что в продукте не будет ошибок, а потом обнаруживаем, что для их устранения надо потратить больше времени, чем на системный анализ, проектирование и кодирование вместе взятые.
Есть, кроме того, анализ осуществимости. Оптимизм действительно доводит нас до беды, когда речь заходит о технической реализуемости. В тех (слишком немногочисленных) проектах, в которых анализ осуществимости предшествует фактическому проекту создания системы, он практически неизменно дает ответ: "Да, мы можем это сделать". И в некотором количестве случаев этот ответ оказывается неверным. Но мы узнаём об этом лишь спустя несколько месяцев.
Полемика
Временной зазор между получением ответа и обнаружением его неправильности таков, что мы редко связываем эти два события. Из-за этого данный факт не порождает той полемики, какой можно было бы ожидать. Может быть, по поводу того, что анализ осуществимости вообще проводится (это бывает так редко), спорят больше, чем из-за его неправильных результатов.
Источник
Источник данного факта представляет для меня особый интерес. Я участвовал в Международной конференции по технологии Программирования (International Conference on Software Engineering, ICSE) в Токио в 1987 году, где в качестве основного докладчика выступал прославленный Джерри Вайнберг (Jerry Weinberg). Он поинтересовался, кто из присутствовавших в зале когда-либо участвовал в анализе осуществимости, результат которого был бы отрицательным. Сначала в аудитории воцарилось неловкое молчание, затем раздался смех. Не поднялась ни одна рука. В один момент все 1500 человек (или около того) осознали, я думаю, что Джерри затронул одно из значительных явлений отрасли — явление, о котором мы никогда до этого не задумывались.
ACD>>Есть ли тестинг? SE>У нас на каждого разработчика в среднем по тестировщику.
Вы в MS работаете? Там только по помоему есть на каждого девелопера один тестировщик, вернее developer in test.
Здравствуйте, Vzhyk, Вы писали:
V>AC1D пишет: >> >> >> В итоге пришол кризис и решили что 2 начальника сильно жирно. И высшее >> начальство сдалало выбор в пользу Н1. >> сроки у него меньше, студенты просят меньше, студенты работают в выходные.
V>Что-то странное ты описываешь. Такое может быть в одном случае, выход V>продукта должен быть нулевой (контора пилит бабло?)
да нет, почему же. студент вполне способен выдать нечто не ахти как, но работающее. И потом, под щелканье кнута H1, под его пристальным наблюдением — даже довести до состояние "работает стабильно". Другое дело, что это все держиться на способностях H1 — он должен все контролировать, все объяснять, все за всеми проверять — и иногда даже дописывать.
но это конечно не нормальный процесс рабочий. с другой стороны, если задачи — относительно простенькие, или H1 — супер мозг, может и получаться все.
Здравствуйте, SE, Вы писали:
SE>Кончится большой текучкой кадров. Раньше, я так понял, была возможность перейти к H2. А теперь только уволиться. SE>Если Н1 мегамозг, который держит весь проект в голове, то может и получится у него. Но сомневаюсь.
Ну вообще он да считал себя мего мозгом) Он написал ядро, общение с бд, а интерфейс уже студенты лабали. Помниться один перешол с большим скандалом к Н2.
Щас насколько я вкурсе Н1 ушел, кто-то другой его заменяет,не знаю как он планирует.
ACD>>Вот еще сталкивался как делают другие: ACD>>Вывод: в книгах конечно пишут там надо планировать, а в реале щас кризис и не кто не дает этого делать. SE>Вообщето это и до кризиса было. Куча книжек от том, как планировать, но почему то большинство ошибаются со строками.
Со сроками имелось ввиду?
ACD>>Пишите ли вы отчеты скажем ежемесячно, ежеднедельно, ежедневно? SE>Ежедневный стенд-ап митинг (все стоят, по кругу рассказывают за пару минут, что сделал, что планирует, каккие пролемы). Делальное обсуждение отдельно, если надо.
Ежедневный не напригает?
ACD>>На старой фирме пытались внедрить что-то типа отчета времени. что сделал. но не прижилось поскольку заставляли писать каждый день. SE>Такие вещи надо автоматизировать.
Внедрили DotProject, вроде получше стало.
ACD>>и человек говорил что я допустим щас базу заполняю, что мне каждый день писать заполняю базу,заполняю базу. SE>"База" это такое аморфное нечто, а он туда незнамо что пихает? Работу нужно разбивать на понятные, кототкие куски не более чем в полдня каждый. Но это ИМХО.
Да примерно так и получалось.За каждым была закреплена часть проекта за которую он отвечал.
Допустим он мог писать в отчетах: пишу парсер, а что он конкретно пишет, не кто не знал. То что он чтото пишет можно было убедиться, а на какой стадии и когда допишет неизвестно. Это было у Н2. Насчет Н1 я не знаю.
SE>Багтрекинг есть конечно, но какое отношение это имеет к пларированию? Разве что в плане закладывания в стратегические сроки рисков.
не имеет. я просто спросил используете или нет. ACD>>CVS,Subversion или другие подобные системы? SE>А это то тут при чем?
Просто было интересно стоят ли эти системы вообще.
SE>Планировать все до точки с запятой?
Да именно так и было.+еще было краткое описание, что в этом методе примерно должно быть.
Получалось программисты тупо кодили, что им сильно не нравилось) SE>До параметры методов не планируем. Делаем предварительные версии. Делаем код ревью друг другу.
Это хорошо.
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте, Vzhyk, Вы писали:
V>>AC1D пишет: >>> >>> >>> В итоге пришол кризис и решили что 2 начальника сильно жирно. И высшее >>> начальство сдалало выбор в пользу Н1. >>> сроки у него меньше, студенты просят меньше, студенты работают в выходные.
V>>Что-то странное ты описываешь. Такое может быть в одном случае, выход V>>продукта должен быть нулевой (контора пилит бабло?)
G>да нет, почему же. студент вполне способен выдать нечто не ахти как, но работающее. И потом, под щелканье кнута H1, под его пристальным наблюдением — даже довести до состояние "работает стабильно". Другое дело, что это все держиться на способностях H1 — он должен все контролировать, все объяснять, все за всеми проверять — и иногда даже дописывать.
Да он как раз таки все контролировал, но каркас который сам написал смотреть не кому не давал и править тем более. Студенты делали только интерфейс по пристальным контролем.
Насчет дописывать это врятли. Возможно более опытный студент исправлял ошибки менее опытного.
Или было парное програмирование. Он написал каркас, а потом царствовал, если студент натыкался на ошибку Н1, скажем там в базе данные есть, а метод нечего не возвращает, то он её конечно исправлял.
Н2 вообще нечего не писал к сожалению.
G>но это конечно не нормальный процесс рабочий. с другой стороны, если задачи — относительно простенькие, или H1 — супер мозг, может и получаться все.
Ну там были не только программисты, там были скажем грамотные люди эксперты в своей области, которые говорили как вообще это должно быть.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, AC1D, Вы писали:
ACD>>В первой группе было примерно так: ACD>>Н1: — за сколько напишешь? ACD>>П: — за неделю ! (с запасом,ну вдруг что-то криво пойдет) ACD>>Н1: =:-O !!!!! Какую неделю! 3 дня у тебя! и то один день резервный,если чёт не получиться!
A>Неделя — это слишком большой срок. Оценить за несколько секунд время для такой объём кода невозможно.
Скорее всего он оценивал по опыту, что-то похожее навярняка писалось и примерное время затраченое тоже известно.
A>Нужно разбивать задачу. A>Вначале понять, что надо сделать, затем представить примерный алгоритм, что нужно будет добавить в существующую систему (или написать для новой программы), что можно использовать. Насколько тривиальная задача? Если сложная, то увеличить вилку. A>После такой оценки (на неё может уйти несколько часов, а то и день) уже готов план действий, накидана архитектура, представляешь себе прототипы интерфейсов. Берёшь и считаешь по часам каждый пунктик, очень грубо, но примерное время будет известно.
A>Все по разному пишут, кто-то быстрее напишет, кто-то медленнее при одинаковом качестве. Кто-то что-то наваяет, и потом надо будет месяц разгребать другому программисту. Так что лучше, чтобы время оценивали сами разработчики. А ответственный человек может это время ещё и увеличить, если считает, что программист может не успеть так быстро сделать, или считает, что тот недооценил задачу.
Время сами разработчики и оценивают, просто начальство его режет.
A>Если же сроки, выдаваемые программистом не устраивают руководство — искать замену. Но не ускорять. Ведь в этом случае будет страдать качество. Бывают ситуации, когда лучше сделать быстро, чем правильно, но постоянно так делать, на мой взгляд, не нормально.
Это не приемлемо. Нового человека сразу в проект не возмешь, да и сроки у него будут по началу не реальные. Да такие ситуации бывают, поскольку думать долго не дают делают первый вариант,
то что придет в голову. Или в крайнем случае 2.Потом уже выесняется, что что-то не додумали и если сделать как запланировали, то в итоге будет производительность страдать или сделать так вообще не получиться. Но есть еще такой вариант, как недостаточность первоночальных данных. Обычно так на первых парах и бывает.
Здравствуйте, MozgC, Вы писали:
MC>Думаю, что глава об оценках из книги Факты и заблуждения профессионального программирования (с) Роберт Гласс будет очень кстати в этой теме. Рекомендую прочитать материал, хоть и понимаю что многим лень, но на мой взгляд материал довольно интересный.
Спасибо за книгу,я её почитаю на досуге. Но хотелось бы узнать в реальности у кого как.
А то книги, книгами, а выясняется что кто-то их вообще не читает или из-за недостаточности времени,
просто игнорирует.
AC1D пишет: > > G>да нет, почему же. студент вполне способен выдать нечто не ахти как, > но работающее. И потом, под щелканье кнута H1, под его пристальным > наблюдением — даже довести до состояние "работает стабильно". Другое > дело, что это все держиться на способностях H1 — он должен все > контролировать, все объяснять, все за всеми проверять — и иногда даже > дописывать.
Ну тогда единственный вывод H1 — "сам себе злобный буратино". если еще
не по 12 часов работает, значит скоро будет.
Здравствуйте, AC1D, Вы писали:
A>>Нужно разбивать задачу. A>>Вначале понять, что надо сделать, затем представить примерный алгоритм, что нужно будет добавить в существующую систему (или написать для новой программы), что можно использовать. Насколько тривиальная задача? Если сложная, то увеличить вилку. A>>После такой оценки (на неё может уйти несколько часов, а то и день) уже готов план действий, накидана архитектура, представляешь себе прототипы интерфейсов. Берёшь и считаешь по часам каждый пунктик, очень грубо, но примерное время будет известно.
A>>Все по разному пишут, кто-то быстрее напишет, кто-то медленнее при одинаковом качестве. Кто-то что-то наваяет, и потом надо будет месяц разгребать другому программисту. Так что лучше, чтобы время оценивали сами разработчики. А ответственный человек может это время ещё и увеличить, если считает, что программист может не успеть так быстро сделать, или считает, что тот недооценил задачу. ACD>Время сами разработчики и оценивают, просто начальство его режет.
Если есть типовая задача, то время на её решение уже известно. Какой смысл резать? Задача от этого не ускориться.
Если менеджеры регулярно уменьшают срок выполнения, то я могу предположить только следующее:
1. Они стараются выжать все соки. Если корову часто доить, она будет давать больше молока.
С коротким сроком человек не будет сидеть в интернете, много болтать, обедать, курить и т.п.
Смысл странный, если человек половину времени сидит в одноклассниках при наличие заданий, то надо с этим бороться, а не сроки уменьшать.
2. Начальство надеется на переработку. Тут без комментариев.
3. Сделать надо быстро. писать можно код любого качества. После этого обматерят все коллеги, но задача будет выполнена.
Бывают такие задачи, но не постоянно же.
По уму время оценивать во время скрам — митинга. Только проблема в том, что скрам — вещь относительная. Например совсем не подходит для исследовательских задач.
В других случаях правильно оценивать так: вот задача, сделай её побыстрее. Нормальный человек сам понимает, что надо работать, а не баклуши бить.
Здравствуйте, alzt, Вы писали:
A>Если есть типовая задача, то время на её решение уже известно. Какой смысл резать? Задача от этого не ускориться.
Ну как какой, задача делается не впервые, подводные камни известны, почему бы не сделать задачу быстро?
A>Если менеджеры регулярно уменьшают срок выполнения, то я могу предположить только следующее: A>1. Они стараются выжать все соки. Если корову часто доить, она будет давать больше молока. A>С коротким сроком человек не будет сидеть в интернете, много болтать, обедать, курить и т.п. A>Смысл странный, если человек половину времени сидит в одноклассниках при наличие заданий, то надо с этим бороться, а не сроки уменьшать.
Нет. Сроки урезаются не из-за этого, а из-за того что они подписали контракт со сжатыми сроками и деваться некуда времени и так мало.
A>3. Сделать надо быстро. писать можно код любого качества. После этого обматерят все коллеги, но задача будет выполнена. A>Бывают такие задачи, но не постоянно же.
Согласен,если постоянно то это конечно же — плохой менеджмент, да и не постоянно тоже нечего хорошего нету.
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Здравствуйте, AC1D, Вы писали:
VM>По уму время оценивать во время скрам — митинга. Только проблема в том, что скрам — вещь относительная. Например совсем не подходит для исследовательских задач. VM>В других случаях правильно оценивать так: вот задача, сделай её побыстрее. Нормальный человек сам понимает, что надо работать, а не баклуши бить.
А как часто у вас проходят скрам — митинги? раз в неделю, в месяц, ежедневно?
