Мы добавили новый раздел на сайте под названием "Решения", в котором будем описывать решения конкретных задач, построенных при помощи системы управления проектами DEVPROM.

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

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

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

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

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

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

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

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

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

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

Мейнстримом во многих старых (ClearQuest) и даже современных инструментах управления процессом разработки (Jira, Mingle) является именно настройка процесса (workflow), по которому ваша команда должна двигаться при выполнении некоторого скоупа. Очевидно, что использовать эти инструменты для прогнозирования сроков проектов чревато самыми печальными последствиями для вашей команды. Выходом является составление плана работ, то есть анализ структуры работ команды, распределение ответственных и предварительная оценка трудоемкостей. Именно поэтому часто встречаются команды, которые работают с Jira, но для планирования используют, например, MSProject.

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

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

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

Пример №1

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

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

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

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

Пример №2

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

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

Надеяться, что несколько независимых разработчиков (фрилансеров в данном случае) объединятся в команду и будут производить высокого качества продукт в нужные сроки - крайне рискованное занятие. Конечно бывают иключения, но нанимать в таком случае лучше всего удаленную команду, которая сработалась и уже знает свои основные параметры: скорость и эффективность (подробнее о них читайте в посте "Agile: использование velocity").

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

Пример №3

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

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

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

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

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

А причина в целом довольно простая:

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

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

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

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

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

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

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

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