- PVSM.RU - https://www.pvsm.ru -
Ранее в статье «JIRA как средство от бессонницы и нервных срывов [1]» был предложен вариант применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Однако неосторожное обращение со средствами автоматизации управления на «цифровой кухне» может не только испортить продукт приготовления, но и привести к многочисленным травмам. В серии статей «Правила своевременного приготовления вкусного программного обеспечения» предполагается подробно исследовать правила организации работ на программном проекте с использованием катализатора под названием JIRA. Приветствуется любая критика.
Источник [2]
Интеллект — это способность избегать выполнения работы, но так, чтобы она при этом была сделана.
Линус Тордвальдс
После публикации статьи «JIRA как средство от бессонницы и нервных срывов [1]» несколько руководителей заинтересовались нашим опытом использования JIRA и решили внедрить подобную схему автоматизации управления на своих проектах. Поэтому в результате написания этого эссе предполагалось одновременно «изловить несколько зайцев»:
— последовательно рассматривая каждый тип задач JIRA как подпроцесс проекта, в ходе изложения:
— сформулировать постановку задачи для администратора JIRA в целях развертывания новых проектов в соответствии с предложенным подходом;
— получить неформальный, но тем не менее, понятный и прозрачный регламент по распределению ответственности всех сотрудников проектных групп;
— формализовать лучшие рецепты, найденные в ходе решения проблемных ситуаций («лайфхаки» руководителя проекта);
— выявить ранее не замеченные слабые места предложенного подхода в ходе обсуждения деталей его реализации с читателями Habr.
Сразу хотелось бы отметить: часть описанных техник хорошо зарекомендовали себя на одной из «цифровых кухонь [3]» ЛАНИТ для управления проектом по разработке и сопровождению заказного программного обеспечения в интересах крупного государственного заказчика. Однако совсем не факт, что эти рекомендации окажутся одинаково полезны и на вашем проекте. С другой стороны, мы вступаем на terra incognita. Часть высказанных соображений только планируется к внедрению. Поэтому если вы видите в предложенном подходе слабые места или есть конструктивные предложения по оптимизации – добро пожаловать к обсуждению в комментариях.
Предполагается, что после проведенной унификации в интересах разных руководителей описанная технология управления будет успешно применяться на программных проектах разной направленности и разного масштаба. В свою очередь, использование единого понятийного пространства при регистрации задач JIRA создает предпосылки для автоматизированной оценки [4]текущего состояния дел в рамках портфеля проектов [5]. Кроме того, предполагается, что единый подход к учету результатов работ в JIRA упростит мобильность сотрудников между несколькими проектными группами, что в свою очередь также будет способствовать повышению успешности проектов.
Любая сложная задача имеет простое, легкое для понимания, неправильное решение.
Артур Блох [6]
Поскольку предложенный алгоритм [1] применения JIRA стал «расползаться» на другие проекты, потребовалось переосмыслить вопрос: «А чем собственно определяются границы программного проекта в JIRA?»
По мнению адептов незамутненного PMBoK [7], ответ на этот вопрос элементарен: «Конечно, границы проекта определяются уставом (паспортом) проекта [8]». С этой точки зрения, для каждого договора с заказчиком в JIRA должен быть сформирован отдельный проект. При этом зачастую разработка одного программного комплекса может предусматривать несколько направлений деятельности, в рамках которых, как правило, заключается несколько контрактов:
Кроме того, в рамках создания программного обеспечения проектная команда должна решать требования, которые не определены ни одним из договоров. Это требования руководителя проекта, связанные с предпроектной деятельностью, рефакторингом, пресейлом, устранением ошибок выявленных самостоятельно, обучением сотрудников и т.п.
Однако, как показала практика, в реальной разработке длительно сопровождаемого программного продукта тяжело разделить работы по развитию и по сопровождению. Еще не закончилась опытная эксплуатация (контракт на развитие не закрыт), а заказчик уже вовсю формирует требования по расширенному сопровождению к компонентам системы, которые еще не приняты в промышленную эксплуатацию. Заказчика можно понять, поскольку мир меняется быстрее, чем это было запланировано в утвержденных контрактах. При этом продолжается выявление новых дефектов программного обеспечения. И пользователю, обнаружившему дефект, совершенно не важно, в рамках какого договора эта ошибка должна быть исправлена. С его точки зрения — ее просто не должно было быть. Для того, чтобы отнести выявленную ошибку к тому или иному договору, нужно время на ее анализ, и если проекты JIRA разделены на основе договоров, возникает дилемма [9]: «А в каком проекте JIRA надо этот дефект регистрировать?». Кроме того, необходимо организовать перенос задачи из одного проекта в другой, если была допущена ошибка классификации требования. Если же все выявляемые дефекты программного обеспечения возложить на отдельный проект группы сопровождения, повышаются риски возникновения проблем при решении вопросов оплаты работ по этапу договора на развитие или рассмотрения рекламаций [10] по несоблюдению соглашения об уровне предоставления услуг (SLA [11]).
С другой стороны, ревнивые руководители подразделений предлагают в рамках проекта сформировать отдельные проекты для группы сопровождения, аналитического отдела, департамента разработки и тестирования. Каждый хочет быть полноправным хозяином в своей епархии и не отвечать за «косяки» соседей. Тем более, что удивительная гибкость JIRA позволяет создавать связи между задачами разных проектов.
Источник [12]
На мой взгляд, вышеописанные подходы регистрации проектов в JIRA похожи на попытки сварить один суп в нескольких разных кастрюлях, находящихся в разных кухнях. Основной целью проекта является своевременное создание программного продукта заданного качества. С точки зрения заказчика, качество продукта определяется набором функциональных возможностей этого продукта, используя которые заказчик может гарантированно (т.е. надежно) решать свои проблемы. И конечному функциональному заказчику не важно, в рамках каких договорных отношений была создана требуемая функциональность. Так же, как не важно для летчика знание перечня субподрядчиков, привлеченных для создания его самолета.
С учетом этого определение границ проекта JIRA должна обеспечить гармонию между двумя следующими соображениями.
Независимо от вида договорных отношений с заказчиком входной точкой процесса создания программного продукта является любое требование на его модификацию. Завершающим мероприятием — получение подтверждения заказчика, что данное требование реализовано (или признано несостоятельным). Это правило является основным для оценки полноты планирования и завершенности задач в проекте JIRA.
Желательно чтобы в проекте JIRA также нашли место вспомогательные работы, которые были инициированы в интересах реализации требования заказчика. В ходе разработки программного обеспечения происходит множество событий, которые, как правило, остаются «за кадром»: регулярные совещания по уточнению сроков, развертывание тестовых серверов, подготовка тестовых данных, формирование дополнительных инструкций и т.п. JIRA может здорово помочь в обнаружении дыр, через которые щедро и безвозвратно утекает рабочее время сотрудников проектной группы. Но только при условии, если эти работы будут регистрироваться в проекте JIRA.
Источник: Сергей Архипенков. Оценка проектов: шарлатанство или шаманство
Стоит подумать о формировании отдельных проектов JIRA для регистрации результатов работ, регулярно выполняемых в рамках нескольких программных продуктов (например, учета времени сотрудников, потраченного на изучение новых технологий или работ, связанных с резервным копированием).
Одним из ограничений на проект JIRA может быть максимальное количество сотрудников проектной группы. Личный опыт подсказывает следующий вывод: максимальный состав группы разработки на одном проекте JIRA подчиняется правилу Миллера [14] (в лучших традициях Agile). Под группой разработки здесь понимаются программисты и аналитики, которые формируют постановки задач для них. И, конечно, руководитель проекта. (Как вы могли подумать! Это святое!) При этом, если бюджет проекта позволяет, оставшиеся 80% сотрудников [15] проектной группы, состоящие из приветливых девушек группы сопровождения, ворчливых тестировщиков, нудных технических писателей и веселого сисадмина, безболезненно и гармонично могут быть включены в проект JIRA.
В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
Шерлок Холмс
На любом проекте навигация сотрудников в потоке решаемых задач является одной из важных составляющих успеха. Однако с ростом объема проекта разобраться в этом потоке становится все сложнее, что может стать, само по себе, одной из проблем управления большим проектом. Поэтому определение единой системы координат, по которым одинаково просто могли бы ориентироваться все ключевые участники, является неотъемлемой частью автоматизации управления проектом.
В основу такой системы координат в нашем проекте были положены следующие соображения: программный продукт, как правило, можно представить, как черный ящик, который общается с внешним миром посредством трех основных способов:
Именно в пространстве этих трех измерений видят программное обеспечение конечные пользователи. С другой стороны, именно на формирование и обработку указанных потоков данных направлено создание программного обеспечения.
Источник [20]
Кроме того, в качестве дополнительных координат в рамках проекта были приняты основные объекты базы данных и автоматизируемые бизнес-процессы. Для навигации в рамках этого пространства координат были сформированы соответствующие классификаторы, сопровождение которых обеспечивалось руководителем и аналитиками проекта. Каждый элемент классификатора состоял из кода и его определения.
В ходе моих проектов для каждого классификатора постепенно были выявлены свои особенности, которые стоит учесть в случае, если вы решите применять у себя подобный подход.
Для тех, кто не ищет легких путей, маркирование задач JIRA может осуществляется на основании регистрации соответствующих кодов в поле «Компоненты». При регистрации в JIRA задач любого типа в поле «Компоненты» необходимо просто указать перечень кодов объектов, на изменение/формирование которых направлена планируемая работа. По итогам решения каждой задачи ответственный исполнитель должен уточнить состав компонентов (в случае необходимости). Сопровождение самих классификаторов компонентов в этом случае осуществляется вне JIRA.
Любителям комфорта в этой связи, возможно, может здорово помочь плагин Subcomponents for JIRA [21].
Необходимо отметить, что применение правильно составленных классификаторов компонентов программного обеспечения неявно стандартизирует коллективное сознание и язык общения проектной группы, в результате чего повышается общий уровень взаимопонимания. С другой стороны, этот подход является одним из методов ненасильственного принуждения аналитиков к большей детализации задач, что, в свою очередь, повышает точность оценки сроков реализации требований на проекте.
Принятые правила классификации задач не только сокращают время, затрачиваемое на поиск, но и обеспечивают возможность автоматизации:
При описании общих принципов нашей модели было сказано [1] об использовании только одного типа связи «причина» -> «действие» (и в рамках описанного проекта этой связи вполне хватало). Однако желание использовать одинаковые механизмы JIRA для автоматизации управления в нескольких разных проектах потребовало расширить количество типов используемых связей и унифицировать подходы к их применению.
Источник [23]
JIRA «из коробки» предлагает пользователю несколько различных типов связей [24] между задачами, и бесконтрольное использование этих связей может привести к печальным последствиям. Чтобы не запутать себя и окружающих, мы согласовали следующие основные правила связывания задач JIRA.
Причина многих бед заключается в том, что мы ставим в план столько задач, сколько нам надо выполнить, а не столько, сколько мы можем выполнить.
Максим Дорофеев [25]
Согласно предложенному подходу для всех типов задач, регистрируемых JIRA, присущи одинаковые черты. Прежде всего, для всех типов задач JIRA характерен одинаковый рабочий процесс (workflow). При этом в рамках каждой задачи статус выполнения работы определялся прежде всего с точки зрения исполнителя этой задачи.
В ходе унификации задач для нескольких проектов ранее приведенный рабочий процесс [26] был модернизирован. Главным изменением явилось введение дополнительного статуса «оценка» предназначенного для преодоления проблемы описанной в эпиграфе к разделу. С одной стороны, задачи в данном статусе уже зарегистрированы в JIRA и не пройдут мимо внимания руководителя проекта. С другой стороны, эти задачи еще не пугают отвлекают ответственных исполнителей.
Также, статус «план» был переименован в «назначено», поскольку такое название оказалось более толерантным по отношению к задачам типа «требование» (для случая когда для требования формируется проектное решение, а задачи по реализации еще не запланированы).
В ходе комплексного анализа нескольких проектов были определены атрибуты, которые присущи для всех типов задач.
Описание общих атрибутов для всех типов задач | |
---|---|
Наименование атрибута | Описание |
Общие атрибуты | |
Автор | Пользователь, создавший задачу в JIRA |
Исполнитель | Текущий пользователь на которого назначена задача |
Ответственный исполнитель | Пользователь, который несет ответственность за результат решения задачи. Данное поле предполагается использовать для предварительной оценки загруженности сотрудников и для автоматического назначения задачи при выполнении условий готовности исходных компонентов (задач). |
Тема* | Тема задачи должна отражать [27] предполагаемый результат решения задачи, в соответствии с лучшими традициями SEO, сочетая правила формирования заголовка страницы H1 [28] и мета-тегов Title [29] и Description [30]. |
Описание* | Описание задачи должно содержать описание последовательности действий для достижения желаемого результата. |
Приоритет | Уровень приоритета, который характеризует важность задачи:
|
Уровни безопасности | Уровень доступа к ознакомлению с задачами проекта:
|
Компоненты | Регистрируются авторами задач, при необходимости уточняются исполнителями по результату решения в рамках следующих разделов:
|
Связи | Связи с другими задачами. |
Метки | Вводятся по решению исполнителей. |
Файлы | Дополнительные материалы задачи (использовать не рекомендуется). Для хранения дополнительных материалов рекомендуется использовать репозиторий документации. |
Журнал работ | |
Срок исполнения | Требуемая дата решения задачи (deadline). |
Плановая трудоемкость* | Предполагаемая (планируемая) трудоемкость решения задачи с учетом квалификации конкретного ответственного исполнителя. |
Нормированная трудоемкость* | Трудоемкость [31] решения задачи без учета квалификации конкретного исполнителя (трудоемкость для отчетов перед заказчиком). Также используется для первичной оценки трудозатрат по реализации требований заказчика. При указании данного атрибута здесь также необходимо учитывать резерв времени на решение форс-мажоров. В частности, если речь идет о задаче на тестирование критической цепи [32], то в этом случае данное поле должно содержать «буфер подстраховки» с учетом всех подзадач, формирующих эту цепь. |
Трудозатраты | Реальные трудозатраты назначенного исполнителя на реализацию конкретной задачи. |
Причина ожидания | Перечень возможных причин перевода в статус «ожидание»:
|
Причина возврата | Перечень возможных причин возврата задачи на доработку из статуса «выполнено»:
|
Причина закрытия | Перечень причин закрытия задачи:
|
Описание причины | Текстовое описание причины переходов «приостановить» или «возвратить», или «эксгумировать». |
Результат решения | |
Описание решения | Краткое описание способа решения задачи (что именно было сделано). |
* особенности атрибутов предполагается обсудить в ходе формирования спецификации для каждого из перечисленных типов задач
Изменение общих для всех задач атрибутов при переходах из состояния в состояние описывается следующей таблицей, где:
— возможно изменение атрибута;
— требуется обязательный ввод данных;
— значение поля очищается.
Переходы «в работу» и «отложить» в таблице не описаны. Данные переходы доступны только исполнителю, изменение атрибутов задач при этих переходах не предполагается. Также не описан переход «эксгумировать». Как видно из названия, использование данного перехода крайне нежелательно. Данный переход используется администратором проекта только в случае заведомо ошибочного перевода задачи в статус «закрыто» (при данном переходе запрашивается только регистрация причины этого перехода).
В последнее время получила широкое распространение концепция управления BPM [33] (business process management), системно рассматривающая деятельность компании через призму процессов. Идеология BPM положена в основу множества современных «библий» по управлению, таких как:
Сегодня практически ни одна вакансия на руководителя проекта не обходится без требования о наличии у соискателя сертификата PMP [41] или ITIL [42]. Множество учебников рассказывает, как, используя методы и подходы BPM практически на любом производстве, можно достичь новых высот конкурентоспособности и взаимоотношений с клиентами, поставщиками и сотрудниками. Во многих из этих книг в интересах скорейшего достижения положительных результатов настоятельно рекомендуется применение тех или иных BPMS [43]. Вот только почему-то мне достаточно редко попадались материалы [44]по прикладному внедрению методов и подходов BPM для производства программного обеспечения (особенно в случаях, когда по тем или иным причинам, применение апробированных методик Agile не представляется возможным). И вообще не встречались материалы по успешному применению BPM для «производства [45]» самого остродефицитного ресурса (если кто знает о таких материалах, поделитесь в комментариях). Перечисленные выше «библии» задают «вершины» (что немаловажно). Однако каким образом проектной команде добраться до этих «вершин»?
Декларации о применении процессного подхода в управлении совсем не означают использование принципов BPM на деле. Опыт моих программных проектов говорит, что, как правило, проектная команда так занята автоматизацией BPM в интересах заказчика, что не имеет времени для использования этих принципов в интересах оптимизации собственной деятельности.
Источник [46]
Изначально описываемый здесь вариант применения JIRA имел основной целью снижение головной боли сотрудников проектной команды от управления программным проектом. Однако, постепенно модифицируя проект JIRA в ходе решения конкретных прикладных задач управления проектом, появилось осознание, что сформированная модель данных проекта достаточно полно отражает сквозные процессы создания программного обеспечения. Это в свою очередь создает все предпосылки для роста эффективности проектных групп на основе применения механизмов BPM. При этом представляется, что возможности JIRA вполне позволяют обеспечить последовательное созревание [47] процесса разработки программного обеспечения без использования специализированных BPMS [43]. Все дальнейшие предложения по использованию JIRA для автоматизации управления программными проектами будут сделаны с учетом этого ключевого соображения.
Один из первых шагов по лестнице CMMI [48] состоит в выявлении, документировании и унификации процессов организации. Поэтому в рамках цикла статей «Правила своевременного приготовления вкусного программного обеспечения» предполагается последовательно сформировать спецификации по всем типам решаемых задач и попытаться сформировать критериальный аппарат их комплексной оценки с точки зрения процессного подхода. Следующая статья будет посвящена особенностям регистрации задач типа «требование» и бизнес-процессам по их реализации.
Автор: Александр Савин
Источник [49]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/339505
Ссылки в тексте:
[1] JIRA как средство от бессонницы и нервных срывов: https://habr.com/ru/company/lanit/blog/464497/
[2] Источник: http://jiraved.ru/vernissage#ruls-jira
[3] цифровых кухонь: https://www.lanit.ru/about/departments/18358/
[4] оценки : https://ru.wikipedia.org/wiki/%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BE%D0%B2_%D0%BF%D0%BE%D1%80%D1%82%D1%84%D0%B5%D0%BB%D1%8F_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
[5] портфеля проектов: https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D1%82%D1%84%D0%B5%D0%BB%D1%8C_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
[6] Артур Блох: https://en.wikipedia.org/wiki/Arthur_Bloch
[7] PMBoK: https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B4_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8
[8] уставом (паспортом) проекта: https://www.youtube.com/watch?v=NiTNqXa0oXI&list=PL4b81pr3uYiufBJ7ggC3-o1xubxb5nsBD&index=9&t=44s
[9] дилемма: https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%BB%D0%B5%D0%BC%D0%BC%D0%B0
[10] рекламаций: https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D0%B0%D1%86%D0%B8%D1%8F
[11] SLA: https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BE%D0%B1_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5_%D1%83%D1%81%D0%BB%D1%83%D0%B3
[12] Источник: http://jiraved.ru/vernissage#cat-project
[13] не должны быть отчуждены: https://youtu.be/-72YklIyIxY?t=85
[14] правилу Миллера: https://4brain.ru/blog/%D1%81%D0%B5%D0%BC%D1%8C-%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81-%D0%B4%D0%B2%D0%B0/
[15] 80% сотрудников: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%B5%D1%82%D0%BE
[16] пользовательский интерфейс: https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F
[17] протоколов : https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B0%D1%87%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
[18] API: https://ru.wikipedia.org/wiki/API
[19] EDI: https://ru.wikipedia.org/wiki/%D0%AD%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BE%D0%B1%D0%BC%D0%B5%D0%BD_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8
[20] Источник: http://jiraved.ru/vernissage#chenge-soft
[21] Subcomponents for JIRA: https://marketplace.atlassian.com/apps/1211548/subcomponents-for-jira?hosting=server&tab=overview
[22] качества разработки документации: https://habr.com/ru/company/lanit/blog/329358/
[23] Источник: http://jiraved.ru/vernissage#agile-jira
[24] типов связей: https://confluence.atlassian.com/adminjiraserver/configuring-issue-linking-938847862.html
[25] Максим Дорофеев: https://www.litres.ru/maksim-dorofeev/dzhedayskie-tehniki-kak-vospitat-svou-obezyanu-opustoshit-inboks-i-sberech-mysletoplivo/?lfrom=265326391&ref_key=5449e8406bddbfe0b503a4fc4ea337b3b89ab8fa896505353975997a17e5ec89&ref_offer=1
[26] рабочий процесс: https://habr.com/ru/company/lanit/blog/464497#waterfall
[27] отражать: https://www.youtube.com/watch?v=N0Z25e2fGVk
[28] H1: https://sitechecker.pro/ru/h1-tag/
[29] мета-тегов Title: https://wiki.rookee.ru/title-meta-teg/
[30] Description: https://yandex.ru/support/webmaster/indexing-options/description.html
[31] Трудоемкость: https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%87%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA%D0%BE-%D0%BC%D0%B5%D1%81%D1%8F%D1%86
[32] критической цепи: https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B9_%D1%86%D0%B5%D0%BF%D0%B8
[33] BPM: https://ru.wikipedia.org/wiki/BPM_(%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D1%8F)
[34] BPM CBOK: https://www.litres.ru/kollektiv-avtorov/svod-znaniy-po-upravleniu-biznes-processami-bpm-cbok-3-0/?lfrom=265326391&ref_key=fc5e97e87599a9808801c90f4f0727f0884db01154966c14cd6caff6792851d5&ref_offer=1
[35] PM BOK: http://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B4_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8
[36] инфраструктуры: https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0
[37] ITIL: https://ru.wikipedia.org/wiki/ITIL
[38] ISO 9000: https://ru.wikipedia.org/wiki/ISO_9000
[39] CMMI SEI: https://ru.wikipedia.org/wiki/CMMI
[40] ГОСТ Р ИСО/МЭК 12207-2010: http://jiraved.ru/doc/iso/2010/12207
[41] PMP: https://www.pmi.org/certifications/types/project-management-pmp
[42] ITIL: http://megapolis-profi.ru/shema_sertifikacii
[43] BPMS: https://top10-bpm.ru/
[44] материалы : https://youtu.be/SAZFp1iGwXw
[45] производства: https://www.youtube.com/watch?v=k0LAZOW1wBg&t=155
[46] Источник: http://jiraved.ru/vernissage#jira-bpm
[47] созревание: https://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15287.pdf
[48] CMMI: https://habr.com/ru/post/79130/
[49] Источник: https://habr.com/ru/post/477344/?utm_source=habrahabr&utm_medium=rss&utm_campaign=477344
Нажмите здесь для печати.