敏捷史话读书笔记5-13章

第五章
【敏捷是什么】
专注于个体对敏捷实践的思考，而不是照搬敏捷专家的说法
敏捷需要严格的纪律来约束团队。
设计编码流程等尽可能简单小步快跑持续反馈。
敏捷实践需要多操练因时而变，让敏捷成为一种习惯。
【I am a programmer】
《程序员修炼之道》Dave Thomas 和Andy Hunt
【不要让自己成为一个标签】
标签理论：标签是一个名词，表明了你是做什么的，却限制了你如何去做。
把标签改成一种解决方案创造更多的可能性
《程序员修炼之道》第二版
所有值得做的事情都是困难的，但克服这些挑战不仅会让你更强大，还会让你变得更加投入。
能够改变世界的人，首先改变的是自己。让自己不只是具备广泛的能力，还能将不同的技术结合起来创造价值。
Robert C. Martin aka UncleBob
敏捷不是项目管理方法，而是一套价值观和纪律，可以帮助相对较小的团队构建中小型产品。
【瀑布开发之旅】
代码的整洁是需要引起重视的。软件质量不仅依赖软件架构及项目管理，还与代码质量紧密相关。
将瀑布模型和代码整洁结合，但进入开发阶段，事情不可控。
【敏捷开发的萌芽】
极限编程（XP），测试驱动开发（Test-Driven Development,TDD）
《代码整洁之道》代码首先要能读懂，其次才去要求功能实现。
一个观点：工作保证速度与质量的唯一方法就是尽可能地保持代码整洁。
【贯彻[匠艺精神]】
对[代码整洁]进行扩充。成功的秘诀在于用很多小团队解决很多小问题，需要每个程序员具备[匠艺精神]。
什么是[匠艺精神]？基于把事情做好的渴望，来提供专业的服务。
软件匠艺(Software Craftmanship)
《敏捷整洁之道：回归本源》
敏捷和匠艺都是为了交付高质量有价值的工作。
Martin Fowler
如何从复杂的局势中找出最简洁、直观的破局之法。
【重构】
由于软件需要不断地修复Bug并添加新特性，这会让原本的代码库变得繁杂，导致之后的工作进度越来越缓慢。
更改逐渐叠加的情况，可以重构代码减少不必要的复杂性。
重构并不是出现在项目计划中的一项特殊任务，而应该是编程活动中的一个常规部分。
【《敏捷宣言》】
轻量 方法论
【Bliki的诞生】
Bliki是Blog+wiki 简短的想法，建立一个交叉链接的主体。
Alistair Cockburn
守 破 离
【守】
做事，需要一个做法的步骤清单，告知怎么做。正确的方法，只要按照方法去做，就能做好。
【破】
不满足于按照清单去做，需要不同的处方，做出不同的效果。
水晶方法 六边形架构
【离】
可以根据方法来做，但即使没有方法，我们也知道怎么做。
敏捷的核心是简化信息提示，以便更好地专注于实现出色的结果。
Jon Kern
【UML/MDA】
UML（Unified Modeling Language, 统一建模语言）
软件开发中，要确保团队提升的是[频繁的、切实的工作成果]，而不是无限趋近于完成但始终没有完成的开发过程。
MDA（Model Driven Architecture，模型驱动体系架构）
基于组件的开发、设计模式、中间件、说明性约束、抽象、多层系统、企业应用整合以及契约式设计。
MDA提高文档编制的便利性。
【Agile UML/MDA】
细节是一项至关重要的因素。从长远角度看问题，善于发现细节，促使团队或公司完善每一个细节，从而推动业务成功。
Stephen J. Mellor
敏捷和建模 前期大规模设计
模型是可运行的。建模要被广泛认为是可执行的。
建模者能从实施敏捷的人身上学到许多，例如尽早为模型构建测试；遵循敏捷过程的人，也能从提高生产率以及轻松地跟客户沟通
过程中受益。
永远不要相信你最近创建的系统是唯一的，应设法寻找不同方法来解决相同类型的问题。
Ron Jeffries
远离人造敏捷，回归敏捷本质。
【Dark Scrum】
XP目的是让程序员的生存环境变得更安全一些。
人造敏捷和黑暗敏捷不能改善开发人员的生活，而是敏捷宣言最初思想的对立面。
人造敏捷对企业有利，对开发人员不利。开发人员不具有自主性而是被强制性工作。
每周产出可运行的集成软件；不断提升自身技能；保持软件设计干净；在软件价值的基础上进行沟通对话。
【敏捷之外】
《Extreme Programming Installed》《软件开发本质论》
惠及程序员、提高效率、产出价值才是敏捷的本质。
Kent Beck
每六个月汇报一次对企业的影响，每个人都专注于自己正在做的事，保证每个人对公司有所贡献。
【极限编程的诞生】
适合重构环境的软件开发方法《规划极限编程》《测试驱动开发》
【JUnit的诞生】
java测试驱动开发。务实的理想主义。现实和理想往往是比较矛盾的，但是在充满竞争和变化的现代社会，这种矛盾却无处不在。
需要一个理想的目标。