Get best of the week

JIRA：及时准备好吃的软件的规则。TLDR 2：需求管理

文章JIRA：及时准备好吃的软件的规则。TLDR 1：可能性的界限 “在我们公司的一个部门中，在管理几个开发自定义软件的项目的情况下，试图统一使用JIRA的一般要求。在开发该主题时，本文将致力于在先前提出的模型的框架中注册，阐明和监视客户需求的实现的关键功能。任何批评都值得欢迎。

资源

任何成品都主要取决于原始成分的质量，软件也不例外（Garbage In-Garbage Out）。如果原始成分稍微腐烂或其中一些根本不存在，则您不可能借助超级烤箱或精美的锅来保存情况。就软件而言，最初的组成部分是客户关于美好未来的良好意愿（梦想）（当“ 机器人在努力工作，一个人很高兴 ”）。 

现代政府合同的悖论之一是承包商通常对需求形成过程的影响很小，即实际需求分析过程在批准这些要求列表之后，项目便开始进行。该事实项目小组的建议，有关的要求的措辞对合同文本没有影响，项目经理通常是从快乐地激发代表的合同部门，谁，拥有完整的债务感，报道说，期待已久的招标终于获得和处理发现仍然很小。同时，一方面，客户会以各种可能的方式阻止更改已批准文档中的要求（梦想是神圣的），另一方面，他可以根据情况轻松地解释相同的要求。

在这些条件下，希望确保所有客户需求都以某种方式存储在“数字厨房”中，以便在项目交付阶段避免对项目的所有相关方造成严重的挫败感。

为了解决这个问题，在先前提出的方法的框架内，设计了一种特殊类型的任务-“需求”。这些任务要求的列表由所谓的项目积压形成。在较新版本的JIRA中，此类任务的类似物是任务类型“ epic”。但是，正如我们稍后将要看到的，我们项目中“需求”的任务类型不仅是固定客户的概念性思维形式，而且是表征项目经理和分析师在需求管理方面的活动结果的任务。 

切片要求规则


如果客户收到用于完成软件的要求清单（例如，批准的职责范围），则可以将在JIRA中注册和维护要求清单的所有活动简化为两个边界方案。

在第一种情况下，项目经理只需将带有客户需求的信函转发给分析人员，并注明“在JIRA中记录有关切线的需求并确保其实施”。之后，项目经理可以对项目进行“锤击”，直到开始进行初步测试为止（唯一的目的是确保所有需求都可以在JIRA中找到他们负责的执行人）。如果您的项目团队由理智的分析师，独具匠心的程序员，工作狂测试人员和技术狂的书写者组成，则此方法的结果将与第二种更为麻烦的选择相同。

在第二种情况下，需求管理工作分为几个阶段。

源

开始。在JIRA中注册用于软件开发/修改的源文档。接收到的材料与提交注释中指示的相应任务的编号一起上传到存储库。

1.根据已登记的原始文件，计划召开一次会议，其目的是确定履行要求的职责范围，确定“白点”和“神秘”要求。会议的计划直接在JIRA中进行（为此，将注册“实施”类型的任务，负责该任务的人员是项目经理，将参与者注册为观察员，并将议程项目记录在描述中）。分析人员以计划会议的子任务形式独立确定了对需求进行初步分析所花费的时间。如果在分析过程中出现问题，这些问题将反映在会议议程的评论中。

会议期间，将决定任命“白点”负责人。评估与“神秘”要求有关的风险，并提出克服这些风险的方法。正在形成第一个（非常近似的）“路线图”版本，根据该版本将组织工作（考虑到项目团队的优先级和当前雇用）。

2.在任命分析师负责需求的执行之后，他将每个需求作为与源文档（链接“补语”）相关的单独任务注册到JIRA。索赔的初始状态为“评级”。

基本规则之一-每个客户要求都必须注册为单独的任务在JIRA。反过来，这种方法使得可以从实现客户的每个需求的角度来评估项目的状态，而不是从执行的任务数量或人工投资的角度来评估项目的状态。需求的字词与客户文档中的字词一样，记录在“描述”字段中。

同样，需求的“原子”注册随后可以在发布版本或更新（功能组成和测试协议）时自动生成报告文档。 

3.鉴于在实施初期就每种要求制定了路线图，负责的分析师应解决以下问题：

  • 澄清需求的语义内容；
  • 澄清实施的界限。 

在澄清时，需求可以转移到“待处理”状态，并指出相应的原因。
用于澄清（解释）需求的所有材料都附加到相应的任务（已上载到文档存储库）。产生的材料应来自客户，并且应允许对以上问题有明确的答案。建议将其作为会议的协议，以明确要求，至少是一封来信中的电子邮件。
消除“白点”后，需求可以转移到“已分配”状态。

4.在一个功能区域的实施框架内（一个关键用例 - 用例）负责的分析师必须制定与相关要求有关的“分析”类型的任务。  

5.必要时，负责的分析师对自动化对象进行信息调查。  

6.在收集了设计所需的初始数据之后，负责的分析师形成设计决策。 

7.根据设计决策的结果，分析人员必须形成/阐明要开发/修改的组件清单。

8.开发的设计解决方案是创建开发，测试和文档编制任务并预测其实施复杂性的必要和充分条件。

这通常是经理和开发人员之间主要的绊脚石所在。之一减少负责解决此问题的不确定性的方法是由负责的开发人员评估建议的任务，但前提是单个任务的总复杂度不应超过16小时。阿列克谢·卡塔耶夫（Alexei Kataev）在其报告中令人信服地表明，如果执行任务的人工成本超过12个小时，则对此类任务的复杂性进行预测的可靠性就与对赌博赢利的预测具有可靠性。因此，为了确保所需的计划质量，建议分解任务。  

另一方面，从管理的角度来看，我希望获得在开发任务期间从客户的角度来看很重要的结果，而这在16个工作小时内并不总是可以实现的。 

在我们的案例中，我们决定，如果任务的复杂性超过8小时，任务的作者应将其分为几个阶段（这并不总是意味着子任务）。此外，确定了每个阶段的特定结果的正式清单。此外，还使用PERT方法创建了在线计算器以提高基于这些列表的预测的客观性。确定不同类型任务的总复杂度（在以下文章的发布期间，应该对使用这些工具进行更详细的描述）。但同时，建立了一个限制，即单个JIRA任务的最大预计复杂度不应超过32小时。如果承包商不同意所计划的任务复杂性，则必须提交使用相同工具进行的复杂性计算。解决负责执行要求的分析师与执行者之间的此类争议的仲裁者是项目经理（团队负责人）。

9.在注册了与开发，测试和文档需求相关的需求之后，项目经理应立即指定实施此需求的优先级和时间（考虑到相关任务的总人工成本，优先级以及执行项目其他任务所需的时间）。反过来，鉴于这些澄清，负责的分析师可以调整开发，测试和文档编制任务的时间安排。

10.设计解决方案的实施是在“开发”类型的任务框架内进行的。
在完成与软件开发有关的第一个需求相关任务后，必须将需求转换为“工作中”状态（可以使用Automation for Jira插件来完成）。

11.根据指定的实施期限，决定将要求的实施包括在一个或另一个软件版本中。必须将版本的组成或交付时间的任何变化通知客户。

12.在开发过程的同时，根据设计决策形成了一个用户文档版本。

13.完成开发任务后，程序员应阐明已开发/修改的组件列表。

14.用户文档的重新说明应作为脱机测试的一部分进行。满足与开发，文档和测试需求相关的所有需求，是将这一需求转换为“已完成”状态并将其包含在发行版中的信号。

15.根据项目经理的交付决定，修订版本包含在软件发行版中。

16.在进行测试之前，会对版本中包含的已实施要求进行重复集成测试。

17.可以在软件测试（初步，试运行，验收）中对已实施要求的正确性进行确认。测试结果作为“实施”类型任务的一部分记录在JIRA中。
在从客户处收到有关正确实施要求的单据后，可以将其转移到“已关闭”状态。如果收到客户关于需求的意见，它将返回到“已分配”状态（第8阶段）。同时，注释本身可以使用“关系”通信类型在JIRA中固定为与主要需求相关的单独需求。

让我提醒您，所描述的方案并不反映JIRA中单独任务的工作流程，而是涉及创建一组各种类型的相互关联的任务（在方案中以相应的颜色反映出来）。给定的顺序概述了实现新客户要求的标准程序。同时，该方案并未排除偏差的可能性，例如，在设计决策之前进行初步原型制作的情况下。但是，在我们的项目中，必须与项目经理商定此类例外情况。

在测试或商业运营期间，不可避免地会透露客户对所创建软件的评论。这些备注可以有条件地分为以下几组：

  • 新要求；
  • 澄清执行情况；
  • 缺陷
  • 错误。

尽管事实上，按照最初提出的方法，注释已记录在JIRA中，并且记录了软件完善的要求（作为“要求”类型的任务），但删除它们的过程值得单独考虑。 

蟑螂上色的规则


无所事事的人不会误会。
西奥多·罗斯福

没有没有错误的软件。绝对。即使代码中没有错误，老练的用户也可以在文档中找到它们或直接提出。无论如何，我没有看到没有软件事件的项目。美国软件工程学会（SEI）的软件维护分析）在90年代初表明，在测试单个模块期间检测到的错误数量与用户在最终产品中发现的错误数量之间的相关系数为0.91。简而言之，如果在测试阶段检测到10个错误，则在试运行期间还会出现9个其他错误。特别是由于测试人员相对于开发人员的十倍优势，因此实现了空间站软件开发所需质量的实现，这不包括使用先进的技术，例如单元测试或GUI测试自动化。我认为，这种软件的可靠性是由于实时用户尽可能少地参与其工作而实现的。当然，当专业的质量控制团队在项目上工作时，这非常酷。但是，在许多软件项目中，由于各种客观和主观原因，不可能实施所有这些建议。

因此，如果项目经理不管理传入事件的流，则很快该线程将管理这样的经理（如果他没有“扼杀”该线程）。 

另一方面，根据经验显示，最初被客户归类为软件错误的客户评论中有很大一部分不是错误。出现此类评论可能是由于以下原因：

  • 违反软件的技术操作条件（客户系统管理员的“弯腰”）；
  • 用户访问权限的限制（分配的用户访问权限不符合他的期望）；
  • 用户的功能期望与已实现的要求不匹配（如果没有帮助，也许您应该阅读说明？）；
  • 软件实现的描述不一致（这是很少见的注释，因为通常，客户的用户和管理员在第一次接触软件后不阅读手册）。

在这方面，在与客户就软件评论进行通信时，建议避免使用诸如“错误”或“缺陷”之类的字眼，至少要在其非常清晰地确定之前。到目前为止，建议使用“备注”或“事件”一词。

开展工作以消除事故的统一过程可以表示为以下步骤的序列。

源

开始。向JIRA注册事件解决应用程序。不同项目的此阶段可以按照自己的方式组织。例如，您可以使用JIRA手动注册从客户那里收到的应用程序，也可以使用特殊的邮箱，JIRA 会根据传入的信件独立查看和配置任务。如果您正在开发Web应用程序，则可以使用JIRA任务收集器来收集用户注释。注释如何以某种方式在JIRA中注册的字段（处于“ rating”状态），有必要对其进行预处理。

1.澄清事故情况。作为此操作的一部分，有必要收集有关软件注释的最完整信息：

  • 事件发生的动作顺序，输入数据的组合；
  • 评论用户的详细信息和权限；
  • 工作站（服务器）的位置；
  • 用户屏幕的屏幕截图；
  • 监测协议；
  • 错误生成的文件样本（报告）。

通常，事件的很大一部分会在此阶段结束其生命过程，因为在收集工件时，事实证明，检测到的“错误”是系统的标准行为。如果JIRA开始积累解决已解决事件的要求而又不创建开发任务，则值得密切注意用户界面的用户友好性和用户手册的相关性。

2.将事件分解为“原子”要求。通常，客户代表可能会在一封信中反映一些评论。因此，如有必要，在第二步中，根据客户给JIRA的挂号信，形成单独的需求任务。另外，这些任务中的每一个都使用Cloners关系与父需求相关联。对于这些任务中的每一个，都将附加上一阶段收集的材料（部分有关）。此外，所有工作都按照每个要求分别组织。

3.定义合同框架。在指定了已识别的缺陷之后，确定可以归因于消除该缺陷的工作是哪种合同关系。从进一步的工作组织的角度来看，此阶段可以从根本上改变其他任务的优先级。在许多项目中，作为开发的一部分开发的新组件的试运行是通过在简短的自主测试后将这些组件直接安装在当前版本上来进行的。但是，客户将在这些情况下已经出现的错误与基本或保修支持合同联系起来，这规定了消除缺陷的严格期限。如果在基本支持的框架内，消除缺陷的合同期限可以以小时为单位进行衡量，则如果识别出与新功能相关的缺陷，消除相同缺陷的期限由试运行的结束日期（最多几个月）决定。如果项目经理不注意这一“细微差别”，则执行公司甚至有机会在简单软件投入商业运营之前就开始对其支付罚款。

4.控制重复项。在重新申请删除先前检测到的缺陷的情况下，此要求通过连接“ Duplicate»（Duplicate）与先前提交的任务相关联。 

根据事件的初步分析结果，有必要将其结果告知客户，因为客户对于消除事件的时间安排的愿景可能与合同义务之间存在弱关联。

5.在将请求提交给开发团队分析师之前，支持团队应在测试服务器上重复该事件。可以按照相关要求的子任务的形式将初始测试记录在JIRA中。

6.如果在先前步骤中未消除事件，则需求将转移到“已分配”状态，并转移到开发团队分析人员，以查明事件发生的原因并制定消除事件的任务。

7.如有必要，分析师必须阐明要求的合同范围。如果对软件的新功能发表评论，则分析师必须将此缺陷与开发/开发/扩展支持的相关要求（“添加”链接）相关联。

8.分析还应确定影响此评论的组件列表。此外，如果注释确实是软件错误，则必须将其生成。典型的检测到的缺陷。

9.在确定了缺陷的原因之后，开发小组的分析人员形成了旨在消除已识别错误的开发任务。如有必要，可以形成测试和澄清文档的任务。作为这些任务的一部分，确定计划的人工成本。如果特定任务的工作量超过8小时，则有必要使用上一节中指定的工具来证明复杂性。考虑到项目团队的优先级和工作量，确定了执行这些任务的计划日期。 
在与软件开发有关的第一个要求开始工作后，该事件必须转移到“正在工作”状态。

10.出现有关需求的开发，测试和文档的相关任务，这是项目经理做出信号的信号，该信号是要确定已修复缺陷的软件版本。同时，项目经理通过将相应的需求链接到“实现”类型的JIRA任务来计划一个软件实施事件。 

11.如有必要，项目经理会澄清执行相关任务的计划日期，并告知客户。

12.缺陷的纠正在“开发”类型的任务框架内进行。

13.消除缺陷后，如有必要，开发人员应阐明检测到的缺陷的类型以及已修改组件的组成。

14.如有必要，请指定文档。

15.支持小组的专家对校正后的功能进行自主测试（作为开发小组的分析师组成的测试任务的一部分）。
同样，与实施新要求的情况一样，将事件转移到“已完成”状态的基础是履行在此基础上创建的所有任务（“实施”类型的任务除外）。

16.进行离线测试后，此更新和当前版本中都包含此修复程序。

17.在准备好计划包括在交付版本中的所有改进之后，将进行集成测试。可以在JIRA中以子任务的形式固定进行集成测试，该子任务用于“实现”类型的相应任务。

18.软件更新以既定方式传输给客户。但是，只有在从客户那里收到消除事件的书面证明之后，才有可能将相关要求的任务转移到“已关闭”状态。 

来源

任何开发人员都知道最大的错误是在需求形成/规格说明阶段没有及时发现的错误。

需求冻结规则


当两者都冻结时，在水上行走并根据规范开发软件非常简单。
爱德华五世·贝拉德

应该注意的是，通过创建一种情况，客户需要对澄清字母：“我同意”做出简单的回答，最有效地阐明了要求。为此，有必要在信中提出几个可能的答案。形成此类信件的技巧是，客户选择的选项对于您作为表演者而言是最可取的。


资源

例如，交付阶段的“简单”要求“提供在所有屏幕上按区域采样的可能性”可能会引起很多问题，因为它无法确定应在哪个屏幕上提供采样，无论是按一个参数值还是多个参数值采样如何考虑地区名称变更的历史性。如果您只是想澄清此要求，答案不太可能解决所指出的问题。 

在这种情况下，可以使用以下内容的字母进行说明：

. 4.5.6. : « 1, 2 3 «». , , ».

这封信的副本附在任务上。任务将转移到“挂起”状态，直到收到客户的响应为止，该响应也随后附加到任务上。该措辞反映在JIRA任务的相应字段中（请参见下文“说明”）。在此基础上形成相关的设计决策，开发任务和测试任务。

理想情况下，出于客观和主观原因，通常可以将其实现，为了将需求转移到进一步的开发中，有必要确保项目团队的所有成员都了解其边界。因此，一旦“需求”类型的任务与开发任务相关联，项目经理就会检查他是否满足以下所述的质量标准（准备就绪的定义））如果要求的基本用语不符合这些标准，则必须不断进行改进。改进工作的结果应该是需求的措辞更新，或者是客户同意的与该需求有关的设计决策（SCF）。
 
评估项目需求质量的标准
特性说明
完成时间该需求在JIRA任务中已完全定义，并且存在所有必要的信息。
一致性该要求与其他要求不矛盾，并且符合法规文件。
原子性要求是“原子的”。也就是说，在不损失完整性的情况下，不能将其分解为许多更详细的要求。
关联该要求并没有随着时间的推移而过时。
可行性可以在项目内实施需求（考虑可用资源和时间表）。
明确的无需使用技术术语，首字母缩写词和其他隐藏短语即可对需求进行简要定义。仅有一种解释是可能的。该定义不包含歧义短语。要求（澄清）的措词不包含负面陈述和复合陈述。
 
当在“要求”类型的任务中考虑人工成本时，仅记录直接花费在改进方面的时间。所有其他人工成本都记录在相应类型的任务（或其子任务）中。

除了前一篇文章中描述的通用属性外，在漫长而痛苦的过程中，JIRA中为“要求”类型的每个任务还​​定义了一组附加属性。

«»
*( ).
:

  • ( , , .. );
  • ;
  • — ( , , );
  • ;
  • ( , );
  • /;
  • (, , , , , ).
, (, ).
(). , , ( ).
– . . . . , . - .
, : 

  • ;
  • ;
  • ;
  • ; 
  • ; 
  • .
( - ). , . «» .
, ( )
/  ( PSP IBM):

  • ( , );
  • ;
  • ( , );
  • ( , , );
  • ( , -, );
  • ( , );
  • ( );
  • ( , , , , );
  • ( , );
  • , .
— , .
: 

  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • ;
  • — ,
  •   ;
  • (e-mail).
/ ( JIRA , [ ].[ ].[()  ])
*如果描述了将需求转移到“已关闭”状态的原因，则此字段应指示文档的详细信息，以确认客户正式认可该需求已得到满足或该需求已被取消。
决断
软件版本实施要求的软件版本号
*具有填充属性，适用于所有类型的任务。

下表描述了从状态转换到状态时更改“要求”类型的任务的特定属性，其中：

-可以更改属性；

-必需的数据输入。


未完待续 


许多项目经理认为，如果职权范围得到客户的认可，那么这就是最终真理，它不会发生任何变化。这在一定程度上是正确的-在项目完成之前，不太可能更改技术规范要求的措辞。但是，在项目的初始阶段（很早在计划和测试程序的批准之前），没有人会与客户明确每个要求的界限并确定建议的程序以进行验证。如果尚未执行此类工作，则很可能在实施过程中表达了客户的所有“愿望清单”，您将在预算和同一项目的时间范围内做出决定。


不要忘记客观定律，早在上世纪80年代末就引起了 Barry Boehm（Barry W. Boehm）的注意。如果项目经理不关心在项目初始阶段消除需求的不确定性和不准确性，那么到项目完成阶段，可以保证他会有许多令人不愉快的“发现”。

但是，经验表明，仅通过明确要求就无法解决大多数歧义。此外，通常不可能将需求彼此隔离，因为只有通过综合实现客户的愿望才能实现创建软件的目的。

建议在解决方法的框架内，协调一组相互关联的需求，以及对批准的职责范围中反映的客户幻想进行切合实际的解释，以解决``分析''类型的问题，其特征将在文章``JIRA：及时准备可口软件的规则''中进行介绍。TLDR 3：设计解决方案。 

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles