2010敏捷大会简单总结及记录

敏捷总结个人思考：

1， 敏捷不是问题本身， 是解决问题的方法， 只要是方法就有其适用性， 实践的时候最重要的是明白自己的问题所在，然后采用敏捷中适当的方法或思想去优化， 明确的目标，是实践敏捷的前提，避免为了敏捷而敏捷

2， 敏捷的启动需要一定的基础工作，大家需要了解敏捷，对敏捷的实践有信心和热情， 团队的参与度和开放的环境是一个团队实践敏捷的基础， 在这个基础上去建立大家的愿景， 挖掘创新的思想， 制定工作的计划。

3， 避免控制和命令，寻求支持和合作，前者应该是master需要注意的东西， 后者是所有成员的定位， 作为一个团队成员集体协作，并作出承诺， 提高一个团队的凝聚力和目标感

4， 具体每个环节如反馈，风险分析，本质上是加强交流，风险前移

5， 问题的描述可衡量，一方面是提高对问题的认识，另一方面是目标明确，可估算， 不容易导致任务结束后无法衡量的结果

6， 持续化，是如何去持续实践的问题，其实是如何去持续改进的问题， 敏捷不是一个模式，不同的组织会有不同的背景， 而且是不断动态变化的，需要一个build一个build的去不断实践， 强行推广某个模式从来就是一个模式的悲哀所在， 没有什么模式是完美无缺的， 所以持续化不是坚持敏捷模式，而是坚持敏捷的思想去不断改进

7， 估算不准导致任务的不可预测性；估算任务有三部分， 任务本身，人， 其他环节， 风险四种因素； 任务本身工作量是固定的， 其他环节如独立的质量活动需要独立估算（这个容易忽视，认为质量环节是任务的一部分， 这是不合理的，也是这类活动效果甚微的原因）， 人（不同人的状态和情况会影响实际的估算结果）， 风险（对于会议，其他活动的时间需要排除）； 对于任务估算不准确的原因或导致加班的原因，往往是对于上面的一些环节粗放的都合并为一个估算，或根本没有考虑， 缺乏理论或经验的指导。

8， 人的因素， 如何让团队的所有人能成长并快乐， 首先要了解团队成员的期望和性格（游戏或活动的方式？面谈？）， 然后结合项目去分析，平衡， 达到团队和个人的双赢9， 文档的缺失导致业务的流失不是敏捷的问题， 是组织的问题， 如何去看待文档及平衡这个环节的价值，不同组织有不同的定位，代码和文档是有各自的价值的， 用代码代替文档个人认为是一种乌托邦的想法。

10， 技术债务， 重构这个事情怎么去做，谁去做，什么时间去做，都是值得思考的问题， 如果没有计划，最后就会形成技术债务，暂时没有想法（理想状况就是人们总是无声无息的自觉的把这些事情做了）项目组的问题：1， 估算常常还是不准确， 应对思考： 估算需要更加细致的分析，寻求理论的指导，实现任务的可预测2， 文档的缺失，应对思考： 如何去建立一个文档的系统及维护，这个文档系统的目标是什么， 还需要仔细思考下3， 技术债务，应对思考： 开发人员在每次做新任务的时候，分析是否需要重构， 估算到任务里， 避免债务的累积。

 

附：讲座的内容：

1， Aglie不是问题本身

2， 实践敏捷需要有目标性

3， 如何做事？

4， 敏捷的实践分三阶段： 启动， 过程， 持续化启动

A， 改进的文化， 可预测性， 团队的参与度， 创造， 新的可能， 愿景

B， 上下同心， 组织的推动， 高层的支持

C， 计划的重要性， 做事的方式， 计划的及时通告， 计划的层次（每天，每周。。。）

D， 有指导的执行计划， 忌照搬书本， 员工培训， 工作的循环过程

E， 避免控制和命令， 寻求支持与合作

F， 团队融为一体， 团队承诺， 集体协作， 避免个人主义

G， 反馈的及时性， 每日风险分析控制， 测试前移， 持续交付

H， 可衡量， 描述的准确性， 可交流可读， 以产品为标准持续化I， 持续学习的文化， 定期反馈， 知识的流动和组织化J，架构的变化， 热情，组织的发展K， 耐心坚持

5， 不同角色的幸福感与项目的价值 的平衡认可 性格的区分， 展现机会创造（游戏）技术 结对（信任感，效率， open）， 能力提升目标（个人差异），持续学习心态 快乐成长日记6， 流程功能演示， 总结（最想重做的事情，最有价值的事情）任务估算（资源）任务愿景， 多人估算+单元测试独立估算+技术难点资源分配系数能力成长系数

7， 中型团队问题：

A，文档少，业务知识流失

B， 技术债务， 简单设计（review和重构）

C， 跨部门的协调， 不同任务的优先级解决方案：协调小组（协调整体规划，公共资源规划， 组织活动， 新技术研究）敏捷环节的性价比考核：反馈问题