Главная » Хабрахабр » Простые практики прогнозирования временных затрат

Простые практики прогнозирования временных затрат

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

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

Сформулировать описания функциональности

Лучший на мой взгляд способ — это достаточно давно придуманный формат пользовательских историй или шаблонов поведения (use cases): Основа хорошего планирования, хорошо сформулированное описание функциональности, которое необходимо реализовать.

Как пользователь, я хочу оплатить заказ пластиковой картой

Ясностью. Чем хороша такая формулировка? Чем меньше информации, тем меньше вероятность совершения ошибки. Хороший управляющий сознательно ограничивает объем информации доступный участникам для обсуждения.

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

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

Определить списки задач

Дальше необходимо каждое из описаний функциональности разбить на задачи. Что дальше? Что включать в список задач? Делать это необходимо вместе с разработчиком, который предположительно будет выбранную функциональность реализовывать. Если разработчик видит задачу впервые и ранее не касался ее, то буквально все действия, которые предположительно могут потребоваться, включая исследовательские и коллаборационные:

  1. Изучить документацию по интеграции с платежным шлюзом, касающуюся части платежей пластиковыми картами
  2. Согласовать со специалистами платежного шлюза выбранный способ подключения и осуществления платежей
  3. Согласовать с руководителем проекта выбранный способ подключения и осуществления платежей
  4. Реализовать хранение и извлечение данных, необходимых для взаимодействия с платежным шлюзом (идентификаторы клиента, ключи безопасности)
  5. Реализовать получение и подготовку данных о заказе, который будет оплачен
  6. Разработать (подключить предоставленную платежным шлюзом) форму для ввода данных пластиковой карты пользователем
  7. Реализовать передачу данных о заказе и его стоимости в форму оплаты
  8. Реализовать получение, обработку и сохранение данных об успешном выполнении платежа
  9. Реализовать обработку ошибок, произошедших в ходе выполнения оплаты
  10. Реализовать отображение пользователю квитанции о выполнении оплаты
  11. Реализовать отображение пользователю сообщения об ошибках, произошедших в ходе выполнения оплаты

После того, как список готов, попросите разработчика поставить оценку в конце описания каждого из пунктов в рабочих часах. Чем более подробный список, тем ближе к реальности будет оценка времени на разработку. Почему я говорю примерно? Просуммируйте часы и предполагайте что на получившееся время можно примерно ориентироваться. Запланировать все невозможно, и неожиданности почти всегда всплывают в ходе работы. Потому что планы, никогда не выдерживают встречи с реальностью. И чем подробнее будет ваш список задач, тем меньше неожиданностей может произойти, и тем меньше дополнительного времени потребуется для того, чтобы разобраться с этими неожиданностями.

По мере выполнения пунктов в списке задач, попросите разработчика указывать фактически затраченное на задачу время, таким образом у вас появится возможность оценить качество вашего планирования.

Инструменты

Я считаю в управлении следует полагаться на здравый смысл и принцип сохранения простоты. Я не сторонник дорогих или не очень понятных инструментов планирования, с покером, диаграммами сгорания и story point-ами.

И там и там описания функциональности можно оформить в виде карточек в списках, и к каждой из карточек можно прикрепить список задач с указанием прогноза по времени выполнения просто в виде числа через тире в конце описания: Для успешной визуализации управления процессом разработки достаточно тривиальных средств, таких как Трелло или доски проектов Github.

Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч

Это можно делать каждый вечер, в конце рабочего дня: Ничто не мешает руководителю проекта при этом добавить к описанию еще и уже фактически затраченное время.

Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч — 15ч

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Python Testing с pytest. Начало работы с pytest, Глава 1

Вернуться Дальше Это уже приносит мне дивиденды в моей компании.Chris ShaverVP of Product, Uprising Technology Я обнаружил, что Python Testing с pytest является чрезвычайно полезным вводным руководством к среде тестирования pytest. 6 и pytest 3. Примеры в этой книге написаны ...

[Перевод] Python Testing с pytest. ГЛАВА 3 pytest Fixtures

Вернуться Дальше Эта книга — недостающая глава, отсутствующая в каждой всеобъемлющей книге Python. Frank RuizPrincipal Site Reliability Engineer, Box, Inc. 6 и pytest 3. Примеры в этой книге написаны с использованием Python 3. pytest 3. 2. 6, 2. 2 поддерживает ...