Good Practice in Agile

96
lvjian700
2015.12.21 23:12* 字数 1391

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

  1. 我昨天做了什么
  2. 我今天要做什么
  3. 碰见什么问题,需要谁或者什么帮助.

站会主持者需要及时识别站会中的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, 效率更高。

Agile team
Gupao