Эта тема довольно многогранна и в сети вы найдете множество блогов, освещающих возможности совместной работы команды с общими артефактами, например, документами. Вот пример такого ресурса: http://www.livebusiness.ru/tools/docs/

Одной из основных практик Agile является использование Task Board (доски задач), которая позволяет удобным образом визуализировать состояние итерации (спринта) и вовлечь команду в активную работу с задачами итерации. С описанием этой практики и примерами использования вы можете познакомиться в статье TaskBoard: Управление в стиле Agile

DEVPROM является в первую очередь инструментом для распределенной разработки, когда ваша команда не может себе позволить использование общей физической доски задач. Поэтому содержимое доски задач отображается у каждого участника проекта на закладке "Итерация".

img1

Дополнительным преимуществом использования доски задач является возможность формирования пула задач (task pool), из которого участники проекта черпают задачи. Вот несколько преимуществ этого подхода:

• Задача координатора или команды сводится к оценке скоупа релиза и формирования пула задач, или плана итерации, если говорить языком классического подхода.
• Участники проекта выбирают себе задачи по вкусу и возможностям, тем самым позволяя раскрыться своим талантам, в вашей команде больше не будет недовольства по поводу распределения задач.
• Можете забыть про выравнивание ресурсов - у вас есть пул задач и есть команда, дайте возможность команде и отдельным ее участникам проявить все свои сильные стороны. Более того, заранее определить все внутренние взаимозависимости между задачами вы не сможете, но команда самостоятельно выстроит нужную цепочку задач.
• Поскольку точно оценить все задачи невозможно, то высвобождающиеся ресурсы не будут сидеть без дела и ждать пока им назначат задачу, а будут брать новые задачи из пула, поскольку у команды есть общая цель: выполнить все задачи итерации в установленный срок.

На закладке "Задачи" участники проекта видят пул задач, причем этот пул можно разделить по фазам разработки: аналитики просматривают пул задач анализа, тестировщики - пул задач по тестированию. Как только участник освобождается от текущей задачи он берет из пула следующую.

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

img2

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

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

• Сводная информация о пожеланиях
• Множественные операции над пожеланиями
• Индикатор состояния итерации

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

Постом Agile: использование time boxing мы открыли серию заметок по использованию Agile практик в разработке программного обеспечения и применению их в системе управления процессом разработки DEVPROM.

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

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

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

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

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

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

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