群里大牛聊天记录摘要

以下记录一些在群聊时看到的非常好的建议，记录下来，方便以后查阅

------------------------------------------------------------------------------

伍斌：

         一种比较靠谱的测试驱动数据库开发的方法，是用XML记录每次数据库的结构和内容的更改的SQL语句，使更改历史能被自动化复现。详情请参考我去年11月翻译完的《测试驱动数据库开发》，人邮社估计4月底能上市。

        h2看看

        用yaml记录数据库数据也比较常见 

        不光记录数据变动历史，还需记录数据库表结构变动历史。

------------------------------------------------------------------------------

关于product backlog和sprint backlog，以下是陈勇的理解：

      大需求+小任务，就是在PB里边，需求大致划分一下，到了SB里边再拆解成任务（至于是什么形式，比如是更小的需求，还是调研/设计/开发/测试……，敏捷没有提）
如果是“更小的需求”，那么在很大程度上就倾向于产品需求了（虽然严谨地说不完全如此） 

      第二种做法，小需求+直接分配需求到SB，这是我们现在的做法。
就是PB中就放好了大/小需求了（我们现在全都是客户需求），直接进SB开发就行。现在我们颗粒度大约在1～2人天左右，所以不用再拆了。 

      在敏捷开发里边现在很少再划分客户需求和产品需求这两个层面了，因为要形成完整的产品需求，一般需要相对完整的客户需求，然后进行相当复杂的分析才行。

而快速迭代里边这些条件都不具备，所以大家直接面向满足客户需求来完成开发了。 

       在形成PB之前，PO就要和客户确认需求了。 

       敏捷开发里边其实还假设，很难提前“确认”。比如在互联网行业，客户是大众，找不到人确认；而企业级应用，客户经常说“好”，又不签字。

所以敏捷开发很希望能首先理解客户为什么要这个东西（也就是客户需求），而不是功能是什么（产品需求），防止做出来的东西被彻底推翻。 

        这样真正的需求确认其实是发生在评审会上。

        

        人的改变是根本性的，敏捷开发尝试希望通过流程的改变（确切说，是流程人性化），来带动人的改变。
因此，流程本身其实作用不大，是流程的成果作用大。 

        

        有些人看到流程改变了，就以为Scrum做到了，于是就失败了。
另外一些人看到流程改变了，而没有效果（因为还没有改变人，或者过于关注流程而忽略了人），也是就放弃了。 

        

      任何看重人的存在，促成人的改进的方法，都是敏捷方法。不固定于某种形式，而注重对实际结果的提升（敏捷开发认为人是对实际结果影响最大的） 
      

     在敏捷之前大约10年，有一种叫做“自适应开发”的东西，其实是敏捷的前身。 

关于sprint中是否能出现需求变更的讨论：

     要解决的问题不变，但解决方法可以变，包括新增东西。

     针对某一个功能，解决的方法可以变化。但是不能增加另一个功能。比如这个sprint没有登录这个功能，不能在sprint中间增加这个功能进来

敏捷3C : Card Conversation Confirmation

    有原则，就是要有是非观，不能和稀泥；无立场，就是不能天然觉得自己应该支持谁反对谁。

    还是刚才PMP哪个问题 其实很多团队转型失败 就是因为 依赖太多权威 互相拍马屁 敏捷中最怕这个

    银行 电信 这些企业 他们敏捷转型最难 因为他们最官僚

    如果外包  客户 有时候 你很难跟他说明白  敏捷 不对时间承诺 时间固定 范围不固定 

------------------------------------------------------------------------------

陈勇：

   如果不用“测试保障的开发”，会很危险，

   测试保障是说，每当完成开发，能瞬间测试；测试保障大约=持续集成+自动化测试 

敏捷开发实的一个方面是有具体的执行方法（用户故事，优先级，迭代……），这些比较适合小型团队。
虚的一个方面则是是一种思维方式（要事优先，拥抱变化，团队协作，不拘泥于形式……），这些适合任何团队。
应该说，如果只有一个人，那么这个人就要站在整个项目的高度（空间广度，时间长度）看问题，不能当作一个人了。

Personal Software Process
PSP所能达到的质量水平，只有极少领域需要。PSP实际上是美国航空院校本科必修课。
把PSP当作一种训练手段，而非常规工作状态。因为PSP的水平太高，成本也高。

将软件架构比作建筑架构会有很大的危害。因为这样会给包括架构师、程序员、产品经理、测试工程师在内的所有参与软件开发的人员一个错误的暗示：根据一个软件架构开发完成的软件，其所遵循的架构将会像一个建筑物的建筑架构那样被凝固住而不会发生变化。

这样的后果，是会促使人们极力想在编程前，就开始猜测未来会发生的所有变化，并设计一个尽量灵活的架构来适应这些变化。但可悲的是，在后来的很长时间里，这些猜测的变化并没有发生。充斥着没有必要的灵活性的架构所带来的无谓的复杂性，吞噬着软件开发和维护人员大量的时间和精力，让项目延期的问题雪上加霜。

开发好的软件与落成后的建筑有着本质的不同。前者的架构可以在事后轻易地通过修改代码而被改变，而后者的架构则被凝固住而无法变化。

如果要为软件架构找一个更贴切的比喻，那么我认为软件架构更像水。孙子兵法曰：“故兵无常势，水无常形。能因敌变化而取胜者，谓之神。”良好的软件架构应该能像水那样，能根据周围环境的变化而不断重构自己的形态，以适应环境。

我的朋友仝键说软件架构像能不断适应环境的“生命”，也是另一个很好的比喻。

------------------------------------------------------------------------------
陈勇：
敏捷估算是一种残缺的估算，用途局限于近期开发，故事点的目的是找到不基于人员的规模，是尝试主观地找到客观的尺度。
偏差最小的是功能点，因为它定义最清晰和严格，但也最复杂，在没有特殊要求下，敏捷开发可以采用人天加扑克牌，敏捷是估算近期马上开发的清晰工作，相对误差还可以接受。如果在项目早期用敏捷估算误差会很大，最好是用功能点估算