敏捷四大宣言
1)“个体和互动”更优于“流程和工具”
;
2)“工作的软件”更优于“详尽的文档”
;
3)“客户合作”更优于“合同谈判”
;
4)“相应变化”更优于“遵循计划”
。
敏捷十二个准则
1)通过尽早和持续地交付有价值的软件来满足客户。
2)欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
3)要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
4)项目过程中,业务人员与开发人员必须在一起工作。
5)要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
6)无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
7)可用的软件是衡量进度的主要指标。
8)敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9)对技术的精益求精以及对设计的不断完善将提升敏捷性。
10)要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
11)最佳的架构、需求和设计出自于自组织的团队。
12)团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
SCRUM 的团队角色
产品负责人(Product
Owner)负责的事情主要是:
1)提供远景;
2)提供边界;
3)提供用户故事的优先级。
Scrum Master [SCRUM
教练、敏捷教练]
1)没有行政权力。例如:你不能决定项目团队某成员薪金或奖金,你无权说:你
被解雇了。
2)你要忍住帮团队做决定的冲动,让团队学会自我成长。
3)不建议你同时兼任产品负责人。产品负责人需要做不少重要的决定,这其实与
Scrum Master
角色冲突,一个人同时做两种角色的事情,容易搞混了角色,当然你是超
人能分得很清楚的话例外。
开发团队
开发团队如果没有项目经理这样的角色来协调和指挥,很可能会成为“乌合之众” ,无法谈得上敏捷。
敏捷最佳实践
需求方面最佳实践:
1)User Story(客户故事)
2)客户全程参与
设计方面的最佳实践:
3)简单设计
测试方面最佳实践:
4)测试驱动开发(TDD)
5)自动化测试
编码方面最佳实践:
6)重构
7)结对编程
8)代码共有
9)强调编码规范
10)持续集成(每日构建)
项目管理方面最佳实践:
11)Sprint(冲刺)
、小版本发布
12)每日站立会议、每日晨会
13)每周工作
40 小时
14)Burn Down
Chart(燃尽图)
15)Lesson
Learned
16)隐喻
<体验极限编程>
中国软件项目的一个大特点,就是“两大限死,两不确定”
!
限死 1:预算限死。
限死 2:工期限死。
不确定
1:需求不确定.
不确定
2:技术不确定.
*.IT项目求生法则
挨踢项目求生法则
敏捷不能当饭吃
机构设置
组织机构设置
组成项目部
矩阵式管理
弱矩阵:各人以部门职责为主,各人做好自己的事情就可以了,各人主要对部门经理
负责。
强矩阵:各人以项目利益为主,不仅仅完成本岗位的工作,还需要跨职能地工作,
只
要对项目成功有意义的事情,都鼓励项目组成员去完成,各人对项目成败直接负责。
弱矩阵:
1)流水线生产,适用于稳定的项目或产品。
2)每个人完成自己的工作职责,对岗位负责。
强矩阵:
1)适用于高难度、高挑战的项目或产品。
2)每个人都对项目成败负责。
3)每个人除了完成本职工作,还需要跨职能地工作。
敏捷对团队文化是有要求的,就是:我们要在一条船上!
敏捷更多是一种精神层面上的要求, 是一种精神文明,
但精神文明是建立在一定物质
文明的基础上的。
员工得不到尊重, 员工的生活得不到保障, 温饱不解决, 你跟我谈敏捷,
就是扯淡!
敏捷是精神文明
保证物质文明
敏捷的核心基础:我们在一条船上!包括:
1)项目组所有人在一条船上。
2)员工和公司在一条船上。
敏捷的几个重要特征:
1)所有人对项目成功负责。
2)所有人直接需求驱动地工作。
3)所有人都需要跨领域地工作。
4)持续交付、迭代前进。
原文地址:http://www.cnblogs.com/cube/p/3708793.html