关于“登山的故事(什么是XP,设计)”的讨论

sungubbi

前段时间在chfyx的个人空间中看到下面这个故事，拿来跟公司的QA团队成员分享了一下，大家都有些感慨。并且促使了一次敏捷学习的任务形成。
在此也与大家分享，希望一起讨论。


从前，有一个A型血的人和一个B型血的人去登山。显然A和B有着不同的登山方法。
A到了山脚下，总是先停下来，仔细打量山势。接着，围着山脚转转，看看哪些是小山包，哪个是主峰。然后，设计几条不同的
登山线路，并选择出最好的登山线路作为首选计划。同时，他还考虑到如果首选计划出现问题，则可以启用第二计划或第三计划...
而此时的B几经爬上了第一个小山包。B登上小山包的时候，发现这个小山包不是去主峰的路。B并没有气馁，稍微打量一下环境，立即从小山包上下来，往更高的一个山峰进发...就这样，B无时无刻不在后退中前进，在下坡中上山，已经将A远远的甩在后面。
最后，B成功地登上主峰，而A还在半山腰艰难地攀登。当A终于登上主峰之后，B说了一句很有很有意思的话：你现在知道极限编程的威力了吧！A默然不语...
一位想学登山的新手来向A和B请教登山的方法。A把他的线路图和计划全部给了新手，没有说一句话。新手看都没看，就跑去问B。B意味深长地说：努力，努力，再努力，当你到达山顶的时候，就知道了登山的方法！新手由衷敬佩。
多年以后，A成功地登上了珠穆朗玛峰。据说B倒下的地方离一号营地只有一百米远...
当那位新手终于找到A求教的时候，A还是将所有的登山线路和计划交给了他，依然没有说一句话。
但新手明白：这就是设计！


上一篇：实施CMMI易犯的8个错误
下一篇：CMMI评估过程中的需求分析

sungubbi

以下是QA团队的讨论摘要：

疯子：
RE:邮件的故事
1.考察实际情况---相当于收集需求吧，前期调研
2.设计---多个方案，并制定计划
3.确定方案后，考虑首选方案的风险
4.说明前期的工作是很重要的，减少不必要的返工。尤其是一个大工程的时候。
   小项目可能会觉得效率高，但是一个大项目往往会影响进度，甚至项目失败。


冰の淇の琳：
只要时间允许，无论大小项目都要从设计开始。
第一次登山，A虽然没有和B同时登到山顶，但A一直在前进，B却是在后退中前进。说明B没有考虑到某些风险。
第二次登山，B的方法显然耗费体力，而A能够成功登顶，是因为他是在科学的登山，而不是盲目的爬山
对于新手来说，还是应该学A。要有计划的完成任务。

decset：
如果有时间跟能力当然是以设计为主，有的时候我们遇到的问题是给定的周期短，设计资源匮乏，就是你很认真做了设计也不一点做的很完美，就要有个度，在实践的过程中时时改进，最后是总结经验，然后传承。其次，登山毕竟不能等同软件开发，性质不一样的东西无法鉴别方法。

风
建议A和B组一个团队，那就无敌了
恩，和登山好像不好联系一起。登山的那个更像是做了很多返工，，而极限编程好像是吧项目分解成小块突破。。

疯子
但是我认为做底层框架开发的时候，返工是必然的，摸索实践是必要的。
就算 技术好的，也不可能一次性完成吧。

火：
无论是A还是B，他们的目标都很明确——征服山峰。
1.用A型血和B型血来作为故事开头，个人觉得在项目建设过程中人的因素是很重要。


风：
我对极限编程的困惑在于，，不做前期的设计，你如何分解项目，如何后期拼装衔接，，如何保证结果是你想要的，有点胡子眉毛一把抓的感觉，，

葡萄：
谁能先解释一下“极限编程”

鱼：
旺旺的血型说有点意思，看来我们还要查一下AB型人才的特质

风：
ExtremeProgramming（极限编程，简称XP）XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

火：
登山需要有个能够把团队凝结在一起的队长，这个队长就是我们通常所说的项目经理。

decset：
其实我很早就看过极限编程了，那个时候参加的项目也很单一，看到网上介绍的文字都很晦涩难懂。这些都是偏向项目管理方面的内容，需要培养我们的项目经理一起来认知，同时我们也分享项目经理的一些经验，我们大多数时候是在项目边缘的，要更深入的了解。

火：
我们俱乐部的队长就很不错，所以人气很旺盛

decset：
事实感觉到，leader真的很重要


decset：
更多时候，我们的理论都在哪里实践到，目前我们公司的情况又如何，工作中需要的改进是啥，我比较关心这个哈，找到自己工作的重心，才是本命啊！

鱼：
早期极限编程很受关注，大概是受9000啊RUP啊CMMI啊这些大型的模型的压迫，所以开发人员非常推崇极限和敏捷。但是我接触过很多人他们推崇它却只是狭隘地理解为极限就是啥都不要，一骨脑的往上冲，有问题再重做，这样真是太爽了。
但实际上无论是敏捷还是极限，都有一套的方法、最佳实践和工作要求，而不是毫无要求
敏捷、极限和CMMI并没有啥冲突，它们更多是一种方法，但在应用范围、项目类型、团队类型上会有区别，不是所有的项目都适合敏捷，也不是所有项目都适合RUP和完整的CMMI。前面谁说的也很对，要有度，并且要看项目

jane

看了登山故事，一直在思考跟QA有什么联系，好像更多的讲的是开发思想。不过有一点，个人比较赞成A的这种做法，适合个人或公司财富积累项目；在应付紧急任务时，极限编程是个好方法，比较有灵活性，而且最终项目还是能顺利完工。

Scott

to 虔诚的初衷，文章可能是让QA了解一下传统的开发方式和敏捷的区别吧：）

我以前也这样想过，用CMMI做新增项目开发，用敏捷做优化和维护项目。可这里有一个问题，如果这样做了，相当于一个人穿着一身西装，又穿了一个球鞋 - 不伦不类的感觉。为什么这样说呢，比如我们可以通过CMMI收集度量数据，比如需求稳定度、生产率，可我不清楚敏捷是否关注这些度量项，即使也关注，那么两套不同的数据收集系统，是否能够满足我们度量的要求？这只是其中一个方面。所以我觉得不能单纯的来看CMMI降低风险，可预测，敏捷适应变化，而应该从一个更加系统的角度来综合的考虑这些因素。这就需要你对所有的都有所了解：）

tongtong

大家考虑的角度挺客观的。方法没有一个对另外一个就是绝对的错。关键是用在什么场景。

20065503

描述中的B离极限编程还有很远的路，极限编程并不是没有计划的盲目，我们做项目也不是一味的图块。

在选择何种开发方法上，还得考虑项目的实际情况。最起码要把项目的规模、项目成本、项目合同的紧迫性纳入我们选择开发模型上嘛。
在时间不紧迫的条件下，我比较欣赏A的做法，即达到了登山山顶的目的，也比B节约了不少重复返工的成本，同时还降低了项目的风险。
B登珠峰失败就是一个比较惨重的教训，上规模的项目如果没有周密的计划是有很大的风险的。
当然，在时间紧迫的情况下我们可以把A和B做一个结合，AB型的开发模式也许才是极限编程的核心思想吧

牛哄哄

赞！这个探讨收获很大。

bealiz

今天又学习了~~

扣费

很有见地的探讨，先收藏着~

人善被人欺i

还不错哦，如果再能多分享一些就perfect了！

叼烟斗的猫

前排支持下了哦~

心有余悸的爱。

支持，赞一个

宝贝狐

不错 支持一个了

夜机

我也来顶一下..

雪婷

众里寻他千百度，蓦然回首在这里！