内容简介:这个问题可能源于对敏捷开发的误解。敏捷项目团队旨在为特定项目进行组装。一旦进行了一定数量的产品规划,积压计划和冲刺计划,第一个冲刺就会启动。从那时起,敏捷团队的目标是在每次冲刺结束时递增用户价值,并使团队提供这种价值的速度最大化(Velocity只是在冲刺期间完成的Story Points数量的一个奇特术语),Story Points是用于相对彼此调整用户故事大小的度量单位。所有这些都意味着速度包含了与开发用户故事所定义的特征相关的所有成本。敏捷团队中仍然存在开销。事实上,故事点根本就不可能追踪绝对时间。
这个问题可能源于对敏捷开发的误解。敏捷项目团队旨在为特定项目进行组装。一旦进行了一定数量的产品规划,积压计划和冲刺计划,第一个冲刺就会启动。从那时起,敏捷团队的目标是在每次冲刺结束时递增用户价值,并使团队提供这种价值的速度最大化(Velocity只是在冲刺期间完成的Story Points数量的一个奇特术语),Story Points是用于相对彼此调整用户故事大小的度量单位。
所有这些都意味着速度包含了与开发用户故事所定义的特征相关的所有成本。敏捷团队中仍然存在开销。事实上,故事点根本就不可能追踪绝对时间。他们的目的是显示相对大小和复杂性的用户故事的优先次序和冲刺规划的目的。
通常,项目管理和产品管理时间被集中在间接成本中。其中一个主要原因是这些角色所做的大部分工作不能用用户故事来一对一映射。有大量的项目管理工作和产品管理工作的产生对用户并没有价值。例如,产品经理可以记录或引导创建一系列用户故事,这些用户故事一旦被评估,最终将被排除在优先级之外。也许做出的决定是,在用户故事中没有足够的价值来开发它们。因此,这是一个例子,用户故事不会跟踪敏捷项目团队工作人员所花费的时间。
所以回到我们原来的问题,是否应该为维护和支持创建不同的用户故事?简短的回答是:不,一旦开发了系统或应用程序,就会继续进行硬件和基础架构管理。有人需要监视服务器负载,当系统负载上升到服务器性能下降开始时,将新的虚拟服务器联机等。
稍微长一点的答案是,尽管用户故事不应该只为系统支持或维护创建,支持和维护任务有时可以在有意义的情况下被定为新的用户故事。如果预先知道用户故事中定义的特征需要大量的基础设施来支持新的功能,那么在用户故事估计中应该包括建立和配置新服务器所需的时间。当然,将时间分配给需要新后端资源的几个用户故事是有意义的。所以,这取决于工作是否是用户故事本身的结果。
值得注意的是,重构是敏捷开发的一个自然和必要的部分。重构描述了在不影响用户查看系统外部功能的情况下重构现有代码内部结构的行为。可能需要重构来改进系统的非功能方面,如响应时间,或者可能需要重构来支持当前体系结构结构不支持的新特性。在敏捷项目中,重构是预期的并且应该被计划。在可能的情况下,重构的增量成本应该分散在受影响的用户故事中。用户描述包含接受测试,在重构发生后需要重新测试以确保现有功能没有被破坏。
敏捷
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Docusaurus 1.0.13 发布,易于维护的静态网站创建工具
- Docusaurus 1.2.1 发布,易于维护的静态网站创建工具
- guns-lite 将所有表增加维护人员和维护时间信息
- 如何编写无法维护的代码
- Debian 包维护者辞职
- 从 VantCompoent 谈 小程序维护
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
UNIX网络编程
史蒂文斯、芬纳、鲁道夫 / 杨继张 / 清华大学出版社 / 2006-1 / 98.00元
《UNIX网络编程》(第1卷)(套接口API第3版)第1版和第2版由已故UNIX网络专家W. Richard Stevens博士独自编写。《UNIX网络编程》(第1卷)(套接口API第3版)是3版,由世界著名网络专家Bill Fenner和Andrew M. Rudoff执笔,根据近几年网络技术的发展,对上一版进行全面修订,增添了IPv6的更新过的信息、SCTP协议和密钥管理套接口的内容,删除了X......一起来看看 《UNIX网络编程》 这本书的介绍吧!