在文章“
JIRA作为失眠和神经衰弱的一种补救方法 ”的较早版本中，提出了一种选择，可以使用JIRA来管理软件开发项目，以满足大型国家客户的利益。 但是，在“数字厨房”中不小心操作控制自动化设备不仅会损坏产品，还会导致大量伤害。 在一系列文章“及时准备美味软件的规则”中，建议详细研究使用称为JIRA的催化剂组织软件项目工作的规则。 任何批评都值得欢迎。
来源一般秘密
智力是一种避免工作的能力，但是可以做到。
莱纳斯·托德瓦尔兹
在发表文章“
JIRA作为失眠和神经衰弱的补救方法 ”后，几位高管对我们在使用JIRA方面的经验感兴趣，并决定在其项目中引入类似的管理自动化方案。 因此，写这篇文章的结果是，它应该同时“抓几只兔子”：
-在演示过程中，依次将每种JIRA任务类型视为项目的子过程：
- 统一这些子流程的规范；
- 规范组织工作的业务规则；
- 编制典型“陷阱”和需要提前“秸秆垫层”的地方的地图；
- 确定每种任务类型的可测量和可实现的性能指标。
-为JIRA管理员制定问题说明，以便按照提议的方法部署新项目；
-就项目团队所有员工的职责分配制定非正式但可理解，透明的法规；
-规范解决问题情况（项目经理的“生活技巧”）时发现的最佳配方；
-在与Habr读者讨论实施细节时，找出以前未注意到的提议方法的缺点。
我想立即指出：一些描述的技术已经在LANIT
数字厨房之一中证明了自己的价值，该项目用于大型国家客户利益的项目管理，用于开发和维护定制软件。 但是，这些建议对您的项目同样有用完全不是事实。 另一方面，我们正在进入terra incognita。 所表达的一些考虑只是计划实施的。 因此，如果您发现建议的方法存在缺陷，或者有建设性的优化建议，欢迎加入评论中的讨论。
假设在为不同领导者的利益进行统一之后，所描述的管理技术将成功应用于不同方向和规模的软件项目。 反过来，注册JIRA任务时使用单个概念空间会
为在项目组合框架内自动
评估当前状况提供先决条件。 此外，假设在JIRA中记录工作结果的统一方法将简化员工在多个项目组之间的流动性，这反过来也将有助于提高项目的成功率。
项目边界
任何困难的任务都有一个简单，易于理解的错误解决方案。
亚瑟·布洛赫（Arthur Bloch）
由于
提出的 JIRA应用
算法开始“传播”到其他项目，因此有必要重新考虑以下问题：“什么因素决定了JIRA中软件项目的边界？”
根据
未受污染的PMBoK的追随者，对该问题的回答是基本的：“当然，项目的边界由项目
的章程（护照）确定。” 从这个角度来看，对于与客户的每份合同，必须在JIRA中形成一个单独的项目。 此外，一个软件包的开发通常可能包括几个活动领域，通常在其中签订了几个合同：
- 开发-合同中有关创建新系统（子系统）的要求；
- 发展-旨在实质性修订现有子系统的合同框架内的要求；
- 扩展支持-针对客户业务流程中当前更改的各个系统模块的操作完成所需的合同要求；
- 保修支持-消除保修期内发现的软件错误；
- 基本支持-消除保修期结束后发现的软件错误。
另外，作为软件创建的一部分，项目团队必须解决任何合同未定义的要求。 这些是项目经理与项目前活动，重构，预售，消除独立发现的错误，人员培训等相关的要求。
但是，如实践所示，在长期软件产品的实际开发中，很难将开发工作与维护工作分开。 试用操作尚未结束（开发合同尚未结束），并且客户已经全力制定对尚未投入商业运行的系统组件的扩展支持的要求。 之所以可以理解客户，是因为世界变化的速度比批准的合同所计划的要快。 同时，新软件缺陷的识别仍在继续。 发现缺陷的用户根本不在乎在何种情况下应更正此错误。 从他的角度来看-根本不应该如此。 为了将识别出的错误归因于一个或另一个合同，需要花费一些时间来分析它，并且如果JIRA项目是基于合同划分的，则会出现
两难境地 ：“该缺陷应在哪个JIRA项目中注册？”。 此外，如果发生分类错误，则必须组织任务从一个项目到另一个项目的转移。 如果将软件中所有已识别的缺陷分配给支持团队的单独项目，则在开发合同阶段解决工作付款问题或审查有关不遵守服务提供水平协议（
SLA ）的
投诉时，就会出现问题的风险。
另一方面，嫉妒的部门负责人建议在项目框架内为支持团队，分析部门以及开发和测试部门创建单独的项目。 每个人都想成为自己教区的正式主人，而不是为邻居的“浅滩”负责。 此外，JIRA惊人的灵活性使您可以在不同项目的任务之间创建连接。
来源我认为，上述在JIRA中注册项目的方法类似于尝试在位于不同厨房中的多个不同锅中煮一种汤。 该项目的主要目标是及时创建给定质量的软件产品。 从客户的角度来看，产品的质量取决于该产品的功能集，客户可以使用这些功能来保证（即可靠地）解决其问题。 对于最终的功能客户而言，创建所需功能的合同关系都没有关系。 正如飞行员了解参与其飞机制造的分包商名单并不重要。
考虑到这一点，定义JIRA项目的边界应确保以下两个考虑因素之间的协调。
- 项目必须反映出在软件产品（或其子系统）的创建/修改过程中执行的所有工作。 该项目应被视为创建一个软件产品（一个“飞机”）的单一过程。 因此，主要原则是：一种软件产品-一个JIRA项目。 重要的是不要忘记贵公司生产的产品-“飞机”或“飞机发动机”。 在任何情况下，软件创建者都不应脱离其决定的后果。
无论与客户之间的合同关系类型如何，创建软件产品的过程的切入点都是对其修改的任何要求。 最后的事件是收到客户确认已实施此要求（或宣布已破产）的确认。 此规则是评估JIRA项目中计划的完整性和任务的完整性的主要规则。
建议JIRA项目还找到一个辅助工作的场所，该工作是为了满足客户的需求而启动的。 在软件开发过程中，通常会发生许多事件，这些事件通常仍在“幕后”：定期会议以澄清截止日期，部署测试服务器，准备测试数据，生成其他说明等。 JIRA对于发现漏洞是很有帮助的，项目团队员工的工作时间可以大量而不可挽回地流过这些漏洞。 但前提是这些作品必须在JIRA项目中注册。 - 在开发非常大型的软件系统的情况下，您不应将所有内容都放入一个JIRA项目中，这会大大增加中断的风险。 在这种情况下，建议在单独的JIRA项目中按为客户的业务流程之一提供支持的软件功能分组（通常，这些功能已经在概念设计阶段分配给了单独的子系统）。
资料来源：谢尔盖·阿基芬科夫。 项目评估：Qu窃或萨满教值得思考的是，要建立单个JIRA项目来记录在几种软件产品的框架内定期执行的工作结果（例如，考虑员工在学习新技术或与备份相关的工作上所花费的时间）。
JIRA项目的限制之一可能是项目团队员工的最大人数。 个人经验表明以下结论：单个JIRA项目中开发团队的最大人员组成遵循
Miller规则 （遵循敏捷的最佳传统）。 这里的开发小组指的是为他们制定任务的程序员和分析师。 当然还有项目经理。 （您可能会想到！这是神圣的！）此外，如果项目预算允许，则可以安全，和谐地将其余
80％的项目团队
员工 （包括友好的支持团队女孩，脾气暴躁的测试人员，无聊的技术作家和有趣的系统管理员）包括在项目中JIRA。
如何将任务放在架子上
在我的阁楼上，只有我需要的工具。 它们很多，但是它们处于完美的状态并且总是在手边。
夏洛克·福尔摩斯
在任何项目中，要解决的任务流中的员工导航都是成功的重要组成部分之一。 但是，随着项目量的增长，理解这种流程变得越来越困难，这本身就可能成为管理大型项目的问题之一。 因此，所有关键参与者都可以轻松导航的单个坐标系的定义是项目管理自动化的组成部分。
在我们的项目中，这种坐标系的基础是以下考虑因素：通常，软件产品可以想象成是通过三种主要方式与外界进行通信的黑匣子：
最终用户可以在这三个维度中看到软件。 另一方面，软件的创建正是针对这些数据流的形成和处理。
来源此外，主要数据库对象和自动化业务流程被用作项目中的其他坐标。 为了在此坐标空间内导航，形成了适当的分类器，项目经理和分析师提供了相应的支持。 分类器的每个元素都包含一个代码及其定义。
在我的项目过程中，对于每个分类器，它逐渐展现出自己的功能，如果您决定采用类似的方法，则应将其考虑在内。
- 在我们的情况下，打印表格的代码没有根据客户的文件重复对表格进行编号。 此外，单个表格有几种打印选项。 因此，例如，在整个软件存在期间，其中一份报告的形式根据监管文件的更改而发生了数次更改（报告的名称和本质未更改）。 同时，对于旧数据，需要以旧格式保留此报告的打印。 同样的考虑也适用于电子数据交换协议草案下的分类。
- 在表单的层次结构中，各个元素可以包括导航面板（菜单），列表表单，对象卡，选项卡，过滤器面板，数据加载/卸载表单以及复杂的组操作表单。
- 希望“增长”技术过程的“树”，以使它们具有原子（不可分割的）技术操作，而在此基础上，又可以确保访问分配子系统（安全子系统）的功能。
- 由于使用此方法的所有分类元素都显示在一个字段内的JIRA屏幕上，因此除了组件名称之外，还必须至少提供原始编码，以区分“员工注册”表格和“员工注册”流程。
对于那些不希望使用简便方法的用户，可以在“组件”字段中注册相应代码的基础上标记JIRA任务。 在JIRA中注册任何类型的任务时，在“组件”字段中，您只需要指明目标代码的列表即可进行计划的工作以进行更改/形成。 根据解决每个问题的结果，负责的执行者应澄清组件的组成（如有必要）。 然后，将组件分类器本身保留在JIRA之外。
对于这方面的舒适爱好者来说，
JIRA插件的
子组件可能会有所帮助。
应该注意的是，使用正确编译的软件组件分类器可以隐式地标准化项目团队的集体意识和沟通语言，从而导致相互理解的总体水平提高。 另一方面，这种方法是非暴力地迫使分析人员执行更详细的任务的方法之一，这反过来又提高了估计项目需求实施时间的准确性。
针对任务采用的分类规则不仅减少了搜索时间，而且还提供了自动化功能：
- 旨在实施某些软件元素的工程的总计划人工投入（或实际人工成本）估算，
- 评估优先事项的实际分配情况-在项目的某个阶段，其经理可能会惊讶地发现，大部分工作并未针对优先事项进行，
- 分析文件开发质量 ，
- 在规划方面评估项目管理的质量。 一方面，没有计划（未修改）组件的任务计划是没有意义的；另一方面，在开发过程中更改了数十个对象的任务计划表明，问题没有得到认真解决。
捆绑任务时，请勿束缚双手
在描述模型的一般原理时
，据说只使用一种类型的连接“原因”->“动作”（在描述的项目框架内，这种连接就足够了）。 但是，希望在多个不同的项目中使用相同的JIRA机制来自动化管理，以扩大使用的关系类型的数量并统一其应用方法。
来源JIRA“开箱即用”为用户提供了任务之间的几种不同类型的连接，对这些连接的不加控制的使用可能导致可悲的后果。为了不混淆自己和他人，我们就JIRA任务绑定的以下基本规则达成了一致。- 在循环中关闭相同类型的链接是不可接受的（尽管JIRA允许这样做）。
- «» (Depended) («» => «») , «» (waterfall): => => => => => . . , JIRA, , , .
- «» ( Blocks ) («» => «») (, ).
- «» ( Cloners ) («» => «») «». («») «».
- «» ( Relates ) («» => «») «». , , , . , , .
- «» ( Duplicate ) («» => «») «». , . .
Workflow
, , , , .
根据建议的方法，JIRA注册的所有类型的任务都固有相同的功能。首先，所有类型的JIRA任务都具有相同的工作流程。此外，在每个任务中，主要从该任务执行者的角度确定工作状态。在统一多个项目的任务期间，对先前描述的工作流程进行了现代化。主要的变化是引入了一种附加的“评估”状态，旨在克服本节的题词中描述的问题。一方面，处于这种状态的任务已经在JIRA中注册，不会引起项目经理的注意。在另一方面，这些问题都还没有怕分心负责的主管人员。同样，状态“计划”被重命名为“已分配”，因为事实证明这样的名称相对于“需求”类型的任务更为宽容（对于为需求形成设计解决方案且尚未计划实施任务的情况）。在对几个项目进行全面分析的过程中，确定了所有类型任务中固有的属性。*下表中列出了每种任务的类型，应该在制定规范时讨论属性的特性，下表描述了在状态转换到状态之间更改所有任务共有
的属性的方法，其中：-可以更改属性；
-所需的数据输入；
-清除字段值。表中没有描述“工作”和“搁置”的过渡。这些转换仅对执行者可用；不应在这些转换期间更改任务的属性。另外，没有描述呼气过渡。顾名思义，使用这种过渡是非常不希望的。仅当任务被有意错误地转移到“已关闭”状态时，项目管理员才使用此转换（在此转换中，仅要求注册该转换的原因）。待续
最近，BPM管理（业务流程管理）的概念通过流程的角度系统地考虑了公司的活动，这一概念已经普及。BPM的思想是许多现代管理圣经的基础，例如：如今，如果不要求申请人具有PMP或ITIL证书，则项目经理几乎没有空缺。许多教科书描述了在几乎所有生产中都使用BPM的方法和方法如何能够达到新的竞争优势以及与客户，供应商和员工之间的关系。在许多这些书中，为了迅速获得积极的成果，强烈建议使用某些BPMS。但是由于某种原因，我很少碰到材料BPM方法和方法在软件生产中的应用实施情况（特别是在出于某种原因而无法使用成熟的敏捷技术的情况下）。通常，没有关于成功使用BPM来“ 生产 ”最严重缺乏的资源的材料（如果有人知道这种材料，请在评论中分享）。上面列出的“圣经”定义了“峰值”（很重要）。但是，项目团队如何达到这些“高峰”？关于在管理中应用过程方法的声明完全不意味着在实践中会使用BPM原则。我的软件项目经验表明，通常，项目团队为了客户的利益而忙于BPM自动化，以至于没有时间使用这些原理来优化自己的活动。来源这里描述的原始JIRA用例主要是为了减轻项目团队员工管理软件项目的麻烦。但是，在解决项目管理的特定应用问题的过程中，逐步修改JIRA项目变得很明显，所生成的项目数据模型充分反映了端到端的软件创建过程。反过来，这为使用BPM机制提高项目团队效率创造了所有先决条件。同时，JIRA的功能似乎完全允许软件开发过程的一致成熟，而无需使用专门的BPMS。考虑到这一主要考虑因素，将为使用JIRA自动化软件项目管理提供所有进一步的建议。CMMI阶梯上的第一步之一就是识别，记录和统一组织过程。因此，作为``JIRA：及时准备好吃的软件的规则''系列文章的一部分，它应该始终如一地为所有要解决的任务制定规范，并尝试从过程方法的观点出发，为对其进行全面评估制定标准的工具。下一篇文章将专门介绍注册“需求”类型的任务的功能以及实现这些任务的业务流程。