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

Алилуя!

интересно будет узнать сколько старт у PureScript
а то нода оказывается жутко резвой)

целых два?!

Есть опыт применения Elm в боевом продукте? опять таки волнует вопрос переучивания/интеграции разработчиков на функциональную парадигму

те по вашему все єто ООП зло? И его просто очень удобно впаривать неокрепшим умам топ-менеджеров? те все о чем написано столько книг, фреймворков, семинаров, мультиков — все это блажь, ложь, и мираж? неужели вы намекаете на то, что нас всех развели?

Юрий — возможно вы не совсем полностью овладели ООП? Вы хотите об этом поговорить?

1) как обстоят дела с вливанием новых людей в команду?
2) как обстоят дела с поддержанием старого кода?
3) на что похож ваш функциональный язык?
4) у вас выработались какие-то best practise и code styles для вашего языка? что такое «красивый функцилнальный код» по вашему мнению?
5) было ли у вас чувство — а вот с этой задачей отлично бы справился ООП подход?
6) есть ли у вас метрики, что подтверждают "

высокое качество своего продукта и поддерживать его в соответствии с требованиями

" или это интуитивное чувство?
7) если бы вы писали проект с нуля сегодня — какой язык/платформу бы выбрали?
8) возникали ли вопросы с оптимизацией функционального кода?
спасибо

прагматично, даже слишком

спасибо, ошибка исправлена

Совместима ли такая оценка с итеративной разработкой по Agile методологиям?

- в изложенном варианте нет

Требуют ли клиенты оценки готовности проекта, если знают, что разработка будет вестись гибким методом, с внесением нужных изменений каждые 2-4 недели и постоянной интеграцией? И если да, что понимается под «готовым» проектом — его первый выход в свет с минимальным функционалом, какой-то перечень необходимых функций, или ещё что-то?

— зависит от клиента) Но обычно оценка всего проекта я производил с целью получить общее представление о сроках проекта, и, соответсвенно, его стоимости.

Насколько есть уверенность, что описанная математика универсально годится для качественной аппроксимации времени исполнения с учётом иерархии задач?

— уверенности никакой) Мат метод не универсальный — зависимые друг от друга задачи им нельзя расчитывать.

Все числа, похоже, рассчитаны из какой-то фиксированной модели, типа ровно 1 этапа деления на подзадачи.

— да, варианты разбития задач на подзадачи данный метод не рассматривает.

Насколько можно доверять авторам оценок элементарных задач на настолько крайних уровнях вероятности (5, 95%)?

— именно для компесации крайних занчений Номинальноме значение учитывается с весом в 4 раза больше крайних. ->
На сколько именно можно доверять крайним оценкам — в 4 раза меньше уровня доверия к номинальной оценке

Описанный метод — это одна ступень эволюции от оценки типа «Ну где-то за месяц справимся». И применение его для иерархических или зависимых задач требует серейзной доработки

Большое спасибо — ошибка исправлена

попробую

Гадал на кофейной гуще. Не оценили)

В статье не написано об очень важной штуке

 — работв с рисками/assumptions это тема для отдельной статьи)

Все методы и вычисления распределений разобьются о первый же проявленный риск или багу в сторонней библиотеке.

- мой метод по опыту разбивается не о первый, а где-то о третий риск/багу

А все системы и диаграмы — всего лишь красивая, но зачастую бесполезная обёртка.

— бесполезная для непосредственного жтапа разработки — возможно. Но красивые графики и диаграмы могут быть полезны на этапе продаж, рекламы и т.д.

Есть, не покажу — NDA )

Расчет времни приведен как пример. Не более.
В статье прикреплена экселька, куда вы можете подставить адекватные по ващему мнению данные

Нельзя оценивать разработку трех разных проектов по срокам

 — при условии, что вы знакомы со стилем вашего написания и стилем ваших коллег — можно

Оценка должна зависеть от комплектность/на время...

— Простите, немного не понял, что имеется в виду под комплектностью

Вообще он(д. Боб) часто путается сам в себе и действует не последовательно и не логично

- никто не идеален)

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

Группа программстов, ктороая почему-то вместе (команда) — я думаю целесообразна почти всегда

Когда такое возможно, что есть какая-то стабильная общность программистов, как одно неделимое целое?

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

Когда цель ясна, правила понятны, то желание:

— да, когда цель ясна и правила понятны — все хорошо)

Мои вопросы как ра- предназначены для случаев когда цуль не ясна, и правла тоже)

К сожалению да(