敏捷开发估算点数，敏捷开发概念

浅谈敏捷估算与规划

最近在看《敏捷软件开发实践：估算与规划》，结合自己在工作的中的实践，浅谈一点自己的想法和总结。 总的来说敏捷估算与规划更关注纵向的特性，而非横向的活动。

快速获取一个估算值时使用咨询专家意见的方法；已有类似项目，可以使用类比估算的方法；也可以将一个用户故事或者特性分解为更小，更容易估算的部分进行估算。

)专家意见—当需要估算故事点时，咨询专家的意见，可以快速给你提供一个估算值，不过敏捷里专家的意见没有传统项目那么有效。适用于快速估算。

明确产品愿景：确定产品的目标和愿景，以及产品的核心价值主张。制定产品路线图：根据产品愿景和目标，制定一个高层次的产品路线图，以指导后续的规划和开发工作。确定产品特性：根据产品路线图，确定产品的特性和功能。

敏捷团队应该做两级估算，是因为在敏捷开发中，需求是不断变化的，因此，我们需要不断地调整工作量和进度。一级估算是对整个项目的工作量进行估算，而二级估算则是对每个迭代的工作量进行估算。

以下从团队和流程2个角度来诠释产品规划的敏捷。

用户故事与敏捷方法之三---什么时候使用用户故事?

1、比如：一个业务价值高的故事估算出来要4周完成，1个或者多个业务价值中等的用户故事只需要1天就可以完成。客户团队可能会将业务价值中等的这个故事排出更高的优先级，先做。

2、可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

3、用户故事应该小到能够在一次迭代中完成。可测试的用户故事能够避免造成结构不良、过于复杂或是依赖于其他故事等问题，导致迭代失败。 为了保证无法离开迭代（通过测试）的故事不进入迭代，可以采用“先写测试”的方式。

4、”需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。Ron Jeffries的3个C关于用户故事，Ron Jeffries用3个C来描述它：卡片（Card） - 用户故事一般写在小的记事卡片上。

5、用户故事模板： 谁？（作为___）：需求主人公，同一个需求对于不同的人会有不同的方式，在描述需求的时候要指明这是谁的需求。-作为大猩猩 干了什么？（我想/我能___）：产品功能描述，一句话概括。

敏捷开发中的故事点到底是什么?如何预估故事点?

1、故事点（story point）和预估时间（estimated）不一样，故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。

2、故事点估计是对开发该功能所需的工作量、开发工作的复杂性以及蕴藏的风险等方面的综合。 两种常用的故事点估计： 以将要处理的用户故事中，从您认为最小的那些故事里面选择一个，然后设定它被估计1个故事点。

3、可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。

4、对这些故事的用户故事估点，和优先级排序。 选择一个固定的迭代长度。

5、其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

6、通过经典的“三段论“描述和渐进的细节探索，用户故事实现了需求描述的敏捷化；通过优先级排序和故事点的有效应用，用户故事实现了需求到开发的连接；通过验收标准的渐进明确，用户故事实现了需求与测试的连接。

《敏捷估算与规划》:敏捷项目如何进行进度规划呢?

根据“大小/速度=时间”以及“故事点/实际时间=速度”的关系，敏捷项目规划能灵活地结合时间、速度、大小这些变量来规划和调整。产品愿景按照优先级和速率梳理出分层的发布计划或者迭代计划，再按照优先级进入迭代开发。

首先应该逐步完善Product Backlog， 未来比较长一段时间要开发的功能写成Epic Story加入到Backlog里， 然后随着时间前移以及迭代的交付逐渐把它拆分成更小的Story，直到拆到不可再拆的粒度为止。

敏捷方法对产品规划提供了灵活的方法。以下是一些使用敏捷方法进行产品规划的步骤：明确产品愿景：确定产品的目标和愿景，以及产品的核心价值主张。

制定项目进度计划，运用科学方法 项目的进度计划意味着明确定义项目活动的开始和结束日期，这是一个反复确认的过程。

首先从项目起点出发，沿网络图各条路径进行顺时针推算，计算出各项活动的最早开始时间和最早完成时间；然后从项目的终点出发，沿网络图各条路径进行逆时针推算，计算出各项活动的最晚完成时间与最晚开始时间。

项目进度跟进 在输出项目排期表和版本需求范围，确定了关键任务和关键人员，还需要定期跟进项目进度。在敏捷项目管理中会采用每天站会的方式同步开发进度和需要解决的问题，每天站会显得比较繁琐而且至少会占用30分钟的时间。

敏捷开发效率怎么量化

1、多沟通，尽量减少文档 任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。

2、“只要你的软件开发方法遵循敏捷的四条原则(即个体和交互胜过过程和工具、工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划)，就算是敏捷一类的开发方法。

3、敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

关于敏捷开发估算点数和敏捷开发概念的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。