敏捷开发是一种提倡拥抱变化, 控制风险的一种方法论。本文将讲述在实施敏捷团队时的一些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, 效率更高。
