Комментарии 29
Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч — 150ч — готово на 90% — осталось еще 90%
— Да, можно отправлять заказчику, *неразборчиво*.
— Что?
— Да, говорю, тесты писать времени не было, будем надеяться у заказчика заработает.
— На тесты сколько времени ещё надо?
— Да там немного, порефакторить ещё только сначала, а ту часть, которую Вася делал, вообще с нуля переписать надо, там всё плохо, невовремя он уволился, некому разбираться теперь. Дима, который вместо него пришел, говорит надо новый фреймворк использовать, он гораздо удобнее и быстрее можно всё сделать, повезло нам, его в прошлом месяце выпустили, говорят очень хороший, на голову выше аналогов.
Если это так, то возможно тот, кто управляет проектом, не делает свою работу или делает ее очень плохо?
2. Согласовать
Я не занимаюсь пластиковой картой, но по моим наблюдениям любой пункт со словом «Согласовать» непредсказуем. М.б. очень быстро, а может очень долго.
Так и есть. Любые пункты, подразумевающие коммуникации с третьими сторонами непредсказуемы по времени. Особенно если третья сторона за океаном, в другом часовом поясе и говорит на другом языке. Планы никогда не выдерживают встречи с реальностью, я написал это.
Главная мысль в том, что управляющий проектом должен заложить в график некий запас времени на эти коммуникации, чтобы по ходу пьесы понимать отчего время идет, часы расходуются, а функционал не реализовывается.
Вообще появление в списке задач пунктов, подразумевающих масштабные коммуникации, для опытного управляющего представляют собой сигнал о том, что необходим резервный план действий. И это отдельное искусство, потому что с одной стороны надо постараться избежать простоя в работе, с другой стороны не отморозить разработчиков постоянными переключениями между контекстами работы.
Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.
Как пользователь, я хочу оплатить заказ пластиковой картой
Откуда 30 часов?
А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?
Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.
А почему нет?
- Как AI, я хочу спрогнозировать направление следующего движения игрока
- Как система, я хочу прочитать список команд устройства X
- Как система моделирования освещенности, я хочу вычислить компенсацию отражения от плоской поверхности из материала Y
Я бы сказал, что оно применимо, но при одном дополнительном условии, которое автор не сформулировал достаточно четко.
Описанный способ хорошо работает, если разбиение происходит на задачи, объем каждой из которых достаточно мал, скажем часы. В этом случае оценки получаются близкими к реальности. Если вы это можете сделать для игр или CAD — это даст реалистичную оценку. Если нет — точность оценки будет низкая.
P.S. Никакого принципиально более хорошего способа оценки, кроме как декомпозиция и оценка задач по частям, на мой взгляд все равно в природе не существует.
Если вы это можете сделать для игр или CAD — это даст реалистичную оценку.
Я не смогу сделать это для игр или CAD, ибо это не моя предметная область. Однако я полагаю, что если руководитель проекта, управляющий разработкой игр или CAD, совместно с разработчиками, программирующими в этой же сфере будет постоянно, осмысленно и осознанно практиковать описанные мной в публикации действия, то точность оценки будет постепенно нарастать.
Я бы сказал, что оно применимо, но при одном дополнительном условии, которое автор не сформулировал достаточно четко.
Описанный способ хорошо работает, если разбиение происходит на задачи, объем каждой из которых достаточно мал, скажем часы.
У меня была мысль, в дополнение к утверждению:
Во-вторых, требуемый функционал достаточно четко ограничен в объеме используемых данных и во времени.
Добавить рассуждения на тему количества значений переменных, используемых в операции, но мне показалось что это опять же приведет к размыванию основной идеи.
Откуда 30 часов?
Часы указаны в качестве примера того, как управляющий может сделать пометку о прогнозе запланированного времени в системе визуализации процесса управления. Это не сумма реальных часов, необходимых на реализацию оплаты пластиковой картой.
Я не вычислял время для статьи потому что при этом надо учитывать например платежный шлюз, с которым осуществляется интеграция. Текст бы сильно распух, и основная простая мысль, которую я хотел озвучить, размылась бы.
А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?
Я понимаю что 5 минут это утрированный пример. Как показывает опыт, даже если платежный шлюз действительно выдающийся, и у него исключительно понятная документация для разработчиков и она полностью соответствует действительности, и мы используем готовый виджет для отправки собственно платежа, то мы просто экономим какое-то время на пунктах исследований, коммуникации и разработки платежной формы, а остальные пункты из списка никуда не деваются. Так что нет, в любом случае не 5 минут.
Хотя, опять же — о каких задачах мы говорим? Я — о, например, рефакторинге очень старого кода, спагетти, больше 10К строк С, написанным в 90х, с нулевым беспокойством о времени жизни указателей, с нулевым беспокойством о переиспользовании переменных, с отключенными варнингами и прочими прелестями. При этом код не покрыт тестами более чем на 80% и трудится 24/7 в production.
Я честно оценил в 3 мес. Разложил по косточкам план и оценил. Не лукавя. 10К строк. Эка невидаль. Запросил 9 мес и по факту едва уложился в 8. Т.е. с опережением, но минимальным.
а про составление самого списка, есть ли в нем структура. последовательность, правила какие
Структура обычно 2-3 уровня.
Правила — от development cycle зависит. В случае scrum/agile правила одни, в других случаях — другие. Т.е. это бизнес практики компании. Если у вас их нет, то можете попробовать взять — в книжках подробно описаны. Сэкономите время на изобретение велосипеда.
В приведенном примере это не 100% рефакторинг. Там нужно было вычленить 4 этапа работы кода, и 2 из них, нечетные, перенести на клиента, обеспечив его библиотекой, с прежним внешним API, а меж собой эти куски должны взаимодействовать за минимальное количество вызовов RPC. Т.к. это внутренний сервис компании, то там довольно много клиентов сервиса, которые не перейдут на новую клиентскую библиотеку одномоментно. Им нужен старый API. А код мы хотим выдрать из сервиса уже сейчас, чтобы улучшить масштабируемость. Окей, значит мы делаем брокеров, которые транслируют API. Ну вот сидишь, изучаешь, рисуешь и планируешь неделю или две. Ставишь сроки. Умножаешь на 3. И утверждаешь в планы.
Как разработчик, я хочу рефакторить 10 тысяч строк кода — это слишком масштабная история. И если к примеру с этим кодом никто не знаком из разработчиков, то прежде, чем взяться за планирование, надо потратить время на исследование этого кода. Потому что — как планировать неизвестность?
Если бы мне пришлось управлять таким рефакторингом, я бы не взялся сходу за прогнозирование затрат времени на всю реализацию целиком, а попробовал бы сделать это частями. Изучаем часть кода, пишем тесты, выполняем рефакторинг, прогоняем тесты.
Да. Именно это я и имел в виду, когда написал что прежде, чем взяться за планирование рефакторинга 10К кода, надо потратить время на исследование этого кода.
Поэтому привлекаем интуицию. Это еще называется educated gut feeling :)
И если известно насколько она ошибается и в какую сторону, то можно скорректировать цифры в противоположенную сторону.
А задач по сопровождению существующей функциональности, по-моему, гораздо больше, чем на реализацию новой…
Возможно, точно так же, как в случае, когда функциональность ещё не реализована? Ну, может быть, добавится ещё один пункт: изучение текущей реализации. Просто теперь будут другие оценки времени на выполнение требований.
Если SRS ещё нет — её нужно разработать, если есть — адаптировать. Затем на основе SRS разработать/адаптировать HLD. (По сути, написать/адаптировать документацию и ПМИ. Нужен ли далее DLD или в качестве него будет выступать непосредственно патч изменений — это уже зависит от размера компонента.)
Если мы говорим в общем, то нужно учесть и случай с крупными компаниями, где множество систем, интеграций и давно устоявшиеся процессы. И тогда, чтобы разбить юзер стори на мелкие задачи нужен не только разработчик, а ещё аналитик и/или архитектор. А ещё, не редко, нужны и разработчики из других систем. Потому что стори "Я как пользователь хочу оплатить заказ пластиковой картой" выливается в то, что в системе разработчик должен вывести на экране кнопку, которая будет вызывать систему, отвечающую за формирование заказов в эквайрингах. Но эту кнопку нельзя выводить всем, а нужно проверить, что юзер не находится в черном списке. А чтобы вызвать систему с черными списками, нужно сынтегрироваться с ней. А в их доке написано, хост такой-то, порт такой-то. И только архитектор или разработчики той системы знают что она использует аутентификацию через KeyCloak. А чтобы целевая система могла обращаться к KeyCloak и к системе с черными списками, нужно заказать сетевые доступа. Также чтобы и система по формированию заказов могла вызывать новый эквайринг нужны сетевые доступа. Но ещё есть финансовая система учёта. И система по формированию заказов должна сынтегрироваться и с ней, чтобы правильно отправлять в нее инф по заказам в новом эквайринге. Но разработчики не знают какие данные нужны для учёта. Нужно это узнать у аналитика финансовой системы или бухгалтеров. И т.д.
Поэтому нужно по нескольку раз обойти архитектора, аналитиков, разработчиков и продукт овнеров, а потом полученную оценку умножить на 1,5
Простые практики прогнозирования временных затрат