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

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

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

Чаще всего наблюдаются такие сценарии решения этих вопросов:

• На прошлой работе мы использовали инструмент X, зачем нужно что-то еще искать, подбирать или настраивать, если просто можно пойти тем же путем? Без внятного понимания процесса работы над проектом, без обучения команды работе с инструментом X, такой подход приводит к использованию 5% возможностей инструмента, вовлечению в процесс разработки еще 10-ти дополнительных инструментов и, как следствие, низкой эффективности автоматизации работы в проекте, низкого уровня прозрачности и управляемости проектом.
• Я считаю, что методология Y является решением всем проблем, а еще в манифесте сказано: люди важнее инструментов. Методология - это слабо формализованный процесс разработки, а значит и автоматизировать работу по этому процессу практически невозможно, то есть вы не найдете инструмента, который полностью покроет потребности вашей команды в управлении проектом. Через некоторое время, работа в проекте встанет из-за отсутствия сил и времени на переработку всей информации, которая создается в процессе работы над проектом. Работа в проекте будет носить бессистемных характер, постоянно будут происходить сбои, которые потребуют ручного управления (микроменеджмента). Мотивация участников проекта постоянно будет страдать от непонимания того, что должно происходить и кто-что должен делать.
• В нашей компании все процедуры уже прописаны, нечего тут вводить смуту, следуйте прописанным регламентам создания требований, заведения багов и написания тестовой документации, используйте уже готовые шаблоны, которые написали гениальные сотрудники еще 5 лет назад. Любые отклонения от этих процедур должны проходить согласование с генеральным директором.
• Мы наберем самых лучших специалистов и "звезд", заставим работать вместе и в результате сразу получится самоорганизованная проектная команда, которая выстроит наиболее эффективный процесс разработки программных продуктов.

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

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

Любая методология или унифицированный процесс (или framework) выстраиваются относительно некоторых условий выполнения проектов, навыков и уровня квалификации участников проектов, особенностей взаимодействия с заказчиком, пользователями или рынком. В лучшем случае методология требует выполнения определенных магических ритуалов, а в худшем - просто предлагает набор методик и практик, которые при "правильном" применении решают все основные проблемы проекта. Если эти тезисы вызывают у вас сомнения, то самое время перечитать описание семейства методологий Crystal от Alistair Cockburn

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

Любой инструмент предназначен для автоматизации вполне конкретных задач: в лучшем случае инструмент предлагает автоматизацию вполне конкретного процесса разработки ПО (например, семейство продуктов IBM Rational для автоматизации работы по RUP), в худшем - реализует простую вводилку или трекинг списка дефектов.

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

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

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

Любой процесс, связанный с разработкой ПО, делится на этапы, в каждом из которых обозначаются цели этапа, полезные результаты (deliverables), задачи по получению этих результатов, распределение зон ответственности между типовыми ролями участников процесса. Рассмотрим для примера стадии двух известных процессов, отличающихся по структуре:

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

Например, в бережливом производстве ПО (lean software development) контроль качества является центральным звеном во всем процессе разработки, из чего следует необходимость выполнять проверку качества на всех стадиях жизненного цикла разработки. В семействе Agile методологий активно применяется практика Test-driven development, при применении которой вначале создаются тесты на программный код и только после этого выполняется само кодирование. В методологиях семейства Model-driven development выполняется тестирование моделей, прежде чем создается программный код, их реализующий.

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

В Open Unified Process (или сокращенно OpenUP) есть набор подготовленных контрольных списков (checklists), используемых для проверки артефактов на полноту, корректность и непротиворечивость. Сейчас я хочу показать, каким образом можно использовать систему управления проектами DEVPROM для реализации идеи раннего тестирования (early testing) не только на этапе разработки, но и на этапе анализа и проектирования будущего решения.

Пример раннего тестирования

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

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

Планирование

Согласно OpenUP на начальной стадии процесса разработки приложения (Inception) выявляются потребности заказчика, создается видение приложения (Vision), формируются предварительные требования (Use cases) и архитектура приложения (Architecture notebook).

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

Разработка артефактов

1. Создаем видение будущего приложения или его части, если мы ограничили скоуп первого релиза приложения. Детальное описание бизнес-требований содержится в исходном пожелании. По окончании создания этого артефакта выполняем соответствующую задачу.
2. Создаем несколько архитектурно значимых вариантов использования нашего приложения, покрывающие функциональные особенности. В качестве шаблона описания варианта использования применим готовый шаблон из процесса OpenUP.
3. Создаем описание будущей архитектуры, в котором описываем основные принципы на которых будет строиться архитектура приложения и чем будут руководствоваться проектировщики модулей приложения.
4. Создаем тестовые артефакты, используя в качестве шаблонов контрольные списки, соответствующие тестируемым артефактам, например, Vision checklist для создания тестового случая для тестирования Vision.

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

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

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

Таким образом, вполне обоснованным является желание использовать нечто среднее: некоторый формальный процесс, описанный и проверенный опытом индустрии, с готовыми шаблонами артефактов, но не обремененный всевозможными деталями и в большей степени опирающийся на Agile-принципы. Встречайте: Open Unified Process (OpenUP).

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

В плане "легкости" OpenUP предлагает командам использовать следующие практики:

• измерение скорости работы команды, предварительную оценку пожеланий в story points
• проведение ежедневных митингов и ретроспектив по окончании каждой итерации
• концепцию микро-шагов, повторяющую принцип непрерывного создания работающего продукта
• концепцию раннего тестирования с использованием проверочных листов (checklists)
• методику гибкого моделирования (AMDD), направленную на быстрое создание только той документации, которая потребуется в ближайшем будущем.

В плане "тяжести" OpenUP предлагает:

• Готовые шаблоны для
• Описания видения продукта
• Проведения ретроспектив и измерения состояния проекта
• Создания требований, архитектуры, дизайна и тестовой документации
• Контрольные списки (checklists), по которым проверяется корректность и полнота создаваемых артефактов
• Формализованный, но упрощенный с точки зрения RUP, процесс, в котором описано какие активности и в какой последовательности должна выполнять команда, какие цели должна перед собой ставить
• Перечисление ролей, описание зон их ответственности, артефакты, которые они создают и потребляют.