Обычно журнал пожеланий продукта (product backlog) или его часть, оценивается по сумме планируемых трудоемкостей пожеланий (user story), в него входящих. Эта цифра интересна тем, что с ее помощью можно прикинуть срок, через который данные пожелания будут реализованы командой.

1. Классика жанра здесь: сумма трудоемкостей / (размер команды * рабочих часов в день) * фокус-фактор = выдает очень неточный прогноз, потому что не учитывает исторические данные.

2. Чтобы увеличить точность, берем среднюю скорость разработки команды (velocity) в данном релизе или итерации, учитываем погрешность недооценки пожеланий и среднее время, которое тратится на исправление ошибок — и считаем с учетом этих параметров = получаем гораздо более точный результат, допустим 5 дней для некоторого набора пожеланий.

Однако, часто бизнес-заказчку (при ресурсной модели) и боссам со стороны команды (fixed-price модель) интересно оценить реализацию набора пожеланий в тех единицах, к которым они привыкли — в деньгах.

Известный факт и типичная проблема — в софтверной компании люди из разных проектов мало знают о том, чем занимаются их коллеги. Каким бы ни было хорошо поставлено неформальное общение, все равно очень много полезной информации не раскрывается в повседневных разговорах.

И казалось бы, такой простой инструмент, как проектные блоги — а действительно способен здорово посодействовать в передаче важной информации между проектными командами:

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

Классическим примером оценки текущего состояния проекта является burndown диаграмма — объективно, самый лучший инструмент, позволяющий увидеть реальное состояние дел в итерации.

Но оказывается, и его можно усовершенствовать — дополнительно измерять скорость разработки по проектным фазам: анализ требований, разработка, тестирование, документирование и т.п.

Для 100% кросс-функциональной команды, где разработчик = тестировщик = аналитик, это наверное не так важно — если анализ требований будет не успевать, остальные накинутся и помогут. Но много ли таких команд вы знаете?

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

Мы постарались сделать установку максимально простой: запускаете инсталлятор, настраиваете почту, подключаетесь к SVN — 10 минут и все готово. Инструкция прилагается :)

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

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

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

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

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

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

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

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

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

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

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

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

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