Управляйте гибкой командой с XPlanner

Объем, дизайн, сборка, тестирование, доставка, извинения. Это часто используемые шаги традиционной инженерной методологии, когда они применяются в переменчивом мире программных проектов. Как разработчик программного обеспечения вы, вероятно, хорошо знакомы с этим «последним» системным требованием, которое, кажется, уклоняется и переплетается, как боец ​​призов. Возможно, вы потрудились над проектом разработки только для того, чтобы появиться спустя месяцы (или годы) и встретиться с клиентом, который, кажется, глубоко разочарован тем, что его реальные потребности не были удовлетворены. Возможно, ваши коллеги достигли той точки, когда перед ними поставленный тщательно продуманный долгосрочный план развития вселяет ощущение надвигающейся гибели. Итог - ваша команда готова к гибкой разработке, но приспособлен ли ваш традиционный инструмент управления командой к традиционному управлению командой?

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

XPlanner - это веб-приложение на Java, разработанное для поддержки управления командой в соответствии с методологией экстремального программирования (XP). Однако мы обнаружили, что этот инструмент достаточно гибкий, чтобы обеспечить ценную поддержку для других основных гибких подходов (например, Scrum) в разгар реализации проекта. Несмотря на свою простоту, XPlanner предоставляет удобный инструмент для поддержки вашей команды, независимо от того, имеете ли вы опыт или только начинаете в увлекательном мире гибкой разработки программного обеспечения.

Традиционные и гибкие инструменты управления командой

Традиционные инструменты управления командой (такие как Microsoft Project) основаны на структурной декомпозиции работ, которая позволяет заглянуть в будущее проекта. Планируемое распределение ресурсов и тщательный контроль отклонения от базового уровня используются для управления «критическим путем» к окончательной доставке. Применение таких инструментов требует значительных усилий по предварительному планированию, жесткой зависимости задач и стабильной базы требований. Существенные изменения в области применения или требований могут потребовать значительных изменений модели. Таким образом, эти традиционные инструменты являются наиболее подходящими при планировании путешествия из пункта А в пункт Б, предполагая небольшое изменение курса. Напротив, гибкие проекты рассчитаны на изменения, не предполагая, что B даже будет конечным пунктом назначения.

Чтобы понять культуру гибкого проекта, полезно рассмотреть принципы гибкой разработки в том виде, в каком они поддерживаются авторами Agile Manifesto:

  • "Люди и взаимодействие важнее процессов и инструментов
  • Рабочее программное обеспечение над обширной документацией
  • Сотрудничество с клиентами вместо переговоров по контракту
  • Реагирование на изменения вместо следования плану "

    (Кент Бек и др., 2001)

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

Планирование и отслеживание проектов с XPlanner

XPlanner - это гибкий программный инструмент для управления проектами, доступный по лицензии GNU Lesser General Public License (что делает его «бесплатным, как в пиве», на жаргоне с открытым исходным кодом). Пакет развертывается как веб-приложение, которое позволяет членам вашей команды и заинтересованным сторонам проекта подключиться к работе, используя свои любимые веб-браузеры. После настройки вы сможете планировать и отслеживать различные аспекты реализации вашего гибкого проекта через простой веб-интерфейс.

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

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

Скачивание и установка

XPlanner - это чистое Java-приложение, которое можно развернуть в любой среде разработки J2SE 1.4, оснащенной Apache Ant и подходящим механизмом сервлетов. Мы выбрали Apache Tomcat в качестве механизма сервлетов; однако подойдет любой движок, совместимый с Servlet 2.3 (или более поздней версией). XPlanner поставляется в виде файлового архива (zip или tar.gz), который необходимо распаковать и собрать перед развертыванием и использованием инструмента.

Требуется обязательный этап настройки, так как вам нужно настроить свою любимую базу данных, которая будет использоваться в качестве репозитория для информации о проекте. Поскольку XPlanner использует уровень объектно-реляционной персистентности Hibernate для взаимодействия с базой данных, у вас есть возможность использовать любую базу данных, поддерживаемую Hibernate, для репозитория вашего проекта. В комплекте идет облегченная база данных Java Hypersonic (теперь она называется HSQLDB); однако мы использовали Oracle 9i в качестве нашей базы данных репозитория. Чтобы настроить эту базу данных, нам пришлось отредактировать файл xplanner.properties, раскомментировав уже определенные свойства Oracle. Нам также необходимо было изменить build.xmlфайл, чтобы включить драйвер тонкой базы данных Oracle. После настройки вы можете создать развертывание XPlanner. Это включает выполнение Ant для создания развертываемого веб-архива (WAR) следующим образом:

ant install.db.schema ant build.war 

Разверните полученный файл веб-архива ( xplanner.war) на выбранном вами движке сервлетов, а затем перейдите по URL-адресу // your-server: your-port / xplanner / (используя пользователя по умолчанию «sysadmin» и пароль «admin»), чтобы проверить результаты!

Интеграция с вашей экосистемой

Большинство сред разработки уже содержат систему отслеживания ошибок, форумы для совместной работы, системы безопасности, репозитории стандартов и т. Д. Несмотря на то, что XPlanner полезен как отдельный инструмент, ценность XPlanner может быть увеличена за счет его простых и мощных функций интеграции. XPlanner включает, например, возможность поддерживать рендеринг речи разработчика в поле описания, например bug: 1001 как ссылку на //mybugzilla/show_bug.cgi?uid=1001. Это можно сделать, просто добавив twiki.scheme.bug=//mybugzilla/show_bug.cgi?id=в xplanner.propertiesфайл. Этот же метод можно использовать для других веб-инструментов, таких как viewcvs (xplanner.propertiesпоказывает еще несколько примеров). XPlanner также имеет расширенный модуль форматирования вики (не используется в нашем проекте), который позволяет автоматически создавать ссылки на записи вики. Более подробную информацию о расширениях XPlanner можно найти в разделе "Ресурсы".

В большинстве организаций сервер каталогов, совместимый с LDAP (облегченный протокол доступа к каталогам), неизменно предоставляет централизованное хранилище учетных записей безопасности пользователей. Например, в организации, спонсирующей наш проект, этой цели служил устаревший, но функциональный сервер LDAP (Microsoft Active Directory также в значительной степени поддерживает протокол LDAP). Было приятно обнаружить, что XPlanner XPlannerLoginModuleлегко интегрируется с LDAP. Это включало обновление xplanner.propertiesследующим образом:

-> Comment out default security #xplanner.security.login.module=com.technoetic.xplanner.security.XPlannerLoginModule

-> Uncomment and edit the LDAP entries from... xplanner.security.login.module=com.technoetic.xplanner.security.jndi.JNDILoginModule

-> ...to: xplanner.security.login.option.roleSearch=(uniqueMember={0})

-> Add user search entries xplanner.security.login.option.userBase=ou=people,o=person

-> And blank out values for xplanner.security.login.option.userPattern= xplanner.security.login.option.userPassword=

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

Команда, встречайте XPlanner

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

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

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

Сбор пользовательских историй

Каждая пользовательская история для итерации проекта должна быть кратким и ориентированным на результат описанием пользовательского опыта, рассказанным от первого лица (например, «Затем я ищу по цвету ...»). Этот опыт написан пользователем, который представляет себе идеальный будущий продукт в действии, поэтому вы можете думать о пользовательской истории как о позитивной визуализации для программного обеспечения! Цель каждой визуализации - предоставить разработчику программного обеспечения достаточно информации, чтобы оценить усилия, необходимые для воплощения этой истории в реальность.

XPlanner каталогизирует коллекцию пользовательских историй вашего проекта, записывая для каждого клиента, трекера, приоритет и оценку усилий. Основная трудность, с которой мы часто сталкиваемся, - это сбор качественных пользовательских историй из умов пользователей системы. Это, безусловно, имело место в нашем проекте, поскольку это был значительный сдвиг парадигмы от жестких требований раздела / подраздела, к которым пользователи привыкли. Тем не менее, возможность использовать XPlanner для управления историями таким образом, чтобы их могли легко увидеть и обновить заинтересованные стороны, а также быстро продать их в данной итерации, безусловно, помогла. Одна приятная, хотя и не функциональная, особенность XPlanner - это аутентичное ощущение, которое он дает истории пользователя, отображая каждый на экране как похожую учетную карточку 3 на 5, как показано на рисунке 1.

Оценить и записать усилия

Гибкая разработка предписывает разработчикам устанавливать собственные цели, которые включают анализ пользовательской истории и определение технических задач, необходимых для реализации этой истории. Разработчик должен иметь право добавлять дополнительные задачи или изменять существующие задачи по мере появления дополнительных деталей истории. XPlanner поддерживает эту гибкость, предоставляя разработчикам полный доступ для определения и редактирования задачи. Каждой задаче может быть назначен тип, например, задолженность, функция или дефект, чтобы характеризовать вид выполняемой работы (например, долг - это задача по очистке технического "мусора", оставшегося в системе от предыдущей итерации). Задачи также указываются с расположением (запланированным или незапланированным), принимающим разработчиком, описанием работы и оценкой количества идеальных часов, необходимых для выполнения этой задачи.

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

Разработчики также должны записывать количество идеальных часов, которые они вкладывают в выполнение данной задачи. Если вы побудите своих разработчиков честно записывать идеальные часы (не требуя знать, где идет время), вы сможете извлечь некоторые полезные метрики из XPlanner (обсуждаются ниже). Мы обнаружили, например, что в нашем проекте на достижение идеального часа ушло около 1,4 часа. Затем эту информацию можно использовать для уточнения оценок для последующих итераций, что помогает сдержать обещания команды и ожидания клиентов на одном уровне.

Метрики и планирование следующей итерации

Вы находитесь на середине итерации, и босс хочет знать, «как мы смотрим». Известный ответ на этот вопрос: «Мы прошли около 80 процентов пути». Конечно, эти последние 20 процентов всегда занимают гораздо больше времени, чем следовало бы - последние 20 процентов - это программный эквивалент скучных овощей за ужином, которые вы оставляли напоследок.