Хотите узнать быстрый способ, как за пару минут проверить процесс разработки в вашем проекте?

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

В чем это проявляется? Вот основные моменты:

1. На каждого разработчика назначены одновременно десятки задач, многие из которых висят на нем уже долгие месяцы
2. В трекере висят десятки критичных багов, порой даже со статусом "Блокер" - обнаруженные несколько месяцев (или даже лет!) назад
3. Приоритеты задач и ошибок расставлены как попало, совершенно независимо от того, в каком порядке эти задачи будут выполняться. Следовательно, совершенно непонятно, над чем будет работать команда даже завтра, не говоря уже о более далекой перспективе
4. Есть десятки задач, "зависших" в особенном, специально (!) добавленном статусе, например, "Ожидает фидбека". Как правило, подобное ожидание может происходить месяцами, особенно если ждем что-то от заказчиков или архитекторов

Кстати, используя в качестве трекера Devprom, вы никогда не столкнетесь с первыми тремя проблемами, потому что:

• Баклог продукта (список задач и ошибок) по-умолчанию всегда отсортирован по приоритету, если задача действительно важная, она всегда будет на виду и вы непременно либо решите ее, либо смените приоритет на более низкий
• Задачи на отдельных разработчиков создаются только в рамках краткосрочных итераций (как правило, 1-2 недели), с четко определенными датами начала и окончания, поэтому одни и те же задачи просто не могут висеть на разработчике долгое время - ему придется либо отказаться от них, либо наконец выполнить :)

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фиксирование результатов митингов
• Формирование состава работ для мини-проектов
• Координирование оперативной работы при выкате сборки на продакнш

Фиксирование результатов митингов

Можно писать meeting minutes в виде письма, можно оформлять в виде документа Word, а можно вести минутки митингов в виде mindmaps.

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

Просто и наглядно. Скорость восприятия информации - невероятная.

Но есть один минус, специально его не буду указывать - скажете, какой?

Мини-проекты

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

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

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

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

Единственное неудобство - невозможность положить mindmap в быстром и редактируемом виде в вики проекта, приходится вставлять как картинку.

Но тем не менее, даже такой способ крайне удобен для совместной работы команды:

• каждый может посмотреть текущее состояние дел и последние результаты на проектном портале
• даже после долгого перерыва, один взгляд на mindmap позволяет, что называется, "вспомнить все".

Координирование оперативной работы

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

В качестве примера:

А вы используете карты памяти на своих проектах?

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

• доступность (бесплатный инструмент)
• высокая гибкость настройки (или программирования) сценариев тестирования
• возможность тестирования современных Web-приложений
• возможность записи поведения пользователя при работе с приложением

Для собственных проектов мы выбрали связку NUnit + Watin, которая позволяет использовать готовую инфраструктуру автоматического юнит-тестирования и добавить к ней тестирование работы приложений через графический интерфейс пользователя (прокликивание).

Разработка тестов для прокликивания интерфейса пользователя заключается в написании программного кода на C#, вызова методов браузера и валидации полученных значений или содержания страниц приложения. Чтобы упростить генерацию программного кода тестов можно использовать также свободный продукт Watin Test Recorder, который позволяет записывать действия пользователя при непосредственной работе с продуктом и затем конвертировать их в Watin-тесты, например, на C#.

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

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

Для организации регистрации сообщений об ошибках из тестов, достаточно добавить следующий код:

 
 class WebAssert
 {
 ...
 public static void Fail(IBrowser browser, string msg)
 {
     String picturePath = TestHelper.CaptureScreen(browser, "");
 
     Context context = new Context();
     context.Server = new Uri("http://localhost").Host;
     context.Project = "myproject";
     context.UserName = "user";
     context.UserPassword = "password";
 
     Report report = new Report();
     report.Description = msg;
     report.AttachFile(picturePath);
     report.Submit(context);
 
     Assert.Fail(msg);
 }
 ...
 }
 

Классы Context и Report определены в файле CSharpBugReporter.cs, инструкцию по использованию которого вы можете найти в разделе C#: пример организации обратной связи.

Используемый в разработке программного обеспечения инструментарий не ограничивается только лишь системой управления проектом и интегрированной средой разработки. Для моделирования и проектирования разработаны специализированные инструменты, о которых обязательно нужно знать разработчикам и уметь применять. В этом посте я хочу рассказать про наш опыт использования Enterprise Architect (EA) в собственных проектах.

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

• Поддержка UML построена в целом на базе RUP, что будет полезно для команд, которые используют этот фреймворк, то есть при создании нового проекта автоматически создается дерево моделей и представлений по RUP. Не всегда это удобно, но легко модифицируется. Вы можете описывать прецеденты, логические модели, поведенческие модели (диаграммы состояний и последовательностей), модели данных, компонентов и диаграммы развертывания. В этом плане EA не заменим для работы аналитиков, разработчиков и архитекторов.
• Возможности кодогенерации и создания скриптов моделей могут пригодиться командам, которые используют методологию MDD (model driven development), по сути EA нацелен именно на подобные команды. Из неудобств моделирования баз данных хочу отметить отсутствие автоматической возможности переключаться между логическим и физическим уровнем данных, отлично реализованном в ERWin. Настройка физических аспектов элементов базы данных конечно не такая гибкая как в более специализированных инструментах.
• В последних версиях EA появились возможности по управлению требованиями и изменениями (issue, defect), которые можно привязывать непосредственно к элементам модели. Аналитики теперь могут вести требования непосредственно в моделях EA. Мы эту возможность не использовали, но она будет крайне полезна адептам MDD. Тестировщики могут описывать приемочные тесты непосредственно в EA для каждого элемента модели. Все члены команды могут списывать затраченные часы, связанные с моделированием или реализацией отдельных элементов модели.
• EA предлагает использовать большое количество проектных метрик, рассчитываемых в основном на сложности элементов модели и связях между элементами. Вы можете использовать эти метрики для оценки рисков, с которыми может столкнуться команда в рамках работы над проектом.
• В EA есть возможность отслеживать изменения моделей, выполняемые участниками. Для этого необходимо создавать baseline, после чего текущую версию или предыдущий baseline можно сравнивать с любым другим baseline.

Что касается вопросов интеграции, то EA можно использовать совместно с Eclipse и VSTS, организовать контроль версий моделей при помощи систем контроля версий. Отдельно хотелось бы отметить возможность организации единого репозитория проектов и моделей на базе СУБД. В этом случае все участники команды могут работать с единым хранилищем всей информации, сосредоточенной в моделях EA.