博客探讨了软件开发中衡量生产力的手段以及团队是否真的需要缺陷跟踪工具的争议。文章涉及不同观点，如个人效率难以衡量、敏捷开发中缺陷统计的可有可无等。同时，讨论了在敏捷开发背景下，团队成员的贡献和价值评估的重要性。
今天的微博热报主要关注两条微博，@左洪斌指出：目前没有普遍认同的衡量生产力的手段；@伯乐在线官方微博则引用一篇文章的话说：团队中可能不需要缺陷跟踪工具。
\左洪斌在微博中说：遗憾的是，没有普遍认同的衡量生产力的手段。Martin Fowler甚至说，衡量开发人员的效率是不可能的，情何以堪。
\大家对此的看法包括：
\\\龙年大吉LiuJ：很简单，到目前为止，软件开发仍然是日趋复杂而不是简单。在这种情况下自然很难衡量单体效率。等到生产率上去了，需求生产力平衡了，就能衡量了。
\大绍鹏：很多东西都是无法准确度量的，但因为组织原因必须度量，那就度量呗，几点建议是：1. 选择成本较低的方式 2. 选择负面效应小的方式 2. 主观反馈永远都很重要（不小于50%）
\兔子瞧：我个人的意见是：普适意义的衡量手段不可能，但是在一个可管理的组织范围内（比如一个团队或者一个部门），应当是可以建立的。
\常言笑932：衡量生产力之前，需要定义对于开发人员而言，什么是他的生产力的体现。对于这点个人和组织的理解往往不一致。
\吴瑶511： 太认同了！团队成员的贡献角度很有可能就不同，每个人的工作价值都很难评价，更何况衡量效率了。与其把精力都放在衡量这些上，不如好好想想怎么更能激发大家的潜力和积极性。TW的360评价就很好！
\王海鹏Seal： 创新组织只有一个测量指标：结果。规模复制会有厚厚的一本评分手册。推荐《组织的进化》。
\吴瑶511： 回复@王海鹏Seal:我还是觉得，每个人有不同阶段，乔布斯的成功并不能代表他整个人生都是成功的，被踢出去，也是说明当时的他不能适应当时的环境。360考评是我心里最认可的考评方式，踢出去的人，无论他能力多强，至少他不能说服别人认可他的能力，这也是种不适合的表现，那么他的价值也无法体现。
\王海鹏Seal： 敏捷和传统软件工程有个基本看法不同：软件开发是创新还是规模复制？有时候结果的成功和失败都不好定义，例如XP的C3项目。
\
伯乐在线在微博中说：《Bug统计是在浪费时间》在跟敏捷团队谈论缺陷管理技术时，大家情绪有些激动。谈论的思想是团队中可能不需要缺陷跟踪工具。看起来这个想法很另类。幸运的是，没有人很直接反对这个想法，参加讨论的很多人只是说如果不使用这个让人喜爱的东西，会造成一系列的混乱……
\大家对此的看法包括：
\\阳光蝙蝠：Bug与ToDoList都可以通过持续集成方案处理，恐惧的根源在于无休止的需求变更。
\繁少LeSaRDe：于是当部门经理问开发人员，“搞的怎样啦？”，开发人员说，“还有bug”，当项目经理问部门经理，“搞的怎么样啦？”，部门经理说，“还有bug”，当总经理问项目经理，“搞的怎么样啦？”，项目经理说，“还有bug”，当用户翻开产品使用说明书，第一页赫然的写着，“本产品还有bug”……
\woshigoushiyun：我也觉得标题很刺啊，不过我也没法直接反对这个说法呢，在敏捷开发过程中，bug统计确实可有可无啊，测试驱动开发，有问题当时就解决了，干净的逻辑看来，记录已解决的问题成本有些多余。当然仅限于事情本身了，管理角度的想法估计不同吧，毕竟一个公司来说开发不只是那点事。
\其实我一直都不低调：bug统计到底有没有用见仁见智，关键要看怎么统计，想得到什么。从来没有认真分析过bug数据的人，肯定不会知道数据里面隐藏着什么。抛开bug统计这个问题，缺陷追踪工具到底是一个什么地位？一个项目2000bug，如果没有工具辅助，所有人估计要崩溃了。没有人直接反对这个想法，应该这是DEV的内部会议，与测试无关。
\双子的天马行空-Adey：其实我觉得他说得很有道理的, 真正的敏捷应该不需要bug track system。Facebook的开发模式，就是dev直接面向客户，它有多个直接面向客户的开发团队,，只要有需求，开发后直接上线。如果后面有issue，是有second tier的dev team来support fix。tier one的dev永远在敏捷快速状态。
\柴阿峰：回复@双子的天马行空-Adey:三五个人的成熟团队敏捷也许不需要，大部分还是需要的。否则各种基于bug trace的管理系统就不需要开发持续集成、变更驱动测试的功能了。好的软件可以帮助实施敏捷，而不是反过来，不可能什么都靠嘴和白板的。
\Sab866：敏捷的基础是团队成员都是自律自发且积极的，不需要用报告来鞭策，但是简单易用的缺陷管理工具还是必须的，不然还真是会一片混乱。
\
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
