Create: Update:
Красивая картинка про оценки трудоемкости разработки софта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
Красивая картинка про оценки трудоемкости разработки софта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
>>Click here to continue<<
Системный сдвиг
