Самой большой проблемой в индустрии разработки программного обеспечения является неспособность прогнозирования времени завершения задач с достаточно высокой точностью. Очень часто — это происходит из за того, что разработчики позволяют себе давать беспочвенные предположения по времени завершения для достаточно объемных или неопределенных задач.
Возьмем для примера ситуацию, когда мы говорим о разнице между временем реализации 1 часовой и 2х часовых задач. Нам довольно просто оперировать подобными цифрами и объяснить почему выполнение одной задачи займет на час больше времени не составит труда. Но когда разговор заходит о разнице между 34х часовой и 35и часовой задачами, обоснование подобной одночасовой разницы выглядит совершенно невероятным. Собственно подобное сравнение показывает, что лучшие эстимейты зависят от величины оцениваемых задач.
Итак мы пришли к выводу что наши стори (User Story), должны быть разбиты на небольшие части (чем меньше части, тем большая точность оценок). Насколько маленькими должны быть эти части? Ответ на этот вопрос заключен в названии двухдневного метода.
Наверное самое хорошее в этом методе то, что в нем существует только одно правило — разбивайте ваши юзер стори на части не превышающие по времени реализации 2 дня.
Этот простой метод приведет также к появлению многих, не совсем очевидных, но хороших и полезных привычек:
— Поспособствует изучению/обсуждению непонятных или больших частей функционала;
— Заставит разделить большие юзер стори;
— Разовьет вашу способность узнавать то, что было не очевидно в начале;
Я не собираюсь убеждать вас в том, что все истории могут быть разбиты на небольшие части длительностью до 2х дней, однако я утверждаю, что большинство из ваших историй подошли бы под этот двухдневный метод.
Независимо от того решите ли вы просто проверить мой метод или попробуете справиться с реальной проблемой на вашем проекте я обещаю, что вы увидите его преимущества уже через пару дней… ну или я гарантирую вам 100% возврат ваших денег!
От переводчика
Хотел бы дополнить автора и сказать что подобный метод хорошо подходит для высокоуровневой оценки юзер стори и сослаться на методы применяемые при подготовке эстимейтов в экстремальном программировании таких как Метод Функциональных Точек, пересчет эстимейтов на основании полученного результата — Метод Вчерашней Погоды и Велосити, которые хорошо описанны в книге User Stories Applied: For Agile Software Development
.
Возьмем для примера ситуацию, когда мы говорим о разнице между временем реализации 1 часовой и 2х часовых задач. Нам довольно просто оперировать подобными цифрами и объяснить почему выполнение одной задачи займет на час больше времени не составит труда. Но когда разговор заходит о разнице между 34х часовой и 35и часовой задачами, обоснование подобной одночасовой разницы выглядит совершенно невероятным. Собственно подобное сравнение показывает, что лучшие эстимейты зависят от величины оцениваемых задач.
Итак мы пришли к выводу что наши стори (User Story), должны быть разбиты на небольшие части (чем меньше части, тем большая точность оценок). Насколько маленькими должны быть эти части? Ответ на этот вопрос заключен в названии двухдневного метода.
Наверное самое хорошее в этом методе то, что в нем существует только одно правило — разбивайте ваши юзер стори на части не превышающие по времени реализации 2 дня.
Этот простой метод приведет также к появлению многих, не совсем очевидных, но хороших и полезных привычек:
— Поспособствует изучению/обсуждению непонятных или больших частей функционала;
— Заставит разделить большие юзер стори;
— Разовьет вашу способность узнавать то, что было не очевидно в начале;
Я не собираюсь убеждать вас в том, что все истории могут быть разбиты на небольшие части длительностью до 2х дней, однако я утверждаю, что большинство из ваших историй подошли бы под этот двухдневный метод.
Независимо от того решите ли вы просто проверить мой метод или попробуете справиться с реальной проблемой на вашем проекте я обещаю, что вы увидите его преимущества уже через пару дней… ну или я гарантирую вам 100% возврат ваших денег!
От переводчика
Хотел бы дополнить автора и сказать что подобный метод хорошо подходит для высокоуровневой оценки юзер стори и сослаться на методы применяемые при подготовке эстимейтов в экстремальном программировании таких как Метод Функциональных Точек, пересчет эстимейтов на основании полученного результата — Метод Вчерашней Погоды и Велосити, которые хорошо описанны в книге User Stories Applied: For Agile Software Development
.