如何阅读一本书

无论是电子阅读还是纸质阅读都需要一定的方法，这篇导图将从阅读的活力与艺术、阅读的层次阅读不同读物的方法为您提供了怎样阅读的方式，其中当您了解到阅读的层次时一定会获得新的学识

Scrum

• 项目管理故事
  • 项目管理管理历史
    • 50年代
    • 80年代
    • 10年代
  • 软件项目管理
    • 项目计划
      • 开发计划
      • 资源计划
      • 测试计划
      • 风险计划
      • ……
      • WPS工作分解
    • 项目执行和跟踪
      • 进度跟踪
      • 度量：工作量投入，产出
      • 变更
    • 项目结项和总结
      • 度量
      • 评价
  • 项目团队的要素以及选择
    • 目标（purpose）
      • 宏伟的蓝图？
      • 可执行的交付件？
    • 人（People）
      • 懂规矩？
      • 有经验？
    • 定位（Place）
      • 多层次的行政团队？
      • 扁平的专项执行团队？
    • 权限(Power)
      • Leader集中权利强力驱动？
      • 高度默契自驱动？
    • 计划(Plan)
      • 满足领导需求，全面完整的计划？
      • 只计划我们知道的，80％的计划
• 敏捷是必然选择
  • 敏捷的历史事件
    • 前30年
    • 前10年
    • 后10年
  • 同时代的历史故事
    • 互联网的兴盛
      • 电子邮件
      • dotcom经济
      • 搜索引擎
    • 互联网的泡沫
  • 人类使用信息的方式改变
    • 更多的产品、更多的服务
    • 实体经济到注意力经济
    • 越来越短的等待周期
    • 比质量更重要的是速度
  • 只能是敏捷
• Scrum框架介绍
  • 基于经验主义－经验性过程控制理论
  • 角色
    • PO
    • DevlopmentTeam
      • 弱分工
      • 不包含业务分析、测试等特定领域工作者
    • Scrum Master
  • 事件
    • Sprint
    • Sprint计划会
    • 每日立会
      • 关键的检验和适应会议
      • 不是汇报
      • 而是为了增量交付
    • Sprint评审
    • Sprint反思
  • 工件
    • Product Backlog
    • Sprint Backlog
    • Increment(增量)
      • 可将交付的功能“增量”
      • 必须定义好“完成”的标准
• Scrum应用和扩展思考
  • 更多主题应用
    • 便利贴里乾坤大
    • 扑克牌底说因缘
    • 今日方知不为迟
    • 前排是猪，后排是鸡
  • Scrum分析实践
    • Scrum评估
    • Scrum趋势行情
• 组织级改进
  • 管理者的顾虑
    • 1、管理者还能控制敏捷团队吗？
      • 管理层在敏捷中仍然具备指挥权。如果管理层当前的管理风格是面面俱到，事无巨细的命令和控制，那么引入敏捷时，需要作出变化，转而抓大放小，转向高层次的指导，采用服务型管理方式。总之，敏捷团队仍然需要管理层的指导，但不需要过于细节的、命令式的指导。
    • 2、项目经理会不会不再重要了？
      • 而实际上目前还没有哪个体系的敏捷方法在正式的文字中宣称“不能对敏捷团队中个人进行绩效考核”。之所以口口相传，最大可能原因是敏捷方法被程序员类技术人员（包括敏捷的最早先行者们）率先采纳接受并倡导，在目前敏捷界，这样的群体发出了较大的声音。 职场的事实是“对个人的评价在组织中不可避免”。其中最无法避免的个人评价是如何挑选员工晋升？满足条件就能晋升？满足条件本身的判断就是判断个人，晋升的机会永远是少的、但又是必然有的，而且在时机充满了不确定性：有时是有人突然离职，有时是业务扩充。其次是优秀员工评选、加薪等等。 所以刚开始采用敏捷，个人绩效考核方面完全可以基于组织自身的历史来处理，没有必要在敏捷引入开始时就一定要想办法调整个人绩效考核办法。随着敏捷实践的开展，基于组织的发展实际，寻求更好的个人绩效评价办法。不排除达到“不进行个人绩效考核而各方共赢”的效果。所以管理层不必因为此而害怕敏捷。
    • 3、敏捷团队享有太多特殊待遇？
      • 其它考察团队整体的老方法同样适用于敏捷团队绩效考核，比如用户反馈调查（用户反馈调查的可能带来误差，这是用户反馈调查本身的问题，不是敏捷团队绩效考核的问题）。因此敏捷团队的横向比较是有办法的。 敏捷团队的横向比较也是有必要的。在组织内营造积极的竞争氛围是有利的，这早已被证明，也被大量的组织采用。对于敏捷团队，正因为团队不能简单地显示可比的开发效率，管理层难免会有疑问：他们这个迭代计划的工作是否充实，哪些用户故事真的需要这么多工作量吗？所以敏捷团队的横向比较机制能够让敏捷团队向更好的结果努力，管理层也会打消团队磨洋工的疑虑。
    • 4、没有文档，维护代价是否巨大？
      • 那么是不是说引入 Scrum 后，再来取消项目经理，安排牧羊犬式的 Scrum Master，并来倡导并建设自组织的团队？ 笔者认为未必有这个必要，因为：1、继承项目经理制度，Scrum Master 可以就是项目经理，Scrum Master 是带领 Scrum 成功的领头羊；2、完全的团队自我管理在职场（以劳动换取报酬）是不可行的。（参考文献 10） 总之，项目经理制度已经很成熟了，引入敏捷时（哪怕是引入 Scrum）没有必要撤销项目经理。
    • 5、组织文化和团队是否会格格不入？
      • 文档的价值在于信息传递。但事实上，文字的靠谱程度有些时候甚至比图示还要糟糕。 显然，如果我们的目标是让任何一个新员工都可以快速的在Team内展开合作，那么我们一定会安排合适的方法传承重要的信息。比如用更多更容易阅读的低保真原型，或者更多的业务流程图，我们完全可以把这些做为重要的任务项。
  • Scrum价值观
    • 承诺：乐于对目标做出承诺。Scrum为人们提供实现承诺所需的所有权限。 专注：做自己的工作。把所有精力和技巧专注于你所承诺的工作上。不用担心其他事情。 开放：Scrum中与项目相关的每件事对所有人都是可见的。 尊重：背景和经验塑造出不同的个体。对团队中不同的人保持尊重非常重要。 勇气：有承诺的勇气、行动的勇气、开放的勇气和期望得到尊重的勇气（Schwaber和Beedle 2001）。 如果你不使用Scrum，但认为这些价值观会带来益处，不引用Scrum这个词即可。（甚至不需要说明它们来自Scrum。）对于软件开发团队，也可以用极限编程的价值观来代替或补充说明Scrum价值观。这些价值观的定义有一个前提，那就是团队在整个软件开发过程中已经在应用极限编程的实践。 沟通：利用许多实践可以保持畅通的正确沟通，而这些实践必须通过沟通才能完成。项目中的问题总是能追溯至同一根源，那就是大家没有沟通好一些重要的事情。 简单：什么是最简单可行的事？打个赌，今天做件简单的事情明天再稍微改进一下，要比今天做件较复杂的、日后也许再也不会用到的事情要好。 反馈：对系统当前状态的具体反馈绝对是无价的。乐观是编程人员的职业病，而反馈则是解药。 勇气：有勇气去开发优良的软件，开发这样的软件也许意味着扔掉现有代码、改变方向甚至是延迟开发周期。不是说任何时候都别自己走入死角么？勇气（Beck和Andres 2004）。 如果这些价值观都不适用且你的公司已有一套有效的价值观，那就用那些已有的价值观。关键在于：必须定义出你要使用的价值观，要与敏捷相关、易于理解（不要满是抽象概念或商业术语）且能引起共鸣。只选用那些能激发团队成员渴望感的价值观。当团队成员仔细琢磨这些定义并说道：“是的，这就是我希望自己做到的，希望我们都可以做到，希望我们公司能够做到”，那就说明你们有一套不错的价值观了。
  • 培训和支持
    • 敏捷俱乐部
  • 敏捷实践升级
    • Scrum Of Scrums
    • 敏捷能力模型&敏捷评估
  • 没有银弹
    • 当我们发现某样东西有效时，就很容易认为它普遍适用。这正是银弹的特性，软件生产力联盟的Sarah Sheard对银弹的生存周期进行过令人愉快的描述。银弹的生存周期是这样一个过程：发现→成功应用→对成功的宣传→要素的建立和公布→首次（轻微的修改）重复运用→早期采用者的证实→无知的中层管理者在迥然不同的环境中对其进行过程化和实施→资金不足以及误用→由于最初思想的退化导致回报逐步变少→最终被丢弃并开始新的发现