Стратегии, которые помогут вам в разработке программного обеспечения

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

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

Фон

Высокие ставки

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

Гибкий

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

Причины, по которым оценка не идеальна

Давление для выполнения

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

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

Люди борются с оценкой

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

Неточная информация

  • Масштаб — требования к любому проекту, задаче или подзадаче чрезвычайно важны, когда дело доходит до оценки. Если требования не полностью поняты, бизнес-проблема редко понимается, и, конечно же, сроки завершения работы, скорее всего, будут неточными.
  • Ограничения ресурсов — могут быть встречи, которые должен посетить разработчик, или другие ошибки, возникающие в работе, которые необходимо исправить. И не только это, но что, если в проекте не предусмотрены активы, необходимые для создания функции вовремя? Если каких-либо ресурсов не хватает, это, скорее всего, повлияет на время, необходимое для создания функции или улучшения некоторого кода, и еще труднее заранее увидеть, когда эти ресурсы вряд ли будут доступны.

Решения

Приоритет функций

Вы можете использовать простой набор уровней приоритизации: это может быть что-то простое, например:

Должен, должен, может, не будет.

Первыми в крайнем случае должны быть те вещи, которые программа «Может» делать. Затем мы переходим к вещам, которые программное обеспечение «должно» делать, и если вы начнете слишком углубляться в то, что программное обеспечение «должно» делать, вы явно столкнетесь с серьезной проблемой, о которой вам нужно сообщить своим заинтересованным сторонам в кратчайшие сроки.

Короткие индивидуальные задания

Задачи не должны занимать более 16 часов — в противном случае они должны быть разбиты на более мелкие задачи. Это означает, что задачи, скорее всего, будут хорошо оценены.

Удалить время из оценки (относительная оценка)

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

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

Один из способов сделать это — использовать шкалу от 1–10 до (где 1 — тривиально, а 10 — эпично), но это поднимает вопросы о том, в чем может быть разница между 2 и 3.

Обычный способ избежать этого — создать шкалу, подобную последовательности Фибоначчи 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, где разработчикам придется принимать сложные решения о масштабе работы в соответствии с баллами, которые они решили присудить ей. Поскольку ценности представляют сложность, а не время, команда сосредоточена на предоставлении ценности, а не на количестве затраченного времени.

Когда разработчики подсчитывают свою скорость, они могут регистрировать количество очков истории, которые они выполнили за определенный период времени (скажем, за спринт). Это даже можно отследить с течением времени! Замечательный!

Работа в команде

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

Предотвращение коротких путей

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

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

Понимание начала процесса оценки

Владелец продукта в Scrum организует и расставляет приоритеты в невыполненной работе. Владелец продукта улавливает требования бизнеса, но не обязательно понимает детали реализации. Когда команда разработчиков начинает процесс оценки, бэклог продукта может быть переупорядочен (поскольку новая информация собирается от команды разработчиков и возвращается владельцу продукта).

После вашей оценки

Если вы срезали углы

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

Не принимай это так тяжело

Оценку можно уточнить! Если вы завершаете проект, в котором много неизвестных и неизвестных неизвестных, возможно, вы сражаетесь в темноте. Это совершенно нормально! Вам просто нужно убедиться, что вы сообщаете «что» и «почему» в процессе разработки и обучения.

Выводы

Кто платит цену

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

Твоя неудача — это неудача команды.

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

Если оценка неверна, быстрое и раннее сообщение является ключом к успеху для всей команды.

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

Если у вас есть вопросы, комментарии или предложения, пишите мне в Твиттер