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

Сын ошибок трудных

И опыт - сын ошибок трудных...

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

Лучшие варианты сводились к использованию проектной командой одной из многочисленных систем отслеживания ошибок (bug tracking system). Структура задач и бизнес-процессов проекта обычно разворачивалась «из коробки». Данные системы использовалась в основном группами программистов и тестировщиков. Такая организация разработки хорошо себя оправдывала на небольших проектах с частными заказчиками или если в задачи исполнителей входило только гарантийное сопровождение программного продукта (исправление выявленных ошибок). Однако с ростом новых требований такой подход начинал буксовать. Это проявлялось в росте временных затрат на сопоставление требований заказчиков и сведений, сохраненных в багтрекере (и ручном составлении интегральных отчетов), а также разделения команды на два лагеря («хороших» программистов и «плохих» аналитиков).

Другие ситуации сводились к «гениальным» озарениям руководства, когда, используя административные рычаги, в деятельность проектных групп «внедрялись» лучшие методологии разработки программного обеспечения. Правда, эти руководители считали, что их действия ограничивались только процессом нахождения этой «серебряной пули». Они не заморачивались с такими понятиями как « спринт», « диаграмма сгорания задач » или « диаграмма совокупного потока ». А даже если и заморачивались, отчетные документы, которые требовалось формировать о состоянии проекта (опять же вручную), были слабо связаны с этой самой лучшей методологией. Попытки приобщить заказчиков к этим методикам, приводили к тому, что условия проекта не менялись, а к старым отчетам дополнительно требовалось формировать новые дополнительные отчеты (по новой методике). Особенно ярко такие противоречия проявлялись на проектах по госконтрактам, условия организации которых напрямую конфликтовали с условиями успешности применения Agile, RUP или PMBOK .

Апофеозом автоматизации управления стал проект по доработке информационной системы федерального уровня в интересах одного крупного государственного заказчика. В рамках этого проекта сам заказчик использовал HP Service Manager и JIRA. HP Service Manager использовался для сбора и анализа ошибок программного обеспечения. C помощью JIRA заказчик планировал деятельность своих сотрудников, связанную с исправлением этих ошибок и дальнейшим развитием системы. Перечень состояний задач в этих системах предусматривал все многообразие возможных вариантов их обработки. Подробнейшие регламенты сопровождения этих задач, сформированные проектным офисом заказчика (т.е. людьми, не отвечающими за сопровождение и разработку), были размещены на платформе Confluence. Сотрудники исполнителя были допущены к обеим системам и на них были возложены обязанности по сопровождению инцидентов и требований (с временными нормативами по обработке задач и прогрессивной шкалой штрафов). Кроме того, на площадке исполнителя был развернут свой экземпляр JIRA, с помощью которого планировалась деятельность проектной группы. Синхронизация деятельности всех трех систем осуществлялась вручную (для этого приходилось вести «простыню» в Excel, в которой отмечались взаимосвязи задач и их текущее состояние). Кроме того, отчеты, которые формировала JIRA, руководство не устраивало, и поэтому сотрудники проектной группы должны были предоставлять почасовые отчеты о своей деятельности, также создаваемые ими вручную в Excel. Не редкостью была ситуация, когда руководитель группы разработки или руководитель групп сопровождения «зависали» на работе до поздней ночи, формируя сводные отчеты о состоянии проекта по результатам деятельности проектной команды. Данный проект был успешно завершен точно в перенесенные сроки и запомнился, кроме рекордно низкой производительности, повышенным количеством нервных срывов, стремительным профессиональным выгоранием и, судя по премиям «выживших» сотрудников, неожиданно невысокой маржинальностью. После таких проектов долго не дает покоя мысль: «Если мы создаем инструменты, которые значительно облегчают жизнь заказчиков, то почему, за счет подобных инструментов, мы так изощренно ухудшаем свою жизнь?»

Особенности национальной разработки

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

Источник

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

• зачастую исходные требования технического задания сформулированы расплывчато, заказчик вкладывает в эти требования все новые смыслы по мере развития проекта (что связано, в числе прочего, с изменением действующей нормативной базы, регламентирующей автоматизируемые бизнес-процессы);

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

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

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

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

• бюджет и сроки сдачи проекта остаются неизменными, несмотря на изменение и дополнение требований;

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

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

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

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

• Ядро проектной команды может состоять из 5-12 сотрудников: руководитель проекта, аналитики, тестировщики, технические писатели, программисты. Несмотря на то, что некоторые сотрудники иногда могут выполнять несколько ролей, как правило, для этих проектных команд характерен низкий « автобусный фактор ». Это само по себе также накладывает ограничения на применение методов Agile (например, использование покера планирования в таких условиях вряд ли будет полезным).

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

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

Победа надежды

Второй брак – это победа надежды над жизненным опытом.

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

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

• способность регистрировать связи между задачами «многие ко многим»;

• гибкость настроек коробочной версии;

• сохранение истории всех изменений по проекту;

• отчасти открытая архитектура, возможность доработки под собственные нужды;

• возможность сопряжения с внешними системами, которые уже использовались проектной командой (SharePoint, Git, SVN и т.д.);

• возможность использования на своем сервере (для закрытых проектов);

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

Исторически для применения в работе была взята JIRA версии 6.4, однако отдельные элементы решений, которые были реализованы на этой версии в нашем проекте, частично появились в новых версиях JIRA уже «из коробки» (что косвенно подтвердило правильность принятых решений).

Автоматизация управления проектом изначально преследовала следующие цели:

• улучшить качество сна сотрудников проектной команды (как известно отдохнувший человек работает гораздо эффективней);

• обеспечить прозрачное распределение ответственности за выполнение задач проекта;

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

• обеспечить автоматическое формирование текущего состояния дел по реализации каждого из требований заказчика;

• обеспечить мониторинг текущего состояния проекта, позволяющих выявить проблемы и риски проекта на ранних этапах;

• сформировать единые подходы по учету, методике оценки и сравнения состояния разных проектов по разработке программного обеспечения (по аналогии сервисов Google Analytics или Яндекс.Метрика, которые позволяют оценивать по одинаковым показателям любые сайты);

• повысить точность оценки сроков выполнения задач, на основе собранных статистических данных.

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

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

Гарантии преемственности. Одной из целей автоматизации управления проектом является обеспечение преемственности, чтобы любой квалифицированный сотрудник мог «подхватить» обязанности выбывшего члена команды без «испытательного срока» и с минимальной головной болью, чтобы «отряд не заметил потери бойца». В этой связи вспомнился случай, который мне рассказал один из заказчиков. Однажды он остался за начальника, который, уехав в отпуск, сообщил ему пароль от своего компьютера с репликой: «Ну, там все понятно, разберёшься в случае чего…». Этот сотрудник потратил несколько бессонных ночей на осознание содержания нескольких папок с названиями «xxxxx1», «xxxxx11» и «xxxxx111» (названия папок изменены, в интересах соблюдения правил приличия). Предотвращение таких ситуаций требует регистрации в JIRA результатов работы всех сотрудников проектной команды, включая руководителя проекта.

Минимализм. Цель автоматизации управления проектом состояла не в том, чтобы посчитать с точностью до минуты, сколько тот или иной сотрудник потратил рабочего времени на решение поставленных перед ним задач, а в том, чтобы обеспечить решение задач с заданным качеством в требуемые сроки. Поэтому при развертывании проекта в JIRA был принят принцип минимизации данных, регистрируемых в системе. Т.е. набор параметров, регистрируемых в системе управления, должен был быть минимально необходимым для принятия обоснованных решений (« Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать »). При этом подразумевалось, что принятая модель автоматизации управления проектом должна работать в условиях высокой неопределенности и непоследовательности (например, можно знать дату документа, но не знать его номер и наоборот). При типизации регистрируемых сведений использовалось, где только возможно, правило Миллера , говорящее о том, что оптимальное количество типов (состояний) должно лежать в пределах «семь плюс-минус два» (что значительно упрощает понимание работы системы сотрудниками). Так, например, при проектировании жизненного цикла задач (workflow) изначально предполагалось, что количество состояний должно соответствовать данному правилу.

Системность. Автоматизация управления проектом должна способствовать согласованности и слаженности действий всех сотрудников проектной команды (предотвращение ситуации «лебедь, рак и щука»).

В одном из проектов, в котором мне довелось поучаствовать, команда аналитиков в течении месяца разрабатывала модель автоматизируемой деятельности в нотации IDEF0. Как казалось, само использование методологии, созданной ВВС США (!), гарантировало успешность такого подхода. Однако, когда многостраничный аналитический отчет изучил начальник отдела программирования, его первым вопросом был: «Так, что собственно надо сделать?». Сформированная модель оказалась непригодной для использования, как описание постановки задач для программистов. Представители заказчика несколько раз восхитились, бегло просматривая многочисленные схемы, однако также не нашли применения этой модели для оптимизации своей деятельности. В конце концов эти схемы украсили описание технологических процессов, придав этому документу невиданную доселе толщину и солидность, однако на этом положительный эффект проведенного анализа был исчерпан. Результаты месяца работы нескольких аналитиков фактически оказались невостребованными в рамках проекта.

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

Garbage in – garbage out

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

Фундаментом для построения любой модели является классификация объектов, которые используются для формирования этой модели. Классификация дает возможность увидеть систему в разрозненном наборе фактов и событий. Научный подход начинается именно с построения правил классификации - таксономии . Оцените сами какое значение для управления исследованиями в биологии имеет классификация Карла Линнея. Или что привнесла для химии переодическая система элементов Дмитрия Менделеева. При формировании таксономии ключевым моментом является определение признака (основания) классификации - свойства или характеристики объекта, по которому производится однозначное соответствие принадлежности объекта к тому или иному классу. Это настолько простое и примитивное правило, что во многих случаях им просто пренебрегают. Увы, вообще многие из современных разработчиков не придают значения классификации. А потом удивляются архитектурным проблемам, которые как айсберги «внезапно» возникают в ходе реализации проекта. И тому объему работ которые приходится выполнять для поддержания жизнеспособности конструкции в которую заложена неправильная классификация.

Базовым элементом первичного учета выполняемых работ в JIRA является задача (проблема, тикет, запрос - < issue>). Вы можете классифицировать работы в JIRA, создавая различные типы задач. Для каждого типа задач можно определить свой набор пользовательских атрибутов и свой рабочий процесс ( <workflow >).

Однако, если присмотреться каким образом разработчики JIRA рекомендуют типизировать задачи, то можно заметить, что как раньше так и сейчас в документации Atlasian предлагается типизация задач по разным классификационным признакам. Другими словами в рамках одного уровня классификации предлагается разделять задачи по признакам «теплое», «зеленое» и «мягкое». Если проект существует в мире, где теплое никогда не бывает зеленым или мягким, то такой подход работает безупречно. Но если вдруг случается «теплое», «зеленое» и «мягкое» вместе? Или выясняется, что «теплое», на самом деле «мягкое»? Например может оказаться, что задача которая была зарегистрирована с типом <ошибка> (<Bug>) ошибкой не является.

Обратите внимание: по умолчанию в JIRA предлагается регистрировать проблему/задачу. Что такое проблема в обычном понимании пользователя JIRA? Это и требования и все работы по решению этих требований «в одном флаконе». Например, задача типа <ошибка> (<Bug>) предполагает фиксацию требования по исправлению выявленной ошибки, поиск причин её возникновения, исправление при необходимости кода и документации, тестирование, включение в релиз. Если эти работы выполняются разными исполнителями это влечет автоматическое переназначение задачи по этим исполнителям в ходе ее реализации. С другой стороны замес нескольких разных работ в одном типе задач влечет за собой смешение понятий <бизнес-процесс> и <рабочий процесс>.

В оригинальном варианте интерфейса и документации JIRA используется термин <issue workflow> – в дословном переводе <рабочий процесс> или <поток работы> . Вместе с тем, русский вариант интерфейса JIRA предлагает для термина <issue workflow> перевод <бизнес-процесс>. На первый взгляд, может показаться что это одно и то же. Почти...

Бизнес- процесс ( business process )– согласно концепции BPM - это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. Как правило бизнес-процесс изображается в форме графа ( сетевого графика ), где узлами графа являются работы или мероприятия, а с помощью рёбер этого графа отражается последовательность выполнения этих работ.

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

Не заметили «небольшой» разницы в этих двух понятиях?

Кстати, если рассмотреть рабочий процесс предлагаемый Atlasian из коробки, то выясняется, что предлагаемый перечень статусов опять же слабо стыкуется с базовыми принципами классификации. Видимо, авторы создавшие эти статусы жили в мире, где статус «в работе» принципиально отличается от статуса «переоткрыт». Правда, в документации JIRA авторы не описали, чем именно отличаются эти состояния. Надо додумывать. При этом JIRА никак не ограничивает фантазию своих администраторов. И многие при формировании workflow так и поступают. Стараются всеми доступными способами показать, как они могут замешать все возможные бизнес-процессы с жизненными циклами. Для каждого типа задач – свой.

Правда, видимо эти фантазеры не задумываются о том, как они потом будут управлять всем хитросплетением задач на проекте, построенных по таким принципам. Как сказал один известный персонаж : «Они все фантазеры – наши шефы. Им можно фантазировать – у них нет конкретной работы.»

Например, на картинах Ивана Айвазовского гениально в многочисленных ракурсах нарисованы корабли. Это тоже модели. Модели кораблей. Но вряд ли кому то в голову может прийти мысль о том, что с помощью этих моделей можно этими кораблями управлять. Зачастую, знакомясь с результатами моделирования программных проектов в системах управления, у меня складывается смутные подозрения, что авторы этих моделей создавали их только для того чтобы показать свое мастерство владения изобразительным искусством. Или для того чтобы ошеломить зрителя сложностью, многообразием и непредсказуемостью программного проекта. Чтобы любой, глядя на модель проекта в JIRA, мог почувствовать всю ничтожность и никчемность своего интеллекта перед проектными бизнес-процессами.

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

Теория и практика

Теория без практики мертва, а практика без теории слепа.

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

Источник

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

Моделировать реальный мир можно разными способами. Ученые стараются построить математическую модель. Военные моделируют предстоящие боевые действия на картах. Дети с удовольствием моделируют самые разные миры с помощью примитивных кубиков LEGO.

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

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

• задачи-требования - цели которые предполагается достичь;

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

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

Регистрация целей

Все требования в наших проектах регистрируются как задачи одного типа. При этом в рамках одного проекта JIRA объединяются требования и работы по всем договорам по одному продукту в интересах одного заказчика. Роль задач-требований могут выполнять задачи предопределенного типа < эпик >, однако наш подход учета эпиков содержит ряд особенностей.

При регистрации требований должны соблюдаться два важных правила:

1. Каждое требование заказчика должно регистрироваться как отдельная задача в JIRA. Другими словами, в рамках каждой задачи JIRA регистрируется одно нормализованное (логически неделимое) требование. И если приходит письмо об инциденте в котором описаны три ошибки программного обеспечения – то в JIRA регистрируется три разных требования-задачи.

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

Такой подход оправдывает себя, поскольку на программном проекте, как правило, никогда нельзя точно заранее предугадать сколько придется потратить времени и сил на реализацию того или иного требования. Эта вероятностная природа программных требований очень напоминает «туман войны», невозможность однозначного предсказания при планировании результатов боевых задач для воинских подразделений. Очень здорово, со стороны, давать советы по применению принципа Паррето . Вопрос в том как определить эти 20% усилий которые дают 80% результата? Бывает, что требование по устранению «чудовищной ошибки программного обеспечения» решается в ходе пятиминутной консультации, а вскользь брошенное замечание вдруг выявляет серьезные архитектурные просчеты. Выполнение «небольшой» просьбы вышестоящего руководства может на несколько дней парализовать работу проектной команды, а казавшаяся неподъемной задача решается за несколько минут с помощью бесплатной библиотеки с открытым кодом, найденной в Интернете.

Если вы не будете регистрировать все требования в JIRA, вы рискуете не угадать контуры «слона» с которым имеете дело. С другой стороны, нормализация требований определяет с какой точностью вы сможете определять приоритеты и распределять ресурсы на проекте.

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

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

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

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

В соответствии с установленными на проекте правилами, регистрация требования является обязательным основанием для планирования других задач. После регистрации требования и его уточнения с заказчиком (в случае необходимости) формируются задачи других типов, направленные на реализацию данного требования. Другими словами, в рамках принятой модели, другие задачи всегда должны быть связаны с требованием, в интересах которых они выполняются (с использованием типа связи «причина» -> «действие»). В интересах реализации одного требования может быть создано несколько задач на разработку, с другой стороны одна задача (на анализ, разработку, тестирование, документирование, внедрение) может быть создана в интересах нескольких требований (в отличие от стандартного подхода JIRA, когда предполагается, что задача может быть связана только с одной задачей типа epic). В рамках предложенной модели также можно связать другие зависимые задачи. С одной стороны, такой подход обеспечивает системность принимаемых решений, с другой предоставляет возможность достаточно точного отражения реального состояния дел на проекте. При этом возможны самые различные варианты организации работ, разобраться в путанице которых кажется весьма непросто.

При регистрации задач-требований предполагается учет следующих дополнительных атрибутов:

• тип требования;

• требуемая квалификация ответственного исполнителя;

• вид договора;

• стадия жизненного цикла продукта;

• реквизиты основания для регистрации требования;

• компоненты, которые затрагивает требование.

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

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

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

Регистрация работ

Типы задач-работ создаются на основании классификации проектных работ по характеру выполняемых действий. На наших проектах приняты следующие базовые типы задач для учета выполняемых работ:

• «анализ» – тип задачи для регистрации проводимых совещаний по согласованию требований, проведение занятий по обучению пользователей, материалов информационных обследований (пользовательских историй) и описаний постановок задач (проектных решений) по связанным требованиям (аналог в новых версиях JIRA – story);

• «разработка» – тип задачи для регистрации результатов работы программистов;

• «тестирование» – тип задачи, содержащей описание тестовых заданий и результаты тестирования реализованных требований;

• «документирование» – тип задачи, содержащей сведения о результатах деятельности по формированию документации всех разновидностей;

• «внедрение» – тип задачи для регистрации результатов работ, направленных на внедрение разработанного ПО в деятельность заказчика (проведение испытаний, демонстраций, выпуск релиза/патча/datafix, развертывание программного обеспечения на серверах заказчика, и т.д.).

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

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

Для прозрачности распределения ответственности при автоматизации управления проектом был реализован принцип «1 задача – 1 исполнитель». Т.е. процесс выполнения задачи заведомо не предполагал ее передачу другим исполнителям. Этот принцип позволил применить одинаковый бизнес-процесс ко всем типам задач, поскольку статус выполнения работы определялся прежде всего, с точки зрения исполнителя этой задачи.

Жизненный цикл

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

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

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

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

• автор задачи;

• ответственный исполнитель.

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

За качество выполнения отдельной задачи отвечает только один ответственный исполнитель (при выполнении задачи не предполагается смена исполнителя). Однако, если в процессе выполнения задачи исполнитель был переназначен - ответственность за качество решения задачи несет исполнитель переведший задачу в статус <контроль>.

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

Канбан-доска наизнанку

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

Созданный дашборд позволял отобразить состояние задач на проекте с позиции реализации каждого требования отдельно. Этот дашборд, на первый взгляд, слабо отличался от классической Канбан-доски , однако в нашем случае столбцы означали не статус выполнения задач, а их тип. В этом дашборде для каждого требования формировалась отдельная строка, в которой были отражены все связанные с этим требованием задачи, сгруппированные по видам деятельности (в классической последовательности waterfall). Если задача была создана в интересах выполнения нескольких требований, то карточка этой задачи повторялась в каждой из строк связанных требований. Статус выполнения задач отражался на данном дашборде цветом, который создавал «третье измерение». Степень готовности требования определялась при этом готовностью всех связанных с этим требованием задач. Получилась как бы Канбан-доска вывернутая наизнанку. С другой стороны, с позиции положений PMBOK, сформированный дашборд представлял собой усовершенствованный вариант классической матрицы отслеживания требований (Requirements Traceability Matrix).

Для отображения статуса выполнения задач была принята следующая цветовая схема:

• голубой – задача включена в план работ;

• синий – задача находится в работе;

• розовый – у задачи отсутствует исполнитель;

• желтый – задача в ожидании, требует решения;

• серый – задача закрыта (про нее можно забыть);

• оранжевый – сорваны сроки выполнения задачи.

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

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

Фактически, этот дашборд стал основным инструментом для ежедневного получения ответа на вопрос управления проектом: «А что у нас сегодня самое важное?», что позволило в свою очередь своевременно реагировать на возникновение проблем. С позиций предложенной модели, для предотвращения проблем на проекте, необходимо ежедневно обеспечивать снижение количества красного, оранжевого и желтого цвета на предложенном дашборде. С другой стороны, поводом для беспокойства также являлось отсутствие связанных задач для требования (т.е. ситуация, когда требование запланировано, а работы по его реализации - нет).

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

Waterfall нельзя Agile

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

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

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

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

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

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

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

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

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

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

В рамках предложенного подхода хорошо зарекомендовало себя планирование работ с использованием метода «набегающей волны» (Rolling Wave Planning). При этом, отчасти благодаря вышеописанному дашборду, удавалось избегать разрозненности и несогласованности планируемых работ. На начальных этапах регистрации выборка по требованиям напоминала красный зонтик , когда для большинства требований не определены сроки готовности и ответственные исполнители, а работы запланированы только по их малой части. Однако постепенно дашборд требований превращался в сине-зеленый ковер. Появляющийся на этом ковре красные и оранжевые пятна заставляли проводить ежедневную корректировку намеченных задач, что способствовало снижению проектных рисков.

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

Несмотря на то, что замысел автоматизации управления проектом базировался на каскадной модели разработки (waterfall), оказалось, что в рамках предложенного подхода, при желании, могут безболезненно применяться элементы Agile. А кто, вообще, сказал, что водопад не гибкий? Например, для применения Scrum, в рамках предложенной модели, достаточно обеспечить регулярность проведения мероприятий (задач) по внедрению программного обеспечения, и тогда, соответственно, все работы, связанные с этим мероприятием, будут «вынуждены» подчиниться правилам спринтов, заданных таким образом.

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

Продолжение следует

Что в итоге? Разработанное программное обеспечение принято в промышленную эксплуатацию. В ходе проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний заказчик зафиксировал множество замечаний к реализованному программному продукту. Однако впоследствии на основании материалов уточнения требований, которые хранились в JIRA, 25% замечаний заказчик был вынужден признать как новые требования, выходящие за рамки проекта (планируемая трудоемкость выполнения этих требований была соизмерима с реализованным техническим заданием). Проблемы, связанные с выполнением контракта по госзаказу, не исчезли, однако контроль исполнения требований с использованием JIRA позволил выявлять риски срыва на стадии зарождения и оперативно на них реагировать. Это, в свою очередь, обеспечивало положительную динамику проекта на всех его этапах, несмотря на особенности национальной разработки программного обеспечения. Было замечено, что если требования заказчика зарегистрированы в JIRA и по ним сформированы задачи на анализ, разработку и тестирование, то в отношении таких требований происходило гораздо меньше разногласий и споров.

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

Двухлетний опыт применения JIRA по новым правилам подтвердил старые истины:

• JIRA не заменяет руководство проектом, но она помогает оперативно ориентироваться в потоке разнородных задач;

• JIRA поможет сосредоточить усилия по выполнению проекта в нужном месте и в нужное время, но она не будет делать эти усилия за вас;

• JIRA не решит проблемы проекта за вас, но поможет выявить их уже на ранних стадиях (при этом, она выявит и те проблемы, которые вы надеялись скрыть);

• как любая автоматизированная система, JIRA поможет быстрее реализовать любое ваше решение, независимо от того, хорошее оно или плохое;

• JIRA не заменяет общение сотрудников проектной группы, но поможет безболезненно разрешить спорные ситуации;

• JIRA не спасет от увольнения сотрудника, но поможет другому, занявшему место выбывшего, быстро войти в курс дела;

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

И самое главное – JIRA не примет решение за вас, воспользуетесь ли вы ее помощью или нет.