Как я могу планировать гибкую разработку программного обеспечения?

Question

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

Answer 1

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

Разработка программного обеспечения не похожа на гладильные рубашки. Если вы закончите через 5 минут, вы можете быть уверены, что вам понадобятся еще 20 минут для оставшихся 4.

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

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

Итак, что вы можете сделать? Вот несколько рекомендаций:

• Используйте свой опыт. Проанализируйте свои предыдущие проекты. Сколько вы оценили, сколько это действительно заняло? Используйте расхождение в качестве поправочного коэффициента. Популярными упрощениями этого метода являются «Double it», «Triple it» и так далее.
• Используйте гибкую методологию. Это означает, что вы должны убедить своего клиента действовать небольшими шагами. Гораздо легче оценить небольшие шаги. После каждого шага требуется обратная связь от клиента. Если возникнут непредвиденные проблемы, немедленно сообщите об этом своему клиенту. Заставьте его понять, что необходимы дополнительные усилия. Agile, вероятно, лучшее решение, но для этого требуется определенное доверие между вами и вашим клиентом.

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

Answer 2

Статистически, начальная оценка превышена на 300% :) В вашем случае, когда используется модель с фиксированной ценой, добавьте не менее 20% для покрытия рисков. Кроме того, если возможно, укажите два значения: «реализация займет от 40 до 60 часов в зависимости от API». Опять же, поскольку это «фиксированная цена», никакие изменения не могут быть добавлены к первоначальной области, это должно быть ясно указано клиентом. Если вы получаете новый запрос функции, оцените его как отдельную часть работы (более подходящий вариант) или переоцените начальную область (если вы не можете оценить ее отдельно). Если требования слишком расплывчаты, лучше использовать «время и материал», когда вам выплачиваются ваши фактические часы работы, так как вы не сможете дать точную оценку.