"Он почти готов, но мне просто нужно протестировать некоторые крайние случаи" "
Вот Часть 1.
В предыдущем посте я рассказал, что такое оценки программного обеспечения и из чего они состоят. Теперь самое интересное. Из нашего опыта в Code Runners мы собрали несколько полезных практик, которые делают оценку быстрее и точнее.
Например, сеансы груминга призваны прояснить цель и задать правильное направление. Вы должны поощрять разработчиков задавать все возможные вопросы, чтобы уточнить спецификацию. Следует подчеркнуть, что не должно оставаться тени в отношении того, что необходимо сделать. Конечным результатом сеанса должна быть понятная и понятная история пользователя. Как я уже упоминал в предыдущем посте - никогда не делайте предположений относительно требований пользователя.
На этапе предварительного планирования обязательно проверьте существующий код и его поведение. Это поможет вам проанализировать сложность задачи с технической точки зрения, учитывая влияние новой функции на существующие. Часто есть зависимости, которые невозможно выяснить, не пройдя сначала базу кода. Результатом должна быть история, понятная с точки зрения реализации. Если требуемая функциональность слишком велика для оценки, ее можно разбить на более мелкие части, которые затем легче оценить.
Метод, который мы часто используем для оценки проектов, заключается в сравнении с предыдущими аналогичными проектами, которые мы реализовали. Вот почему нам нравится сосредотачиваться на проектах в конкретных отраслях - с каждым успешно завершенным проектом мы становимся все лучше и лучше на каждом этапе процесса разработки, включая оценку. Еще одна уловка - это добавление буфера на 20–30%, в зависимости от сложности проекта и ясности требований заказчика. (Обновление: спасибо, Джеймс Кингсбери за совет относительно буфера оценки)
Компании часто используют противоречивую практику, называемую «покер планирования». В нем члены команды разработчиков записывают свою личную оценку на листе бумаги и одновременно демонстрируют ее. Далее следует обсуждение каждого личного прогноза и обоснование того, как член команды выбрал это количество времени. Я называю это спорным, поскольку иногда это может иметь неприятные последствия, если разработчики начнут конкурировать, снизив свои оценки. Знание этого риска может помочь компаниям избежать его, сообщив команде о важности игнорирования личного эго в пользу более эффективного рабочего процесса.
Ранее мы упоминали о важности четкой пользовательской истории, прежде чем делать точную оценку. Но функциональные истории могут сильно отличаться от технических, и если помнить об этом различии, это может значительно улучшить возможности команды по оценке.
Во-первых, функциональные истории гораздо более осязаемы и лучше определены. Они могут быть разбиты на конкретные более мелкие задачи или части функциональности. Эти истории также можно выделить в определенную часть всей системы. Благодаря тому, что они становятся настолько подробными и конкретными, разработчики получают больше информации о влиянии нового кода и упрощают оценку потенциальных регрессов.
С другой стороны, технические истории гораздо более расплывчаты, хотя конечная цель определена. Это значительно затрудняет их оценку и увеличивает вероятность возникновения непредвиденных проблем в системе. Кроме того, они с большей вероятностью включают неизвестные технологии, которые также вызывают неожиданные проблемы во время разработки.
Еще одна вещь, которая может помочь команде стать более точной в своих оценках, - это учет количества эффективных рабочих часов, содержащихся в фактических часах. Обычно это максимум от 6 до 7 часов. Эта сумма дополнительно уменьшается, если человек также участвует в других задачах, таких как управление проектами, действия Scrum-мастера, поддержка других членов команды, интеграция и развертывание, а также дополнительные встречи.
Делая шаг вперед, команды также должны учитывать, сколько эффективных дней входит в недельный спринт разработки. Выделив время на планирование, уход за телом, демонстрацию, ежедневные стендапы и ретроспективные сеансы (если применимо), время, оставшееся на фактическое кодирование, значительно сокращается.
На нашем недавнем внутреннем семинаре мы также обсуждали, когда определенная задача считается выполненной. Мы считаем, что это чрезвычайно важно, поскольку позволяет еще больше повысить точность оценок за счет определения точной точки остановки «таймера». Для завершения любой данной функции необходимо отметить следующие поля:
- Анализ с технической точки зрения завершен.
- Глобальный дизайн (архитектура) завершен.
- Детальный дизайн (кодирование) завершен.
- Модульный тест завершен.
- Проверка кода завершена.
- Интеграция завершена.
- Основные интеграционные тесты завершены.
- Основные регрессионные тесты завершены.
- Документация (например, обновление описания API) завершена.
Представляя этот список, наша команда может четко отмечать свой прогресс и видеть, что на самом деле сделано, а что осталось. Мы также ввели список фраз, которые четко передают, что что-то определенно не сделано.
- «Это работает, но ...»
- «Готово, но мне нужно доработать пару вещей».
- «Готово, но я не тестировал».
- «Готово, но мне нужно еще несколько часов, чтобы проверить крайние случаи».
- «Ничего страшного, но конфликтов много, так что мне, наверное, понадобится день, чтобы слиться».
- «Это работало раньше».
- «Это работает на моей машине».
- "Готово. (три дня спустя) Хорошо, теперь все готово »
Оценки трудны. Чтобы сделать их правильно, нужно время и практика, и даже в этом случае они могут выйти за рамки фактического графика из-за непредсказуемых обстоятельств. Существуют различные методы и приемы, которые команды могут использовать для более эффективных оценок, но первым шагом является признание важности оценок и принятие активных мер по обучению вашей команды тому, как она становится лучше.
Вы можете посмотреть исходное сообщение на нашей домашней странице.
