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

Секреты Полишенеля

Интеллект — это способность избегать выполнения работы, но так, чтобы она при этом была сделана.

После первой публикации несколько руководителей заинтересовались нашим опытом использования JIRA и решили внедрить подобную схему автоматизации управления на своих проектах. Поэтому в результате написания этого эссе предполагалось одновременно «изловить несколько зайцев»:

- последовательно рассматривая каждый тип задач JIRA как подпроцесс проекта, в ходе изложения:

• унифицировать спецификации этих подпроцессов;

• стандартизировать бизнес-правила организуемых работ;

• составить карты типовых «подводных камней» и мест, требующих заблаговременной «подстилки соломы»;

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

- сформулировать постановку задачи для администратора JIRA в целях развертывания новых проектов в соответствии с предложенным подходом;

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

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

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

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

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

Границы проекта

Любая сложная задача имеет простое, легкое для понимания, неправильное решение.

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

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

• разработка – требования в рамках договоров на создание новых систем (подсистем);

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

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

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

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

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

Однако, как показала практика, в реальной разработке длительно сопровождаемого программного продукта тяжело разделить работы по развитию и по сопровождению. Еще не закончилась опытная эксплуатация (контракт на развитие не закрыт), а заказчик уже вовсю формирует требования по расширенному сопровождению к компонентам системы, которые еще не приняты в промышленную эксплуатацию. Заказчика можно понять, поскольку мир меняется быстрее, чем это было запланировано в утвержденных контрактах. При этом продолжается выявление новых дефектов программного обеспечения. И пользователю, обнаружившему дефект, совершенно не важно, в рамках какого договора эта ошибка должна быть исправлена. С его точки зрения - ее просто не должно было быть. Для того, чтобы отнести выявленную ошибку к тому или иному договору, нужно время на ее анализ, и если проекты JIRA разделены на основе договоров, возникает дилемма : «А в каком проекте JIRA надо этот дефект регистрировать?». Кроме того, необходимо организовать перенос задачи из одного проекта в другой, если была допущена ошибка классификации требования. Если же все выявляемые дефекты программного обеспечения возложить на отдельный проект группы сопровождения, повышаются риски возникновения проблем при решении вопросов оплаты работ по этапу договора на развитие или рассмотрения рекламаций по несоблюдению соглашения об уровне предоставления услуг ( SLA ).

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

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

С учетом этого определение границ проекта JIRA должна обеспечить гармонию между двумя следующими соображениями.

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

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

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

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

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

Одним из ограничений на проект JIRA может быть максимальное количество сотрудников проектной группы. Личный опыт подсказывает следующий вывод: максимальный состав группы разработки на одном проекте JIRA подчиняется правилу Миллера (в лучших традициях Agile). Под группой разработки здесь понимаются программисты и аналитики, которые формируют постановки задач для них. И, конечно, руководитель проекта. (Как вы могли подумать! Это святое!) При этом, если бюджет проекта позволяет, оставшиеся 80% сотрудников проектной группы, состоящие из приветливых девушек группы сопровождения, ворчливых тестировщиков, нудных технических писателей и веселого сисадмина, безболезненно и гармонично могут быть включены в проект JIRA.

Как разложить задачи по полочкам

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

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

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

• через пользовательский интерфейс ;

• через документы, формируемые для печати на бумаге;

• посредством протоколов электронного обмена данными ( API / EDI ).

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

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

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

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

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

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

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

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

Любителям комфорта в этой связи, возможно, может здорово помочь плагин Subcomponents for JIRA .

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

Принятые правила классификации задач не только сокращают время, затрачиваемое на поиск, но и обеспечивают возможность автоматизации:

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

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

- анализа качества разработки документации ,

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

Границы вместо связей

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

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

А насколько точно надо смоделировать бизнес-процесс для того чтобы эффективно им управлять? Для того чтобы управлять эффективно автомобилем на панель управления водителя не отображается полные схемы процессов, которые приводят этот автомобиль в движение. Может и в случае JIRA, не стоит пытаться учесть все возможные комбинации, которые могут возникнуть при организации работ на проекте?

Источник

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

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

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

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

В последнее время получила широкое распространение концепция управления BPM (business process management), системно рассматривающая деятельность компании через призму процессов. Идеология BPM положена в основу множества современных «библий» по управлению, таких как:

• свод знаний по управлению бизнес-процессами ( BPM CBOK );

• свод знаний по управлению проектами ( PM BOK );

• библиотека инфраструктуры информационных технологий ( ITIL);

• международные стандарты по управлению качеством ISO 9000;

• модель зрелости разработки программного обеспечения Института программной инженерии ( CMMI SEI);

• и, конечно, ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

Сегодня практически ни одна вакансия на руководителя проекта не обходится без требования о наличии у соискателя сертификата PMP или ITIL. Множество учебников рассказывает, как, используя методы и подходы BPM практически на любом производстве, можно достичь новых высот конкурентоспособности и взаимоотношений с клиентами, поставщиками и сотрудниками. Во многих из этих книг в интересах скорейшего достижения положительных результатов настоятельно рекомендуется применение тех или иных BPMS. Вот только почему-то мне достаточно редко попадались материалы по прикладному внедрению методов и подходов BPM для производства программного обеспечения (особенно в случаях, когда по тем или иным причинам, применение апробированных методик Agile не представляется возможным). И вообще не встречались материалы по успешному применению BPM для « производства » самого остродефицитного ресурса. Перечисленные выше «библии» задают «вершины» (что немаловажно). Однако каким образом проектной команде добраться до этих «вершин»?

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

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

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