主题介绍
谷雨霖 说:
今天，我们有幸请到的是
敏捷专家王老师。他从事电信移动网络监测系统的开发与维护。在互联网、电信、电子和铁路等行业，在敏捷开发和项目管理等方面，具备多年实践经验。2006年开始将Scrum应用到项目管理实践，致力于在中国的软件开发业界推广Agile理念和方法论，笃信以人为本，关注敏捷，专注Scrum和XP。
时间正好到了，下面我们请王老师给大家做敏捷的介绍，然后留些时间讨论。
内容阐述
王老师说:
其实敏捷应该不是什么新名词了，相信大家都有所了解，但一开始还是罗嗦些理论吧
敏捷是针对瀑布模型而来的，大家知道，瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)， 集成，和维护坚定地顺畅地进行。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划 分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下 落。 但瀑布带来的问题就是：
1、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； 2. 在瀑布开发模式下，早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 3. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；。。。。。
还有很多就不列举了
而敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
1、XP（极限编程） 其思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
2. SCRUM 这是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
Scrum是在十多年前由Ken Schwaber 和Jeff Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ，Microsoft， Google， Lockheed Martin， Motorola， SAP， Cisco， GE Medical， CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队都取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。
3. 水晶方法族 由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。 水晶方法有很多分支，包括橙色水晶、蓝色水晶。。。。
4. 自适应软件开发 ASD 由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
5 。 DSDM动态系统开发方法 这也是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。在英国，由于其在各种规模的软件组织中的成功。
6. 轻量型RUP 这是从IBM发展出来的，但是即使现在在IBM内部，也有很多争论，也开始转向SCRUM 与 XP， 因为其流程还是较复杂
7. 精益方法 这个事从丰田的 精益生产理论发展出来的， 精益模式提倡持续不断地改进、减少流程中的浪费。
在我们的实践过程中，我们主要关注更多的、采用更多的是前两个，也就是Scrum 与 XP....我觉得这两个方法非常具备操作性，应用起来比较有效果
Scrum 主要提倡如下敏捷原则 ：
? 保持简单：Scrum本身就是很简单轻量级的流程，它能简化我们的开发流程。
? 接受变化：Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间，但是只有在这些时间段的中间，我们才可以重新调整工作的优先级。
? 不断迭代：Scrum需要在小于30天的一次次迭代中构建应用程序。
? 不断的反馈和改善：在每一次迭代的末尾，Scrum流程要求我们回顾以前是怎么做的，并且思考我们下次可以做哪些不同的事来改善流程。
? 协作：Scrum强烈鼓励团队成员的协作和沟通。如果没有这些，Scrum就一点用都没有。
? 减少浪费：Scrum帮助我们识别做那些只对客户或者团队有价值的事情。
这些都是跟 敏捷宣言 相一致的
Scrum其实仅仅定义了一个开发框架(Framework)，具体的编程实践，完全取决于每个团队，并且是完全基于常识进行管理的，这也是为什么我们要采用XP的缘故
Scrum的流程 涉及如下一下概念 ：
"产品订单" (product backlog)：这是你构建一个产品所需做的所有事情的一个高层次的列表，并按优先级排列，这样可以保证你总是工作在最重要的任务上。
" 冲刺订单"（sprint backlog)：是sprint的工作任务列表。一个"冲刺"订单来自于产品订单上最高优先级的一些任务，以及产生的附加任务，每一个任务都应该有一个 明确的“完成（Done）”的定义。
注意， 这里的冲刺就是 一次迭代！！
"冲刺"（sprint）：一个sprint就是一次为完成特定目标的迭代，一般是2-4个礼拜。
此外，还有一个角色叫 "产品负责人"(Product Owner)：这个人是负责维护产品订单内容和优先级。
Scrum 真的很简单， 概括讲 是一个非常轻量级的流程。简单讲 "产品负责人"是先建立一个产品"订单"(backlog)，做一个短期“冲刺”(sprint)计划，执行这个计划，每天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思，接着不断重复以上流程。
每天开一次短会，检查sprint中每个任务的进展状况，对未完成的任务，要求任务所有人给出新的剩余工作量的估算。
最后后再开一次回顾会议，找出不足，持续改善
Scrum 中还有另外一个角色 ，Scrum Master ScrumMaster 促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。ScrumMaster 并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。
ScrumMaster 是规则的执行者。
“每日站立会议” 每个团队成员需要回答三个问题：
* 今天你完成了那些工作？
* 明天你打算做什么？
* 完成你的目标是否存在什么障碍？
需要注意的是Scrum Master需要记下这些障碍，并负责帮助解决
Scrum 的要点基本就这么多。。。很简单的，没有涉及到任何实践，所以能跟其他敏捷方法并存，还能跟其他方法论并存，譬如CMM
下面再看看 XP， 极限编程 。 相信这个大家应该都很熟悉的，简单说几句
极限编程实践作业的核心 价值 是 ：
* 沟通
* 简单
* 回馈
* 勇气
* 尊重
比较好的常用的XP实践有 ：
1、结对编程
2.。 TDD 测试驱动开发（Test-driven development）
3. 持续集成
4. 重构与简单设计
5. 代码集体所有权 与 编程标准
6. 增量和迭代开发， small release
7.与使用者（在场的客户）不断交互
XP还有实践，较有争议的是 8. 每周40小时工作制（40-hour Week）
嗯，就讲这些吧
时间关系
问答时间
1.
王老师说:
Scrum 解决的是组织层面的敏捷问题，XP解决的是编程实践层面的问题，二者正好互为补充，相得益彰
Iverson 说:
就是说要用就一起用？
王老师说:
这不见得，要看你想解决什么问题。。。人们通常容易犯的错误，就是拿工具去消灭任何问题。 你拿了锤子，什么东西都可能是钉子
2.
Iverson 说:
其他都好办，说说你们TDD 测试驱动开发是怎么做的吧
王老师说:
测试驱动的。也就是说是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
通常可以这样来做
(1) 明确当前要完成的功能。可以记录成一个 TODO 列表。
(2) 快速完成针对一个功能的测试用例编写。
(3) 测试代码编译通过，但测试用例通不过。
(4) 编写对应的功能代码。
(5) 测试通过。
对代码进行重构，并保证测试通过。
(7) 循环完成所有功能的开发。
Iverson 说:
理论我知道，我想知道你们实际是怎么做的阿
特别是与数据库有关的开发
还有gui的测试做吗？
王老师说:
你需要有个UT框架, 这是针对白盒测试而言的，也是最常见的TDD。 另外测试人员也要早点介入， 从系统的功能的角度进行考虑
x99说:
UT框架 一般java的话 就是junit?
Iverson 说:
wang_lj9057，你能不能把你们公司tdd开发的详细做法给大家介绍一下阿，或者写个专题，供我们大家学习一下，呵呵
x99说:
老王的意思 是不是开发人员管开发人员开发 测试人员管测试人员写测试代码啊
王老师说:
每个产品不同，平台不同，人员不同， 采用的TDD方式与工具也不一样
3.
Cruiser 说:
请问对于分布式开发的项目（开发团队不在一个地点）可以采用敏捷方法吗？如可以要点是什么？
王老师说:
关于分布式开发，完全可以采用敏捷方法， 关键还是在人上，在人与人的沟通上
谷雨霖 说:
每天standing up meeting视频会议是可以取代的
王老师说:
首先你要决定哪方负责需求，这个很关键，一定是挨着客户最近的那方负责需求
Cruiser 说:
关于分布式开发，关键肯定在沟通上，我的意思是专家是否参与过分布式项目组并采用敏捷开发方法获得成功？因为我看到很多项目即使采用视频会议系统，在分布式开发时沟通效率还是很低的。
Cruiser 说:
在保证沟通效率方面有什么好的实践吗？
王老师说:
我们现在的项目出问题也就是出在分布式开发的沟通上，效率的确是个问题。不仅仅是一个视频会议的问题，还有时差。跟印度很好说，相差不大， 跟欧洲就是6-7个小时，跟美国就更多了
4.
x99说:
测试用例 写代码？还是文档？
王老师说:
测试用例， 主要是写代码！！
5.
caixd说:
项目团队平均工作年限2年左右的情况，可以应用XP吗？我们比较经常碰到的情况，是新项目组有一定比例经验不是很丰富的新员工。
王老师说:
可以。我们的新员工进来都要
譬如说我们有结对，但在实践过程中，不会真正的结对编程
而是更多的结对设计、结对评审，帮助新员工迅速掌握产品，掌握TDD开发等
因为实际过程中，真正的结对 1+1 >1 是肯定的， 但不一定就是 1+1 > 2的
caixd说:
补充说明下第三个问题。之所以提到项目组平均工作只有2年，主要是针对于个人技能的不全面，很多时候，即便用瀑布模型，开发人员对于实际任务完全要多少时间，会遇到什么困难都不知道，而用XP，会不会更难以预测和管理进度？
王老师说:
关于如果员工工作经验不够，这个我们的实践是这样的
王老师说:
做任务估算时，所有人都参与估算，结果按照DELPHI法则进行。 进行任务认领时，每个认领到该任务的人，可以对该估算做一个调整，调整按照10%进行，就是正负10%， 新人可以增加，有经验的可以减
这样，计划出来后，就充分考虑到了员工差异性，减少了 个人的工作进度对项目组整体进度的影响
6.
Alex 说:
对于Scrum，我的理解是：如果是用瀑布式的话，我们做的就是一个项目；如果是用Scrum的话，就相当于将这一个项目拆成很多很多的小项目；这样的话，是不是在一定程度上增加了工作量呢？
王老师说:
Scrum 不能简单的说吧一个项目拆成很多的小项目，只是说把原来一个大的项目，分成多次迭代来实现。
谷雨霖 说:
实际经验看工作量是否增加？
王老师说:
对于工作量， 是否增加这个我也没有定论，因为没做过这个实验，同时两种方法做同一个项目。。。个人认为，不会增加
7.
不胜人生一场醉(2009年春节，茫然中...) 说:
Scrum 更适合做产品开发，XP适用的场合是那些？
从项目总的流程来看还是瀑布模型多些，XP和Scrum能否与瀑布模型搭配使用?
王老师说:
总体来讲， 瀑布模型 跟敏捷模型、迭代模型相冲突的。。。前面提到了，瀑布模型只有在整个生命周期结束后，才会有一次发布，才会有真正的产品， 而敏捷，可以在很早期就有一个可以工作的版本。。。这个概念是不一样的
王老师说:
另外，敏捷模型、迭代模型的每次迭代也看以看成是一个 小瀑布 :)
在SCRUM 与 XP 的早期阶段，还是需要瀑布模型的。。。就是需求分析与高级设计
只是说要做的很轻量，不要很重，譬如我们可以花1-2个迭代专门做需求分析于 高级设计
从项目总的流程来看，如果是采用敏捷方法的，一定迭代模型多
XP和Scrum能与瀑布模型搭配使用，但一定要杜绝“瀑布式敏捷”
chinamathman@hotmail.com说:
什么叫”瀑布式敏捷“?
王老师说:
”瀑布式敏捷“----- 简单讲， 你还是按照瀑布模型来做事， 譬如 分成 需求分析 3个月， 高级设计2个月， 编码6个月， 测试 3个月，集成测试3个月，然后发布。。。其中的每个阶段做成几个milestone, 似乎是按照迭代来做
8.
sue说:
我的问题：会不会导致变更剧增，如：一次迭代完成就发现需要变更上一次迭代的结果
王老师说:
需要变更上一次迭代的结果？ 是说需求？
王老师说:
还是说自己的实现？
sue说:
对，就是发现上一次迭代的结果不合理，需要变更实现
王老师说:
哦，这样，我觉得这个应该是 总体设计或者 高级设计做的不好。 譬如你从.net平台转到 linux 去，或者CS转向BS.
这时候应该停下来，自己考虑一下设计与架构
9.
x99说:
迭代+功能分+每天一次15分钟左右的会议 属于Scrum了吗？
王老师说:
呵呵，关于什么是Scrum的标准，Nokia有一个。。我转一下吧
王老师说:
不能简单就说 ： 迭代+功能分解+每天一次15分钟左右的会议 == Scrum
x99说:
是Scrum一部分了吗？
王老师说:
对，是一部分
王老师说:
因为还会有演示、回顾
王老师说:
这是非常关键的，这样不断回顾总结，才能提高
未解决问题
10.
caixd说:
软件项目组的上级单位，一般是一个软件研发部门，管理很多项目组，这时候就期望每个项目组的工作是可预期的。如果员工工作经验不够，如何预期每个人的工作进度和项目组整体进度？
x99说:
同问 如果员工工作经验不够，如何预期每个人的工作进度和项目组整体进度？
11.
chinamathman@hotmail.com说:
结对编程有什么要求或者前提条件吗？我在实践中觉得结对编程难度挺大的，对结对的双方其实都有一定的要求。如果任意一方某些方面做的不合适，都会影响结对的效率，反而适得其反。
12.
Cruiser 说:
对于敏捷开发Delphi法是不是太复杂了？DELPHI法要求背靠背，而且对估算结果要多轮讨论直到达成一致。
Cruiser 说:
不过我猜如何准确估算应该已经不是敏捷方法的范畴了吧
liyizhou88@hotmail.com说:
DELPHI最后是要收敛的，也就是说大家都认可了这个估算结果，那怎么还会需要根据个人情况再次调整呢？或者说，这不是调整，只是正常的估值区间？
谷雨霖 说:
今天，我们有幸请到的是
敏捷专家王老师。他从事电信移动网络监测系统的开发与维护。在互联网、电信、电子和铁路等行业，在敏捷开发和项目管理等方面，具备多年实践经验。2006年开始将Scrum应用到项目管理实践，致力于在中国的软件开发业界推广Agile理念和方法论，笃信以人为本，关注敏捷，专注Scrum和XP。
时间正好到了，下面我们请王老师给大家做敏捷的介绍，然后留些时间讨论。
内容阐述
王老师说:
其实敏捷应该不是什么新名词了，相信大家都有所了解，但一开始还是罗嗦些理论吧
敏捷是针对瀑布模型而来的，大家知道，瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)， 集成，和维护坚定地顺畅地进行。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划 分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下 落。 但瀑布带来的问题就是：
1、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； 2. 在瀑布开发模式下，早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 3. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；。。。。。
还有很多就不列举了
而敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
1、XP（极限编程） 其思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
2. SCRUM 这是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
Scrum是在十多年前由Ken Schwaber 和Jeff Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ，Microsoft， Google， Lockheed Martin， Motorola， SAP， Cisco， GE Medical， CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队都取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。
3. 水晶方法族 由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。 水晶方法有很多分支，包括橙色水晶、蓝色水晶。。。。
4. 自适应软件开发 ASD 由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
5 。 DSDM动态系统开发方法 这也是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。在英国，由于其在各种规模的软件组织中的成功。
6. 轻量型RUP 这是从IBM发展出来的，但是即使现在在IBM内部，也有很多争论，也开始转向SCRUM 与 XP， 因为其流程还是较复杂
7. 精益方法 这个事从丰田的 精益生产理论发展出来的， 精益模式提倡持续不断地改进、减少流程中的浪费。
在我们的实践过程中，我们主要关注更多的、采用更多的是前两个，也就是Scrum 与 XP....我觉得这两个方法非常具备操作性，应用起来比较有效果
Scrum 主要提倡如下敏捷原则 ：
? 保持简单：Scrum本身就是很简单轻量级的流程，它能简化我们的开发流程。
? 接受变化：Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间，但是只有在这些时间段的中间，我们才可以重新调整工作的优先级。
? 不断迭代：Scrum需要在小于30天的一次次迭代中构建应用程序。
? 不断的反馈和改善：在每一次迭代的末尾，Scrum流程要求我们回顾以前是怎么做的，并且思考我们下次可以做哪些不同的事来改善流程。
? 协作：Scrum强烈鼓励团队成员的协作和沟通。如果没有这些，Scrum就一点用都没有。
? 减少浪费：Scrum帮助我们识别做那些只对客户或者团队有价值的事情。
这些都是跟 敏捷宣言 相一致的
Scrum其实仅仅定义了一个开发框架(Framework)，具体的编程实践，完全取决于每个团队，并且是完全基于常识进行管理的，这也是为什么我们要采用XP的缘故
Scrum的流程 涉及如下一下概念 ：
"产品订单" (product backlog)：这是你构建一个产品所需做的所有事情的一个高层次的列表，并按优先级排列，这样可以保证你总是工作在最重要的任务上。
" 冲刺订单"（sprint backlog)：是sprint的工作任务列表。一个"冲刺"订单来自于产品订单上最高优先级的一些任务，以及产生的附加任务，每一个任务都应该有一个 明确的“完成（Done）”的定义。
注意， 这里的冲刺就是 一次迭代！！
"冲刺"（sprint）：一个sprint就是一次为完成特定目标的迭代，一般是2-4个礼拜。
此外，还有一个角色叫 "产品负责人"(Product Owner)：这个人是负责维护产品订单内容和优先级。
Scrum 真的很简单， 概括讲 是一个非常轻量级的流程。简单讲 "产品负责人"是先建立一个产品"订单"(backlog)，做一个短期“冲刺”(sprint)计划，执行这个计划，每天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思，接着不断重复以上流程。
每天开一次短会，检查sprint中每个任务的进展状况，对未完成的任务，要求任务所有人给出新的剩余工作量的估算。
最后后再开一次回顾会议，找出不足，持续改善
Scrum 中还有另外一个角色 ，Scrum Master ScrumMaster 促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。ScrumMaster 并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。
ScrumMaster 是规则的执行者。
“每日站立会议” 每个团队成员需要回答三个问题：
* 今天你完成了那些工作？
* 明天你打算做什么？
* 完成你的目标是否存在什么障碍？
需要注意的是Scrum Master需要记下这些障碍，并负责帮助解决
Scrum 的要点基本就这么多。。。很简单的，没有涉及到任何实践，所以能跟其他敏捷方法并存，还能跟其他方法论并存，譬如CMM
下面再看看 XP， 极限编程 。 相信这个大家应该都很熟悉的，简单说几句
极限编程实践作业的核心 价值 是 ：
* 沟通
* 简单
* 回馈
* 勇气
* 尊重
比较好的常用的XP实践有 ：
1、结对编程
2.。 TDD 测试驱动开发（Test-driven development）
3. 持续集成
4. 重构与简单设计
5. 代码集体所有权 与 编程标准
6. 增量和迭代开发， small release
7.与使用者（在场的客户）不断交互
XP还有实践，较有争议的是 8. 每周40小时工作制（40-hour Week）
嗯，就讲这些吧
时间关系
问答时间
1.
王老师说:
Scrum 解决的是组织层面的敏捷问题，XP解决的是编程实践层面的问题，二者正好互为补充，相得益彰
Iverson 说:
就是说要用就一起用？
王老师说:
这不见得，要看你想解决什么问题。。。人们通常容易犯的错误，就是拿工具去消灭任何问题。 你拿了锤子，什么东西都可能是钉子
2.
Iverson 说:
其他都好办，说说你们TDD 测试驱动开发是怎么做的吧
王老师说:
测试驱动的。也就是说是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
通常可以这样来做
(1) 明确当前要完成的功能。可以记录成一个 TODO 列表。
(2) 快速完成针对一个功能的测试用例编写。
(3) 测试代码编译通过，但测试用例通不过。
(4) 编写对应的功能代码。
(5) 测试通过。
对代码进行重构，并保证测试通过。
(7) 循环完成所有功能的开发。
Iverson 说:
理论我知道，我想知道你们实际是怎么做的阿
特别是与数据库有关的开发
还有gui的测试做吗？
王老师说:
你需要有个UT框架, 这是针对白盒测试而言的，也是最常见的TDD。 另外测试人员也要早点介入， 从系统的功能的角度进行考虑
x99说:
UT框架 一般java的话 就是junit?
Iverson 说:
wang_lj9057，你能不能把你们公司tdd开发的详细做法给大家介绍一下阿，或者写个专题，供我们大家学习一下，呵呵
x99说:
老王的意思 是不是开发人员管开发人员开发 测试人员管测试人员写测试代码啊
王老师说:
每个产品不同，平台不同，人员不同， 采用的TDD方式与工具也不一样
3.
Cruiser 说:
请问对于分布式开发的项目（开发团队不在一个地点）可以采用敏捷方法吗？如可以要点是什么？
王老师说:
关于分布式开发，完全可以采用敏捷方法， 关键还是在人上，在人与人的沟通上
谷雨霖 说:
每天standing up meeting视频会议是可以取代的
王老师说:
首先你要决定哪方负责需求，这个很关键，一定是挨着客户最近的那方负责需求
Cruiser 说:
关于分布式开发，关键肯定在沟通上，我的意思是专家是否参与过分布式项目组并采用敏捷开发方法获得成功？因为我看到很多项目即使采用视频会议系统，在分布式开发时沟通效率还是很低的。
Cruiser 说:
在保证沟通效率方面有什么好的实践吗？
王老师说:
我们现在的项目出问题也就是出在分布式开发的沟通上，效率的确是个问题。不仅仅是一个视频会议的问题，还有时差。跟印度很好说，相差不大， 跟欧洲就是6-7个小时，跟美国就更多了
4.
x99说:
测试用例 写代码？还是文档？
王老师说:
测试用例， 主要是写代码！！
5.
caixd说:
项目团队平均工作年限2年左右的情况，可以应用XP吗？我们比较经常碰到的情况，是新项目组有一定比例经验不是很丰富的新员工。
王老师说:
可以。我们的新员工进来都要
譬如说我们有结对，但在实践过程中，不会真正的结对编程
而是更多的结对设计、结对评审，帮助新员工迅速掌握产品，掌握TDD开发等
因为实际过程中，真正的结对 1+1 >1 是肯定的， 但不一定就是 1+1 > 2的
caixd说:
补充说明下第三个问题。之所以提到项目组平均工作只有2年，主要是针对于个人技能的不全面，很多时候，即便用瀑布模型，开发人员对于实际任务完全要多少时间，会遇到什么困难都不知道，而用XP，会不会更难以预测和管理进度？
王老师说:
关于如果员工工作经验不够，这个我们的实践是这样的
王老师说:
做任务估算时，所有人都参与估算，结果按照DELPHI法则进行。 进行任务认领时，每个认领到该任务的人，可以对该估算做一个调整，调整按照10%进行，就是正负10%， 新人可以增加，有经验的可以减
这样，计划出来后，就充分考虑到了员工差异性，减少了 个人的工作进度对项目组整体进度的影响
6.
Alex 说:
对于Scrum，我的理解是：如果是用瀑布式的话，我们做的就是一个项目；如果是用Scrum的话，就相当于将这一个项目拆成很多很多的小项目；这样的话，是不是在一定程度上增加了工作量呢？
王老师说:
Scrum 不能简单的说吧一个项目拆成很多的小项目，只是说把原来一个大的项目，分成多次迭代来实现。
谷雨霖 说:
实际经验看工作量是否增加？
王老师说:
对于工作量， 是否增加这个我也没有定论，因为没做过这个实验，同时两种方法做同一个项目。。。个人认为，不会增加
7.
不胜人生一场醉(2009年春节，茫然中...) 说:
Scrum 更适合做产品开发，XP适用的场合是那些？
从项目总的流程来看还是瀑布模型多些，XP和Scrum能否与瀑布模型搭配使用?
王老师说:
总体来讲， 瀑布模型 跟敏捷模型、迭代模型相冲突的。。。前面提到了，瀑布模型只有在整个生命周期结束后，才会有一次发布，才会有真正的产品， 而敏捷，可以在很早期就有一个可以工作的版本。。。这个概念是不一样的
王老师说:
另外，敏捷模型、迭代模型的每次迭代也看以看成是一个 小瀑布 :)
在SCRUM 与 XP 的早期阶段，还是需要瀑布模型的。。。就是需求分析与高级设计
只是说要做的很轻量，不要很重，譬如我们可以花1-2个迭代专门做需求分析于 高级设计
从项目总的流程来看，如果是采用敏捷方法的，一定迭代模型多
XP和Scrum能与瀑布模型搭配使用，但一定要杜绝“瀑布式敏捷”
chinamathman@hotmail.com说:
什么叫”瀑布式敏捷“?
王老师说:
”瀑布式敏捷“----- 简单讲， 你还是按照瀑布模型来做事， 譬如 分成 需求分析 3个月， 高级设计2个月， 编码6个月， 测试 3个月，集成测试3个月，然后发布。。。其中的每个阶段做成几个milestone, 似乎是按照迭代来做
8.
sue说:
我的问题：会不会导致变更剧增，如：一次迭代完成就发现需要变更上一次迭代的结果
王老师说:
需要变更上一次迭代的结果？ 是说需求？
王老师说:
还是说自己的实现？
sue说:
对，就是发现上一次迭代的结果不合理，需要变更实现
王老师说:
哦，这样，我觉得这个应该是 总体设计或者 高级设计做的不好。 譬如你从.net平台转到 linux 去，或者CS转向BS.
这时候应该停下来，自己考虑一下设计与架构
9.
x99说:
迭代+功能分+每天一次15分钟左右的会议 属于Scrum了吗？
王老师说:
呵呵，关于什么是Scrum的标准，Nokia有一个。。我转一下吧
王老师说:
不能简单就说 ： 迭代+功能分解+每天一次15分钟左右的会议 == Scrum
x99说:
是Scrum一部分了吗？
王老师说:
对，是一部分
王老师说:
因为还会有演示、回顾
王老师说:
这是非常关键的，这样不断回顾总结，才能提高
未解决问题
10.
caixd说:
软件项目组的上级单位，一般是一个软件研发部门，管理很多项目组，这时候就期望每个项目组的工作是可预期的。如果员工工作经验不够，如何预期每个人的工作进度和项目组整体进度？
x99说:
同问 如果员工工作经验不够，如何预期每个人的工作进度和项目组整体进度？
11.
chinamathman@hotmail.com说:
结对编程有什么要求或者前提条件吗？我在实践中觉得结对编程难度挺大的，对结对的双方其实都有一定的要求。如果任意一方某些方面做的不合适，都会影响结对的效率，反而适得其反。
12.
Cruiser 说:
对于敏捷开发Delphi法是不是太复杂了？DELPHI法要求背靠背，而且对估算结果要多轮讨论直到达成一致。
Cruiser 说:
不过我猜如何准确估算应该已经不是敏捷方法的范畴了吧
liyizhou88@hotmail.com说:
DELPHI最后是要收敛的，也就是说大家都认可了这个估算结果，那怎么还会需要根据个人情况再次调整呢？或者说，这不是调整，只是正常的估值区间？
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/3433/viewspace-611909/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/3433/viewspace-611909/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
