Есть такое понятие, как «предпроектные показатели». Например, договариваетесь о водоизмещении не более 1 м^3 — и у вас заведомо не получится авианосец :)
Договоритесь что из дерева и без мотора — и всё станет совсем хорошо) А дальше оценка на основе исторических данных / аналогий, по предпроектным показателям, вполне работает)
Обсуждаемая статья в общем-то не про это. Не про оценку проекта, а про cоставление плана проекта, когда цель более-менее ясна. Хотя бы цель текущей итерации.
Подскажу (благо 'матмех finished'...)
Вот картинка «нормального распределения» (представьте, что по оси X — срок, за который будет выполнен план целиком, а по оси Y — вероятность такого исхода):
Естественно распределение вероятных сроков по одной конкретной задаче — не такое, однако в статистике есть теорема, согласно которой сумма множества случайных величин (одного порядка) стремится к нормальному распределению.
Вот на графике: точка, которая помечена «Mean» — это ваш BG (Best Guess), т.е. оценка которая выполнится (или не выполнится) с вероятностью 50%. Точка "-3 sd" — это O, а "+3 sd" — это P. Cам же sd — это среднеквадратичное отклонение от мат.ожидания (показан на графике полоской).
Формула (1O + 4BG + 1P)/6 призвана дать гипотезу о средне-арифметическом сроке выполнения одной задачи (это не то же самое, что оценка 50%). В методе PERT вы потом складываете Mean всех задач по критическому пути проекта, и прибавляете к ним корень из суммы квадратов SD по тому же пути, умноженный скажем на 3 — и получаете 99% дидлайн общего срока выполнения.
Понятно, что это всё теория, которая применима ограничено (например, если все риски по всем задачам выстрелят одновременно, вы улетите далеко за вычисленный по PERT план). Но сама практика учета рисков отдельно от «ожидаемых» сроков всё же улучшает планирование, так что можно и PERT считать :)
В изложении метода (кстати, неплохо бы упомянуть, что он происходит из PERT) есть некоторые неточности.
Замечание по теории: Пессимистическая и оптимистическая оценка выставляются исходя не из 100% случаев, а из 99%. Это зафиксировано в формуле, где знаменатель 6 — это «три сигма» в обе стороны.
Замечание по практике менеджмента: практического смысла спрашивать у исполнителя все три точки нет никакого. Это связано с тем, что обычно исполнитель не понимает, к чему его, например, обязывает вынесение точной оптимистической оценки (и что он получит, если назовет малое число). Реальная практика обычно такая: либо спрашивается «одна» оценка (которая рассматривается, например, как 70% — где-то по середине между BG и P), либо спрашивается две (реалистичная и пессимистичная, которые используются как BG и P). Что же касается оптимистической оценки, то её (как и вообще все корректировки в оптимистичную сторону) может сделать только менеджер или тим-лид, т.е. человек, ответственный за проект в целом и за риски по срокам в частности. Либо её можно принять равной BG, т.е. вообще не учитывать «положительные» риски в планировании.
При этом, по совокупности, никто не мешает всю эту практику «спроси исполнителя» в итоге сводить в формат PERT (я так делал и у меня это работало), однако надо понимать суть трудовых отношений и не писать в таблицу всё, что вам сказали. Оценки, пришедшие снизу, крайне желательно дублировать другими данными (историческими, внешней оценкой и т.д.).
P.S. Всё вышенаписанное, конечно, относится к программным проектам (где, в отличии от например строительных, нет устоявшихся нормативов). Как я понял, мы говорим про программные проекты)
Вообще-то Agile и Continuous Integration как раз и призваны решить проблемы, цитирую:
«бизнес-требования появятся, как аппетит, приходящий во время еды».
«нужно выполнить итерационное решение проблемы, с каждым разом подбирая оптимальное соотношение ресурсов на оптимизацию кода приложения, тюнинга серверов админами и закупки железа».
Если вместо итерационного решения проблемы, о котором Вы говорите, получается «херак, херак и в продакшн», это довольно грустно… но разве не очевидны выводы? Видимо я Вашу точку зрения не вполне уловил. Решения по технологическому выбору, по выбору алгоритмов в любом случае должны делаться квалифицированными людьми и с осознанием последствий.
Делать API удобным, простым и понятным — это безусловное благо.
К сожалению, призыв «простые вещи должны делаться просто» иногда приводит к разработке API из двух частей: «упрощённой» и «настоящей».
Если реально необходимый объём функциональности будет доступен только на уровне заведомо выше «базового» понимания, то разработка «простых и понятных» (упрощенных) методов, скрывающих настоящую сложность подсистемы — не кажется хорошей идеей. В плохом сценарии, эти методы потребуют много усилий по разработке и поддержке, но окажутся применимыми весьма ограничено.
Поэтому, если причина разработки API — необходимость не просто состыковать программные модули, а скрыть сложность какой-то подсистемы, к вопросу упрощения следует подходить сдержанно, а к проработке API — более серьёзно.
Кстати говоря, доработка компилятора, чтобы он выполнял операции с плавающей точкой программным путем, обошлась бы в десятки раз дешевле, чем все те ужасы, которые вы написали. Далее система тестов просто выполняется на обоих режимах компиляции (симуляция float и честный fixed) и все случаи, когда для перехода от FP к фиксед требуются специальные полиномы и нетривиальная математика, возвращаются упомянутым «белым алгоритмописателям» обратно. Так что «путь умника», — я хочу сказать, техническое решение, не затрагивающее оргвопросов, — из той ситуации, наверное, тоже был.
Я понимаю, что идеи «мой начальник неумен» и «надо пореже испытывать неудачу» звучат подкупающе. Однако, в конечном счете, минимизация рисков не является способом получить наибольшую отдачу ни в какой деятельности, в том числе и в разработке. Неудачи необходимы для успеха, просто нужны дешевые неудачи. И контролируемые. Ваша неудача была дешевой?
Это еще более неблагодарное занятие, чем писать библиотеку «на выброс» — компенсировать недостатки в орг.структуре личными усилиями рядового разработчика. Кто-то должен был оценить расходы на такую конструкцию до того, как вы вляпались в поддержку двух ветвей кода — с FP и без, или хотя бы в момент, когда эта конструкция начала создавать проблему. Либо кто-то этого не сделал (и тогда проблема совсем не в ПО), либо кто-то это сделал и решил, что написание boilerplate-кода вашими силами — наиболее дешевый путь (и низкорисковый, кстати). Вы, как человеческий ресурс, для этих людей значите не более, чем для вас значит загрузка конвейера GPU. Похоже, что Вас такой подход не устраивает — и это, пожалуй, проблема.
Статья хорошая. Но содержательная часть этой статьи — об отношениях на фирме, а не о программировании. Ну и небольшая «история неудачи» в добавок.
Ну, ожидать «обычный вкусный объект» от девелопера, который только что накатал 2000 строк write-only кода в единственном методе, это слишком оптимистично.
Если, конечно, там на одного Маркуса целый отдел QA, то они конечно добьются требуемых потребительских качеств. Но в реальности, любой адекватный руководитель заставит такого «разработчика» самого писать тесты на этот код. И тогда диаграмма компонентов (вместе с немаленьким самопальным фреймворком тестирования) будет куда как печальнее
Кому доводилось рефакторить методы из тысяч строк — меня понимает)
В статье не хватает картинок, какой хлеб у обоих на выходе получается. Как я понимаю, у Бориса класс бред (class Bread), но что же у Маркуса? (int)0x80030050?
Не вкусно! )
C мультимедиа таймером ситуация такая: он в принципе даёт миллисекундное разрешение, но при этом имеет где-то в 100 раз большую погрешность за сутки, в сравнении с аппаратным таймером. Называется «выберите либо то, либо другое».
Поэтому обеспечить выполнение некоего кода послезавтра в 12:00:00.000 +- 0.001 с средствами Windows фактически невозможно. Это приводит к весьма своеобразным велосипедам при разработке систем телеметрии — доводилось сталкиваться слегка…
Что-то в этой истории недоговорено, поскольку протокол NTPv4 предусматривает защиту от подобного «цикла» из двух серверов: с помощью нумерации уровней (stratum), и с помощью поля пакета (refid). Может, использовалось какое-то нестандартное ПО?
Верхнюю границу интервала вы оценили неправильно, так как при подключении без burst часть запросов фильтруются (oversampling) и реально при maxpoll==10 может быть обработан не первый полученный пакет, а второй или даже третий. Соответственно вместо рассуждений про рандомное значение — оценку неплохо бы утроить с учётом механизма clock filter)
Поскольку Mercurial — это Git минус проблемы с сабмодулями и минус возможность «сделать что-то не то и сломать репозиторий».
Договоритесь что из дерева и без мотора — и всё станет совсем хорошо) А дальше оценка на основе исторических данных / аналогий, по предпроектным показателям, вполне работает)
Обсуждаемая статья в общем-то не про это. Не про оценку проекта, а про cоставление плана проекта, когда цель более-менее ясна. Хотя бы цель текущей итерации.
Вот картинка «нормального распределения» (представьте, что по оси X — срок, за который будет выполнен план целиком, а по оси Y — вероятность такого исхода):
Естественно распределение вероятных сроков по одной конкретной задаче — не такое, однако в статистике есть теорема, согласно которой сумма множества случайных величин (одного порядка) стремится к нормальному распределению.
Вот на графике: точка, которая помечена «Mean» — это ваш BG (Best Guess), т.е. оценка которая выполнится (или не выполнится) с вероятностью 50%. Точка "-3 sd" — это O, а "+3 sd" — это P. Cам же sd — это среднеквадратичное отклонение от мат.ожидания (показан на графике полоской).
Формула (1O + 4BG + 1P)/6 призвана дать гипотезу о средне-арифметическом сроке выполнения одной задачи (это не то же самое, что оценка 50%). В методе PERT вы потом складываете Mean всех задач по критическому пути проекта, и прибавляете к ним корень из суммы квадратов SD по тому же пути, умноженный скажем на 3 — и получаете 99% дидлайн общего срока выполнения.
Понятно, что это всё теория, которая применима ограничено (например, если все риски по всем задачам выстрелят одновременно, вы улетите далеко за вычисленный по PERT план). Но сама практика учета рисков отдельно от «ожидаемых» сроков всё же улучшает планирование, так что можно и PERT считать :)
Замечание по теории: Пессимистическая и оптимистическая оценка выставляются исходя не из 100% случаев, а из 99%. Это зафиксировано в формуле, где знаменатель 6 — это «три сигма» в обе стороны.
Замечание по практике менеджмента: практического смысла спрашивать у исполнителя все три точки нет никакого. Это связано с тем, что обычно исполнитель не понимает, к чему его, например, обязывает вынесение точной оптимистической оценки (и что он получит, если назовет малое число). Реальная практика обычно такая: либо спрашивается «одна» оценка (которая рассматривается, например, как 70% — где-то по середине между BG и P), либо спрашивается две (реалистичная и пессимистичная, которые используются как BG и P). Что же касается оптимистической оценки, то её (как и вообще все корректировки в оптимистичную сторону) может сделать только менеджер или тим-лид, т.е. человек, ответственный за проект в целом и за риски по срокам в частности. Либо её можно принять равной BG, т.е. вообще не учитывать «положительные» риски в планировании.
При этом, по совокупности, никто не мешает всю эту практику «спроси исполнителя» в итоге сводить в формат PERT (я так делал и у меня это работало), однако надо понимать суть трудовых отношений и не писать в таблицу всё, что вам сказали. Оценки, пришедшие снизу, крайне желательно дублировать другими данными (историческими, внешней оценкой и т.д.).
P.S. Всё вышенаписанное, конечно, относится к программным проектам (где, в отличии от например строительных, нет устоявшихся нормативов). Как я понял, мы говорим про программные проекты)
Если вместо итерационного решения проблемы, о котором Вы говорите, получается «херак, херак и в продакшн», это довольно грустно… но разве не очевидны выводы? Видимо я Вашу точку зрения не вполне уловил. Решения по технологическому выбору, по выбору алгоритмов в любом случае должны делаться квалифицированными людьми и с осознанием последствий.
А вот итог статьи — абсолютно правильный.
К сожалению, призыв «простые вещи должны делаться просто» иногда приводит к разработке API из двух частей: «упрощённой» и «настоящей».
Если реально необходимый объём функциональности будет доступен только на уровне заведомо выше «базового» понимания, то разработка «простых и понятных» (упрощенных) методов, скрывающих настоящую сложность подсистемы — не кажется хорошей идеей. В плохом сценарии, эти методы потребуют много усилий по разработке и поддержке, но окажутся применимыми весьма ограничено.
Поэтому, если причина разработки API — необходимость не просто состыковать программные модули, а скрыть сложность какой-то подсистемы, к вопросу упрощения следует подходить сдержанно, а к проработке API — более серьёзно.
Это еще более неблагодарное занятие, чем писать библиотеку «на выброс» — компенсировать недостатки в орг.структуре личными усилиями рядового разработчика. Кто-то должен был оценить расходы на такую конструкцию до того, как вы вляпались в поддержку двух ветвей кода — с FP и без, или хотя бы в момент, когда эта конструкция начала создавать проблему. Либо кто-то этого не сделал (и тогда проблема совсем не в ПО), либо кто-то это сделал и решил, что написание boilerplate-кода вашими силами — наиболее дешевый путь (и низкорисковый, кстати). Вы, как человеческий ресурс, для этих людей значите не более, чем для вас значит загрузка конвейера GPU. Похоже, что Вас такой подход не устраивает — и это, пожалуй, проблема.
Статья хорошая. Но содержательная часть этой статьи — об отношениях на фирме, а не о программировании. Ну и небольшая «история неудачи» в добавок.
Если, конечно, там на одного Маркуса целый отдел QA, то они конечно добьются требуемых потребительских качеств. Но в реальности, любой адекватный руководитель заставит такого «разработчика» самого писать тесты на этот код. И тогда диаграмма компонентов (вместе с немаленьким самопальным фреймворком тестирования) будет куда как печальнее
Кому доводилось рефакторить методы из тысяч строк — меня понимает)
Не вкусно! )
Поэтому обеспечить выполнение некоего кода послезавтра в 12:00:00.000 +- 0.001 с средствами Windows фактически невозможно. Это приводит к весьма своеобразным велосипедам при разработке систем телеметрии — доводилось сталкиваться слегка…