论道WP（三）：应用程序栏
作者通过具体翔实的例子介绍了Winodws Phone 7中应用程序栏的使用方式。
文章
该内容已经被标记书签！
标记书签错误，请重试！
建设全功能团队
作者 胡凯 发布于 2010年11月26日
简介
团队的开发人员撇开需求沉浸在想象中的“完美”程序中；测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能；设计师造出了没有尽头的楼梯，更糟的是，客户爱上了这个设计；团队领导四处救火，力有不逮。种种迹象表明，我们得打破分工带来的壁垒，建设全功能团队——大多数人能完成大多数种类工作的团队。
在一次闲聊中，女友的母亲说起实习大夫必须轮岗一年才会进行分科学习，我质疑道：“对于致力于心脏病治疗的医生来说，他岂不是在不相干的学习上浪费了一年时间么？”，她母亲笑着说：“不这么作，你怎么确信病人的确患有心脏病呢？”。不知道为什么，我眼前突然浮现出这样的场景?测试人员在怯生生的询问：“这是一个缺陷么（而不是操作系统/浏览器的限制）？”。
亚当与大头针工厂
亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处：提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度，提升效率，并由此提升企业的盈利能力。
然而市场的不断变化让重复生产的美梦不在，切换任务变得越来越频繁。IT公司不是大头针工厂，知识工作者毕竟有别与体力劳动者，在劳动主体发生变化的过程中有两件事情的差异被放大了：一是局部优化与整体优化的差异，二是正确的做事与做作正确的事情的差异。
有一道数学题，假设每个开发人员每天可以完成一个功能，测试人员每天可以测试2个功能，团队由3名开发人员和1名测试人员组成，那么一周内通过测试的功能最多为多少个？
大多数人的第一反应是5（天）x2（功能/天）=10功能，下面的表格会告诉你，由于负载不均衡，测试人员在周一没有功能可测，团队其实无法在一周内交付10个功能。
|
周一 |
周二 |
周三 |
周四 |
周五 |
总计 |
|
|
开发人员 |
3功能 |
3功能 |
3功能 |
3功能 |
3功能 |
15个功能 |
|
测试人员 |
0功能 |
2功能 |
2功能 |
2功能 |
2功能 |
8个功能 |
（表一）
那么我们改变一下条件，假设团队中有4个开发人员，并且开发人员可以参与测试，结果会怎样呢？
|
|
周一 |
周二 |
周三 |
周四 |
周五 |
总计 |
|
开发人员 |
4功能 |
4功能 |
3功能 |
2功能 |
0功能 |
13个功能 |
|
测试人员 |
0功能 |
0功能 |
2功能 |
4功能 |
8功能 |
14个功能 |
（表二）
我们最终能够交付13点，产量提高了60%， 如果我们只留下三名全能人员：
|
|
周一 |
周二 |
周三 |
周四 |
周五 |
总计 |
|
开发人员 |
3功能 |
3功能 |
3功能 |
1功能 |
0功能 |
10个功能 |
|
测试人员 |
0功能 |
0功能 |
0功能 |
4功能 |
6功能 |
10个功能 |
（表三）
居然比3个开发人员和1个测试的人员组合还多交付两个功能！
我们当然有理由质疑第二题的假设：“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。我对此的的回答是：
第一，以我的观察来看开发人员之所以不进行测试工作，不是能力不允许，而是主观上认为测试工作是简单、重复而枯燥的，不愿意作。客观上开发人员们比较贵也更难于培养，组织层面不允许这样的“浪费”。
对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业，而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情（作正确的事），从而更倾向于熟练的按照脚本进行操作（正确的做事）。
第二，我的关注点不在交付8点还是10点，我希望这个例子能够引发大家对于均衡生产的思考。
软件的需求和实现可以被细化，但它毕竟不是大头针，需求和实现间往往呈现出关联与依赖，换言之，局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产（参考表三），即消除生产的波峰(过度生产)和波谷（生产不足），避免任务时松时紧，松时生产力浪费（周一时专职测试人员），紧时加班加点，粗制滥造。
我倾向于认为亚当·斯密对劳动分工论述的假设是：需求稳定，简单生产。对于IT领域来讲，这些假设还成立么？
拧螺丝的卓别林
不难发现，对分工以及个体效率的迷信已经深刻的影响着IT领域。分工的端倪在招聘时就已经显现，即便对于差异不大的毕业生们，雇主也会根据其极有限的技能，用不同的标准进行测试(Java, .Net, PHP等)，并在入职后将其冠以前端工程师，后端工程师，测试工程师，支持工程师等不同的头衔，甚至可能在其可见的职业生涯中专门负责某个文件的维护。
整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。对于IT企业来说，变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急，员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种（不是唯一一种）证明。
整体效率的优化要求员工必须持续学习、成长，兴趣无疑是成长的催化剂，然而丧失意义的工作却在不断扼杀人的兴趣。丹?艾瑞里在怪诞行为学里著述到：
劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。
如果员工成长是必须的，那么，帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。
在我看来，进行角色轮换的最大阻碍在于编程能力的普遍缺乏，大多数的测试、需求分析工作（鉴于大多数团队所处的地位，需求分析师实在言过其实，更精确的名字是需求整理师），迭代管理，简单的客户交流，学习曲线都非常低，任何成员都可以在师傅的带领下迅速掌握工作要点，然而编写程序却是个例外，即便对于基础良好的新人，在经验丰富的导师带领下，也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下，用别的角色轮换开发人员几乎是个死局。
非常奇怪，IT领域如此的看重抽象能力和逻辑分析能力，可为佐证的是层出不穷的建模语言，模式，领域模型，架构。然而最能训练抽象能力和分析能力的一项活动，却仅仅有选择性的开展，这是不是意味着我们认为IT项目可以在大多数人无法（也没有能力）达成共识的情况下顺利展开并成功交付呢？在我看来，编写程序不仅仅是一项技能，一种思考方式，还承担着构造IT团队成员间共同经验区，提高交流效率的目的。
一个值得从其它行业借鉴的经验是首先展开基础素质培养，再进入领域培养专业素养，换言之，避免过早的分工，所有新人从编程开始职业生涯，在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后，在员工对工作内容和自身兴趣有了充分的了解后，根据个人意愿进入领域发展专业技能，兴趣将成为员工成长的内在动力，而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。
同时公司应当鼓励员工跨界工作，《应用Selenium和Ruby进行面向领域的Web测试》的作者是拥有卓越能力的开发人员，他曾经进行了相当长时间的测试工作，在其它人抱怨自动化界面测试难于维护时，他优秀的抽象能力、分析能力已经帮他提炼出测试模式，识别出缺陷，找到了优雅高效的工作方式并诞生了这篇优秀的文章。
丹·艾瑞所言于我心有戚戚焉。
知行合一
在过去9个月间我们在团队中进行了建设全功能团队的初步实践，在分享具体实践前，我希望下面的总结性数据能帮助你获得一些背景知识。
项目处理的是期货交易领域，使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成（其中一名测试人员在项目中期加入），其中4位是毕业生，3位具备工作经验，但刚刚加入Thoughtworks，只有一位开发人员具备.Net开发经验。
下面是全部35周的燃尽图，黑色实线代表项目的范围，绿色实线代表开发完成的速度，蓝色实线代表测试完成的速度，每周为一个迭代。
在这张图的大部分区域内蓝色和绿色是重叠或者非常接近的，这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面，这归功于测试人员自行实现的自动化测试框架对效率的提升，另一方面，开发人员参与测试也起到了平衡开发和测试速度的作用。
让我们截取开发过程的一部分，观察每个迭代的速度，在下面这样图中，横轴代表第几个迭代，纵轴代表每迭代完成的功能点数。
从项目经理的角度看，团队的交付速度很稳定，从15周开始直到项目的结束，我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多，包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下，每个人都具备跨角色，跨模块工作的能力才保证了可持续的交付节奏。
在这篇文章中我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在下一篇文章中我将详细分享一些实践以及经验数据。
作者简介
胡凯, ThoughtWorks公司的敏捷咨询师，官方认证的Spring Framework讲师，近2年一直从事持续集成工具Cruise以 及CruiseControl的设计开发工作。 创造和参与了开源测试框架junit-ext，以及用于分析CruiseControl构建的报表工具iAnalyse, 对于Web开发，敏捷实践，开源软件与社区活动有浓厚的兴趣，可以访问他的个人博客进行更多的了解。
感谢滕振宇对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
记录与反思——个人成长，协作与分享——团队成长
发表人
高 翌翔
发表于
Re: 记录与反思——个人成长，协作与分享——团队成长
发表人
胡 凯
发表于
Re: 缺乏协作是导致分享艰难的主要原因！
发表人
高 翌翔
发表于
很想知道这两张图是用什么工具统计来的呢？
发表人
k zj
发表于
Re: 很想知道这两张图是用什么工具统计来的呢？
发表人
胡 凯
发表于
Re: 很想知道这两张图是用什么工具统计来的呢？
发表人
chen Joseph
发表于
开发人员之当然不进行测试工作
发表人
He Yiding
发表于
Re: 开发人员之当然不进行测试工作
发表人
胡 凯
发表于
Re: 开发人员之当然不进行测试工作
发表人
Feng Fan
发表于
Re: 开发人员之当然不进行测试工作
发表人
景 志刚
发表于
Re: 开发人员之当然不进行测试工作
发表人
胡 凯
发表于
Re: 开发人员之当然不进行测试工作
发表人
Li Bruce
发表于
Re: 开发人员之当然不进行测试工作
发表人
Chen Gary
发表于
Re: 开发人员当然可以进行测试工作！
发表人
高 翌翔
发表于
Re: 开发人员之当然不进行测试工作
发表人
Zhao Qing
发表于
这个我们叫全攻全守
发表人
Liu Tiger
发表于
Re: 这个我们叫全攻全守
发表人
Li Bruce
发表于
测试......
发表人
chen Rex
发表于
全功能团队与极限编程中的WholeTeam
发表人
赵 建伟
发表于
国内什么样的公司可以拥有这样的团队?
发表人
MJ Lord
发表于
Re: 国内什么样的公司可以拥有这样的团队?
发表人
元脉 林
发表于
所谓全功能团队也许只是一支曼陀罗华
发表人
Wei Jim
发表于
专才和全才
发表人
李 鑫
发表于
深有同感！
发表人
熊 军
发表于
用“约束理论”TOC 来解释全功能团队的好处
发表人
guan jayden
发表于
转熊节同学对本文的评论
发表人
霍 泰稳
发表于
There is some discussion for this topic in yahoo group
发表人
Zhang William
发表于
-
似乎在“全功能团队”可以很好地应用“协作与分享”，
而处于传统开发模式下团队，“协作与分享”只是一种奢望！
劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动，因此劳动者就无法对劳动产生认同或者领略到劳动的意义，而缺少了意义，专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色，一切都由工厂的齿轮控制，他们根本不会有全心全意工作的愿望 。
——希望所有对编程仍心存热情的程序员早日加入“全功能团队”！ -
这两张图很实用，很想了解是用什么工具统计的。谢谢！
-
Mingle
我有时候手绘这样的图，也见过有人在excel里定义公式来画，重要的是这些信息一定要可视化，让客户，团队看见。 -
当每人都被圈定在一个特定的圈子里，分享也变的很艰难，分享者难于理解观众，观众也不理解分享者，最终我们得到了对一切都冷漠的团队。
丹·艾瑞对劳动者的论述让我在做完咨询，回顾那些处在痛苦中的团队时特别有感触。 -
开发人员之所以不进行测试工作，不是能力不允许，而是立场不允许。人不可能一下子就能从开发的角色充分转变为用户角色，这样太难为人了。
-
首先这是可为的，因为有些团队确实可以做到，包括我们自己的团队，其次，考虑到软件行业长期以来开发与需求，需求与用户之间的层层壁垒，我非常质疑多少测试团队真得了解用户是如何使用软件的。有多少团队进行过persona，了解目标用户类型? 有多少团队对用户的使用习惯进行过调查？相比之下，了解这个软件的人，能发散出更多的测试场景，测试的质量也更高。
有一些实践可以帮助开发人员更好的参与测试工作，这也是这个文章的下篇我想讨论的内容。 -
1.我更愿意把此文视作探讨而非结论，测试领域永远不会存在一种普适的方法或者理论。
2.重复性高的测试工作虽然入门简单，但也需要一定时间的经验积累，从而快速而高效地完成测试迭代；而开发人员工作职能的转换，我怀疑是否能做到高效率？
3.开发人员有较强的代码和业务阅读能力，但是否同样具有同样水平的测试用例设计能力？
4.开发同测试无明显差别是当今IT公司的发展趋势，但目前20%的那块测试工作仍需要手工去总结发现；当测试人员在忙碌这些琐事重复的事甚至杂事时，其编码能力同开发的差距随着时间的差异也就越来越大；俗话说，熟能生巧，接触代码较开发少的测试在编码和代码阅读能力这块弱是绕不过去的事实！ -
可以尝试将软件开发与IT项目实施分离。
这样软件开发就比较从容了，也便于公司的技术积累。同时，业务专家也就避免陷入到软件技术、甚至代码中去了。 -
Burn-down可以手画，很多工具可以做，excel等等
-
测试完全可以与开发完美地融为一体，建议有时间看下“测试驱动开发（Test-driven development, TDD）”的相关信息。
-
敏捷开发所做的恰恰是打破圈子，促进协作，提倡分享！
希望有机会能加入敏捷团队感受协作与分享的快乐。 -
1.我更愿意把此文视作探讨而非结论，测试领域永远不会存在一种普适的方法或者理论。
2.重复性高的测试工作虽然入门简单，但也需要一定时间的经验积累，从而快速而高效地完成测试迭代；而开发人员工作职能的转换，我怀疑是否能做到高效率？
3.开发人员有较强的代码和业务阅读能力，但是否同样具有同样水平的测试用例设计能力？
4.开发同测试无明显差别是当今IT公司的发展趋势，但目前20%的那块测试工作仍需要手工去总结发现；当测试人员在忙碌这些琐事重复的事甚至杂事时，其编码能力同开发的差距随着时间的差异也就越来越大；俗话说，熟能生巧，接触代码较开发少的测试在编码和代码阅读能力这块弱是绕不过去的事实！
1. 这篇文章是我尝试了全功能团队建设后的思考，既是探讨，也是结论。结论是对我个人而言，我将继续在我所负责的团队里加速建设，探讨是对读者而言，对大家是否有借鉴价值，有没有一些活动我们在自己环境里，在自己的能力范围内是可以作的。
2. 测试经验的积累可以被固化在代码内，一个再有经验的测试，他的快速和有效也不会高的过自动化测试，所以自动化测试才是王道。你也提到了测试工作“重复性高”，那么一个有能力进行自动化工作的开发就能在更短的时间内掌握更多的东西，没有100%的高效率，我也无法保证，但是不做，肯定是一点效率都没有的。
3. “开发人员有较强的代码和业务阅读能力”， 除此之外，高强度的编程活动训练出来的是极具抽象能力和逻辑分析能力的大脑，这些都为进行得当的测试用例分析提供了好的基础。
4. 同意，探索性测试使不能缺少的。在后半段你描述了一个现状，其实也是普遍面临的困境的其中一个原因，因为木桶的短板就在这样的不均横中。我们或者开发的太快，测试跟不上，或者测试无所事事，开发忙的要死。我们要做正确的事情，就是让大家具备一定的业务能力，减少短板的存在。 -
这个我们几年前就在执行了，套一个足球的术语，我们叫它全攻全守。
-
我只说一句：测试，没你想得那么简单！
-
弱弱的问一句：全功能团队与极限编程中的WholeTeam是一回事吗？极限编程中的WholeTeam对于成员的要求也是全功能的吗？
-
很难想象5个乔丹在一支队伍中进行一场比赛中会获得什么样的结果，所以我不认为构建全功能团队会是一件值得尝试的目标。每个人都有他擅长的与不擅长的天赋(除了爱因斯坦)，就像在教育我们孩子的时候是让他们尽量弥补他的不足，而是全力发展他的长处?
-
5个乔丹在一支队伍中进行一场比赛，那将是多材小用了，必定也是人才的过度浪费。
-
有没有考虑到打造这样一支“全功能团队”的成本和周期呢？要有充分的培养和指导，要为这样的团队在企业内部提供清晰合理的职业发展方向等等。无论开发和测试都需要成长周期，即便又有多少企业愿意承担这样长周期的等待？尤其对于大型项目/产品团队来讲。否则以IT业的人员流动率，这样的全明星阵容很可能是昙花一现。
“全功能团队”无疑是吸引人的，但是我对它的适用性和可操作性（主要是大型团队）有保留意见。也特别担心会因此对开发和测试两方面都有负面影响。术业有专攻，一个人的精力怎么能同时兼顾开发和测试两个领域。从个人兴趣和发展角度，只能有所轻重。
目前我们的团队是寄希望开发人员在开发阶段能通过加强单元测试来及早暴露问题，但是不能指望单元测试或者简单的功能测试就能代替QA。本文有些看轻了QA的工作。在敏捷开发中，是不是在前期的sprint，测试人员真的就无事可做？过分削弱QA团队迟早会为此付出代价。就像曼陀罗华一样，看上去很美丽，很适意，可以满足你的一切愿望，但是你得用自己的鲜血作为代价。 -
1.我觉得楼主说的全功能团队并不是真正的“全功能”。楼主的主要论述是集中在开发和测试这两个“功能”上。而“开发”和“测试”并不是技能的不同而是工作内容的不同，之所以这两个岗位可以通用是因为他们对技能要求有很多重叠的地方：都要求有强的逻辑思维能力，丰富的代码经验等等。所以说，基本上一个团队的开发人员也好，测试人员也好只要具备这些基本素质，经过简单的培训就可以工作了。
2.全功能团队具备的技能深度是有限的，这个世上通才是很少的，跨行业跨知识领域的通才就更少了。所以要建立一个有深度的全功能团队是相当困难的。全功能团队就像我们的学习流程一样，最开始小学，初中的时候所有人都学习一样的知识。这时候的每个班，每个学校都相当于一个全功能团队。但是进入高中后分工就开始了，每个人根据自己的兴趣和情况选择了文科或理科。再往后进入大学分工就更细了。所以要让一个团队成员都必须掌握同时“3D图形引擎”和“模式识别”这样的技术，全功能化，代价是巨大的。
3.开发人员的测试和测试人员进行的测试，他们的特点是不一样。，开发人员对代码熟悉，在定位问题上有优势。测试人员没有开发人员先入为主的限制，更容易暴露问题。而开发人员应该掌握的测试应该更多的是脚手架的功能和替代文档。测试人员的测试应该从更多的角度，去审视代码。 -
敏捷团队需要善于换位思考的开发人员。
-
深有同感，如有不信，请看我去年写的一遍文章：
一个萝卜三个坑:blog.vsharing.com/junhm/A947957.html -
“约束理论（TOC）” 指出整个系统的最大产出，受制于瓶颈环节的最大产出。
全功能团队最大的好处,能够以全部资源作为全流程环节的潜在缓冲资源,必要时投入到瓶颈环节，以提高整个系统最终产出。
表1：代表了开发能力和测试能力，各自追求自身环节产出最大化的效果。
表2：代表了利用部分开发能力作为测试能力的缓冲，所产生的效果。
表3：代表了利用全资源作为全流程各能力的全局缓冲，所产生的效果。
通才指的是，具备多个环节能力的资源。专才指的是具备特定环节能力的资源。
至于专才和通才之争，这其实不是理念之争。而是一个基于现实资源情况，以TOC为指导原则，用各种资源的转化参数、约束参数等输入条件，求解系统最大产出结果的数学计算的问题。 -
我一直认为不论是开发还是测试，越多了解客户是怎么使用软件，越能把软件做好，现实中大多数开发和测试都被重重篱笆包围着，很难了解客户的真实想法，日复一日，逐渐失去了激情和动力。
-
“全攻全守”，这个术语用的不错，看看巴萨现在的华丽打法，全攻全守的打法到了新的境界。
-
胡凯在InfoQ发表了 两篇 文章 。读后，简单的感想是：追求卓越的团队，就得所有人会做所有事。
所有人都得会编程。所谓编程，是指在离散的数字世界中输入信息量以建模连续的真实世界之某一局部方面的智力活动。如果不会编程，如何知道用户的价值应该怎样以数字方式建模？如果不会编程，如何知道数字模型的哪些部分可能存在潜在错误？不会编程的人做不好软件需求，也做不好测试。
所有人都得会测试。所谓测试，是指提前发现和消除用户可能在真实使用中发现的软件缺陷的智力活动。如果不站在最终用户、最终生产环境的角度思考，“质量内建”从何谈起？不会做测试的人做不好软件需求，也做不好软件开发。
当然，常见的角色还有需求和管理。不过，“所有人都要了解需求”是敏捷软件开发中的老生常谈。而管理，私以为它就是一种浪费。如果团队每个人都会编程、会测试、会跟客户沟通需求，我们真的需要项目经理吗？
其中最难的部分是“所有人都得会编程”。因此每个追求卓越的软件企业招聘和人才培养以及每个追求卓越的软件从业者的个人成长都应该将编程能力作为一个重点。
原文链接：gigix.agilechina.net/2010/12/4/everyone-does-ev... -
错误的想法,分工是必然的.沟通也是必须的.除了开发和测试,还有其他各种角色,研发和测试可以通过其他角色更清楚了解客户的想法.
开发和测试还是有很大区别,不要试图去削弱测试的力量.什么时候研发和测试比例是1:1,国内还有很长的差距.
27 条回复
关注此讨论 回复