Ранее в статье «JIRA как средство от бессонницы и нервных срывов» был предложен вариант применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Однако неосторожное обращение со средствами автоматизации управления на «цифровой кухне» может не только испортить продукт приготовления, но и привести к многочисленным травмам. В серии статей «Правила своевременного приготовления вкусного программного обеспечения» предполагается подробно исследовать правила организации работ на программном проекте с использованием катализатора под названием JIRA. Приветствуется любая критика.
Источник
После публикации статьи «JIRA как средство от бессонницы и нервных срывов» несколько руководителей заинтересовались нашим опытом использования JIRA и решили внедрить подобную схему автоматизации управления на своих проектах. Поэтому в результате написания этого эссе предполагалось одновременно «изловить несколько зайцев»:
— последовательно рассматривая каждый тип задач JIRA как подпроцесс проекта, в ходе изложения:
— сформулировать постановку задачи для администратора JIRA в целях развертывания новых проектов в соответствии с предложенным подходом;
— получить неформальный, но тем не менее, понятный и прозрачный регламент по распределению ответственности всех сотрудников проектных групп;
— формализовать лучшие рецепты, найденные в ходе решения проблемных ситуаций («лайфхаки» руководителя проекта);
— выявить ранее не замеченные слабые места предложенного подхода в ходе обсуждения деталей его реализации с читателями Habr.
Сразу хотелось бы отметить: часть описанных техник хорошо зарекомендовали себя на одной из «цифровых кухонь» ЛАНИТ для управления проектом по разработке и сопровождению заказного программного обеспечения в интересах крупного государственного заказчика. Однако совсем не факт, что эти рекомендации окажутся одинаково полезны и на вашем проекте. С другой стороны, мы вступаем на terra incognita. Часть высказанных соображений только планируется к внедрению. Поэтому если вы видите в предложенном подходе слабые места или есть конструктивные предложения по оптимизации – добро пожаловать к обсуждению в комментариях.
Предполагается, что после проведенной унификации в интересах разных руководителей описанная технология управления будет успешно применяться на программных проектах разной направленности и разного масштаба. В свою очередь, использование единого понятийного пространства при регистрации задач JIRA создает предпосылки для автоматизированной оценки текущего состояния дел в рамках портфеля проектов. Кроме того, предполагается, что единый подход к учету результатов работ в JIRA упростит мобильность сотрудников между несколькими проектными группами, что в свою очередь также будет способствовать повышению успешности проектов.
Поскольку предложенный алгоритм применения JIRA стал «расползаться» на другие проекты, потребовалось переосмыслить вопрос: «А чем собственно определяются границы программного проекта в JIRA?»
По мнению адептов незамутненного PMBoK, ответ на этот вопрос элементарен: «Конечно, границы проекта определяются уставом (паспортом) проекта». С этой точки зрения, для каждого договора с заказчиком в JIRA должен быть сформирован отдельный проект. При этом зачастую разработка одного программного комплекса может предусматривать несколько направлений деятельности, в рамках которых, как правило, заключается несколько контрактов:
Кроме того, в рамках создания программного обеспечения проектная команда должна решать требования, которые не определены ни одним из договоров. Это требования руководителя проекта, связанные с предпроектной деятельностью, рефакторингом, пресейлом, устранением ошибок выявленных самостоятельно, обучением сотрудников и т.п.
Однако, как показала практика, в реальной разработке длительно сопровождаемого программного продукта тяжело разделить работы по развитию и по сопровождению. Еще не закончилась опытная эксплуатация (контракт на развитие не закрыт), а заказчик уже вовсю формирует требования по расширенному сопровождению к компонентам системы, которые еще не приняты в промышленную эксплуатацию. Заказчика можно понять, поскольку мир меняется быстрее, чем это было запланировано в утвержденных контрактах. При этом продолжается выявление новых дефектов программного обеспечения. И пользователю, обнаружившему дефект, совершенно не важно, в рамках какого договора эта ошибка должна быть исправлена. С его точки зрения — ее просто не должно было быть. Для того, чтобы отнести выявленную ошибку к тому или иному договору, нужно время на ее анализ, и если проекты JIRA разделены на основе договоров, возникает дилемма: «А в каком проекте JIRA надо этот дефект регистрировать?». Кроме того, необходимо организовать перенос задачи из одного проекта в другой, если была допущена ошибка классификации требования. Если же все выявляемые дефекты программного обеспечения возложить на отдельный проект группы сопровождения, повышаются риски возникновения проблем при решении вопросов оплаты работ по этапу договора на развитие или рассмотрения рекламаций по несоблюдению соглашения об уровне предоставления услуг (SLA).
С другой стороны, ревнивые руководители подразделений предлагают в рамках проекта сформировать отдельные проекты для группы сопровождения, аналитического отдела, департамента разработки и тестирования. Каждый хочет быть полноправным хозяином в своей епархии и не отвечать за «косяки» соседей. Тем более, что удивительная гибкость JIRA позволяет создавать связи между задачами разных проектов.
Источник
На мой взгляд, вышеописанные подходы регистрации проектов в JIRA похожи на попытки сварить один суп в нескольких разных кастрюлях, находящихся в разных кухнях. Основной целью проекта является своевременное создание программного продукта заданного качества. С точки зрения заказчика, качество продукта определяется набором функциональных возможностей этого продукта, используя которые заказчик может гарантированно (т.е. надежно) решать свои проблемы. И конечному функциональному заказчику не важно, в рамках каких договорных отношений была создана требуемая функциональность. Так же, как не важно для летчика знание перечня субподрядчиков, привлеченных для создания его самолета.
С учетом этого определение границ проекта JIRA должна обеспечить гармонию между двумя следующими соображениями.
Источник: Сергей Архипенков. Оценка проектов: шарлатанство или шаманство
Стоит подумать о формировании отдельных проектов JIRA для регистрации результатов работ, регулярно выполняемых в рамках нескольких программных продуктов (например, учета времени сотрудников, потраченного на изучение новых технологий или работ, связанных с резервным копированием).
Одним из ограничений на проект JIRA может быть максимальное количество сотрудников проектной группы. Личный опыт подсказывает следующий вывод: максимальный состав группы разработки на одном проекте JIRA подчиняется правилу Миллера (в лучших традициях Agile). Под группой разработки здесь понимаются программисты и аналитики, которые формируют постановки задач для них. И, конечно, руководитель проекта. (Как вы могли подумать! Это святое!) При этом, если бюджет проекта позволяет, оставшиеся 80% сотрудников проектной группы, состоящие из приветливых девушек группы сопровождения, ворчливых тестировщиков, нудных технических писателей и веселого сисадмина, безболезненно и гармонично могут быть включены в проект JIRA.
На любом проекте навигация сотрудников в потоке решаемых задач является одной из важных составляющих успеха. Однако с ростом объема проекта разобраться в этом потоке становится все сложнее, что может стать, само по себе, одной из проблем управления большим проектом. Поэтому определение единой системы координат, по которым одинаково просто могли бы ориентироваться все ключевые участники, является неотъемлемой частью автоматизации управления проектом.
В основу такой системы координат в нашем проекте были положены следующие соображения: программный продукт, как правило, можно представить, как черный ящик, который общается с внешним миром посредством трех основных способов:
Именно в пространстве этих трех измерений видят программное обеспечение конечные пользователи. С другой стороны, именно на формирование и обработку указанных потоков данных направлено создание программного обеспечения.
Источник
Кроме того, в качестве дополнительных координат в рамках проекта были приняты основные объекты базы данных и автоматизируемые бизнес-процессы. Для навигации в рамках этого пространства координат были сформированы соответствующие классификаторы, сопровождение которых обеспечивалось руководителем и аналитиками проекта. Каждый элемент классификатора состоял из кода и его определения.
В ходе моих проектов для каждого классификатора постепенно были выявлены свои особенности, которые стоит учесть в случае, если вы решите применять у себя подобный подход.
Для тех, кто не ищет легких путей, маркирование задач JIRA может осуществляется на основании регистрации соответствующих кодов в поле «Компоненты». При регистрации в JIRA задач любого типа в поле «Компоненты» необходимо просто указать перечень кодов объектов, на изменение/формирование которых направлена планируемая работа. По итогам решения каждой задачи ответственный исполнитель должен уточнить состав компонентов (в случае необходимости). Сопровождение самих классификаторов компонентов в этом случае осуществляется вне JIRA.
Любителям комфорта в этой связи, возможно, может здорово помочь плагин Subcomponents for JIRA.
Необходимо отметить, что применение правильно составленных классификаторов компонентов программного обеспечения неявно стандартизирует коллективное сознание и язык общения проектной группы, в результате чего повышается общий уровень взаимопонимания. С другой стороны, этот подход является одним из методов ненасильственного принуждения аналитиков к большей детализации задач, что, в свою очередь, повышает точность оценки сроков реализации требований на проекте.
Принятые правила классификации задач не только сокращают время, затрачиваемое на поиск, но и обеспечивают возможность автоматизации:
При описании общих принципов нашей модели было сказано об использовании только одного типа связи «причина» -> «действие» (и в рамках описанного проекта этой связи вполне хватало). Однако желание использовать одинаковые механизмы JIRA для автоматизации управления в нескольких разных проектах потребовало расширить количество типов используемых связей и унифицировать подходы к их применению.
Источник
JIRA «из коробки» предлагает пользователю несколько различных типов связей между задачами, и бесконтрольное использование этих связей может привести к печальным последствиям. Чтобы не запутать себя и окружающих, мы согласовали следующие основные правила связывания задач JIRA.
Согласно предложенному подходу для всех типов задач, регистрируемых JIRA, присущи одинаковые черты. Прежде всего, для всех типов задач JIRA характерен одинаковый рабочий процесс (workflow). При этом в рамках каждой задачи статус выполнения работы определялся прежде всего с точки зрения исполнителя этой задачи.
В ходе унификации задач для нескольких проектов ранее приведенный рабочий процесс был модернизирован. Главным изменением явилось введение дополнительного статуса «оценка» предназначенного для преодоления проблемы описанной в эпиграфе к разделу. С одной стороны, задачи в данном статусе уже зарегистрированы в JIRA и не пройдут мимо внимания руководителя проекта. С другой стороны, эти задачи еще непугают отвлекают ответственных исполнителей.
Также, статус «план» был переименован в «назначено», поскольку такое название оказалось более толерантным по отношению к задачам типа «требование» (для случая когда для требования формируется проектное решение, а задачи по реализации еще не запланированы).
В ходе комплексного анализа нескольких проектов были определены атрибуты, которые присущи для всех типов задач.
* особенности атрибутов предполагается обсудить в ходе формирования спецификации для каждого из перечисленных типов задач
Изменение общих для всех задач атрибутов при переходах из состояния в состояние описывается следующей таблицей, где:
— возможно изменение атрибута;
— требуется обязательный ввод данных;
— значение поля очищается.
Переходы «в работу» и «отложить» в таблице не описаны. Данные переходы доступны только исполнителю, изменение атрибутов задач при этих переходах не предполагается. Также не описан переход «эксгумировать». Как видно из названия, использование данного перехода крайне нежелательно. Данный переход используется администратором проекта только в случае заведомо ошибочного перевода задачи в статус «закрыто» (при данном переходе запрашивается только регистрация причины этого перехода).
В последнее время получила широкое распространение концепция управления BPM (business process management), системно рассматривающая деятельность компании через призму процессов. Идеология BPM положена в основу множества современных «библий» по управлению, таких как:
Сегодня практически ни одна вакансия на руководителя проекта не обходится без требования о наличии у соискателя сертификата PMP или ITIL. Множество учебников рассказывает, как, используя методы и подходы BPM практически на любом производстве, можно достичь новых высот конкурентоспособности и взаимоотношений с клиентами, поставщиками и сотрудниками. Во многих из этих книг в интересах скорейшего достижения положительных результатов настоятельно рекомендуется применение тех или иных BPMS. Вот только почему-то мне достаточно редко попадались материалы по прикладному внедрению методов и подходов BPM для производства программного обеспечения (особенно в случаях, когда по тем или иным причинам, применение апробированных методик Agile не представляется возможным). И вообще не встречались материалы по успешному применению BPM для «производства» самого остродефицитного ресурса (если кто знает о таких материалах, поделитесь в комментариях). Перечисленные выше «библии» задают «вершины» (что немаловажно). Однако каким образом проектной команде добраться до этих «вершин»?
Декларации о применении процессного подхода в управлении совсем не означают использование принципов BPM на деле. Опыт моих программных проектов говорит, что, как правило, проектная команда так занята автоматизацией BPM в интересах заказчика, что не имеет времени для использования этих принципов в интересах оптимизации собственной деятельности.
Источник
Изначально описываемый здесь вариант применения JIRA имел основной целью снижение головной боли сотрудников проектной команды от управления программным проектом. Однако, постепенно модифицируя проект JIRA в ходе решения конкретных прикладных задач управления проектом, появилось осознание, что сформированная модель данных проекта достаточно полно отражает сквозные процессы создания программного обеспечения. Это в свою очередь создает все предпосылки для роста эффективности проектных групп на основе применения механизмов BPM. При этом представляется, что возможности JIRA вполне позволяют обеспечить последовательное созревание процесса разработки программного обеспечения без использования специализированных BPMS. Все дальнейшие предложения по использованию JIRA для автоматизации управления программными проектами будут сделаны с учетом этого ключевого соображения.
Один из первых шагов по лестнице CMMI состоит в выявлении, документировании и унификации процессов организации. Поэтому в рамках цикла статей «JIRA: правила своевременного приготовления вкусного ПО» предполагается последовательно сформировать спецификации по всем типам решаемых задач и попытаться сформировать критериальный аппарат их комплексной оценки с точки зрения процессного подхода. Следующая статья будет посвящена особенностям регистрации задач типа «требование» и бизнес-процессам по их реализации.
P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI. В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии статей, с учетом изменений и уточнений произошедших после публикации этой статьи на Habr.
Секреты Полишенеля
Интеллект — это способность избегать выполнения работы, но так, чтобы она при этом была сделана.
Линус Тордвальдс
После публикации статьи «JIRA как средство от бессонницы и нервных срывов» несколько руководителей заинтересовались нашим опытом использования JIRA и решили внедрить подобную схему автоматизации управления на своих проектах. Поэтому в результате написания этого эссе предполагалось одновременно «изловить несколько зайцев»:
— последовательно рассматривая каждый тип задач JIRA как подпроцесс проекта, в ходе изложения:
- унифицировать спецификации этих подпроцессов;
- стандартизировать бизнес-правила организуемых работ;
- составить карты типовых «подводных камней» и мест, требующих заблаговременной «подстилки соломы»;
- определить измеримые и достижимые показатели результатов выполнения задач каждого типа.
— сформулировать постановку задачи для администратора JIRA в целях развертывания новых проектов в соответствии с предложенным подходом;
— получить неформальный, но тем не менее, понятный и прозрачный регламент по распределению ответственности всех сотрудников проектных групп;
— формализовать лучшие рецепты, найденные в ходе решения проблемных ситуаций («лайфхаки» руководителя проекта);
— выявить ранее не замеченные слабые места предложенного подхода в ходе обсуждения деталей его реализации с читателями Habr.
Сразу хотелось бы отметить: часть описанных техник хорошо зарекомендовали себя на одной из «цифровых кухонь» ЛАНИТ для управления проектом по разработке и сопровождению заказного программного обеспечения в интересах крупного государственного заказчика. Однако совсем не факт, что эти рекомендации окажутся одинаково полезны и на вашем проекте. С другой стороны, мы вступаем на terra incognita. Часть высказанных соображений только планируется к внедрению. Поэтому если вы видите в предложенном подходе слабые места или есть конструктивные предложения по оптимизации – добро пожаловать к обсуждению в комментариях.
Предполагается, что после проведенной унификации в интересах разных руководителей описанная технология управления будет успешно применяться на программных проектах разной направленности и разного масштаба. В свою очередь, использование единого понятийного пространства при регистрации задач JIRA создает предпосылки для автоматизированной оценки текущего состояния дел в рамках портфеля проектов. Кроме того, предполагается, что единый подход к учету результатов работ в JIRA упростит мобильность сотрудников между несколькими проектными группами, что в свою очередь также будет способствовать повышению успешности проектов.
Границы проекта
Любая сложная задача имеет простое, легкое для понимания, неправильное решение.
Артур Блох
Поскольку предложенный алгоритм применения JIRA стал «расползаться» на другие проекты, потребовалось переосмыслить вопрос: «А чем собственно определяются границы программного проекта в JIRA?»
По мнению адептов незамутненного PMBoK, ответ на этот вопрос элементарен: «Конечно, границы проекта определяются уставом (паспортом) проекта». С этой точки зрения, для каждого договора с заказчиком в JIRA должен быть сформирован отдельный проект. При этом зачастую разработка одного программного комплекса может предусматривать несколько направлений деятельности, в рамках которых, как правило, заключается несколько контрактов:
- разработка – требования в рамках договоров на создание новых систем (подсистем);
- развитие – требования в рамках контрактов, направленных на существенную доработку существующих подсистем;
- расширенное сопровождение – требования договоров по оперативной доработке отдельных модулей системы по текущим изменениям бизнес-процессов заказчика;
- гарантийное сопровождение – устранение ошибок программного обеспечения, выявленных в рамках гарантийного периода;
- базовое сопровождение – устранение ошибок программного обеспечения, выявленных после завершения гарантийного периода.
Кроме того, в рамках создания программного обеспечения проектная команда должна решать требования, которые не определены ни одним из договоров. Это требования руководителя проекта, связанные с предпроектной деятельностью, рефакторингом, пресейлом, устранением ошибок выявленных самостоятельно, обучением сотрудников и т.п.
Однако, как показала практика, в реальной разработке длительно сопровождаемого программного продукта тяжело разделить работы по развитию и по сопровождению. Еще не закончилась опытная эксплуатация (контракт на развитие не закрыт), а заказчик уже вовсю формирует требования по расширенному сопровождению к компонентам системы, которые еще не приняты в промышленную эксплуатацию. Заказчика можно понять, поскольку мир меняется быстрее, чем это было запланировано в утвержденных контрактах. При этом продолжается выявление новых дефектов программного обеспечения. И пользователю, обнаружившему дефект, совершенно не важно, в рамках какого договора эта ошибка должна быть исправлена. С его точки зрения — ее просто не должно было быть. Для того, чтобы отнести выявленную ошибку к тому или иному договору, нужно время на ее анализ, и если проекты JIRA разделены на основе договоров, возникает дилемма: «А в каком проекте JIRA надо этот дефект регистрировать?». Кроме того, необходимо организовать перенос задачи из одного проекта в другой, если была допущена ошибка классификации требования. Если же все выявляемые дефекты программного обеспечения возложить на отдельный проект группы сопровождения, повышаются риски возникновения проблем при решении вопросов оплаты работ по этапу договора на развитие или рассмотрения рекламаций по несоблюдению соглашения об уровне предоставления услуг (SLA).
С другой стороны, ревнивые руководители подразделений предлагают в рамках проекта сформировать отдельные проекты для группы сопровождения, аналитического отдела, департамента разработки и тестирования. Каждый хочет быть полноправным хозяином в своей епархии и не отвечать за «косяки» соседей. Тем более, что удивительная гибкость JIRA позволяет создавать связи между задачами разных проектов.
На мой взгляд, вышеописанные подходы регистрации проектов в JIRA похожи на попытки сварить один суп в нескольких разных кастрюлях, находящихся в разных кухнях. Основной целью проекта является своевременное создание программного продукта заданного качества. С точки зрения заказчика, качество продукта определяется набором функциональных возможностей этого продукта, используя которые заказчик может гарантированно (т.е. надежно) решать свои проблемы. И конечному функциональному заказчику не важно, в рамках каких договорных отношений была создана требуемая функциональность. Так же, как не важно для летчика знание перечня субподрядчиков, привлеченных для создания его самолета.
С учетом этого определение границ проекта JIRA должна обеспечить гармонию между двумя следующими соображениями.
- Необходимо, чтобы в проекте нашли отражение все работы, которые выполняются в ходе создания/модификации программного продукта (или его подсистемы). Проект должен рассматриваться как единый процесс по созданию одного программного продукта (одного «самолета»). Поэтому основной принцип: один программный продукт — один проект JIRA. При этом важно не забывать, что производит ваша компания — «самолет» или «двигатель для самолетов». В любом случае создатели программного обеспечения не должны быть отчуждены от последствий своих решений.
Независимо от вида договорных отношений с заказчиком входной точкой процесса создания программного продукта является любое требование на его модификацию. Завершающим мероприятием — получение подтверждения заказчика, что данное требование реализовано (или признано несостоятельным). Это правило является основным для оценки полноты планирования и завершенности задач в проекте JIRA.
Желательно чтобы в проекте JIRA также нашли место вспомогательные работы, которые были инициированы в интересах реализации требования заказчика. В ходе разработки программного обеспечения происходит множество событий, которые, как правило, остаются «за кадром»: регулярные совещания по уточнению сроков, развертывание тестовых серверов, подготовка тестовых данных, формирование дополнительных инструкций и т.п. JIRA может здорово помочь в обнаружении дыр, через которые щедро и безвозвратно утекает рабочее время сотрудников проектной группы. Но только при условии, если эти работы будут регистрироваться в проекте JIRA. - В случае разработки действительно больших программных комплексов не стоит запихивать все в один проект JIRA, значительно повышая риски срыва. В таких случаях в рамках отдельного проекта JIRA целесообразно группировать по функциям программного обеспечения, которые обеспечивают поддержку одного из бизнес-процессов заказчика (как правило, такие функции выделяются в отдельные подсистемы уже на этапе концептуального проектирования).
Стоит подумать о формировании отдельных проектов JIRA для регистрации результатов работ, регулярно выполняемых в рамках нескольких программных продуктов (например, учета времени сотрудников, потраченного на изучение новых технологий или работ, связанных с резервным копированием).
Одним из ограничений на проект JIRA может быть максимальное количество сотрудников проектной группы. Личный опыт подсказывает следующий вывод: максимальный состав группы разработки на одном проекте JIRA подчиняется правилу Миллера (в лучших традициях Agile). Под группой разработки здесь понимаются программисты и аналитики, которые формируют постановки задач для них. И, конечно, руководитель проекта. (Как вы могли подумать! Это святое!) При этом, если бюджет проекта позволяет, оставшиеся 80% сотрудников проектной группы, состоящие из приветливых девушек группы сопровождения, ворчливых тестировщиков, нудных технических писателей и веселого сисадмина, безболезненно и гармонично могут быть включены в проект JIRA.
Как разложить задачи по полочкам
В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
Шерлок Холмс
На любом проекте навигация сотрудников в потоке решаемых задач является одной из важных составляющих успеха. Однако с ростом объема проекта разобраться в этом потоке становится все сложнее, что может стать, само по себе, одной из проблем управления большим проектом. Поэтому определение единой системы координат, по которым одинаково просто могли бы ориентироваться все ключевые участники, является неотъемлемой частью автоматизации управления проектом.
В основу такой системы координат в нашем проекте были положены следующие соображения: программный продукт, как правило, можно представить, как черный ящик, который общается с внешним миром посредством трех основных способов:
- через пользовательский интерфейс;
- через документы, формируемые для печати на бумаге;
- посредством протоколов электронного обмена данными (API / EDI).
Именно в пространстве этих трех измерений видят программное обеспечение конечные пользователи. С другой стороны, именно на формирование и обработку указанных потоков данных направлено создание программного обеспечения.
Кроме того, в качестве дополнительных координат в рамках проекта были приняты основные объекты базы данных и автоматизируемые бизнес-процессы. Для навигации в рамках этого пространства координат были сформированы соответствующие классификаторы, сопровождение которых обеспечивалось руководителем и аналитиками проекта. Каждый элемент классификатора состоял из кода и его определения.
В ходе моих проектов для каждого классификатора постепенно были выявлены свои особенности, которые стоит учесть в случае, если вы решите применять у себя подобный подход.
- В нашем случае коды печатных форм не повторяли нумерацию форм согласно документов заказчика. Кроме того, отдельные формы имели несколько вариантов печати. Так, например, на протяжении существования программного обеспечения, форма одного из отчетов изменялась несколько раз на основании изменения нормативной документации (название и суть отчета не изменялась). При этом, для старых данных требовалось сохранить печать этого отчета в старых формах. Те же самые соображения касаются и классификации в рамках проекта протоколов электронного обмена данными.
- В иерархии форм отдельными элементами могут выделяться панели навигации (меню), списковые формы, карточки объектов, вкладки, панели фильтров, формы загрузки/выгрузки данных, а также формы сложных групповых операций.
- «Деревья» технологических процессов желательно «выращивать» таким образом, чтобы «листьями» у них были атомарные (неделимые) технологические операции, на основании которых, в свою очередь, можно обеспечить функционирование подсистему распределения доступа (подсистема безопасности).
- Поскольку все элементы классификации при таком подходе отображаются на экранах JIRA в рамках одного поля, необходимо кроме названий компонентов предусмотреть хотя бы примитивную кодификацию, чтобы отличать форму «Регистрация сотрудника» от процесса «Регистрация сотрудника».
Для тех, кто не ищет легких путей, маркирование задач JIRA может осуществляется на основании регистрации соответствующих кодов в поле «Компоненты». При регистрации в JIRA задач любого типа в поле «Компоненты» необходимо просто указать перечень кодов объектов, на изменение/формирование которых направлена планируемая работа. По итогам решения каждой задачи ответственный исполнитель должен уточнить состав компонентов (в случае необходимости). Сопровождение самих классификаторов компонентов в этом случае осуществляется вне JIRA.
Любителям комфорта в этой связи, возможно, может здорово помочь плагин Subcomponents for JIRA.
Необходимо отметить, что применение правильно составленных классификаторов компонентов программного обеспечения неявно стандартизирует коллективное сознание и язык общения проектной группы, в результате чего повышается общий уровень взаимопонимания. С другой стороны, этот подход является одним из методов ненасильственного принуждения аналитиков к большей детализации задач, что, в свою очередь, повышает точность оценки сроков реализации требований на проекте.
Принятые правила классификации задач не только сокращают время, затрачиваемое на поиск, но и обеспечивают возможность автоматизации:
- оценки общей планируемой трудоемкости (или реальных трудозатрат) по работам, направленным на реализацию тех или иных элементов программного обеспечения,
- оценки реального распределения приоритетов — на каком-то этапе проекта его руководитель может с удивлением обнаружить, что основная часть работ проводится отнюдь не в отношении приоритетных компонентов,
- анализа качества разработки документации,
- оценки качества управления проектом в части планирования. С одной стороны, не имеет смысла планирование задач, в ходе которых не формируются (модифицируются) компоненты, с другой стороны — планирование задачи, в ходе разработки которой изменяются десятки объектов, говорит о недостаточно тщательной постановке этой задачи.
Связывая задачи, не свяжите себе руки
При описании общих принципов нашей модели было сказано об использовании только одного типа связи «причина» -> «действие» (и в рамках описанного проекта этой связи вполне хватало). Однако желание использовать одинаковые механизмы JIRA для автоматизации управления в нескольких разных проектах потребовало расширить количество типов используемых связей и унифицировать подходы к их применению.
JIRA «из коробки» предлагает пользователю несколько различных типов связей между задачами, и бесконтрольное использование этих связей может привести к печальным последствиям. Чтобы не запутать себя и окружающих, мы согласовали следующие основные правила связывания задач JIRA.
- Недопустимо замыкание в цикл связей одного типа (хотя JIRA позволяет это сделать).
- Дополнительная связь «Причинность» (Depended) («причина» => «действие») используется только для соединения задач разного типа, причем только в направлении «течения» классической каскадной модели (waterfall): требование => анализ => разработка => тестирование => документирование => внедрение. Указание этих связей в обратном порядке и связывание с помощью нее задач одного типа недопустимо. Если при внедрении родились новые требования, то при регистрации этих требований в JIRA, связь между ними и задачей на внедрение, в ходе выполнения которой они появились, не формируется.
- Связь «Блокировка» (Blocks) («блокирует» => «блокируется») может использоваться в рамках любого из типов задач для выстраивания последовательностей выполнения работ (например, составления сценария выполнения тестовых заданий).
- Связь «Отношение» (Cloners) («родитель» => «потомок») используется только для связи задач типа «требование». Связывает исходный документ заказчика содержащей несколько требований («родитель») с задачами содержащими атомарные требования «потомки».
- Связь «Дополнение» (Relates) («дополняет» => «дополняется») применяется только для связей в рамках задач типа «требование». Используется для регистрации отношения между задачей основного требования и задачами, в которых регистрируются ошибки, замечания и уточнения, выявленные в ходе проведения испытаний. Фактически, с помощью этого вида связи, обеспечивается регистрация истории изменения требований.
- Связь «Дубликат» (Duplicate) («дублирует» => «дублируется») используется только для связи задач типа «требование». При указании дубликатов необходимо определиться с основным требованием, в рамках которого будут планироваться работы по его реализации. В отношении дубликатов связи с задачами по реализации не создаются.
Workflow на все случаи жизни
Причина многих бед заключается в том, что мы ставим в план столько задач, сколько нам надо выполнить, а не столько, сколько мы можем выполнить.
Максим Дорофеев
Согласно предложенному подходу для всех типов задач, регистрируемых JIRA, присущи одинаковые черты. Прежде всего, для всех типов задач JIRA характерен одинаковый рабочий процесс (workflow). При этом в рамках каждой задачи статус выполнения работы определялся прежде всего с точки зрения исполнителя этой задачи.
В ходе унификации задач для нескольких проектов ранее приведенный рабочий процесс был модернизирован. Главным изменением явилось введение дополнительного статуса «оценка» предназначенного для преодоления проблемы описанной в эпиграфе к разделу. С одной стороны, задачи в данном статусе уже зарегистрированы в JIRA и не пройдут мимо внимания руководителя проекта. С другой стороны, эти задачи еще не
Также, статус «план» был переименован в «назначено», поскольку такое название оказалось более толерантным по отношению к задачам типа «требование» (для случая когда для требования формируется проектное решение, а задачи по реализации еще не запланированы).
В ходе комплексного анализа нескольких проектов были определены атрибуты, которые присущи для всех типов задач.
| Описание общих атрибутов для всех типов задач | |
|---|---|
| Наименование атрибута | Описание |
| Общие атрибуты | |
| Автор | Пользователь, создавший задачу в JIRA |
| Исполнитель | Текущий пользователь на которого назначена задача |
| Ответственный исполнитель | Пользователь, который несет ответственность за результат решения задачи. Данное поле предполагается использовать для предварительной оценки загруженности сотрудников и для автоматического назначения задачи при выполнении условий готовности исходных компонентов (задач). |
| Тема* | Тема задачи должна отражать предполагаемый результат решения задачи, в соответствии с лучшими традициями SEO, сочетая правила формирования заголовка страницы H1 и мета-тегов Title и Description. |
| Описание* | Описание задачи должно содержать описание последовательности действий для достижения желаемого результата. |
| Приоритет | Уровень приоритета, который характеризует важность задачи:
|
| Уровни безопасности | Уровень доступа к ознакомлению с задачами проекта:
|
| Компоненты | Регистрируются авторами задач, при необходимости уточняются исполнителями по результату решения в рамках следующих разделов:
|
| Связи | Связи с другими задачами. |
| Метки | Вводятся по решению исполнителей. |
| Файлы | Дополнительные материалы задачи (использовать не рекомендуется). Для хранения дополнительных материалов рекомендуется использовать репозиторий документации. |
| Журнал работ | |
| Срок исполнения | Требуемая дата решения задачи (deadline). |
| Плановая трудоемкость* | Предполагаемая (планируемая) трудоемкость решения задачи с учетом квалификации конкретного ответственного исполнителя. |
| Нормированная трудоемкость* | Трудоемкость решения задачи без учета квалификации конкретного исполнителя (трудоемкость для отчетов перед заказчиком). Также используется для первичной оценки трудозатрат по реализации требований заказчика. При указании данного атрибута здесь также необходимо учитывать резерв времени на решение форс-мажоров. В частности, если речь идет о задаче на тестирование критической цепи, то в этом случае данное поле должно содержать «буфер подстраховки» с учетом всех подзадач, формирующих эту цепь. |
| Трудозатраты | Реальные трудозатраты назначенного исполнителя на реализацию конкретной задачи. |
| Причина ожидания | Перечень возможных причин перевода в статус «ожидание»:
|
| Причина возврата | Перечень возможных причин возврата задачи на доработку из статуса «выполнено»:
|
| Причина закрытия | Перечень причин закрытия задачи:
|
| Описание причины | Текстовое описание причины переходов «приостановить» или «возвратить», или «эксгумировать». |
| Результат решения | |
| Описание решения | Краткое описание способа решения задачи (что именно было сделано). |
Изменение общих для всех задач атрибутов при переходах из состояния в состояние описывается следующей таблицей, где:
— возможно изменение атрибута;
— требуется обязательный ввод данных;
— значение поля очищается.
Переходы «в работу» и «отложить» в таблице не описаны. Данные переходы доступны только исполнителю, изменение атрибутов задач при этих переходах не предполагается. Также не описан переход «эксгумировать». Как видно из названия, использование данного перехода крайне нежелательно. Данный переход используется администратором проекта только в случае заведомо ошибочного перевода задачи в статус «закрыто» (при данном переходе запрашивается только регистрация причины этого перехода).
Продолжение следует
В последнее время получила широкое распространение концепция управления 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 состоит в выявлении, документировании и унификации процессов организации. Поэтому в рамках цикла статей «JIRA: правила своевременного приготовления вкусного ПО» предполагается последовательно сформировать спецификации по всем типам решаемых задач и попытаться сформировать критериальный аппарат их комплексной оценки с точки зрения процессного подхода. Следующая статья будет посвящена особенностям регистрации задач типа «требование» и бизнес-процессам по их реализации.
P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI. В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии статей, с учетом изменений и уточнений произошедших после публикации этой статьи на Habr.
