敏捷开发一千零一夜读书笔记之敏捷初探

最近很忙，有个把月没读过书，没上过这里，趁着今天项目结题验收，上来转转。

    我常常想，我这里应该是没有读者的吧，我完全把这里当成是一些我脑子里记不住，或者感觉“啊，原来是这样”的东西集合地。因此，看起来杂乱无章。

    一晃27岁生日就要到了，装修已毕，婚期将至，手下的人，也越来越多，最近，总是在思考团队管理的事情。了解过瀑布开发，也了解了UML，然而，当我完全处于好奇，买了敏捷开发这本书时，寥寥几页，发现，啊，原来这就是我要找的管理方法，因为，它很贴近目前我所处公司的实际环境。好了，废话不多，开始拜读。

    首先，我是一个什么都不懂的leader，但我要很快变成一个靠谱的leader...

    我们如何打造企业核心能力，毫无疑问，应该是保证质量前提下的交付率。

    那么，我们必须有适合本土的管理体系，对于组织级的管理体系，有两种方式：

    1.可以从企业自我出发，循序渐进的优化流程。前提是，你必须知道自身的痛处和优化重点。这种方法，先重点总结好反思组织当前的实际业务，项目执行过程中遇到的实际问题，然后根据问题的优先级，选择某些方面先优先开始优化，并针对组织在该阶段的管理水平，团队能力，想要达到的目标和结果等，进行有针对性的培训，辅导，执行和复盘总结，等后收到了实际效果时，再逐步开始其他方面的优化和改进。这种方式的确能收到一些实际效果，但这种组织“优化”文化的形成，技术管理人才的培养，需要经历一个比较漫长的过程，可能遇到的问题是时间周期太长，没有明显的效果。

    2.以体系和管理工具为中心，拿来主义地进行流程优化，即照搬硬套，用的过程中再逐步完善和优化，以适应组织需要。即先僵化，再固化，最后优化。这种方式，效率高，引进速度快，但可能水土不服，因为在企业自身的业务方向，团队能力，对于流程规范的理解等条件不成熟的情况系，容易引起员工的抵触情绪，很难深入推进。这一点，我所在公司就是如此。

   敏捷项目管理的原则是：可工作的软件是衡量项目成果的主要指标，软件可工作，则必须让一线员工参与选择和决策。显然，员工更喜欢没有废文档，没有各种报告，只有每个Sprint交付有用的软件。

   那么，如何敏捷立项？

   其实，立项只是传统项目管理中的事情，在敏捷中，如何简化立项？实际上，在敏捷中没有立项之说，你所关注的，只是以下几个问题点：

   1.为什么要做？也就是要大家共识立项的目的。一般要研发团队和测试团队来问产品经理。这与传统立项不同点在于，它可以让研发和测试团队更加积极，而不像以前一样，有什么需求，研发就实现什么需个求，即使需求有逻辑错误。而现在，这种方式，让大家都有了质疑精神。

   2.有没有更重要的项目？其实是优先级的问题，产品经理列出的N多的用户故事，具体优先级如何排，也要在立项时讨论清楚。

   3.项目的交付结果是什么？

   4.可运行的软件质量标准是什么？这一点必须要在立项前定义清楚。

   5.有没有对需求达成共识？对需求达成共识是必须的，这样大家可以分头去准备必须的需求文档，设计文档，测试用例。

   6.大家最担心什么？

    然后，Sprint计划会议是在立项前还是后？

    建议在立项后，同时Sprint计划会应该多次讨论，针对需求，用户故事，进行合理的工时估算，如果产品在规定的Sprint周期内确实无法完成，则可根据优先级将某些不重要的用户故事删除，待下个版本增加。

   最后，就是一些立项后项目的基本规则，比如变更。在Sprint周期的三分之一处，尽量朝着用户体验更好方向提有用的变更，在1/3~2/3时段，团队只接受优化类别的需求变更，在后三分之一处，拒绝变更。

    然而，对敏捷开发中的很多概念，团队成员并不熟悉，如Sprint如何高效的开会？如何估算？如何让一个没有实施过敏捷开发的团队，成功实现敏捷开发？这些东西，都是需要培训的。

   关于度量

   对于一个具体的项目，采用敏捷项目管理，可以从项目的任务按时完成率，燃尽图，缺陷移除率等方向实施度量。但不应该讲度量与考核放在一起，否则，您只能看到很好的缺陷率报告，交付率图等。所以，人为产生的度量不应该用来做考核，而是系统产生的，不轻易干预的数据，拿来考核。

  不要迷恋度量工具，也不用每次度量很多指标，或者每次度量相同指标，只要度量的数据与直接业务有关，那么度量就有意义。

    关于复盘

    实际上，复盘框架如下：

    目标复盘->及格/卓越

    时间轴->如果你真的注重项目进度，那么，应该在复盘中，根据时间轴，做项目检查点回顾，是否每个检查点按时达到，如有偏差，是规划问题，还是执行问题？

    得失分析->关键任务完成及背后付出的努力/或者重大失误及原因。

    复盘结论->可以是报告，也可以是复盘纪要，重要的是，团队要有成长和学习。

    关于敏捷例会

    可以采用展示板和信息系统的巧妙结合，监视项目进度。

    关于配置管理

    SVN，由专门人员负责管理SVN。

    关于代码走查

    技术评审，包括需求评审，设计评审，代码走查，测试用例评审等和项目直接结果相关的工程活动评审。管理评审指的是敏捷项目管理的三个仪式：Sprint规划会，每日例会，Sprint评审会。与传统项目管理的项目立项评审，里程碑评审和验收评审也属于管理评审。

    从评审正式程度上，技术评审分为正式评审，技术审查，代码走查。其中，技术审查不用准备，代码走查也不用准备，但结果不需要确认，其他方面，都需要计划，准备，会议，修正，确认。

   代码走查，主要是对代码质量分析和编程规则做检查。分两种，交叉代码审查，代码会审，内容包括，代码规范，满足功能，逻辑实现，性能要求，对性能影响的瓶颈给出解决方案，代码简化，可读性提升。

   关于测试报告

   测试报告的目的是让所有团队成员都熟悉但当前Sprint交付软件的质量情况，每个开发人员身上有多少个bug没有解决，以及交付模块的质量情况。团队内部，不要求做正规和全面，应该为团队减负，提高沟通效率。所以要问团队需要什么的报告，基本情况总结，包含bug移除率，bug人员分布，bug模块分布。

    一些基本规则：

    1.软件可用规则：即每一个交付的功能，如果说可用，就一定可用。

    2.目标导向规则：即在指定敏捷规划时，要指定何为卓越，何为及格，有明确的目标。

    3.代码提交原则：即必须满足经过单元测试，且提交后整体代码编译通过。

    4.有话好好说原则：每个成员必须清楚需求，互相沟通。

    5.文档极简规则：只写必须的文档，如需求，关键点设计，方便长期维护和更新。

    6.精英团队规则：不要求成员规模很大，但要精练。

    关于持续优化

     敏捷核心思想，倡导款速迭代和交付、燃尽图方便你观察整个项目情况，关于燃尽图可能出现的7种情况，后期在做详细整理。

     燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和 企业主提供工作进展的一个公共视图。这个词常常用于敏捷编程。

    Kane Mar将燃尽图分为以下七种情况：

    1、Fakey-Fakey：表面完美而已。软件项目过于复杂以致于难以界定直观的目标。大多数情况下，这种图来自于充满了命令与控制的环境，在这种环境下，开放的交流变得难以进行。

    2、Late-Learner：燃尽图中会有一个顶峰。通常出现在沟通高效且正在学习 Scrum的团队中。

    3、Middle-Learner：要比late-learner更加成熟。团队在Sprint的中期会探寻出大多数的任务与复杂性。

    4、Early-Learner：开始有一个顶峰，然后是平缓的衰退。团队认识到早期探寻的重要性，然后高效工作以实现目标。

    5、Plateau：团队在一开始取得了很大的进展，但却在Sprint的后半部分丧失了方向。

    6、Never-Never：燃尽图在Sprint的后期突然开始上扬并且不会再下降。需要尽快找到这些迟来的变化并进行自省。

    7、Scope-Increase：Sprint中的工作量突然增加。通常这表明团队在Sprint计划会议上没有完全认清工作范围。

         集中规划，优化交付周期。产品人员尽早的组织研发，测试，敏捷教练一起来集中讨论下下个版本的需求。

         用Wikil来建立过程资产库，记录团队开发经验，

         持续集成，保证每个版本可用，且提交简答。

         度量与流程优化，压缩研发周期，测试周期等。

    关于组织文化

    1.组织文化，可包容的，不只是质量文化，效率文化，还有适合发挥公司资源到极致的各种文化。

      尽量只去做对项目目标有直接影响的事情，要有优化意识，经常去审视别人的代码或者自己的代码，将代码写的简而精，在每个功能完成的时候，都要去考虑哪些代码需要优化。即优化，也是一种企业文化。

     2.对人才，技术和流程制度的完善，包含政策导向，比如员工的政策鼓励，人才储备，成立项目管理训练营，建立公司的资产库。

     3.任职资格管理体系，项目经理培训，干部培训。

    到此，简单结束，将来细细体会。