本文不是描述敏捷的文章,也不是用来褒扬敏捷的文章。

记录了这一年来在敏捷实践中的一些东西。这些东西不一定是符合教科书的,仅仅是我们的一些实践。

沟通

作为技术人员,我们的交付者是产品人员,与产品人员沟通很重要。往往产品人品就是一份产品文档. 而且会提前发给技术, 那么在仔细阅读了产品文档后, 需要做的事情就是沟通。在沟通的过程中要注意:

  • 不能急,很多产品不懂得技术,所以,对于一些冲突的问题,不能够用技术语言来描述,需要想清楚,好好的组织语言,组织出产品能够明白的语言,并且加以说服
  • 沟通的过程中,记录下product backlog
  • product backlog 需要排好优先级(按照价值观)
  • 优先级别高的, 往往会比较细, 优先级别高的, 往往会比较粗
  • 这些backlog是需要产品最终点头确认的

开发

  1. pair:

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

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

    • 每天需要有人进行code review
  4. refactoring:

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

交付

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

关于会议

  1. sprint planning metting

    • 与Team和产品同时沟通
    • 拿到backlog后, 针对里面的优先级别高的, 会进行任务的细分, 给出能完成的时间. >注意会影响系统架构的地方 和 有依赖关系, 前后顺序 的地方要及时发现, 并把优先级调高
  2. daily standup meeting

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

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

结论

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