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

Что происходит дальше? Если посмотреть со стороны на отношения заказчиков и аутсорсеров, то в 90% случаев они напоминают два враждующих лагеря. Одни обвиняют друг друга в вечном срыве сроков и завышении бюджетов, другие — в непрофессионализме и “саминезнаютчегохотят”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Долго не покупал себе в машину навигатор, так как собирался менять телефон, и волею судеб мой выбор пал на iPhone 3G.

Первую ночь, как наверное и большинство счастливых обладателей, я провел за перепрошивкой, настройкой и поиском необходимых мне приложений, акцентируя внимание на работу с GPS. Так как на тот момент еще слабо понимал, что такое Cidia, Installous и прочие, смог загрузить только огромный двухгиговый кеш карт центральной России из торрентов.
И с утра поехал из Москвы в Кострому тестировать предустановленное приложение Карты.

«О Ужас!» — это лучшее, что мне пришло на ум после первых километров. Кому довелось пользоваться, тот поймет.

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

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

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

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

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

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

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

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

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

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

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

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