100% done
Max Pendyschtschuk
Я в курсі, що дана тематика обговорюється всюди, і можливо вже навіть
набридла... Але все ж таки вона важлива і пропоную її обговорити і
тут...
Отже, при розробці проекту важливо використовувати принцип "зроблено
на 100%", інакше ми не впевнені, що проект прогресує... Але досить це
складно пояснити, можливо "заставити" когось робити так, тобто давати
вірну оцінку стану завдання. На практиці люди схильні завищувати
оцінку, щоб не "падати в очах у інших"... Чи як це поянити...
Чи має хтось якісь думки з цього приводу? Наприклад, є програміст,
який репортує завжди, що завдання виконано на 90% у той час коли
насправді виконано на 60% і то з натяжкою... І це при тому, що ніяких
"репресій" не відбудеться, якщо він скаже, що завдання виконано на 60%
у звязку з чимось...
(приклад вигаданий, будь-які "подібності" вважати співпаданням :-))
Макс.
Alexey Krivitsky
отличный топик. то, что эта тема обговаривается везде только
доказывает её важность.
я сейчас работаю в проекте, где, когда я пришел, большая часть задач
была выполнена на 80-95%
что это дало? ничего кроме полной неясности ситуации.
у нас ушло 3 месяца, чтоб понять реальную ситуацию готовности продукта.
макс, проблема не научить давать верную оценку.
проблема научиться говорить "готово или нет" - перейти к двоичной
оценке, ибо только такая оценка несет наименьший обман, а следствие и
наименьшие риски.
нам не важно готова ли задача на 70% или на 85%
нам важно может ли заказчить безопасно использовать фичу или нет.
также нам важно выполнены ли все инженерные практики, оговоренные
командой (тесты, рефакторинг, документация)
так что тут речь о 3 моментах:
1. переходе на двоичную оценку прогресса
2. переходе на оценивание фич (единиц требований), а не задач
3. критериям приема работы (тесты, рефакторинг, документация)
эстимейшины тем не менее важно обновлять по ходу работу.
к примеру нет ничего плохого в выссказывании "мне осталось часа 3 для
завершения задачи", даже если выяснится, что на самом деле на
завершение ушло 5 часов. в этом нет обмана.
лёша
Tim Yevgrashyn
Супер, что ты поднял этот вопрос. Сам давно думаю на эту тему.
Предлагаю всем вместе попробовать докопаться до истины...
Для начала, предлагаю ссылку на главу из книги Джеймса Шора (James
Shore) The "Art of Agile Development", которую он пишет в режиме он-
лайн на своем блоге. В частности нас интересует глава Done Done
(http://www.jamesshore.com/Agile-Book/done_done.html). В ней Джеймс
описывает разницу между пониманием термина Done со стороны
разработчика и со стороны product owner и прочих product-related
людей.
Скорее всего это и есть частичный ответ на твой вопрос. Я думаю, что
программист считает время до конца написания чего-то работающего. При
этом он не учитывает время на:
- commit в CVS (SVN)
- Code Review и возможные исправления после этого
- плюс необходимость документирования кода (javadoc или же обновление
внешней технической документации по модулю)
- ну и конечно время на UnitTests. Если они не были написаны сразу, то
в представлении этого разработчика они вообще идут отдельной задачей,
хотя на практике - они неотъемлемый атрибут разработки :-)
В статье Джеймс даже предлагает некий внутренний чеклист, который
каждый программист должен проверить, прежде чем он скажет "все". Это
должно помочь учесть все виды работ, которые нужно сделать прежде чем
можно сказать "ВСЁ" по отношению ко всему Backlog Item.
На практике же, я думаю, нужно все эти виды работ заносить как
сабтаски в Sprint Backlog на каждый backlog-item. Плюс, использовать
настоятельно рекомендованный подход к разбиению Items на задачи
длинной не более дня. Тогда должно быть четко видно: день прошел, шаг
пройден. Или не пройден, потому что возникли такие-то проблемы
(возможно новые шаги добавили).
Разработчик видит сколько еще _его_ шагов осталось. Все вместе видим
сколько всего шагов осталось до выполнения этого Item. Это то, что в
идеале, дает SCRUM при правильном использовании.
Надеюсь, что объяснил понятно. Если нужны пояснения - не стесняйтесь.
Ну и хоршо бы, чтобы еще кто-то высказался! :-)
Tim Yevgrashyn
wrote:
> макс, проблема не научить давать верную оценку.
> проблема научиться говорить "готово или нет" - перейти к двоичной оценке, ибо только такая оценка несет наименьший обман, а следствие и наименьшие риски.
>
> нам не важно готова ли задача на 70% или на 85%
> нам важно может ли заказчить безопасно использовать фичу или нет.
> также нам важно выполнены ли все инженерные практики, оговоренные командой (тесты, рефакторинг, документация)
О! Почти тоже самое я и имел в виду.
Все необходимые шаги (инженерные и организационные) доложны быть
занесены в план работ (Sprint Backlog) для каждого Backlog Item. Тогда
мы четко отмечаешь прошли мы шаг или нет.
Плюс, оценка каждого шага длинной в день (6 эффективных работчих часов
или кому как удобно), дает возможность отчитаться о прогрессе за
каждый день. Если возникли неучтеннные проблемы (технические,
архитектурные и т.п.) - значит нужны еще шаги и их тоже добавим в
план.
Когда оценка не один день - возникает как раз ситуация "почти
сделал" :-)
Max Pendyschtschuk
Это видомо вечная пробоема программиста - давать оценку только на
написание кода, а все прочее... выливается в овертайм и т.п.
И двоичная система "сделано - не сделано", это тоже урок...
Спасибо.
ArtyRak
90% готовности функции (выполненности задачи). Поскольку ни в одном из
промежуточных случаев нельзя приступать к тестированию (не говоря уже
о внедрении). Поэтому стандартной практикой для меня лично является
оценка "выполнено/не выполнено". И если разрабочик/команда видит, что
за час/день потраченного времени выполненность нельзя рапортовать как
100%, функция/задача делится на части.
Точно так же, при оценке всех работ итерации, работы, которые сложно
оценить в часах, разбиваются на части. Иногда это невозможно сделать
но начала разработки. В таких случаях помогает "пилотирование",
определение контрольных вопросов и выделение функции в отдельное
"тестовое" приложение.
Оценку 75% и 90% я иногда все же применяю для случаев, когда
разработчик получает часть кода "по наследству" и этот код нужно
пересмотреть, отладить и интегрировать в приложение. Но в таком случае
75% - это тоже чистая фикция, которая лишь отражает степень
"знакомости" данной функции разработчику.
Вот где действительно полезны промежуточные %, так это в оценке хода
выполнения проекта. Причем календарный график проекта в первом
приближении можно делать не очень тщательно, и не морочить голову
зависимостями функций/работ. Достаточно "выровнять" загрузку
участников проекта, а потом регулярно переставлять работы и отмечать
выполненные. % выполнения в этом случае служит индикатором
"ошибочности" начальной оценки. Если мы потратили 75% времени из
запланированного, а задачи выполнены только на 10%, значит пришло
время остановиться и тщательно пересмотреть цели и границы проекта.
Иначе мы рискуем вообще ничего не сделать даже после сорванных сроков.
Ну и последний момент с %. Иногда разработчик не очень опытен в
командной работе и в самооценке. В этом случае он склонен
перестраховываться, рапортуя о том, что функции не готовы на 100% (но
еще немного, и будут готовы). И при этом он начинает разработку
очередной функции не закончив предыдущую. На вопрос "Почему?" отвечает
- "Я еще не все проверил, есть ряд идей, которые я еще не обмозговал.
Вот закончу с запланированным и...". В этом месте следует обрывать
рассуждения и настаивать на возвращении к недоделанной работе. Обычно,
у нормального специалиста на самом деле функция уже готова, просто
есть желание сделать ее "лучше", и даже есть идеи как. В этом случае
лично мне очень помогает принцип "Make it compile, make it run, make
it right, make it fast". Нет ничего страшного в том, что бы передать в
тестирование функцию уже на втором шаге. А после третьего это просто
обязательно для большинства функций в прикладных системах. Если этот
принцип правильно аргументировать и продуманно применять с такими
"перестраховщиками-перфекционистами", можно получать результат гораздо
быстрее и без потери качества :)
On 19 фев, 09:59, "Max Pendyschtschuk" <gotischer...@yahoo.de> wrote:
Theme
Задание выполнено когда проходят приемочные тесты,
если, конечно, они у вас есть ;)
А модульное тестирование и рефакторинг -- отличные вещи, улучшающие
код
Кстати, а как вы объясняете клиентам зачем нужно время на рефакторинг
системы ?
Alexey Krivitsky
On 2/20/07, Theme <the...@gmail.com> wrote:
> Кстати, а как вы объясняете клиентам зачем нужно время на рефакторинг
> системы ?
мы не объясняем - небольшие рефакторинги включены в эстимейты задач по
умолчанию.
ну а для больших - нужно писать отдельные истории, чтобы заказчики
видели для себя прибыль от их выполнения.
последнее касается больше legacy кода
borys....@gmail.com
Код должен быть соответствовать тому, что планировалось делать, покрыт
юнит тестами, задокументирован и проверен другим программистом.
Здесь вопрос чисто психологический: нужно обосновать необходимость
проведения рефакторинга. Нужен индивидуальный подход
Вообще-то у меня иногда получается донести до ума заказчика Business
Value рефакторинга, даже до тех его представителей, которые далеки от
разработки софта. Здесь нужна гармоничная смесь Дейла Коренеги и
Дональда Трампа (а иногда и Фрейда :))
Убедительно доказать, что рефакторинг снижает цену дальнейшей
разработки
Показать, что это снижает количество потенциальных багов.
оперировать графиками и цифрами
да мало ли что ... это же проще чем сочинение по русской литературе ;)