敏捷还是银弹，这是一个问题

Agile Project Management: Creating Innovative Products 2nd Edition

 

对敏捷理念的阐述，这本书讲的挺好，也挺实在的。推荐之！

最近比较忙，好久没来，发现这里热闹起来了。

问题的处理逻辑一般可分为why，what，how三个层次。
从敏捷本身的精神来说，就是缩短这三个层次之间的反馈弧，在不断修正中得到问题的足够好方案，所以其核心是短迭代和快修正。
极限敏捷的目的是将what和how之间的反馈进一步加速，TDD就此而生，T作为一个可执行的what to do的描述，其好处的确是巨大的，但这块加速的成本无疑巨大，也增加了一定风险。
回到实际开发实践，就我所见所知来说，最大挑战是why到what的处理，由于应用水平相对较低，这一点在国内项目中更为强烈。往往是why到what的解决能力都不足，但在顾问们的忽悠下，将大量成本转移到what到how的这一点极限加速当中，各种杯具琳琅满目。
事实上，极限敏捷的先驱者们是在why到what解决的足够好的前提下，困扰于过于繁复的文档，在what到how的阶段，用可执行代码取代文档（参考Uncle Bob的某一段谈话，找不到原文了，当我瞎扯亦可）。
实际生产中的核心问题是往往缺乏有效文档，why到what解析不足；而不是足够好了，甚至多了。在这种情况下，追求极限轻量型过程，是否可笑？我接触过好几个国内极限敏捷的活跃鼓吹者，自身都不具备有效文档的编写能力，但是无妨他们采用“因为爱所以爱”的思辨击败你。
极限敏捷的很多组件是非常好的，针对实际情况作出合理剪裁，在资源，时间，质量等要素中作出有效的平衡，这才是一个务实的态度。

同时致gigix大牛，在下也在合适的环境下还算成功的应用过极限敏捷开发，同时坚定不移的认为，在绝大多数地方，弯道超车大跃进到极限敏捷是不可取的，当然这无法妨碍跨越式发展爱好者的取向。
同时你举的某100%测试覆盖的例子，与贵公司的研究报告不符，貌似贵公司认为80%（抑或60%？）的测试覆盖率之上，已经基本获取不到可观测的价值。如果贵公司研究报告无误，则此例子是个良好的违背敏捷精神的范例，无可观测的价值的测试同样是一种过度，可以称为敏捷过度。

我只是告诉你，有这么一家上市公司，他这么做了，他效果很好。至于他是过度还是什么，你自己琢磨去。有人愿意说这是敏捷过度了于是就可以对自己分明连50%都到不了的测试覆盖率安然自得，fine，你花自己的钱，谁管你？
BTW，我从来没见过你说那样的研究报告，麻烦你给个链接呗。

实话实说，你说的这些东西，我看起来不着边际。 至少和我说的不着边际。我看起来像是茶杯里淹死了一只骡子这样的故事，尽管可能发生，但是要解释起来大费周折。问个私人问题，你为什么喜欢这么说话呢？或许你已经到了如来佛祖的境界，凡夫之人难以理解你的思想？即便如来佛祖，在讲法的时候也尽量用众生都能听得懂的语言来说话啊。

你可以喝你的larger。
我可以喝我喜欢的Belgium strong ale。
品味在你自己。

去年实践过敏捷，深刻理解到如果没有高素质的成员，就不要谈这个问题。

还是老老实实的搞CMMI或者简版cmmi靠谱

大侠对中小公司的手工作坊式开发很有经验。
在此请教一下 我下面的经历有什么地方可以和敏捷关联得上？

我们三个人历时一年半做一个大公司的业务系统。技术上困难几乎没有，主要是业务复杂，客户需求变动极快——与我们交流的是小BOSS，他上面还有部门BOSS，上面还有亚太BOSS关注，朝令夕改是经常的事。

因为人少，又是分布式开发（技术总监是外援），只有一测试。

所以大家没人写文档（连个数据字典都不会有），最常见的情况有，扭头问唯一的哥们，那个啥是干啥的？那个业务怎么来着，我忘了！哥们要么立马回话，要么是都忘了，一起翻下代码，马上就能找到答案，所以不要文档没感觉到有啥不适应的地方。

有需求来了，甭管给谁的，俩人先讨论一下怎么搞，顺便当是放松一下。所以他的代码我都看得懂，我的他也都知道怎么回事。

做完一个CASE，扭头就喊唯一的测试，登我的系统来测测这个好使不。发现有问题，通常在10分钟内修复，没问题，就扔SVN上了。

BUG管理系统形同虚设，因为测试没机会在正式的项目管理流程中开BUG出来，都提前搞定了。
唯一比较麻烦的是会有一些都忽略的BUG流到客户那里去，不过上线前会由客户做一周的测试，有BUG对关系不会有影响，他知道我们测试人员少。麻烦的地方就是这种BUG就要写文档按流程给客户看了，修复代码要测了再测才能上SVN了，没有内部那种哪怕改个命名也随手提交的惬意了。

开始总监老大还要求写测试用例，后来发现写测试用例的速度实在是赶不上开发的速度，就放弃了。完成一期功能，全员出动搞系统测试，你测我的，我测你的。 对各种问题商量然后决定是否妥协还是拉上老板找客户改变不切实行的业务想法。

从外援总负责人那来需求都是很粗的，比如要做什么什么模块，大概什么什么功能，自已下来就开干，从数据库设计到前台页面全搞，页面美工请了外援做了一整套设计，能搬进去的就搬，CSS不合适的自已去改美工的设计样式。

除了基本的SSB，别的用到什么加什么，要分页导出就加个displaytag，要写ajax就加个DWR，写上传图片就再自已加jQuary，下一期可能还会加EXT的一些组件，和YUI的一些东西。弄起来还是比较开心的，想用什么搞都行，只要功能实现，效果好。

反正就这么搞了大半年，一期上线，运营一段居然没有出啥问题。但越做业务越复杂，要求越多，要搞二期，三期。估计还会这么草头班子搞下去。

请教这种开发算是什么情况？以后能不能说咱也敏捷了？

太绝对，测试驱动只是敏捷的一种方式

顶，，，

当然不是敏捷。，，，