敏捷开发模式下测试前移，TC的工作怎么度量和评价？
[问题点数：20分]
本版专家分：0
CSDN今日推荐
本版专家分：0
本版专家分：0
本版专家分：0
本版专家分：0
本版专家分：0
2017年 总版技术专家分年内排行榜第十2013年 总版技术专家分年内排行榜第八
2017年2月 总版技术专家分月排行榜第三
2018年6月 .NET技术大版内专家分月排行榜第一2018年1月 .NET技术大版内专家分月排行榜第一2017年5月 .NET技术大版内专家分月排行榜第一2017年4月 .NET技术大版内专家分月排行榜第一2017年3月 .NET技术大版内专家分月排行榜第一2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2018年4月 .NET技术大版内专家分月排行榜第二2018年3月 .NET技术大版内专家分月排行榜第二2017年12月 .NET技术大版内专家分月排行榜第二2017年9月 .NET技术大版内专家分月排行榜第二2017年7月 .NET技术大版内专家分月排行榜第二2017年6月 .NET技术大版内专家分月排行榜第二2016年12月 .NET技术大版内专家分月排行榜第二2016年9月 .NET技术大版内专家分月排行榜第二2016年6月 .NET技术大版内专家分月排行榜第二2016年3月 .NET技术大版内专家分月排行榜第二2016年1月 .NET技术大版内专家分月排行榜第二2015年12月 .NET技术大版内专家分月排行榜第二2015年2月 .NET技术大版内专家分月排行榜第二2015年1月 .NET技术大版内专家分月排行榜第二2014年11月 .NET技术大版内专家分月排行榜第二2014年5月 .NET技术大版内专家分月排行榜第二2014年4月 .NET技术大版内专家分月排行榜第二2012年2月 多媒体/设计/Flash/Silverlight 开发大版内专家分月排行榜第二
本版专家分：0
本版专家分：0
匿名用户不能发表回复！|
其他相关推荐后使用快捷导航没有帐号？
Scrum度量的一些想法
查看: 711|
评论: 0|原作者: nini
摘要: 今天看《平衡敏捷与规范》，想到另外一些可以着手准备的度量，先记录下
Scrum上的需求和任务都是明确的，Sprint会议应该做一些基础的度量，比如Task，可以根据下面的表来识别是否太粗的容易更容易延期，或者相反。（ ...
今天看《平衡敏捷与规范》，想到另外一些可以着手准备的度量，先记录下
Scrum上的需求和任务都是明确的，Sprint会议应该做一些基础的度量，比如Task，可以根据下面的表来识别是否太粗的容易更容易延期，或者相反。（如图，数据是我杜撰的）
如果把任务按照设计、研究、开发、UI、测试等来分，可以得到更多的任务估算准确度数据。
另外，从需求方面来考虑，每个需求都会要分解成若干个任务，也可以从这里着手，来分析需求的变迁曲线，比如A需求，Sprint会议中确定的Task是否足够，最终完成时消耗的总资源和初始的资源比例，来识别最可能有把握的需求大约多大颗粒度。
本主题已经同步到我的新浪微博。
逛了这许久，何不进去瞧瞧？
&下次自动登录
用其他账号登录：
思步组织：||||||
(首次备案号:浙ICP备号)|邮箱：service#step365.com(将#换成@)|服务热线：0
||||||||||||
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&一、什么是敏捷宣言？
　　敏捷宣言（Manifesto for Agile Software Development），也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。
二、敏捷宣言的诞生
　　2000年9月，来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。&我想召集一个为期2天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来，请告诉我。&
　　日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，&敏捷&（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。
三、具体内容
（一）官方网站
（二）四大核心价值[1]
个体和互动&高于 流程和工具工作的软件&高于 详尽的文档客户合作　&高于 合同谈判响应变化& & &高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
（三）十二原则[1]
我们遵循以下原则：
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7、可工作的软件是进度的首要度量标准。
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10、以简洁为本，它是极力减少不必要工作量的艺术。
11、最好的架构、需求和设计出自自组织团队。
12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。
四、解读[4]
（一）四大核心价值的解读
1、个体与互动高于流程和工具&
　　这意味着虽然流程和工具重要（尤其是大型组织），但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。
当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法
在项目期间，产品管理和开发团队必须在一起工作
在项目期间，架构师、设计师和测试人员必须每天在一起工作
面对面沟通是极其重要的，它不能被其它形式完全替换
2、工作的软件高于详尽的文档&
　　这意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。
要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计
设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的
好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。
3、客户合作高于合同谈判&
　　这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。
在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。
产品管理和开发应该密切合作，而不是通过契约或手续。
4、响应变化高于遵循计划&
　　这意味着欢迎需求变化，哪怕是开发后期。
首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。
为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性
计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。
（二）十二原则的解读
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
　　客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。
　　尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
　　我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。
3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
　　开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。&&&
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
　　只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
　　知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。&&&
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
　　面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。
7、可工作的软件是进度的首要度量标准。
　　跟踪有多少功能已经实现，集成，测试是一种更可靠的进度度量。&&&
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
　　目标是为了消除高负荷工作并保持可持续的速度工作(例如，不加班工作)。质量问题通常牺牲长期收益，人们越是疲劳创造力就越低。因此可持续开发吧！&&&
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
　　任何技术负债(代码缺陷、架构缺陷)都会使开发减慢。我们不应该让技术负债积压，所以要持续地做重构，更改发现的缺陷，持续关注实现架构的质量。
10、以简洁为本，它是极力减少不必要工作量的艺术。
　　这种简单原则既适用于产品的功能特性也适用于流程。多余的功能不要增加。所有流程步骤应该时刻面临挑战(例如，这步真的需要吗? 谁会读这个文档？&)。&&
11、最好的架构、需求和设计出自自组织团队。
　　架构、设计和需求会随着团队一起工作慢慢浮现，并且团队会从中学到很多。一些前置需求、架构和设计工作是需要的，但是不能把它们定义在纸面上传递。架构师和系统工程师是自管理研发团队的一部分，不要成为&孤岛&。
12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。
　　花时间反思和从经验中学习能够促进持续化开发。因此&检查与调整&是敏捷核心实践之一。
五、背景和意义
　　&Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候，经理临时换了另一个人和他一起工作，最后他们花了12个星期才完成项目。他的感觉很糟，因为在后面6个星期中间，经理一直喋喋不休，嫌他太慢。Kent有点沮丧，觉得自己作为一个程序员实在是太失败。到最后，他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败，是管理者的失败（指临时换人这件事），实际上是那些持续祸害着我们这个行业的，所谓标准化、流程化的&僵化&头脑的失败。
&　　同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户，当然，也包括开发人员，谁都不想难为自己，去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人，甚至提出荒谬的要求。这不仅仅是软件开发的问题，而是无处不在。
　　先写到这吧。
[1]　　敏捷软件开发宣言-简体中文
&http://agilemanifesto.org/iso/zhchs/manifesto.html
[2]　　51CT0博客-历史：敏捷宣言诞生记
&http://davidzhang33.blog.51cto.com/3860/
[3]　　TechTarget中国-敏捷宣言：四大核心价值和十二原则 &http://www.searchcio.com.cn/showcontent_54322.htm
[4]　　推酷-敏捷宣言及原则解读 &http://www.tuicool.com/articles/ziqIN3Y
[5]　　CSDN博客-敏捷宣言思想认识误区 &http://blog.csdn.net/youcharming/article/details/度量敏捷转型时的问题
近年来，敏捷社区已多次尝试找出衡量组织转型效果的最佳方式，一些较知名的尝试，包括 、、 和。最近，敏捷博客世界中又掀起了一场关于如何度量的辩论。
在最近一篇题为“
”的博文中，回顾了度量的种类，人们通常在想了解自己的组织转型的进展程度时，求助于这些度量指标。
采用敏捷方法的团队数量
接受过敏捷方法培训的人数
采用敏捷方法的项目数量
认证的敏捷教练数量
她指出，这些指标都会让你误入歧途，恰当的度量指标应该是那些能显示出通向敏捷转型所达到的目标的趋势。她的三个建议是：
修理缺陷工作量和开发新特性工作量的比率
遗漏到产品中的缺陷
她最后的建议是：
当你考虑度量指标时，应警惕目标值。和目标值比较几乎总会导致失真。意味着人们总会试图达到目标、也许采取的手段与目标背后的初衷完全相反。
在近期发表在上的，题为“”的系列文章中，也表达的类似的见解：
敏捷社区对于类似“如何衡量敏捷是否成功”问题的典型回应是通过某种敏捷成熟度评估，比如Nokia Test。这些工具清晰、易于使用、并可以非常有效地帮助组织评估他们是否遵从了良好的敏捷实践。然而，在单独使用时，会无法实现高层领导的愿望——也失掉了调整敏捷到它本来目标的一个重要的机会。
他建议问题应该是：
如果敏捷的成功等同于业务的成功，那么真正的问题是：“我们如何度量业务成功？”
Isaac建议采用的指标应属于下面的类别：
客户满意度
员工满意度
最后， 在“
”中有一些简单的建议，当他用敏捷转型的指标与经常被引用的 CHAOS报告对比时：
获取你自己的数据。测量你自己的目标，并确定你的成功。让其他人帮你做（或者完全不做，就这件事来说）是愚蠢的。
你如何衡量组织的敏捷成熟度？你发现什么度量指标最有帮助？
查看英文原文：
译者 姚九强 是一名业务分析师，机器人爱好者，目前在ThoughtWorks。关注敏捷方法、运维和业务模型。
Copyright (C) , All Rights Reserved.
版权所有 闽ICP备号
processed in 0.044 (s). 13 q(s)