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

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

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

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

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

Делайте это гибким способом: показывайте рано и часто.

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

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

Эта проблема звучит как результат отсутствия дисциплины. Вы должны использовать программное обеспечение для управления проектами, чтобы планировать и нести ответственность за потраченное время и усилия. Любое программное обеспечение для управления проектами (на меня произвели впечатление Jira и Redmine ) имеет функциональность для разделения задач до уровня, чтобы вы могли дать точную (~ часов) оценку для каждой задачи.

Оттуда это дело дисциплины и заполнения деталей задачи. Это обеспечит обзор в форме диаграммы Ганта (Redmine) или диаграммы полного цикла проекта (Jira), которая обеспечивает мгновенную оценку прогресса вашего проекта.

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

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

Большая часть программного обеспечения PPM может быть излишней для небольших групп, отслеживающих несколько проектов, распределение ресурсов, элементы контроля качества и т. Д. И т. Д. Если все, что вам действительно нужно, - это создать отчет о состоянии, электронная таблица отлично подойдет. «Мы завершили 92 из 127 функций, и, по нашим оценкам, мы завершим программирование и тестирование на две недели раньше срока». Все хлопают в ладоши.