Good Practice in Agile
敏捷开发是一种提倡拥抱变化, 控制风险的一种方法论。本文将讲述在实施敏捷团队时的一些Good Practice。
识别团队中的Bad Smell
文档
“hey, 帮我写个文档被, 以后我好回顾, 以后来人就按照这个文档操作, 省的你一遍一遍说”.
碰到这种情况一定说, NO. 当面沟通最有效, 我已经交给你了, 再来新人, 你教. 如果认为有必要写文档, 谁提倡谁写.
这种方式, 除了拒绝文档这种低效率的沟通方式, 还要拒绝团队为”只提意见，不主动实践”的人提供土壤。
我们拒绝文档，提倡高效沟通。试想一下，刚进项目的时候，客户的人做我旁边，找我问技术问题竟然发邮件。
站会
"xxx没来, 等等他吧, 我希望听听他的工作. "
依然say no. 我们不能为了站会而站会. 站会不等人, 准备或者提前开始, 团队快速catch up, 然后迅速开始一天的工作.
不用担心有人缺席站会会有影响, 如果有人非常需要跟缺席人的沟通, 自己会去找他, 反之依然.
沟通
“hey, 我发现一个小bug, 能不能现在修一下, 很简单, 估计也就10分钟”.
拒绝. 请JIRA建卡, 或者story上添comments , 简单描述bug, Owner在需要时自己去take卡
此时要培养的习惯
- 优先级的概念
- 再小的任务也有effort, 当前工作被打断, 再拾回也是effort
- 任务的简单与否, 会耗费多长时间, 一般由熟悉本任务的Dev决定, 其他人替Dev做预估都是非常不专业的表现. 一定要培养沟通习惯, 专业的事情, 找专业的人沟通，由专业的人评估。
让每个环节更有效率
站会
go through 每天大家做的事情.
站会时只讲三件事儿, 时间控制在5分钟内（10个人）
- 我昨天做了什么
- 我今天要做什么
- 碰见什么问题,需要谁或者什么帮助.
站会主持者需要及时识别站会中的bad smell
- 站会时进行细节讨论
- 讲述story中, 不需要每个人都知道的细节
- 把站会当开会, 当中宣布一些显而易见事情. 这种事情邮件就可以做到, 不需要大家每个人, 把聆听宣讲当做优先级最高的事情.
提高站会效率的手段
- 准备一个token, 只有拿token的人才能说话
- 站会时计时5分钟, 然后告诉大家我们需要5分钟内结束站会. 会后记录使用时间, 在团队养成习惯后可以不用追踪时间
- 展会前将站会内容按照
Yestoday, Todo, Question分类, 写在卡片上, 站会时按照卡片上的讲 - 及时打断不必要的讨论
- 及时打断问对方要承诺式的对话. (例如, xxx你今天能不能完成 xxx? 然后也渴望的眼神看着对方)
Continuous Integration / Continuous Deliver
CI/CD没有你想象那么难, CI/CD会带来持续的效率增长. 越早引入成本越低，反之成本越高。无论多困难困难，都建议排在最高优先级。
CI最小集合
- build script ( maven, gradle, rake, gulp.js …)
- git repository
- Jenkins Job
CI能保证的内容
- project 能够在一个干净的机器上build, 避免本地依赖
- 每个人都可以使用build script构建相同的开发环境(mvn idea:idea / gradle idea)
- 构建结果能够发布, 客户可以时刻拿到QA过的更新
CI标准集
- run check style
- run unit test
- build package
- run functional test
Continue deliver标准集合
- 将构建结果自动化发布
- 自动化更新到终端(eclipse plugin开发，自动更新到update site)
结对编程
有些客户对结对编程并不理解，虽然不进行100%的full time结对，有些场景结对编程会带来很好的效果。坚持下来后，这种结对方式也赢得了客户的认可。
需要结对编程的信号
- 传递知识, 包括带新人
- story涉及两个人做的内容, 可以double check
- 需要帮助的时候
不适合做结对的情况
- spike
- 需求不清晰的Story
如何结对
- 先就story沟通思路
- 一个人写测试, 一个人写实现
Code Review
每天必不可少的环节，并且需要坚持每天进行。
目的
- catch up 今天的工作,
- 分享代码技巧
- check代码, 保持良好的代码风格
步骤
- 先讲做了什么, 如果条件允许, 先做showcase
- 按照解决思路讲解代码
- 重构(当天发现的问题, 当天重构), 站会时需要有人专门记录refactor建议
关注点
- 别人在做什么, 如果以后碰到相关问题, 知道要怎么做, 或者找谁问.
- 了解别人解决问题的思路
- 关注代码的bad smell
Retrospective meeting
一个安全的环境, 大家讨论团队中遇见的问题.可以采用如下方式:
- Well/Less Well/Question or Suggestion
- Star Fish (Start/Stop/More/Less/Keep)
个人推荐采用Star Fish, 每个象限都是action, 会让回顾会议更容易产生action, 效率更高。
