敏捷开发需求文档
In my training courses, we discuss many topics. Including: how do you document requirements in the long term, in an agile environment?
 在我的培训课程中，我们讨论了许多主题。 包括：如何在敏捷环境中长期记录需求？ 
Documentation is stored knowledge. As things are forgotten, its value increases over time. That’s why I think the question of long-term documentation is interesting.
 文档是存储的知识。 随着事物的遗忘，它的价值会随着时间而增加。 这就是为什么我认为长期记录问题很有趣。 
I’d like to start with two options for long-term documentation that  don’t make sense in an agile environment. Then I’d like to point out  sensible options. Each with advantages and disadvantages.
 我想从长期文档的两个选项开始，这些选项在敏捷环境中没有意义。 然后，我想指出一些明智的选择。 每种都有优点和缺点。 
 不是有用的选项：详细的前期规范 (Not a useful option: Detailed up-front specification)
It does not make sense to specify all requirements in detail in  advance. In a complex environment, there are frequent changes.  Requirements are re-prioritized. This is one of the advantages of agile development. Some requirements are considered, but never implemented. Or not as planned, because you gain new knowledge during development.
 事先详细指定所有要求没有意义。 在复杂的环境中，经常进行更改。 需求被重新排序。 这是敏捷开发的优势之一。 考虑了一些要求，但从未实施。 是否按计划进行，因为您在开发过程中会获得新知识。 
Discussion and documentation of a requirement costs time. If the requirement is not implemented as documented, it was a waste of time.  Time that is urgently needed in development.
 讨论和记录需求会花费时间。 如果未按文档要求实施要求，那将是浪费时间。 开发中迫切需要的时间。 
 也不是一个有用的选择：积压 (Not a useful option either: The backlog)
Let’s say you start to work in an agile way. Maybe you think: there  isn‘t any detailed specification. But a backlog. Let’s use it to document the requirements on a long-term basis.
 假设您开始以敏捷的方式工作。 也许您认为：没有任何详细的规范。 但是积压。 让我们用它来长期记录需求。 
But a backlog serves the future, not the past. It’s more like a to-do list. What do we implement next? The backlog isn't a sensible option for long-term documentation. It doesn’t document what has already been implemented.
 但是，积压的订单是为未来而不是过去服务的。 它更像是一个待办事项清单。 接下来我们要实现什么？ 对于长期文档而言，积压不是明智的选择。 它没有记录已实施的内容。 
 选项1：实施后存档用户故事 (Option 1: Archive user stories after implementation)
In a training course, a participant told me that his company manages user stories in JIRA. And the developers archive them after implementation.  Of course, you can search this archive. The participant reported that it worked well for them.
 在培训课程中，一位参与者告诉我他的公司在JIRA中管理用户故事。 开发人员在实施后将其存档。 当然，您可以搜索此存档。 参加者报告说，对他们来说效果很好。 
An agile pragmatist can hardly disagree. What works, works. At least in a certain context. I see 2 risks of this approach:
 敏捷的实用主义者几乎不会不同意。 什么有效，有效。 至少在某些情况下。 我看到这种方法有两个风险： 
Too many details: In order to be able to use the  stories in the long term, you certainly have to document many details.  What if the details cannot be implemented as planned? Will the user stories be adjusted afterwards? The stories may no longer document the implementation correctly.
 太多细节：为了能够长期使用故事，您当然必须记录许多细节。 如果细节无法按计划实施怎么办？ 用户故事会在以后进行调整吗？ 这些故事可能不再正确地记录实现。 
Delta documentation instead of system documentation:  User stories describe what needs to be done. The “delta” from one state to another state. In order to find out the current state, it may be necessary to analyze several past user stories. Stories lack context  information. They are not system documentation, but only small  fragments.
 Delta文档而不是系统文档：用户案例描述了需要做的事情。 从一个状态到另一状态的“增量”。 为了找出当前状态，可能有必要分析几个过去的用户故事。 故事缺少上下文信息。 它们不是系统文档，而是小片段。 
 选项2：系统文档的增量调整 (Option 2: Incremental adaption of the system documentation)
The documentation can be maintained continuously. During a Scrum Sprint, you document the current state.  The requirements that have just been implemented. The documentation grows over time. It is supplemented incrementally.
 该文档可以连续维护。 在Scrum Sprint期间，您记录当前状态。 刚实施的要求。 该文档随时间增长。 逐步补充。 
If you follow this approach consistently, it has a great advantage.  The system documentation is always up to date. It documents which requirements have actually been implemented.
 如果您始终遵循此方法，则将具有很大的优势。 系统文档始终是最新的。 它记录了实际上已经实施了哪些要求。 
One challenge with this option is discipline. Only if you document consistently, the documentation will remain up-to-date. And that costs  time.
 使用此选项的一个挑战是纪律。 仅当您始终记录文档时，文档才会保持最新状态。 这会花费时间。 
Moreover, not every developer is a born documentation writer. If,  however, the developers do not document themselves, but instead delegate it to other employees, then there is a risk of information loss.
 而且，并非每个开发人员都是天生的文档编写者。 但是，如果开发人员不记录自己，而是将其委派给其他员工，则存在信息丢失的风险。 
One way to promote this discipline within a team is to put it into the Definition of Done. Something like: “System documentation has been  updated”. To be checked in Sprint Review.
 在团队中促进这种纪律的一种方法是将其纳入“完成的定义”中。 诸如：“系统文档已更新”。 在Sprint Review中检查。 
 选项3：代码内的要求 (Option 3: Requirements inside the code)
A completely underestimated type of long-term documentation is the code of the software. If you structure code appropriately and use naming  conventions, you can generate documentation from the code.
 完全被低估的长期文档类型是软件代码。 如果适当地构造代码并使用命名约定，则可以从代码生成文档。 
To realize this, I have developed a library. With it you can specify executable Use Case models in the code. They act similar to a state machine. Here is a code example for a Use Case for a credit card:
 为此，我开发了一个图书馆 。 使用它，您可以在代码中指定可执行的用例模型。 它们的行为类似于状态机 。 这是信用卡用例的代码示例： 
Model model = Model.builder()
	  .useCase("Use credit card")
	    .basicFlow()
	    	.step(ASSIGN).user(requestsToAssignLimit).system(assignsLimit)
	    	.step(WITHDRAW).user(requestsWithdrawal).system(withdraws).reactWhile(accountOpen)
	    	.step(REPAY).user(requestsRepay).system(repays).reactWhile(accountOpen)
	    	
	    .flow("Withdraw again").after(REPAY)
	    	.step(WITHDRAW_AGAIN).user(requestsWithdrawal).system(withdraws)
	    	.step(REPEAT).continuesAt(WITHDRAW)
	    	
	    .flow("Cycle is over").anytime()
	    	.step(CLOSE).on(requestToCloseCycle).system(closesCycle)
	    	
	    .flow("Assign limit twice").condition(limitAlreadyAssigned)
	    	.step(ASSIGN_TWICE).user(requestsToAssignLimit).system(throwsAssignLimitException)
	    	
	    .flow("Too many withdrawals").condition(tooManyWithdrawalsInCycle) 
	    	.step(WITHDRAW_TOO_OFTEN).user(requestsWithdrawal).system(throwsTooManyWithdrawalsException)
	.build();
The documentation generated from this code follows.
 从此代码生成的文档如下。 
GENERATED DOCUMENTATION - START
 生成的文档-开始 
 使用信用卡 (Use Credit Card)
 基本流程 (Basic flow)
Assign limit : User requests to assign limit. System assigns limit.Withdraw : As long as account open: User requests withdrawal. System withdraws.Repay : As long as account open: User requests repay. System repays.
 分配限制 ：用户请求分配限制。 系统分配限制。 提款 ：只要开户：用户要求提款。 系统退出。 回报 ：只要户口不限：用户请求偿还。 系统还款。 
 再次提款 (Withdraw again)
After Repay:Withdraw again : User requests withdrawal. System withdraws.Repeat : System continues at Withdraw.
 退款后： 再次提款 ：用户要求提款。 系统退出。 重复 ：系统继续退出。 
 周期结束 (Cycle is over)
Anytime:Close cycle : Handles RequestToCloseCycle: System closes cycle.
 随时： 关闭周期 ：处理RequestToCloseCycle：系统关闭周期。 
 分配限制两次 (Assign limit twice)
Anytime, when limit already assigned:Assign limit twice : User requests to assign limit. System throws assign limit exception.
 任何时候，如果已经分配了限制 ： 两次分配限制 ：用户请求分配限制。 系统抛出分配限制异常。 
 提款太多 (Too many withdrawals)
Anytime, when too many withdrawals in cycle:Withdraw too often : System throws too many withdrawals exception.
 任何时候，当循环中的提取次数过多时 ： 提取次数过多 ：系统抛出过多的提取异常。 
GENERATED DOCUMENTATION - END
 生成的文档-结束 
The same code controls the application behavior and is the source for the documentation. The advantage is obvious: You can generate documentation with little effort. And it reflects the actual behavior of the software.
 相同的代码控制应用程序的行为，并且是文档的来源。 优点是显而易见的：您可以轻松生成文档。 它反映了软件的实际行为。 
Of course, this approach also requires discipline. Especially on the side of developers. Before using any approach, you should try it out. Is it suitable for the type of software being developed?
 当然，这种方法也需要纪律。 特别是在开发者方面。 在使用任何方法之前，您都应该尝试一下。 是否适合正在开发的软件类型？ 
In addition, you can’t achieve completeness with such an approach.  For example, you can’t generate quality requirements like robustness from the code. Design trade-offs are not part of the code either.
 此外，使用这种方法无法实现完整性。 例如，您无法从代码中生成质量要求，如健壮性。 设计权衡也不是代码的一部分。 
I am looking forward to your feedback. Which options for long-term documentation do you use?
 期待您的反馈。 您使用哪些长期文档选项？ 
This article was first published on HOOD Blog in German. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or twitter. Or visit my GitHub project.
                
 本文最初 以德语 发布在 HOOD Blog 上。 如果您想跟上我的工作进度或给我留言 ，请在dev.to ， LinkedIn或twitter上关注我。 或访问我的GitHub项目 。 
翻译自: https://www.freecodecamp.org/news/long-term-agile-documentation-of-requirements/
敏捷开发需求文档

  SE整理完一个迭代的需求以后，进入下一个流程需求澄清，需求澄清的主要目的是给开发人员澄清需求，确认开发点。
  
  需求澄清的一般流程为：
  
        1.  SE给开发人员讲解需求点
  
        2.  开发人员评论需求点是否合理，完善
  
        3.  开发人员大致描叙实现该需求点的难点
  
        4. 所有人员对该需求点进行评点，如果评的点不统一，则要评点多和少的人员依次讲解他们评该点的原因，讲解完成后在进行一次评点，选择大多数人的点为该需求的点
  
        5. 把评的点和优先级写入故事卡

传统的瀑布工作模式使用详细的需求说明书来表达需求，需求人员负责做需求调研，根据调研情况编制详细的需求说明书，进行需求评审，评审之后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。
然而详细的需求说明书有以下5大弊端：
单向的信息传递，容易出现理解偏差。
文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。
有了详细的文档，我们不会反复讨论它，相互确认。
书面文档不利于团队共享责任，它扮演了证据的角色。Scrum强调团队共享责任，不论是需求人员、开发人员和还是测试员，大家的共同目标是通过讨论、协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。
编制详细的、表达准确需求文档需要花费大量的时间，如果需求变化频繁，维护成本更高。
 敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特点，称之为DEEP：
Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大
Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的
Estimated 经过估算的
Prioritized/ Ordered 根据商业价值排好顺序的
在产品Backlog中，需求的主要表现形式是用户故事。用户故事是从用户的角度对需求的简短描述。用户故事是将团队的焦点从描述、编写功能需求转移到讨论需求的最佳方式。
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>。
比如：作为一个网站的普通会员，我期望在我下订单后，未发货之前可以取消订单，这样对我来说更灵活。
 

我们目前是用的国内的一款敏捷工具Leangoo在做需求管理！


Leangoo是一个非常简洁的看板协作工具，我们可以通过Leangoo创建产品Backlog看板来管理敏捷需求。通过leangoo看板对产品backlog条目进行可视化管理，让整个团队非常直观的了解需求的优先级和规划安排。
下图就是一个产品Backlog看板的示例：

在Leangoo看板上，我们可以创建多个列表，然后在每个列表上添加故事卡片。
因为我们需要将近期高优先级的需求放到Sprint中，所以在看板上可以创建这几个列表：待整理原始需求，以后的迭代，下个迭代待梳理故事，下个迭代就绪故事，当前迭代，已交付。
我们可以根据需求的优先级把需求分别放到这几个列中。当前迭代的优先级最高。

建立好了列之后，我们就可以往列表里面增加卡片了，每个故事一张卡。



我们可以为每一张卡片添加工作量，以及故事的验收测试要点。验收测试要点以检查项的方式体现。
除了工作量，检查项，我们可以对这个故事进行一些讨论，也就是评论，也可以@某位成员！


我们也可以为卡片设置标签

标签通常是用来给卡片分类，也可以用卡片标注优先级！
（每张卡片的优先级可以位置来决定的，每个list里面的卡片根据位置对卡片进行强制排序，高优先级的卡片放到最上面，低优先级的需求卡片在下面）


卡片ID

我们也可以为每一张卡片设置ID,便于卡片定位沟通和跟踪，在菜单栏开启就可以。


卡片多选

当我们开启卡片多选的时候  可以批量移动卡片，为卡片批量添加标签，为卡片批量添加成员等等 ，这也是我最爱的功能之一



燃尽图

当一个迭代结束时，我们要对完成的故事进行评审会议，评审通过的故事可以挪到已交付的列表中。
Leangoo会根据故事卡的变化自动生成发布燃尽图，点击菜单-看板统计，就可以查看！不仅有燃尽图 还有任务周期，任务分布等
如下图所示：

通过上述的方式，我们就可以很好的管理我们的产品Backlog了。
最后还有一点提醒，敏捷强调透明性，所以，可视化管理产品backlog很重要，如果条件允许，我们可以考虑通过大的显示屏幕将产品Backlog进行可视化，有触屏大电视会更好。
 
转载于:https://www.cnblogs.com/shineshine/p/9505022.html

       迭代需求的整理是敏捷开发的第一步，也是敏捷开发很重要的一步，在这一步中我们需要把客户的业务需求按照优先级的顺序，整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。
  
       在此需要说说什么是故事卡，故事卡和业务需求之间的关系。故事卡是一个个独立的，可验收的功能，一个业务需求可以拆分为多个故事卡。比如：我们常见的账号管理需求，需要对账号进行增、删，改、查。因为添加、修改、删除、查询都是一个个可单独验收的场景，我们可以把账号管理需求拆分为四个故事卡。因此把需求拆分为故事卡的原则是：
  
     1.故事卡是可以独立验收的场景
  
      2.故事卡包含的点数应该尽量小，一般划分为1、3、5个点，如果超过了应该重新拆分该故事卡。给故事卡评点的标准是什么了？我们可以按照一个查询完成的工作量是1个点，然后衡量该故事卡的工作量而适量的评点。
  
      3. 注意故事卡完成的工作量中包括自我测试和联调的时间。而不是单独的只是开发完成。
  
        敏捷开发强调成员之间的交互而不强调文档，但这并不意味着不需要文档，需求说明的好坏直接影响着客户价值的交替，我们先来看看下面的一张图：
  
         
  
客户      ： 客户高兴的把具有5个价值点的需求交代给需求人员
  
需求人员： 需求人员由于理解的不同，只从顾客那里接受了3个价值点
  
程序员   ： 由于需求人员表述的不清晰，最终程序员只理解了1个价值点，并交互给客户
  
客户      ： 当客户拿到只有1个价值点的产品后，客户哭了！！
  
因此作为需求人员，当在向程序员解析需求的时候，需要做到以下几点，防止价值点的丢失。
  
a.  功能点：需求包含了那些功能点
  
b.  约束条件： 每个功能点有什么约束条件
  
c.  流程图 ：功能点的业务流程是怎样的
  
d. 如果有界面的话，需要有页面元素图以及说明。
  
e. 验收：验收不同于测试用例，主要用来模拟用户的行为以及期望的响应
  
现在我们就以一个简单的登录界面，来讲讲应该怎样去描叙需求：
  
功能点：
  
         1. 用户可输入用户名、密码。可选择自动自动登录、记住密码。响应登录按钮
  
         2. 当点击登录时： a. 判断用户名、密码是否有为null，有则提示用户。 
  
                                   b. 记录用户名、密码以及记住密码、自动登录的状态
  
                                   c.  发起登录请求，并响应登录状态。成功则调转到下一个界面，失败则提示用户
  
         3. 启动登录界面的时候，读取配置文件，访问记住密码和自动登录状态。如果记住密码为true，自动登录为false，则启动登录界面的时候，用户名和密码为上次登录退出时的用户名和密码。如果自动登录为true，则直接执行点击登录的事件。
  
约束条件：
  
         1. 用户名必须以字母开头，并且包含字母、数字，长度不小于6位，当焦点切换到密码的时候，自动验证输入的用户名的合法性
  
         2. 密码以*号隐藏
  
流程图：
  
          
  
界面（低保真--界面元素草图）：
  
       
  
验收