11.敏捷项目管理——敏捷项目扩展笔记

00.大型项目存在的问题包括日益增加的官僚主义、过多的文案工作、无法管理的通信网络和缺乏灵活性。

 

01.敏捷是一种理念，一种思维方式，而不是一套做法或流程。

 

02.管理技巧变成了创造和控制常量、统一性和效率，而需要变成了协调可变性、复杂性及有效性。

 

03.组织性扩展要素：组织设计、决策设计、协调/协作设计和敏捷文化。

 

04.流程/做法结构包括产品路线图、发布计划和迭代计划。产品功能清单在构想产品、计划体系结果和定义产品需求的过程中产生。

 

05.等级结构图与动态的功能强大信息的信息管理团队几乎没有没有任何关系，相反，他主张了政治议程，等级式的IT基础设施成为政治繁荣和温床，其中团队协作变得非常困难。

 

06.沟通设计之所以困难是因为它取决于一系列关系的基础——信任、尊重和接收文化差异和共享信息。

 

07.协作/沟通做法和工具的两个设计要素是沟通方式的相对的有效性和团队键拥有信任、尊重以及对不同文化理解的基础。

 

08.一套简单的协助指南：

　　*运用各种交互方式

　　*合作做法与交互需求相匹配

　　*尽量使用成本较低的交互方式

　　*对于关键的、高风险活动，采用更有效的协作方式

 

09.交换人比交换文档有效

 

10.如果人们从这样的会议中得不到任何一处，那么这样安排可能错误的。

 

11.决策设计

　　*每个功能和专业团队在完成这那些任务？完成这些人物需要做出那些关键决策？

　　*该决策还会影响到其他什么团队？

　　*受影响的团队是否都需要为决策提供信息？

　　*受影响的团队是否都需要参与决策讨论？

　　*谁应该做决定（功能/专业团队、迭代经理、产品经理、项目经理、项目经理、项目团队一起等）

　　*决策如果应该如何以及向哪些人传达？

　　*谁，如果有那个人，应该评审该决策？

　

12.功能团队原则：如果在实现产品功能时，团队遵循既定规则（比如，按前面所属过程制定有关体系结构的决策），并且的实现似乎不影响其他任何团队，那么该功能团队就授权做有关该功能的任何决策。

 

13.决策小结：

　　团队：体系结构

　　任务：开发应用数据模型

　　*受影响团队，所有功能团队和几个专业团队

　　*提供信息团队，基础团队，挑选几个功能团队

　　*参与讨论：基础团队有两名体系结构团队的兼职成员，来自第N个功能团队的一名高级设计师

　　*决策者：体系结构团队

　　*决策结果传播：给所有团队负责人Email.

　　*决策审核：无

 

14.文档的主要问题在于背景和内容的不同。文档可以承载内容，但要理解其背景却需要专业技术知识。

 

15.文档支持沟通和协作、促进知识传播、保留历史信息、帮助改进产品和满足法律法规的需要。他们并非不重要，仅仅是不如可行的产品版本重要。

 

16.文档不是交互的替代品，复杂情况下，文档本身仅能提供需要了解信息的15%~25%。

 

17.敏捷方法和以文档为中心（或以模型为中心）的方法之间的问题并不是文档过多或者没有文档的问题，而是正确组合文档和交互方式以促进理解和沟通的问题。敏捷主义者倾向于交互方式，而传统方式主义者倾向于文档。

 

18.敏捷主义者淡化的不是文档本身，而是大量的传统文档，人么要么说他们需要但从没有时间开发文档（但认为应该开发），要么他们最初开发了但从不更新所以变得毫无价值的文档。

 

19.敏捷文档的指导原则

　　*根本问题是知识转移——理解而不是文档

　　*知识转移需要人与人的交互，特别在知识复杂性增加时

　　*文档应该刚刚足够，但不能不够，使用概括文档而不是详细文档

　　*高品质且刻度的代码和测试用例，特别当测试用例可以自动实现的时候，或许符合详细文档的需求

　　*模型是一种形式的文档，保持模型轻量级和刚刚足够，紧紧对开发团队有用的模型，和团队一起开发他们

　　*文档应该进可能地非正式——白板、挂图、数码照片，维基等

　　*交互的、动态的文档时对于敏捷项目非常重要

　　*可行的软件是开发目标之一，促使该软件的改进是目标侄儿，考虑用刚刚足够的文档来支持两个目标的实现

　　*文档需求因行业、公司和项目的不同而各异

　　*永久文档是组织愿意花费金钱和时间保存的文档，可行的纸质文档是项目中使用但不保存的文档（可能会非常不正式），不要混淆这两类问昂

　　*用户文档应该和故事一样被确定下来，并由客户团队拍到优先级

 

20.项目经理的职责应该是促进团队间相互交流，而不是参与每个团队产生可交付产品的具体活动。

 

21.交往规则：建立关系、定义做法和制定决策。

 

22.交往规则

　　功能团队

　　*对于影响自身工作的体系结构决策，功能团队可提出自己的意见，并且可以参与决策过程（可能要限制参与表决的团队数量）

　　*有权对任何体系结果变化所带来的影响进行评估，并相应地调整自己的估计方法和进度计划

　　*当团队对某项体系结构决策的否决权置之不理时，有权请求产品和项目经理就该决策进行审核

　　体系结构团队

　　*有权及时得到拟定的体系结构计划的各种信息和反馈

　　*在功能团队实现体系结构决策时遇到问题时，有权及时收到相关的通知

　

23.团队自律

　　*承担团队结果的责任

　　*与其他功能团队协作地交流

　　*在项目自我组织的架构内工作

　　*平衡项目目标与团队目标

 

24.信任与尊重，不仅是个人交互的基础，也是团队交互的基础。

 

25.敏捷是一种平衡艺术——刚刚足够，但不太多。维护可发布产品是一个敏捷原则。

 

26.位于同一地点的项目和分布式项目的根本区别在于建立关系的难度不同。

 

27.分布是敏捷指导原则

　　*敏捷方法不仅使用与分布式项目，而且比传统方法效果更好

　　*无论使用什么方法、分布式团队的问题都是相似的，尤其是在时区、语言、基础设计和文化不同的情况下，建立关系是很困难的

　　*分布式项目的适用原则、做法和工具基本和大型项目相同，主要差异在于组织设计（组织、决策、协作/协调）产生额外的成本为题

　　*分布式项目往往有传统的测试周期

　　*不要把分布式项目中存在的一般问题都归因为敏捷问题，不管使用什么方法，都会产生这样的问题。