| <原文 NewsAID> <添加新主题> 共 56 个主题 71 条评论 |
| (1) 清玄的敏捷有何用？ 清玄的敏捷（Allen0805） （张恂 225 字 0 回复 E2009-9-2 17:17:51 LID:73 Hit:62）楼主的文笔不错！个别的观点我也赞同。 但整篇文章显然过于艺术化、简单化和理想化了，和实际的软件工程差距很大。现实中的软件开发要复杂、困难得多。 清玄的敏捷没什么用。 敏捷软件工程是非常务实和实用的，在国外已经有 15 年以上的发展历史。敏捷必须要能解决实际问题才有用。 |
| (2) 案例：传统项目组织为何低效？ susan: 项目团队的构成也正是我所苦恼的，个人感觉这也是项目很难成功的主要原因之一。 我们项目团队组成基本如下： 1、发起人sponsor：在我们公司，项目都会在年初时做预算，业务部门会提出实施业务系统的要求来申请预算。申请书是会有项目目标这一内容，但实是太粗了，一般来说只有一句话，似乎更像是目的而不是目标。所有IT项目都会邀请最上层的领导（如副总经理）作为发起人，相当于拿到尚方宝剑，发起人基本不过问项目的进展，只是项目汇报时邮件会抄送给他。 副总经理是所有项目的发起人吗？ 2、PM：项目经理一般由业务部门的部长来担任，基本也只是一个挂名，不过会偶尔关注一下进度情况。 虚拟的项目经理。 不知业务部门的部长一般同时担任几个项目的 PM？ 3、key user：由项目经理指派相关业务的部门经理来做为项目管理层用户，而真正参与项目时间最多的是由部门经理指派的项目执行层关键业务人员。在项目需求阶段时，需求获取的对象就是这些关键业务人员。由于层面不同，关键业务人员只会对自己所从事的部分业务非常熟悉。缺少的是对整个业务都精通的人，他可以迅速找出当前状况下最需要改进的点，也能够规划出借助IT系统来改进管理。因此，获得的需求就像一块块的砖头，没人知道也不关心要搭成什么样的房子，关键业务人员认为这个砖头的样子我已经描述清楚了，其他不关我的事。而房子的设计图纸没人能够给出。业务经理就像是一个审核的人，只会对已经设计完成的图纸提出意见，虽然他完全有能力设计这房子。 4、项目联系人：IT部门拿到批准的立项报告，指定一名IT项目管理人员着手准备（看清楚了，只有一名），我们称为IT项目负责人。我就是这个角色。承担部分BA任务，承担QA角色，承担配置管理任务，承担QC任务，碰到项目实施能力弱的乙方团队，还要承担部分SA的任务。自问没这个能力。 看到这些，不知您有何建议？ 我的几个问题： 好像你们是一家甲方企业，能否告知所在行业？ 你们公司是否有统领信息化建设全局的 CIO？ 你们公司是否有一个独立的业务（流程）规划部门？ 公司内外（业务部门、乙方、IT 人员等）对你们目前的项目管理现状有何意见和评价？ 你们的项目是否都外包给乙方，是否有内部的软件开发部门？ |
| (3) 为何选择 ScrumWorks？（张恂 135 字 0 回复 E2009-8-11 11:07:47 LID:71 Hit:52） |
| (4) 讨论：敏捷的是与非 网友 ncut_honghan 有几个疑问： （张恂 2021 字 0 回复 E2009-7-29 21:41:43 LID:70 Hit:56）1）世上没有万能的东西，只有适合和不适合，我不相信只要采用敏捷开发的项目就一定能成功。 2）敏捷开发非常强调个人的能力，有能力就肯定有个性，那么人与人之间的磨合沟通就很重要，一方面这要求实施敏捷开发的团队一定要有默契，知根知底，惺惺相惜，我相信这是先决条件，然而要组建这样的团队并不容易；另一方面，有能力的人毕竟不多，LZ在工作中一定遇到过偏执于技术，不懂沟通，或者只会夸夸奇谈，却什么都不会做的项目成员。 3）敏捷开发强调持续提供给客户交付品，然而我们国内的客户往往都不成熟，需求变更非常频繁，那么如果产品架构扩展性不够的话，对项目会造成非常大的影响。 4）项目经理在敏捷开发过程中对项目的不可控性，或者无法预见结果，对项目要有准确的预测，那么反馈和收集的数据一定要准确，如果敏捷开发都通过代码来反映，总感觉不踏实。 LZ口中的瀑布开发我认为是对项目流程管理的一种统称，我认为如果好的流程，可以解决或辅助上面提到的问题，当然敏捷开发肯定有自己的优越性，但是要根据项目来决定。 我对敏捷开发认识还不够，希望跟LZ能有更多的交流。但是对那种明明是无序无章程的开发，却美名其曰为敏捷开发是不能容忍的。 这些观点和问题非常好，其中有些是正确的，有些是常见的误解。我逐一分析如下： 1）世上没有万能的东西，只有适合和不适合，我不相信只要采用敏捷开发的项目就一定能成功。 对。 世上没有万灵丹/万灵药，这是条公理。 软件开发具有不确定性。现有的敏捷方法不可能适合天下所有的项目，也不是天下所有的项目只要采用现有的敏捷方法都能成功。 2）敏捷开发非常强调个人的能力，有能力就肯定有个性，那么人与人之间的磨合沟通就很重要，一方面这要求实施敏捷开发的团队一定要有默契，知根知底，惺惺相惜，我相信这是先决条件，然而要组建这样的团队并不容易；另一方面，有能力的人毕竟不多，LZ在工作中一定遇到过偏执于技术，不懂沟通，或者只会夸夸奇谈，却什么都不会做的项目成员。 对。 敏捷注重提升个人的能力，同时也强调建设优秀的团队，尤其人与人之间的磨合与沟通。正是因为不容易，所以只有真正优秀的团队才能做到敏捷，这正是大家努力的方向和目标。 敏捷在团队建设、沟通等方面有很多好的、值得大家学习的实践做法。 正是因为有能力的人不多，所以我们要提倡建设敏捷团队，促进沟通，提升大家的能力。 你所说的这类成员，我也的确遇到过。这类成员是不受敏捷团队欢迎的，如果他不能改变或者不愿接受改变，接纳优秀的团队文化，那么就会被敏捷团队所淘汰或抛弃。 3）敏捷开发强调持续提供给客户交付品，然而我们国内的客户往往都不成熟，需求变更非常频繁，那么如果产品架构扩展性不够的话，对项目会造成非常大的影响。 敏捷方法的一个特点或特长就是能够有效地针对需求变更频繁的项目，而且非常强调产品架构设计的扩展性、灵活性。很多敏捷专家本身就是产品架构设计方面的专家。 敏捷项目需要客户的积极参与和配合。客户不成熟，确实是一个难点，需要开发商和团队去积极地引导客户。 与传统方法相比，敏捷方法可以显著地降低项目风险。 4）项目经理在敏捷开发过程中对项目的不可控性，或者无法预见结果，对项目要有准确的预测，那么反馈和收集的数据一定要准确，如果敏捷开发都通过代码来反映，总感觉不踏实。 错。 与传统方法相比，敏捷项目经理对项目具有更好的可控性，更好的预见，更准确的预测，以及更准确的反馈和收集数据。 敏捷开发的效果并不是仅仅通过“源代码”来反映的，关键是看实际可运行的代码通过了多少测试，是否满足了用户的实际需求，同时还可以有一系列的反馈和进度指标，传统有的敏捷也可以有。这种反馈效果要远比传统方法踏实得多。 * LZ口中的瀑布开发我认为是对项目流程管理的一种统称，我认为如果好的流程，可以解决或辅助上面提到的问题，当然敏捷开发肯定有自己的优越性，但是要根据项目来决定。 错。 waterfall 是一个专有名词，有特指。40 年的软件工程实践证明，瀑布流程是一种很差的流程，取而代之的是 IID。无论敏捷过程，还是 CMMI 过程，当今成熟的过程模型大都采用 IID。 根据实际项目的特点来决定是否采用敏捷过程，这是对的。 * 我对敏捷开发认识还不够，希望跟LZ能有更多的交流。但是对那种明明是无序无章程的开发，却美名其曰为敏捷开发是不能容忍的。 对。 敏捷过程是有序和有章可循的，和传统过程一样，在许多方面也有严格的纪律要求。和传统的区别在于，传统过程往往是 heavyweight，而敏捷通常是 lightweight。 |
| (5) 敏捷改进需要本地化 InfoQ 新闻：你的敏捷组织应该关心什么？ （张恂 722 字 0 回复 E2009-6-23 14:45:50 LID:69 Hit:52）对！Mike 说出了敏捷的核心 Scrum、XP 的 practices 只是表象，如果不顾实际条件，盲目地照搬就成了教条。真正重要的是这些做法背后的 why，为什么 Scrum、XP ... 等等敏捷方法要这么做，有哪些前提条件。只有理解了 why（敏捷软件工程的基本原理），才能灵活地运用。 从守，到破，再到离，这是人们认识敏捷的一个必然过程。Mike 大概已经到了破和离的阶段。 2009年6月20日 下午11时18分 发表人 Carl Wang 敏捷，需要按照各自工作、团队的实际情况进行本地化 理论终究还是理论，如果将先进的理论本地化，适应各自团队的需要，才是最重要的。一个项目下来，有了几个敏捷实践不是关键，真正理解这些实践背后的含义，培养敏捷的价值观更为重要。说到底，关键的还是人。在一次惨痛的敏捷后，近期的一次项目中，我们的项目中制定了“词汇手册”。将所要使用的敏捷概念列入其中，然后围绕这些已经可以吃的准的概念开展项目。避免项目成员在众多的敏捷概念中迷失方向。 Carl，能否分享一下你们的那次“惨痛敏捷经历”？我想可能很多人会和我一样对此感兴趣。 你说的这几点都很重要，包括本地化，实践的含义，关键在人，词汇（概念）手册等等。我很赞同。 道理往往很简单而浅显，一点就破，但要让更多的人明白这些简单的道理却往往是不简单的。 |
| (6) RUP 与敏捷方法的区别 这是一个 FAQ。 （张恂 598 字 0 回复 E2009-3-26 15:26:13 LID:68 Hit:108）关于敏捷开发方法（cnyining） 理解一下敏捷开发方法： 1、人文化管理，提高成员的热情度，强调团队的自我管理； 2、着重于生产的产品而非大量文档； 3、需求是变化的，是不能在一两次交流中被确定的，在开发过程中体现出来； 4、紧密合作，加强沟通； 5、持继集成，经常交付； 6、关键在于体会敏捷开发思想，而非实际手段。 大体上整理的不错，5 和 6 有点问题。 敏捷方法和传统方法比较，还有其它一些显著的差别，比方计划性与适应性、计划驱动与风险/价值/反馈驱动等。 与RUP的不同之处在于，敏捷开发方法主要着眼于项目管理，而非具体的实施过程。 不对。 敏捷方法的类型和内容是很丰富的，既有着眼于项目管理的，比如 Scrum、Agile Project Managment 等，也有着眼于具体的“实施过程”的，比如 XP、AgileUP、FDD、Crystal 等等。 RUP 是一个比较全面的过程框架，其中既有项目管理的内容，也有具体的“实施过程”。 所以以上这句话，并没有道出 RUP 与敏捷方法、敏捷过程的真正不同之处，理解是错误的。 |
| (7) 敏捷匠艺宣言 InfoQ 新闻（中文）： （张恂 1724 字 0 回复 E2009-3-14 22:19:39 LID:67 Hit:116）Software Craftsmanship Manifesto: A Call to Arms Craftsmanship 不是工艺，应该译成匠艺、技艺或技能 2009年3月12日 下午10时39分 发表人 Charlie Zhang（张恂） Craftsman + ship 强调的是工匠个人精湛的技艺和能力，应该译成匠艺、技艺或技能。把 Craftsmanship 译成工艺，对初级程序员、业余程序员会形成误导。 所以 Software Craftsmanship Manifesto 是《软件匠艺宣言》，或者《软件技艺宣言》。 不懂“工艺”在软件工程里是啥意思，估计是外行吧。几年前，熊节（Jeff Xiong）翻译的 Pete McBreen 的《软件工艺》这本书，已经被张恂批评过。 听说敏捷首席李剑是北航的软件工程硕士，我想应该懂什么是工程，什么是工艺。偏要这么翻，我估计因为是熊节的坚定饭丝。当然，这是他的自由，而我们也有批评的自由。 立山头、树大旗，这很正常 2009年3月12日 下午10时20分 发表人 Charlie Zhang（张恂） 如果仔细研究，可以发现在 XP 大师里面，Uncle Bob 和 Martin Fowler 的观点与 Kent Beck、Ron Jeffries 的相比是有些微差别的，相对比较全面，走的是温和的中间路线，我比较认同。 由于所持观点、价值观的差异，软件大师流派、阵营的分分合合、此消彼长是常态。于是前段时间，我们看到了继 Agile Alliance 之后又出现了更火爆的 Scrum Alliance。 现在有人敢于质疑《敏捷宣言》，提出它还不够好，于是提出用《软件匠艺宣言》来弥补、改进，我觉得是件好事。 Enigneership over Craftsmanship恢复手工业时代的称谓，软件工匠，真的比软件工程师更潮吗？我举两个反例。 如果要论真正的软件工匠，咱中国恐怕没有几个。我想首屈一指的，当代应属王选老师。毕升是名工匠，王选老师和他率领的团队用光和电取代了铅与火，其成就和影响可以说超过了毕升，称王选老师为水平最高的软件工匠肯定是没问题的。然而，王选老师仅仅是一个匠么？是不是有点低估了？其实，王选老师最合适的身份就是科学家（兼工程师），一位伟大的、实干的科学家。 还有，我们很自豪，世界首富是一名程序员，他退居二线后的头衔是 Chief Engineer。此外，我们熟悉的 n 多位软件工程大师、敏捷大师的头衔也都是 Chief Scientist。 事实上在西方很多国家，受到崇尚科学文化的影响，人们都很尊重各行各业的科学家和工程师，有的科学家、工程师的身份甚至还是由皇家授予、奖励的，地位尊贵。 这些说明了什么？说明 Scientist、Engineer 的地位显然比旧时代的工匠高（至少不低于），受到了人们的普遍尊重。从历史的、发展的角度看，工程师一定有超过工匠的地方。软件工程师、科学家的个人能力难道一定就比工匠差，代码写得不如工匠好？不对吧。 所以我觉得，既然历史上没发生过，现在也没必要倒退回去，提倡工匠的文化，“软件工匠”不过是一个有点不合时宜的比喻而已。咱中国还是多提倡软件科学、软件工程，高水平的软件工程师的文化更好。 无论是《敏捷宣言》、《软件匠艺宣言》，好像都缺少几个关键词： 科学、辩证、系统、智慧 ... 等。这些我会在太极敏捷（宣言）中作补充。所以，我肯定不会加入什么《软件工匠宣言》，《软件工程师宣言》倒是可以考虑。Engineership 比 Craftsmanship 更好！ |
| (8) 组织环境和文化是敏捷成功的关键 2009年2月10日 上午3时50分 发表人 停车 起步 我个人认为环境和文化是敏捷实施的时候必须考虑的内容。即使把敏捷实施是公司高层领导亲自抓的一把手工程，也需要注意员工的思想和行为，考虑企业的能力，资源，目的 ... 一开始就玩的很纯粹（假设他们完全理解敏捷相关内容），遇到的阻力也会很大，敏捷的声音消失得也更快。这种情况在我们这种传统软件开发企业实施的时候很明显。 敏捷方法集虽然一般情况下作用于项目一级，但却需要组织一级的意志去贯彻执行 ... Jeffries说"组织本身"的原因我也同意，或者说是"人"的作用没到位。高层没有亲历亲为，下面就很容易阳奉阴违。 你说的很对，考虑组织的环境、文化、主客观条件的制约，以及实施的策略等因素，是敏捷改进成功的关键。其实技术操作层面的问题往往容易解决，最难的是人的思维、意识、习惯、观念和文化等隐蔽的“人性化”因素的转变。 太极敏捷有一个理论叫 CMT，文化决定管理，管理决定技术，因此太极敏捷认为只有具有先进文化的团队和企业，才能实现真正的敏捷变革，并从中获益。我的这两点也支持你的观点。 如果只是技术人员私下玩敏捷，得不到管理层和高层的支持和投入，这种改进的效果是非常有限的，也不可能持久。 在传统企业中实施敏捷，尤其要讲究实施的策略和艺术，通常渐进和渐变（evolution），不要搞大张旗鼓的革命（revolution），避免极端和极限，是比较好的方式。 |
| <原文 AgileFAQ> <添加新主题> 共 3 个主题 3 条评论 |
| (1) 几个敏捷 Faq 1、每一个迭代过程都需要需求分析、开发、测试、发布这样的过程吗？ （张恂 821 字 0 回复 E2009-8-25 16:21:40 LID:3 Hit:59）是的，包括计划、需求分析、系统设计、开发、集成、测试、评审、发布、文档更新等等必要的活动。 但不是每次迭代都对外发布。 2、迭代的划分什么样的原则更为合理？可以简单理解为一个功能项吗？它的优先顺序是从什么角度来决定的？重要度还是难易度？ 不只一个功能项，一个迭代可以完成多个需求项（items）。 开发的优先级需要考虑多种因素的叠加，包括重要度和难易度等，通常采用权重累加值。 3、如果是您所说的第一类变更——积极的变更发生了，应该定义为一个新的迭代过程还是原有的迭代过程的延续？ 不，不是定义一个新的迭代过程。 通常可以通过每日例会或迭代评审发现这些计划外的变更。一般有两种处理办法： a) 把对该变更的处理放入下一个迭代计划中。 b) 如果比较紧急，可以直接调整本次迭代的开发计划，把新的任务放入 sprint backlog 中。 4、敏捷开发的架构设计如何进行？会不会影响架构师对系统的通盘的设计，而导致系统先天缺陷？（可能有点杞人忧天，呵呵） 这个话题不小，简单地说就是风险驱动的 evolutionary design 以及 T 型设计，广度和深度的结合，通盘设计和关键细节设计的结合，设计、编程和测试的结合。 所以，敏捷架构设计并不会影响系统的通盘设计。 至于会不会导致先天缺陷？没有人敢打保票，但是敏捷的这种做法显然比传统做法更科学、更合理，出现严重问题的风险要小得多。 XP 有点偏激，给人的印象是对前期架构、建模好像不重视，这是它的缺陷。而其他许多敏捷方法（Scrum、AgileUP、FDD、Crystal 和太极等）对架构设计、业务建模等等前期工作和通盘考虑都是比较重视的，不排斥也不反对。 敏捷强调的是 just enough，不要做过了头。 |
| (2) Agile FAQ: TDD（张恂 116 字 0 回复 C2008-12-3 16:27:01 LID:2 Hit:59） |
| (3) Scrum FAQ 来自 controlchaos.com 的 old site。 （张恂 1141 字 0 回复 E2008-12-1 8:30:07 LID:1 Hit:75）Frequently Asked Questions 一共 16 个问题，有些问题还是挺有意思的。 1. Is Scrum a methodology? 2. When is Scrum appropriate? 3. What type of projects have used Scrum and failed? 4. What is important to the success of Scrum? 5. How do you handle geographically dispersed teams using Scrum? 6. How do I track a project’s progress when Scrum is used? 7. How do I track a team’s progress during a Sprint? 8. When and how do I use pert charts? 9. How does our standard methodology work with Scrum? 10. Can I only use the daily Scrum meetings initially and move on to the other parts of Scrum later? 11. Do I need daily Scrum meetings, or can we use 3 Scrum meetings every week? 12. How does Scrum compare to the CMM process? 13. What customer involvement would Scrum require? 14. How is the daily Scrum meeting different from the conventional daily status meeting? 15. How does Scrum handle complex projects made up of multiple interdependent teams running concurrently? 16. How does Scrum reduce development cycle time? |
| <原文 AgileMistakes> <添加新主题> 共 2 个主题 2 条评论 |
| (1) 一些敏捷迭代的误解 * 软件开发的基本模型仍然是瀑布法，任何一个软件系统，它一定要经历分析、设计、编码、测试，才能物理上被生产出来，才能成为最终的交付实体交付给客户，所以无论讨论什么开发模型，归根到底，其本质仍然离不开这个最基本的瀑布模型。 （张恂 1270 字 0 回复 E2009-8-25 10:55:45 LID:2 Hit:61）* 敏捷开发方法实际上是瀑布模型的一个变种而已。 * 软件系统的本质不过就是算法＋数据。 * 对于敏捷模型来讲，与通常的瀑布模型最大的差异就是把一个完整的系统切成若干小份，然后在每个小份里在采用瀑布模型完成小系统的开发工作，最后拼接成为一个完整的大系统。 瀑布模型采用的是 sequential（顺序或串型）的开发。 多年来很多人误以为敏捷就是在迭代中套一个小的瀑布，这其实只是一种初级的做法。 迭代就是小瀑布的看法是错误或者片面的。 更高级的（或真正的）敏捷应该努力做到并行（parallel）、重叠（overlapped）式的开发，比如 Scrum。 这才是本质上的差异（之一）。 * 从本质上讲，其实我是推崇瀑布模型的。因为在瀑布模型的情况下，每一步的成果都是稳定的，这样，即使人员出现变动，损失的也就是本阶段的成果而已。当然，在现实中，瀑布模型确确实实是有着很多弊病，我们要做的其实是利用敏捷的一些思想，来优化传统的开发方法。所以，说到这里，我们就有了一个结论，就是瀑布是本，敏捷是末！ 没有经过用户使用确认（validation）和充分的测试验证（verification），你怎么知道每一步成果都是稳定的？ 只能靠碰运气。 成千上万的项目统计数据已经表明，采用瀑布模型的成果其实是最不稳定的，浪费很大。 你对瀑布模型的推崇，显然缺乏科学依据。 * 开发一个系统，最关键的就是通盘考虑，虽然正统的敏捷方法反对这样做。通盘考虑的事情主要是在业务上，要能够在较短地时间里，把握客户业务的一些抽象模型，建立业务架构，这样才可能对客户的需求有所预测，设计的系统才可能就有一些前瞻性。 正统的敏捷方法反对通盘考虑？No. 正统敏捷方法（Scrum、AgileUP、FDD 等等）主张或支持（至少不反对）通盘考虑，它们反对的是过度、不必要、有很多浪费的通盘考虑。 关键在于度，物极必反，过犹不及，任何事情做过了头，就会形成错误和浪费。 也许你认为 XP 反对通盘考虑，但你所说的业务抽象模型，业务架构，对客户需求的预测，系统设计的前瞻性等等，这些的确很重要，得到了正统敏捷方法和我的太极方法的支持。 以为敏捷就是 XP，只有 XP 才是正统，是一个经典的误解。 来源： http://space.itpub.net/190707/viewspace-612981 |
| (2) 敏捷的误区、陷阱和问题 Sean Ladis (2009-1-4) （张恂 180 字 0 回复 E2009-3-5 11:34:21 LID:1 Hit:64）Traps & Pitfalls of Agile Software Development - A Non-Contrarian View 列举了 11 个敏捷陷阱。 |
| <原文 tdd> <添加新主题> 共 22 个主题 35 条评论 |
| (1) 案例讨论：国内典型的 death march 项目 dearChloe at itpub: 项目管理的一个案例，听听大家的意见 （张恂 1313 字 0 回复 E2009-7-27 11:54:46 LID:35 Hit:102）dearChloe 分享的这个案例非常好，在国内还是非常典型的。首先，感谢你的实话实说，提供了这么好的一个案例，我也实话实说。 如果你无法让这个项目的状况变得更好，你退出这个项目是对的。 从软件工程专业的角度看，这个项目失败的概率非常高，可谓又一个 death march 项目，而且正好可以作为敏捷过程的反面教材。从你的介绍中，我看到的全都是些不利因素、障碍或者风险，我没看到能使它成功（高质按时交付）的有利因素。 所以你提的这些问题非常好，也是我想问的： 领导为什么要指派一个技术和业务都不熟悉，并且缺乏项目管理经验的人做项目经理？领导为什么要指派给他的成员都是其他项目的项目经理，并且都是强势的？领导为什么要指派我这种很久已经不写代码的人去写代码？ 我觉得你们公司的问题是比较严重的（希望不是积重难返），这看上去更像是一个人浮于事的官僚机构，而不是一个有竞争力、效率至上的当代软件研发机构，当然更不是学习型组织了。所有人（包括领导、项目经理、“强势”的技术人员在内）都不知道当代软件工程已经取得了哪些进展，历史上有哪些经验教训，你们还在用农耕时代的思维和方法开发当代软件、管理当代项目。只缘身在此山中吧。 造成这些现象的原因可能有很多（后面我还会分析），我觉得最大的问题首先在于领导的管理能力和意识没有与时俱进，其次是落后的公司/组织管理制度，以及存在严重缺陷的开发过程规范。 我大体同意你说的，“项目经理是无辜的”。 首先说一下这个项目成员。不算其他边边角角的人员，项目组主要有4个人。这4个人里，有三个都是很强势的人（我一直是项目经理，另一个也是，还做些架构设计；还有一个应届生，虽说他是应届生，但他是很强势的，因为一方面他毕业的院校比较好，另一方面他在学校里也很优秀）。最不强势的人就是项目经理了。为什么项目经理会这样呢？因为他对业务和技术都不懂，而且他自己还很清楚这点，所以他平时就什么都不敢说也不敢管（不过我觉得他也缺乏带项目的经验）。并且，我们3个人都不是全职做这个项目。这个项目涉及的技术我们都没有人用过。 接下来说一下工作安排。由于我是项目开始后加入，所以需求分析我没有参加。然后详细设计，大家讨论，然后每个人分一块来写，项目经理收齐后合并成一份文档，交给领导审批。开发时，再打乱分下来一人开发一个模块。由于，我们部门今年内增加了很多规章制度，要求文档要齐全，格式要标准，并且要经过技术委员会审批。因此当这一切做完，已经到年中了。 然后架构师开始搭开发框架（一边摸索一边搭）。我们开始开发。开发时碰到一些问题：1）对使用的新技术我们都不熟；2）详细设计文档不够详细（文档其实就是为了应付领导），需要不断地询问；3）项目经理不统一项目开发标准和管理项目事项。4）每个人都有其他事情不断地打断开发。 |
| (2) Jann Thomas 谈阴阳与软件项目管理 Yin Yang & Project Management （张恂 2270 字 0 回复 E2009-5-23 18:54:13 LID:34 Hit:137）by Jann P. Thomas, 2009-1-7 (ScrumAlliance) 用中国传统文化的阴阳哲学重新诠释了《敏捷宣言》的四条价值观，很好的文章。 4 laws of yin-yang: - Yin and Yang are opposing. - Yin and Yang are mutually rooted. - Yin and Yang mutually transform. - Yin and Yang mutually wax and wane. 困惑的问题： Will the developers now have free reign to do whatever they want to do? Who will be in control? What is the job of the manager on an agile development team? How can I move from command and control to cooperation? Jann 从敏捷项目管理/敏捷项目经理的角度，利用阴阳理论诠释了 4 条敏捷价值观（balanced principles） Individuals and interactions over processes and toolsA process? Yes. Agile is not anti-process ... the agile project manager must create a process for bringing in new, unplanned work. To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes. 敏捷方法和过程本身是科学、严格和规范的（disciplined），事实求是、因地制宜、灵活应变是敏捷的本质特征。 Working software over comprehensive documentationjust enough 是关键。 On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications. Customer collaboration over contract negotiationAll software projects have some type of contract, whether implied or explicit. 往往造成麻烦的是那些 implied/implicit 的契约/约定。 Negotiating with the customer or product owner on scope is a key component of agile project management. 在 scope 的权衡、决策上，product owner 往往具有更大的主导权。 Responding to change over following a planJann 举了 home building 的例子。的确，软件工程与房屋建造、装修装饰工程有很多相似之处，也是我经常喜欢举的例子。 小结Jann 说得很好： Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process). 懂得了阴阳，就懂得了辩证法，这是东西方共有的智慧。 敏捷和传统并非水与火，彼此对立、不相容的关系，它们是互补的。敏捷和传统的精华结合，才是最好。 |
| (3) TDD 能提升质量在意料之中，那么效率呢？ InfoQ 新闻（中文）： （张恂 2305 字 0 回复 E2009-3-4 15:35:43 LID:33 Hit:148）Empirical Studies Show Test Driven Development Improves Quality TDD 的测试部分其实是某种形式的回归测试（regression test）。与传统回归测试不同的是，TDD 测试频度更高，周期更短。然而，回归测试不是什么新概念，恐怕 25 年以前就有了，属于传统软件工程的精华。回归测试也是 TDD 中最有价值的部分。TDD 测试更频繁，更全面，当然能尽早发现错误，减少错误，获得更稳定的软件，从而提高软件质量，这本在意料之中。作者们用实际案例、定量数据的分析证明了我们的推理，正是这篇研究报告的价值所在。 质量和效率往往是一对矛盾。常识是，获得高质量的软件往往需要耗费更多的时间和精力。 Kent Beck 在他的作品中多次提到，TDD 是一种区别于 model-driven, architecture-driven 的方法。那么，在这份研究报告中，IBM 和微软的项目难道用的是 XP 过程，他们有没有用基于 design model、architecture 的过程方法？这是一个疑问。 案例的情况： 1 个来自 IBM，3 个来自微软。 每个案例研究都对比了开发同一个产品的两个团队，他们使用同样的开发语言和技术，处于同一级别的管理之下，唯一不同之处在于：一个团队使用TDD，另一个不用。 IBM 案例中的团队在开发设备驱动程序，微软的团队在开发 Windows、MSN和Visual Studio的相关应用。 这里没有提到他们采用的开发过程，是否采用了 XP，或者采用了基于模型、架构的开发？ 在这篇报告中，提到了 TDD 的两种工作流：minute-to-minute workflow 和 task-level workflow。 分钟级别工作流： - 编写一些新的小单元测试用例 - 运行测试，看着它们失败 - 编写实现代码以满足测试 - 重新运行单元测试用例，确保它们通过 显然，这些案例项目的 TDD 是单元测试驱动。 任务级别工作流： - 将新的实现代码和单元测试集成到现有的代码库中 - 重新运行所有的测试用例，确保新的代码不会导致任何测试失败 - 重构实现代码和测试代码 - 重新运行所有的测试用例，确保重构后的代码不会导致任何测试失败 这实际上是重构、回归测试的结合。 实验结果是： 缺陷密度通过 KLOC 缺陷数目来衡量。 相较于不使用 TDD 的项目，这四个产品在发布前的缺陷密度降低了40%到90%。 从团队管理层的主观报告看来，在开发的初始阶段，使用 TDD 的团队要多花 15% 到 35% 的时间；不过团队都同意一点：这个时间被减少的产品维护时间抵消掉了。 我的观点和问题是： 1、这项研究是否说明 TDD 可以用在非 XP 的过程之下？ 2、案例中的 IBM、微软项目团队都是非常成熟的软件工程团队，Windows、MSN 和 Visual Studio 也都是非常成熟的产品架构。 如果 TDD 用在国内的典型项目上，增加的开发时间很可能要更多，大概在 50% 甚至 1 倍以上（我个人的估计）。 我曾经在 Kent Beck 和 Martin Fowler 的作品中看到，采用 TDD 代码之后，单元测试代码常常和实现代码的规模差不多，有 2 万行的实现代码，差不多也有 2 万行的（单元）测试代码。 编写高质量的单元测试，也是需要时间的。我估计国内的客户、开发商在做项目计划的时候，大多都没有把这个时间考虑在内，或低估了设计、编写测试、执行测试所需要的时间。 3、采用 TDD，在带来质量提升的同时，有可能降低开发效率，延长交付时间。当然，如果质量回报大于效率损失，那么就值得尝试 TDD。 4、TDD 是可行的，而且可以提高开发质量，这些都没有问题，那么是否还有比 TDD 效率更高、风险更小、更加灵活、更符合大众习惯的开发方式？ 我相信是有的。 其他研究Maria Siniaalto 在 2006 年发布的一篇文章，得出结论： 复审并总结了其他 13 项有关 TDD 的研究，包括在纯商业、半商业和学院背景中进行的研究。 * TDD 看来可以提升软件质量，特别是在纯商业背景中。 * 对于半商业背景或学院环境中的研究来说，结论不是那么明显，可这些研究没有提到任何软件质量的降低。 * TDD 给工作效率带来的效果不是十分明显，而且结果会根据研究的环境发生变化。 * 有证据证明：TDD 不一定会降低开发人员的工作效率，或是增加项目的交付时间。某些情况下，TDD 会带来显著的工作效率提升；同时，在提到的13个案例研究中，只有两个案例指出工作效率降低了，不过这两个案例同时指明质量的提升。 |
| (4) Joel 与 Uncle Bob 的论战：关于 TDD 和敏捷设计 InfoQ 新闻（中文）： （张恂 2556 字 0 回复 E2009-2-24 16:15:07 LID:32 Hit:174）Spolsky vs Uncle Bob Joel 的观点和中式太极敏捷 UDD 的观点很相近。 关于 TDD支持 Joel 的观点： 对测试驱动开发有一些争论 …… 应该给所有东西都写单元测试吗，诸如此类的东西 …… 敏捷编程总的观点就是不需要就别做，需要时再引入。我觉得很多时候对所有东西写自动化测试并不能对你有所帮助。 UDD：我们并不需要给所有的代码写单元测试。对于整体应用系统（非框架 API）的开发，很多单元的测试可以通过其他办法间接地做到。 Joel基本上有两个异议，第一个是你把时间花在什么上面了： 我觉得即使团队的单元测试覆盖率达到100%，依然会有一些问题。他们可能花费了相当多的时间编写单元测试，然而质量未必能得到相应的提高。 UDD 观点： 单元测试不如系统功能测试更重要，很多单元测试没必要写。我们应该把时间和精力放在更重要的事情上，比如系统功能测试的驱动。 Joel的第二个异议是测试套件非常脆弱： 我发现单元测试真正的问题在于，随着代码改进，你想修改的内容可能会破坏一定比例的单元测试。有时你修改了代码，不知何故，有10%的单元测试 失败了。因为你修改了某些设计...你移动了一个菜单，现在所有依赖菜单的东西仍然存在...而菜单移到了别处。所以这些测试都失败了。你必须能够重写这 些测试，以反应代码新的实现。 实际情况，不一定非常脆弱。但在项目开发的早中期，单元测试代码和需求、架构一样不稳定，是有可能的。 这两个异议我基本上都同意。 改良的 TDDBob 大叔的回答也是不错的： 我不认为TDD很神圣。我认为它是一个值得遵守的规则。我不会事先编写所有的测试。有一小部分测试在编码后再写只会更方便。甚至有一些代码我根本不会写测试，因为不值得写。但是这些都是例外情况。大多数代码我会先写测试。（不，Joel，这没有浪费我的时间。） 前半部分，我很赞同，TDD 不应该成为神圣的教条。Bob 提出的做法其实是一种改良过的 TDD，放宽了原先 TDD 对开发步骤顺序的严格限制。可见，我们（至少在 Bob 所说的例外情况下）并不需要针对所有实现代码，都必须先写测试代码。一个问题是，如果你不是每次都先写测试代码，后写实现代码，怎么叫 test driven 呢？ Uncle Bob 说，大多数情况下，他会先写测试。具体他没说，是那种类型的测试，估计是单元测试。和 Uncle Bob 不同的是，一般我肯定不会首先去写单元测试，除非有绝对的必要，比方这些单元都很重要，而且它们的外部接口、使用方式和依赖关系已经相对稳定了，需要对外发布这些单元等等。 尤其在开发阶段的早中期，在需求和架构都还不稳定的时候，我更不会首先把精力放在写单元测试上。我会尽量根据功能需求（use case）的基本流、扩展流以及架构的重要性等因素来设计测试，即便要做更小粒度的单元测试，也会首先考虑对一组、一群对象联合进行粒度更大一些的测试。我觉得这种方式效率可能会更高。 UDD 认为需求、架构是软件开发的主要矛盾，每个单元相对于整体和全局来说是次要矛盾，当然这是一对辩证关系。所以，由于存在软件开发哲学观点的差异，TDD 更像是 bottom up 的开发，先保证每个单元积木块的正确，再保证整体、全局的正确；UDD 则更像是 top down（architecure-driven）的开发，先保证整体、全局的稳定和正确，再来完善局部细节。在实践中，其实这两者都是可行的。架构重要？还是单元重要？答案是在运动、变化的。 由于任何带有边界的“系统”（包括类、单元在内）都存在 use case，所以 UDD 的单元测试，也借鉴了 use case/scenario 的设计方法。 针对我所了解的国内的情况，UDD 认为：TDD 对开发步骤顺序的刚性规定（“必须”先写单元测试代码，后写实现代码）在实践中是没有必要的，而且很多时候没有必要从单元测试开始写起。另外，大多数代码都应该努力配上自动系统功能测试，以减少人工测试的麻烦。系统测试的完备性比单元测试的完备性更重要。 关于 TDD 测试的难点： Bob解释了创建测试套件的重要性，这些测试套件不能像Jeol经历中的那样脆弱，不要一点修改就破坏10%的测试，Bob还介绍了怎样做到这一点，比如通过逻辑和呈现层的分离、在界面显示内容之下 正确地测试。Jeff提出Unix社区通常是这么做的，首先写一个命令行程序，然后在其上封装一个UI来驱动它。 如何保证测试套件的稳定性？ Uncle Bob 这个版本的 TDD 听上去更为合理。 关于 SOLID 原则其他一些不错的观点： Atwood：规则、准则和原则是从实践中提炼出来的宝藏，值得研究和尊重。但是它们决不能替代对你工作的认真思考。 播客的最后，Jeff、Joel和Bob再次谈到了遵守建议的风险，以及编程社区的技术水平，他们一致认为太多的开发者根本不关心自己在做什么。总之，他们都认为多动脑筋是很有必要的，但感觉他们对开发软件的方式尚未有一致意见。他们三人都承认对变化做出响应很重要，但是要想做到响应变化，需要对设 计和测试投入多少是他们分歧的核心，也是整个行业普遍存在的分歧。变化是永恒的，我们如何处理变化却差别甚大。 |
| (5) 软件设计的艺术：把握前构与重构的平衡 Prefactoring 与 Refactoring 是两个反义词，两种意义上相对的软件设计活动（和技术）。 （张恂 1358 字 0 回复 E2009-2-11 22:45:46 LID:31 Hit:121）由于软件开发的哲学观有所不同，太极敏捷与强调设计以重构为主的 XP 等敏捷方法，在看待前构与重构的关系上，也有许多不同。 以下列举太极敏捷的一些主要观点、结论和对客观事实的分析。 前构* 软件设计中不可能没有前构活动。 * 敏捷方法反对的是过度的预先设计，不是反对预先设计（前构）。 过度的预先设计，明显会产生很多浪费，你做的设计可能完全没用上。想得太多不好，想得太少不好。软件设计为什么这么难？难就难在如何掌握这个度，微妙的平衡。 * 前构应该包括设计的各种预案，对各种将来可能发生的需求变化的估计和应对准备方案。 * 理想情况下，每位软件设计人员都希望自己的代码和设计能够一步到位，改动越少越好。但事实上，变化是绝对的，没有人是神仙，能够预知未来，掌控一切，所以不可避免地会出现软件设计需要重构的情况。另一方面，软件需要重构的必然性，并不意味着我们应该放弃提高前构能力。 * 程序员的经验越丰富，他的预见能力、前构能力就越强。 初级程序员、经验少的可以只望前看一两步，而软件架构师、设计师的设计应该有更有预见性（和前瞻性），应该在有限的时间内多往前看几步，比方10 步、20 步等。 * 那种走一步、看一步的软件设计，是短视的，效率很低，应该避免，也没有必要。大胆的前构与大胆的重构一样，值得鼓励。 重构* 软件设计中不可能没有重构活动。 * 重构是一种软件设计的变换，把软件从旧的设计（结构和状态），转变到新的设计（结构和状态），在提高软件质量的同时，保持已实现的需求功能不变。 * “重构”是对上一次设计的重构，对下一次设计的前构。所以，前构与重构其实是统一的，是软件设计中两个连续的活动，同一事物的两面。 * 每次重构都形成一次时间和精力上的浪费，是开发商的内部损耗，因为旧的设计被放弃了，取而代之的是新的设计。两次设计，以及重构的过程，都有一定的开销。 * 有工具支持完成的自动重构，开销可能很小。手工进行的重构，开销较大。 * 重构不可能永远进行下去，必须在项目结束前的某个时刻停止。新的重构只有安排在下次发布或项目中。 * 在实际的项目中，通常重构的次数越少越好。如果客户愿意为你的重构买单，则可以取消这个限制。 * 忽视前构，过度依赖重构，与过度预先设计一样，应该避免。 前构与重构的平衡* 是否要对将来可能出现的需求变化作出预先设计，取决于我们预估事实发生的可能性（几率）和预估的风险成本。 如果发生几率很大，估计失败的风险成本，以及事后重构的成本都很大，那么就应该大胆前构，提前作好准备。 如果发生几率较小，估计失败的风险成本较小，事后重构的成本也较小，那么就不必提前实现编码，可以静观其变，等到事情发生了，再应对。 复杂的估计，还要考虑如果估计错误，可能导致的风险成本。 这种决策思维，其实和下围棋、象棋，打桥牌差不多。 |
| (6) 重构的误区 InfoQ 文章（中文）： （张恂 934 字 0 回复 E2008-12-5 9:39:10 LID:30 Hit:80）Debunking Common Refactoring Misconceptions Danijel Arsenovski 是 Professional Refactoring in Visual Basic（Wrox）一书的作者，Excelsys S.A 公司的产品和解决方案架构师。 他列举了许多有关重构的误解： "If It Ain't Broke, Don't Fix It" Refactoring Is Nothing New Refactoring Is Rocket Science Refactoring Causes Poor Performance Refactoring Breaks Good OO Design Refactoring Offers No Short-Term Benefits Refactoring Works Only for Agile Teams Refactoring is indispensable for agile teams Refactoring can be applied as a separate stage in development process and performed by separate team Refactoring can work just as well without unit tests Not relying on comment can't be right What's wrong with Hungarian notation? 在现代 IDE、C# 和 VB.Net 中，匈牙利命名法已经过时了。 |
| (7) 善用代码覆盖率（张恂 646 字 0 回复 E2008-11-23 11:47:26 LID:29 Hit:73） |
| (8) IEEE Software 2007 TDD 特刊 IEEE Software 2007 May/June 期为 TDD 特刊，主要文章有： （张恂 973 字 0 回复 E2008-8-2 11:49:05 LID:28 Hit:432）Guest Editors' Introduction: TDD--The Art of Fearless Programming Ron Jeffries, Independent Consultant Grigori Melnik, University of Calgary Professionalism and Test-Driven Development Robert C. Martin, Object Mentor Test-Driven Development of Relational Databases Scott W. Ambler, IBM Test-Driven Development of a PID Controller Thomas Dohmke, Henrik Gollee, U. of Glasgow Test-Driven GUI Development with TestNG and Abbot Alex Ruiz, Yvonne Wang Price, Oracle Envisioning Next-Generation Functional Testing Tools Jennitta Andrea, clearStream Incorporating Performance Testing in Test-Driven Development Michael J. Johnson, IBM Chih-Wei Ho, North Carolina State U. E. Michael Maximilien, IBM Laurie Williams, North Carolina State U. Learning Test-Driven Development by Counting Lines Bas Vodde, Nokia Networks 值得一读。 InfoQ 对 IEEE Software 主编 Hakan Erdogmus 的采访。 |
| <原文 NewsUseCase> <添加新主题> 共 5 个主题 5 条评论 |
| (1) GIS 需求分析 中国地质大学 GIS 软件工程 网络教学课件 （张恂 518 字 0 回复 E2009-5-24 21:39:18 LID:6 Hit:150）http://course.cug.edu.cn/cugThird/MapGIS_SE/ 讲义 PDF: Project Development Requirements Analysis (SIE 510 GIS Applications, Spring 2009) by Kate Beard, professor in the Department of Spatial Information Science Engineering at the University of Maine http://www.spatial.maine.edu/~beard/ |
| (2) 用户故事估算技巧（张恂 214 字 0 回复 E2008-9-2 21:40:47 LID:5 Hit:164） |
| (3) OMG 正在进行 UML 中用例描述的应用调查 Survey on the Role of Use Case Narratives in the UML （张恂 377 字 0 回复 E2008-3-26 16:58:14 LID:4 Hit:114）这份调查由加拿大 Lethbridge 大学的教授 Brian Dobing (brian.dobing@uleth.ca) 和 Jeffrey Parsons (jeffreyp@mun.ca) 组织，是一项更大的有关 UML 对于系统开发的影响调查研究项目的一部分。 两位专家的一部分研究结果已发表在 2006 年 5 月期的《ACM 通讯》上： How UML is Used |
| (4) 新型用例工具 Case Complete（张恂 98 字 0 回复 E2007-6-10 12:47:01 LID:3 Hit:160） |
| (5) 采访敏捷大师 Cockburn（InfoQ）谈及用例与用户故事的异同 Interview: Agile Thought-Leader Alistair Cockburn （张恂 728 字 0 回复 E2007-1-23 14:58:10 LID:2 Hit:236）(2007-Jan-22, InfoQ) 在 Agile2006 上 InfoQ 记者采访了久违的 Alistair Cockburn 博士。这篇采访将近半个小时，涉及很多很有意思内容，可以让我们了解 Cockburn 对敏捷方法、Crystal、用例的一些最新想法，值得我们好好研究一番。 真巧，我这两天刚写完 这篇文章 的第一稿，没想到上 InfoQ 头版一瞧，记者也正好问到了用例与用户故事比较的问题，当然这是我最感兴趣的地方。 Cockburn 夸奖了 Gerard Meszaros 的文章，对用户故事与用例的比较作了比较细致全面的研究，我找到了这篇文章 Using Storyotypes to Split Bloated XP Stories 如果说用户故事像一只扁平虫（flatworm），那么用例就像一匹马（horse），很有意思的比喻！ |
