导图社区 从传统到敏捷思维导图
从传统软件工程，到敏捷开发，IT行业发生了哪些变化？将来会是怎样的一个发展趋势？点击下图查看。
习惯就是人们长时间养成的生活方式和行为方式，它决定了我们做事的基本方法，有好的习惯的人做事都会有好的结果，而坏习惯的人往往难以成事，因而，人们常说习惯决定命运。这里总结了7个习惯帮助大家成为高效人士。
认知获取的概念 知道一些概念、过程、信息、现象、方法,知道它们大概可以用来解决什么问题,而这些东西过去你都不知道。 结论:认知获取是学习的开始,而非结束。 比如当朋友给我们介绍一位新朋友时,朋友说,这位朋友性格活泼开朗。
国标重点水污染源运维工作日常事项，整理了仪器设置、运维、维修检查的内容，一起来看吧！
社区模板帮助中心，点此进入>>
互联网9大思维
安全教育的重要性
组织架构-单商户商城webAPP 思维导图。
个人日常活动安排思维导图
域控上线
西游记主要人物性格分析
17种头脑风暴法
python思维导图
css
CSS
趋势－从传统到敏捷
趋势：传统项目30年的主流
项目管理管理历史
50年代
80年代
10年代
软件项目管理
项目计划
开发计划
资源计划
测试计划
风险计划
……
WPS工作分解
项目执行和跟踪
进度跟踪
度量：工作量投入，产出
变更
项目结项和总结
度量
评价
趋势：90年代，兴盛的IT行业
企业信息化和IT企业
创造和使用信息
企业人对企业人
信息的价值
效率/时间/投入产出比
软件产业化之路
从作坊到车间
从游击队到军团
大规模集成开发
专业化分工
矩阵结构组织
趋势：00年代，IT到底是什么
IT不是行业
IT是一种普及技术
提供什么服务比利用什么技术更重要
谁来买单决定了生产方式
人类使用信息的方式改变
更多的产品、更多的服务
实体经济到注意力经济
越来越短的等待周期
比质量更重要的是速度
互联网企业和软件企业
工具供应商和服务供应商
谁来买单
信息的创造和消费者
社会人对社会人
消费
【3G四字经】智能手机，应用重要。分类介绍，找准目标。白领办公，蓝领研讨。少年听歌，成年网炒。帅哥网游，美女米聊。老公微博，老婆淘宝。公公看戏，婆婆财道。学生学习，老师辅导。懒人听书，天气预报。相声小品，琴棋茶道。收听广播，幽默搞笑。玩转应用，轻松营销！
趋势：自组织项目非主流的20年
敏捷的历史事件
前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对银弹的生存周期进行过令人愉快的描述。银弹的生存周期是这样一个过程：发现→成功应用→对成功的宣传→要素的建立和公布→首次（轻微的修改）重复运用→早期采用者的证实→无知的中层管理者在迥然不同的环境中对其进行过程化和实施→资金不足以及误用→由于最初思想的退化导致回报逐步变少→最终被丢弃并开始新的发现
