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

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

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

一晃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.任职资格管理体系，项目经理培训，干部培训。

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

敏捷开发一千零一夜读书笔记之敏捷初探相关推荐

敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）...
这是敏捷开发绩效管理的第六篇.(之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很"程序员".如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统 ...
敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）...
这是敏捷开发绩效管理的第七篇.(之一,之二,之三,之四,之五,之六,之七) 续前文-- 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够. 谁能在刚拿出2页 ...
敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算）
这是敏捷开发绩效管理的第五篇.(之一,之二,之三,之四,之五,之六,之七) 度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容. ...
从持续交付看敏捷开发的自相似性（敏捷开发的心跳）
作者:陈勇出处:blog.csdn.net/cheny_com 自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性. 从大的方面看,敏捷开发具有重视客户价值,提倡持续交付等思想.但一般而言, ...
iPhone与iPad开发实战读书笔记
iPhone开发一些读书笔记手机应用分类 1.教育工具 2.生活工具 3.社交应用 4.定位工具 5.游戏 6.报纸和杂志的阅读器 7.移动办公应用 8.财经工具 9.手机购物应用 10.风景区相关 ...
JAVA WEB整合开发王者归来 -- 读书笔记 by CZF 完整版
JAVA WEB整合开发王者归来 -- 读书笔记目录第1章概述. 1 第2章搭建web开发环境. 1 第3章 Servlet技术. 1 第4章深入JSP技术. 7 第5章会话跟踪. 12 ...
javascript设计模式(javascript设计模式与开发实践读书笔记)
javascript设计模式(javascript设计模式与开发实践读书笔记) 单例模式策略模式代理模式迭代器模式发布-订阅模式命令模式组合模式模板方法模式享元模式职责链模式中介者 ...
《HTML5 Canvas核心技术图形、动画与游戏开发》读书笔记
<HTML5 Canvas核心技术图形.动画与游戏开发> 读书笔记文章目录 <HTML5 Canvas核心技术图形.动画与游戏开发> 读书笔记第1章基础知识第2章 ...
《Scrum敏捷游戏开发》读书笔记
第一章:业界状态游戏行业三大危机:创作保守,内容缩水,加班繁重第二章:敏捷开发大型游戏项目特点:开发过程中容易产生'新增特性',任务复杂度高>评估准确性低,demo阶段不确定性高.---- ...

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

敏捷开发一千零一夜读书笔记之敏捷初探相关推荐

最新文章

热门文章