关键词：
第6章 敏捷流程
本章主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论。以及什么时候选择敏捷的开发方法，什么时候选择其他方法。
1.敏捷的流程
定义：“敏捷流程”是一系列价值观和方法论的集合。
|
现有的做法 |
敏捷的做法 |
|
流程和工具 |
个人和交流 |
|
完备的文档 |
可用的软件 |
|
为合同谈判 |
与客户合作 |
|
执行原定计划 |
响应变化 |
2.敏捷开发原则
- 尽早并持续地交付有价值的软件以满足顾客需求
- 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
- 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
- 业务人员和开发人员在项目开发过程中应该每天共同工作
- 以有进取心的人为项目核心，充分支持信任他们
- 无论团队内外，面对面的交流始终是最有效的沟通方式
- 可用的软件是衡量项目进展的主要指标
- 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
- 只有不断关注技术和设计，才能越来越敏捷
- 保持简明—尽可能简化工作量的技艺—极为重要
- 只有能自我管理的团队才能创造优秀的架构、需求和设计
- 时时总结如何提高团队效率，并付诸行动
3.敏捷的步骤
1.找出完成产品需要做的事情—Product Backlog
2.决定当前的冲刺需要解决的事情—Sprint Backlog
3.冲刺
4.得到软件的一个增量版本，发布给用户
4.如何成为敏捷的团队？
1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3. 多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
5.敏捷流程的经验教训
- 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
- Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
- 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。
- 在复杂的项目里，要让一线团队成员做决定。
- 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。
- 在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
- 不要和管理层谈“流程”，他们只关心“结果”。
- 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。
6.敏捷的试用范围
|
客观因素/ 最适用方式 |
敏捷(Agile) |
计划驱动(Plan-driven) |
形式化的开发方法(Formal Method) |
|
产品可靠性要求 |
不高，容忍经常出错 |
必须有较高可靠性 |
有极高的可靠性和质量要求 |
|
需要变化 |
经常变化 |
不经常变化 |
固定的需求没需求可以建模 |
|
团队人员数量 |
不多 |
较多 |
不多 |
|
人员经验 |
有资深程序员带队 |
以中层技术人员为主 |
资深专家 |
|
公司文化 |
鼓励变化，行业充满变数 |
崇尚秩序，按时交付 |
精益求精 |
|
实际例子 |
写一个微博网站 |
开发下一版本的办公软件；给商业用户开发软件 |
开发底层正则表达式解析模块；科学计算；复杂系统的核心组件 |
|
用错方式的后果 |
用敏捷的方法开发登月火箭控制程序，前N批宇航员都挂了 |
用敏捷方法，商业用户未必受得了两周一次更新的频率 |
敏捷方法的大部分招数都和这类用户无关，用户关心的是：把可靠性提高到99.999% ,不要让微笑的错误把系统搞崩溃 |
构建之法（第六章敏捷流程）
第六章主要讲了 1.1敏捷流程及其原则，Backlog,Burn-down,Sprint,Scrum方法论 1.2什么时候选择敏捷的开发方法，什么时候选择其他方法。 1.敏捷的流程：“敏捷流程”是一系列价值观和方法的集合。 1.1敏捷... 查看详情
《构建之法》第六章自习感想与知识点
本章的学习主要讲的是敏捷流程。敏捷流程从字面上来看敏捷就是快速的，同时透露出一种年轻化的感觉的流程。但在深入的学习了之后才发现要快速的完成有价值的软件并交付给客户是有很大的学问在里面的。同时，也不是所... 查看详情
构建之法第六章
构建之法第六章本章为敏捷流程，主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论，各种软件开发方法论的优缺点，，选择软件流程根据等敏捷开发：是一系列价值观和方法论的集合敏捷开发的原则：1、尽早... 查看详情
构建之法第六章敏捷流程
敏捷是一种很“年轻态”的思路/策略，是以“万事万物都在不停地发展变化”为指导去组织软件工程的需求分析、内部的调和、代码编写甚至维护，所以我读起来会觉得很有共鸣。然而并不是所有的地方都适合让“敏捷”去闯... 查看详情
构建之法学习
本周学习的是第六章——敏捷流程在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。从2001年开始，一些软件界的专家开始倡导“敏捷”的价值观和流程，他们肯定了流行做法的价值，但是强调敏捷的做法更... 查看详情
构建之法第四次心得
第六章学习了之前的内容之后，我了解到了团队合作的流程以及在编码时候一些格式的注意，在学习第六章后，对敏捷流程有了大致的了解。敏捷流程是一种很好的软件开发的流程，我认为在软件开发时，敏捷开发可以使得软件... 查看详情
《构建之法》第六章读书笔记
一、敏捷的流程简介敏捷开发的原则是：1、尽早并持续地交付有价值的软件以满足顾客需求2、敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势3、经常发布可用的软件，发布间隔可以从几周到几个月，能短则短... 查看详情
构建之法六章读后感
在本周我主要学习了构建之法的第五章和第六章，第五章主要讲述团队和流程，第六章主要讲述敏捷流程；软件团队的模式有：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐... 查看详情
构建之法：第四次心得
这周的构建之法学习了第六章、第七章和第八章，主要对项目的制作，项目的出发有了一定的了解。第六章这一章主要学习了敏捷流程的相关内容。在现在的软件企业，大多默认流行做法的价值，较偏于墨守成规，按照章程办事... 查看详情
《构建之法》第四次随笔
《构建之法》第四次随笔这半个月我阅读了《构建之法》第六章，第七章，第八章。 第六章主要讲的是敏捷流程。敏捷流程是一系列价值观和方法论的集合。敏捷对团队的要求很简单：自主管理，自我组织，多功能型。但是... 查看详情
构建之法第六七八章
第六章敏捷流程敏捷流程开发原则1.尽早并持续的交付有价值的软件以满足顾客需求2.敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势3.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短4.业务人员... 查看详情
四渎《构建之法》——计划估计敏捷流程项目经理和用户场景
本周再次打开《构建之法》，这次我阅读时重点在于学习敏捷流程、项目经理和用户场景等相对较为宏观的内容。第六章开篇即简单地介绍了敏捷开发的流程：ProductBacklog—>SprintBacklog—>Sprint—>软件的增量发布。同时提出... 查看详情
20171104-构建之法：现代软件工程-阅读笔记3
本周阅读了《构建之法》第六章。第六章讲了敏捷流程的相关知识看了第六章了解到敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个... 查看详情
构建之法小结六
本周阅读了第六章，主要了解了敏捷流程。敏捷流程是指价值观和方法论的集合。本章详细介绍了敏捷流程的流程、流程的问题和解法等。该流程强调快速反馈，从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。... 查看详情
《构建之法》4
第六章，讲的是敏捷流程。主要的内容是敏捷流程及其原则，方法论，以及各种软件开发论的优缺点，选择软件流程的根据。在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。敏捷开发的原则：1、尽早并持... 查看详情
第四周读书笔记《构建之法》(代码片段)
第四周读书笔记《构建之法》#wmd-previewh1color:#0077bb 第四周读书笔记《构建之法》沈三景PB15061249软件工程读书笔记 前言本周接着读了构建之法（上周读了《程序员的修炼之道》）的第六、七两个章节。 第六章敏... 查看详情
构建之法第六，七章
第六章敏捷流程敏捷是一种态度，而不是一个说明性的过程。它不能解决问题，但可以用于优化解决问题的过程。我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。即使到了开发后期，也欢迎改... 查看详情
构建之法——读书笔记
第六章敏捷流程在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。敏捷开发的原则： 1.尽早并持续地交付有价值的软件以满足顾客需求。 &nbs... 查看详情