敏捷与精益
近期读了2本关于敏捷开发的书, 《敏捷开发一千零一夜》和《精益开发实战》.
回想起以前读过的所有关于敏捷和精益的书,感触良多。
一千零一夜的第六章:”从敏捷到精益” 和第十一章：“敏捷无它，持续改进” 于我的共鸣是最多的。
Do Right Thing vs. Do Thing Right
如果没有在做：“正确的事情”，越是“正确地做事”，就越是错的多，因为他们浪费就更多。
只有敏捷是不够的
敏捷不是银弹，其实这个世界很残酷，并不是掌握了什么就能一帆风顺的。
掌握知识是很重要，何时用，怎么用，对于每个人来说都不可能像看着菜谱煮菜那么简单。
只有Scrum是不行的，如果只有Scrum。
单单靠敏捷是不够的，结合精益能够增加多些成功的机会。
TDD的精神
TDD是XP的基础,也是敏捷的基础,同时TDD的精神也是精益创业的基础.
测试驱动,快速得到反馈,迅速做出调整就是TDD的精神.
基本步骤:
- 提出需要验证的前提假设
- 建立观测数据指标
- 开发最小可行产品
- 收集数据验证假设
我把TDD当做程序员的分水岭,TDD不只是关于测试,更是关于设计.
道与术
技术牛人有两种, 精通”道”的与精通”术”的.
道是形而上的,是关于抽象的能力.
术是形而下的,是关于具象的能力.
面向对象设计的能力,TDD的能力都是关于”道”的.
熟练掌握各种工具和语言的, 则是”术”上的高人.
好的程序员是 “道” “术”双修的. :)
架构
Uncle Bob大叔 : 架构无非是设计中不可逆的部分.
Martin Folwer : 架构师有2种: 传统的架构师,非常厉害的做了很多"大"的设计（架构），他的设计可逆性很差，尽管合情合理。另外一种架构师尽量增强可逆性，哪怕是很大的设计。
架构师做2件事： 建立架构，消灭架构。
You are what you do 。
裸奔的领域模型
用户不关心你的“解决方案”，用户关心他们的“问题”。
领域层封装客户的业务需求,日常业务规则,我们开发软件的目的就是解决他们的需求.
UI是可变的,存储逻辑也是可以换掉的,业务逻辑才是我们的核心。
所以领域模型必须裸奔，不依赖其它层。
通过IOC或者六边形架构可以解决依赖的问题。
问题与解决方案 ，5个why
很多开发团队非常容易犯的错误，他们激烈的讨论某一个技术问题如何实现，却不知道背后的用户逻辑。
问题和解决方案是一对多的。
不要沉溺于技术问题，要时时记得用户的问题。
Scrum里的User Story背后就隐藏这样的智慧：
As a （who），
i want （what），
in orderto （why）
最后的why就是用于描述用户的问题或者业务需求。
估算的过程很有帮助，估算的结果往往没有。
团队估算是为了打破鸿沟，它会把团队成员的假想暴露出来，通过暴露假想来发现更多的问题。
觉得浪费时间，让一个人去做这些事情，完成估算，拆好任务，贴在板上，完毕？
呵呵。