导图社区 善思善知善行
善思善知善行包括了scrum应用和扩展思考、组织及改进、scrum框架介绍、敏捷是必然的选择和项目管理的故事这几个部分。
社区模板帮助中心，点此进入>>
项目时间管理6大步骤
互联网9大思维
项目管理的五个步骤
电商部人员工作结构
组织架构-单商户商城webAPP 思维导图。
暮尚正常运转导图
域控上线
产品经理如何做好项目管理
车队管理
python思维导图
善思善知善行
项目管理故事
项目管理管理历史
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(增量)
可将交付的功能“增量”
必须定义好“完成”的标准
组织级改进
管理者的顾虑
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对银弹的生存周期进行过令人愉快的描述。银弹的生存周期是这样一个过程：发现→成功应用→对成功的宣传→要素的建立和公布→首次（轻微的修改）重复运用→早期采用者的证实→无知的中层管理者在迥然不同的环境中对其进行过程化和实施→资金不足以及误用→由于最初思想的退化导致回报逐步变少→最终被丢弃并开始新的发现
scrum应用和扩展思考
更多主题应用
便利贴里乾坤大
扑克牌底说因缘
今日方知不为迟
前排是猪，后排是鸡
Scrum分析实践
Scrum评估
Scrum趋势行情
