Проворная оценка – предпосылки для более точных оценок


Узнайте, как улучшить свои навыки оценки Agile!

Оценка является одним из важных этапов разработки программного обеспечения. Понимание этого будет большим риском для других действий. Вы получите много контента в Интернете, чтобы понять различные типы оценок в Agile. Некоторые из них похожи на игру в покер, определение размера футболки, точечное голосование, аффинное картирование и т. Д. Вы выбираете любой метод оценки, он будет работать неправильно, если у вас нет необходимых условий для процесса оценки.

Я буду обсуждать эти важные предпосылки для правильной оценки в моей статье.

Вам также может понравиться: Проворная оценка: что сработало для нас!

Опыт и оптимизация

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

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

Целостный подход и более глубокий анализ

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

Это также зависит от ваших лучших практик доставки, если вы считаете, Модульный тест, Автоматизация, Доступность, поддержка устройств являются частью критериев готовности, тогда оценка будет другой. Конечно, я определенно рекомендую, чтобы все эти лучшие практики были частью вашей оценки. Эти лучшие практики необходимы для качества и лучшего обслуживания. Они сократят стоимость в долгосрочной перспективе.

Таким образом, здесь речь идет о предпосылках, прежде чем войти в процесс оценки, независимо от типа метода оценки.

Важность ретроспективы

Имея опыт более 19 лет разработки программного обеспечения, я очень счастлив и горжусь тем, что мы столкнулись лишь с несколькими неудачными случаями. Критическая вещь, которой мы следовали, – это изучение предыдущего опыта. Важно определить аспект, который вызвал турбулентность в процессе и сделал его неудачным.

В Agile очень важна ретроспектива каждого спринта в положительном ракурсе. Делать ошибки – не проблема, но не ретроспективно их искать, и найти решение этих ошибок – проблема. Поскольку мы выполняем более частые поставки в agile, очень важно исправлять ошибки как можно раньше.

Я настоятельно рекомендую делать ретроспективу после каждого спринта очень непредвзято, определять области для улучшения и находить решения для них. Убедитесь, что они вступают в действие сразу после следующего спринта.

Предпосылки для правильных оценок

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

Выровняйте Землю

Команда разработчиков и команда управления продуктами должны находиться на одной странице. Команда разработчиков должна понимать бизнес-цели наравне с командой управления продуктом.

Кроме того, понимайте цели команды управления продуктом и определяйте необходимые требования для поддержки роста бизнеса.

Это поможет вам выбрать тип необходимой архитектуры. В соответствии с бизнес-целями, ожидание будет расти с точки зрения размера (пользователь, объем данных) в дорожной карте, тогда архитектура должна будет отличаться от более коротких бизнес-целей.

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

Детализируйте требования

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

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

Вам необходимо как можно более подробно описать требования, чтобы получить правильные оценки. Если вы ожидаете высокоуровневых оценок, понимайте требования более широко, а не глубже.

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

Хорошо определенная сфера

Понимая требования и проектируя системы, важно понимать объем требований. Самое главное, что находится в области видимости и вне области видимости.

Уровень реализации, необходимый для бизнеса. Некоторые из вопросов, которые нам нужно задать, чтобы определить сферу

  • Есть ли у нас возможности по разработке продукта для онлайн или оффлайн или для обоих?
  • Понять план продукта в долгосрочной перспективе. Он будет определять срок службы продукта, помогает учитывать архитектуру, необходимую для поддержки срока службы продукта.
  • Какой тип нагрузки должна поддерживать система?
  • Нужно ли поддерживать мобильных пользователей, нужно ли иметь мобильное приложение или нет?
  • В случае веб-приложения, уровень поддержки, необходимый для устройств, доступности и т. Д.

Подобные вопросы очищают разрыв между бизнесом и инженерными командами. Это поможет вам получить более точные оценки.

Спайки исследований

Есть много случаев, которые невозможно оценить по нескольким причинам.

  • Нет контакта с технологией или доменом.
  • Комплексные требования.
  • Технологические проблемы.

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

Сбалансированная команда

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

Команда должна состоять из старших и юниоров. Это даст разные восприятия при выполнении оценок. Это поможет прийти к хорошей оценке.

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

Нефункциональные требования

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

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

Дальнейшее чтение

Методы оценки

Прекратить оценку: движение #NoEstimates в Agile

4 вещи, которые я включаю в свои гибкие оценки