Давно не было обновлений, однако мы не сидели сложа руки. Почти закончили реализацию одной очень интересной возможности сервиса, но пока не будем публиковать подробную информацию о ее использовании, сначала завершим бета-тестирование :)

Занимались внедрением DEVPROM как инструмента управления проектами у нового клиента - российской компании-разработчика: пофиксили ряд ошибок, сделали инструмент еще лучше, стабильнее и полезнее для использования.

Все детали ниже:

• Установка на локальный сервер - мы наконец-то закончили отладку решения для установки на локальный сервер. Это может быть полезно для тех команд или проектов, которым не нужно, не удобно или опасно вести проект на публичном сервисе (даже с использованием приватного проекта). На главной странице есть ссылка для загрузки. Загрузка бесплатная, но ограничения не позволяют создавать более 5ти пользоваетелей и 2х проектов.
• Новости - на этой закладке размещаются сообщения из блогов публичных проектов, а также лента последних изменений в публичных проектах. Теперь вы не пропустите что-то для вас важное.
• Управление бюджетом - теперь вы можете оценивать бюджет своего проекта, пока только на основе зарплат участников. Данная оценка может быть полезна как самой команде, так и заказчику, который теперь самостоятельно сможет формировать скоупы пожеланий на основе стоимости их реализации. Методика основана на оценке продолжительности реализации набора пожеланий и вычислении на ее основе стоимости из расчета зарплат на каждого участника. Оплату труда можно определять в часах в день или за месяц.
• Интеграция с MS Project - усовершенствовали экспорт релиза и итерации в план MS Project. Теперь выгружаются пожелания, а если вы используете функции, то пожелания будут сгруппированы по функциям. Используйте автоматическое выравнивание ресурсов в настройках MS Project для получения реального плана.
• Уведомления - переработали немного систему почтовых уведомлений о пожеланиях, задачах и т.п. Теперь письма выглядят лучше, а также появилась опция "Подписаться на все изменения в проекте", это нужно для особо переживающих участников команды :)
• Импорт пожеланий - реализовали возможность испортировать пожелания из Xml, который можно сформировать из Excel с вашим списком пожеланий. Предыдущий способ через Copy+Paste не всегда работает, особенно, когда текст пожелания большой и содержит переносы строк.
• Производительность - провели ряд архитектурных улучшений и снизили время отклика системы на действия пользователя. На наш взгляд результат налицо, однако, мы еще не исчерпали всех возможностей :)

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

Страница загрузки DEVPROM как инструмента управления проектами на вашем собственном сервере: http://devprom.ru/download

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

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

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

В чем суть проблемы: самое главное преимущество jira — это возможность ее настройки: формы, состояния, воркфлоу, фильтры.

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

Отсюда вытекают следующие проблемы:

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

Знакомая ситуация? Думаю, для тех кому хоть раз приходилось пользоваться этим инструментом, да.

Но если внимательно присмотреться к действительно необходимым потребностям большинства (за редким исключением) проектов в плане таск- и баг-трекинга, все оказывается чрезвычайно просто — достаточно самых простых настроек.

При разработке системы управления проектами DEVPROM, мы руководствовались принципом «чем проще, тем понятнее, лучше и удобнее»:

• Не стали придумывать сложную модель секьюрити — достаточно разбиения прав доступа по жестко определенным ролям пользователей (Заказчик, Разработчик, Аналитик, ПМ и т.п.)
• Задача и Ошибка у нас имеют одинаковый воркфлоу, потому что по сути они не отличаются
• Состояния задач только действительно необходимые: Добавлена, Утверждена, Запланирована, В работе, Выполнена, Закрыта и Отложена

Это позволяет покрыть 80% потребностей всех современных проектов, а оставшиеся 20% оставить на откуп монстрам конфигурации, которые необходимы либо чрезвычайно формальным заказчикам, либо таким же менеджерам проектов.

Потому что команде это совсем не нужно.

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

Инструмент как помощник, а не как дополнительное препятствие на пути к успеху.

В марте, при информационной поддержке DEVPROM, в Москве пройдут два мероприятия, которые наверняка будут вам интересны:

Тренинг по Test Driven Development (13-14 марта)

Разработка через тестирование (TDD) - одна из наиболее интересных и противоречивых методик Экстремального программирования, которой практически невозможно овладеть, просто прочитав книгу.

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

Язык и используемые технологии здесь не имеют значения, Test Driven Development успешно применяется разработчиками на C++, Java, C#, Pithon, PHP и других языках программирования.

К сожалению, на текущий момент в аудитории осталось всего 4-5 свободных мест, поэтому для посещения тренинга просто черкните письмо c темой Test Driven Development и мы сразу же вас зарегистрируем.

Стоимость участия составляет 16 тысяч рублей, тренинг пройдет 13-14 марта в Москве.

Отдельно хочется порадовать тех, кому ближе приехать в северную столицу - 3-4 апреля пройдет аналогичный тренинг в Питере. Спешите зарезервировать свое участие!

Agile labs - конференция разработчиков программного обеспечения (31 марта)

Однодневная двух-трековая конференция IT специалистов, работающих с применением Agile практик или еще только обращающих на них свое внимание.

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

Ознакомиться с программой конференции и зарегистрироваться на нее вы можете на сайте конференции: http://agile-labs.ru/conf/program

До встречи!

Команда DEVPROM

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

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

Подробнее о релизе

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

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

Методика

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

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

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

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

Результат

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

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

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

Ограничения

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

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

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

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

Если ваша команда разрабатывала Web-приложение, автоматизирующее деятельность магазина, а теперь ей предлагается разработать трейдинговое приложение на C++, то скорее всего показатели команды придется собрать заново. Однако, в любом случае это крайне рискованная затея :)