敏捷实践

本文不是描述敏捷的文章，也不是用来褒扬敏捷的文章。记录了这一年来在敏捷实践中的一些东西。这些东西不一定是符合教科书的，仅仅是我们的一些实践。

沟通¶

作为技术人员，我们的交付者是产品人员，与产品人员沟通很重要。往往产品人品就是一份产品文档. 而且会提前发给技术, 那么在仔细阅读了产品文档后, 需要做的事情就是沟通。在沟通的过程中要注意： - 不能急，很多产品不懂得技术，所以，对于一些冲突的问题，不能够用技术语言来描述，需要想清楚，好好的组织语言，组织出产品能够明白的语言，并且加以说服 - 沟通的过程中，记录下product backlog - product backlog 需要排好优先级(按照价值观) - 优先级别高的, 往往会比较细, 优先级别低的, 往往会比较粗 - 这些backlog是需要产品最终点头确认的

开发¶

pair¶

结对要做到定时的rotate, 因为每个人都有自己的优点，要通过和不同的人进行pair，学习到他们身上的有点，提升自己
结对的过程中，一定会出现冲突。怎么解决？
遇到冲突不要激动，不要急。代码是不会骗人的。先以某一个人的思路进行，如果成功了，就证明他的是对的。
如果另一个人还不服气，可以再用他的思路进行，如果也成功了，那么表示也是对的。
如果都是对的，那么采用较好的一种思路即可

unittest¶

以test开始，以test结束
当存在一个没有通过的test，不要写下一个test，直到这个test通过为止
当存在一个没有通过的test，不要写下一段实现，直到这个test通过为止
mock是一个好东西，但是不要经常用到，如果发现test很难写，或者经常要用mock，那么很可能是设计出了问题。可以回过头来重新考虑代码的结构和设计
Python中的Fudge是一个用来做mock的第3方开源lib，很好用
第一个test往往是最直观的，能表明编码意图和思路的，所以，值得下功夫

code review¶

每天需要有人进行code review

refactoring¶

发现了bad smell，就应该及时的 refactoring
"以后再重构吧。" 这是不可能的事情
"先这样，实现功能，到时候在改。" 这也是不可能的事情

交付¶

小步提交代码
每次提交代码就可以给产品人员看最终的效果
每次当效果和产品的不一致的时候，需要马上沟通
沟通结束后，需要马上迭代

几个会议¶

sprint planning meeting¶

与Team和产品同时沟通
拿到backlog后, 针对里面的优先级别高的, 会进行任务的细分, 给出能完成的时间.

注意会影响系统架构的地方和有依赖关系, 前后顺序的地方要及时发现, 并把优先级调高

daily standup meeting¶

一共5分钟左右
只允许一个人发言，发言者需要拥有Talk Token，比方一个玩具小熊
昨天做了什么
今天预计做什么
昨天遇到了什么问题
如何解决昨天问题的
如果发生冲突，一定要有一个主持人中断冲突，请会下解决冲突

retrospective meeting¶

个人认为最重要的一个会议
总结出阶段内的well，less，puzzle
列出action list
每个的action list 需要找到对应的actor

结论¶

agile 提升了开发效率
agile 提升了代码质量
agile 解决了一个萝卜一个坑的问题，最大限度上允许了成员的离开
agile 需要长期的坚持，就算是自己一个人写代码，也可以用它