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

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

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

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

OmniPlan

Инструмент планирования Mac OS X.

Pivotal Tracker

Полезно, даже если вы не занимаетесь «гибкой» разработкой.

FogBugz

Невероятно полезное и популярное отслеживание проблем.

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

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

FogBugz предоставляет простой в использовании интерфейс для непрограммистов для отправки ошибок или запросов функций и отслеживания прогресса. Проблемы, которые приходят, оцениваются и регистрируются в Pivotal. Затем они перемещаются в OmniPlan, если он становится более сложной задачей с несколькими компонентами.

Мы используем Redmine -> http://www.redmine.org/

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

Легко получить из коробки (написано на Ruby, будет работать на большинстве небольших серверов) и с некоторыми довольно мощными аддонами, которые просты в установке и использовании.

Можно ли ответить ни на что ?

Похоже, вы подразумеваете, что для успешного гибкого планирования необходимы программные инструменты. Я не согласна Если ваша команда использует scrum или XP правильно («по книге»), вам не нужно вообще использовать какие-либо программные инструменты для планирования.

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

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

(Распределенные команды - особый случай)

Я использовал как Rally, так и JIRA с Greenhopper .

Я начну с JIRA. JIRA - отличный инструмент для отслеживания ошибок. Greenhopper - это надстройка, позволяющая командам начать работать с agile. Поскольку с самого начала он не разрабатывался как гибкий инструмент, некоторые процессы кажутся неловкими. Инструмент также трудоемкий и трудоемкий. Тем не менее, это чрезвычайно настраиваемый. В общем, это похоже на инструмент, которым вы должны втиснуть свои гибкие процессы.

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

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

Мы используем систему отслеживания проблем под названием FIT (я работаю в этой компании как на внешнем подрядчике, так что это был мой выбор, что использовать). Фогбугз был дорог в сравнении. Он имеет небольшой размер, веб-сайт, недорогой и делает обычные вещи. Я посмотрел на Redmine, который является замечательным пакетом, но руководство было непросто по поводу пакета с открытым исходным кодом, который все еще находился на острие.
Для такого инструмента, как средство отслеживания ошибок, я не хотел поддерживать его, обновлять или настраивать: я просто хотел, чтобы он работал прямо из коробки и оставался таким же.