项目中的教训

1, 每个迭代没有及时的review, 造成无法快速的响应变化

2, 虽然defect被良好的跟踪记录了，但是需求和设计的更新没有有效的跟踪和记录，每次更新设计文档的时候都很混乱。应该一开始就用wiki来写文档，每次做review或者讨论的结果都应该及时更新wiki.

3, 既然团队缺少明确的leader，我应该主动承担leader的一些任务，比如及时更新记录每次review和讨论的结果，这个我做的相当不够

读《轻松scrm之旅》

这两天一口读完的这本书，如同读金庸小说血脉贲张，梳理下points:

1. 迭代(sprint)分的小些比较好，每个sprint都是调整的机会，sprint多了调整的机会也多了，在每个sprint都要完成几个story

2. 工作task化, story都要细分成task，task是最小的work item（8-10 person-hour工作量最好）, 团队成员自主来选择task, 用task面板来管理task, 大家在task面板上能看到所有task的状态.


3. 每天开scrum每日会议，时间不超过15分钟，大家都站着开，看着task面板轮流发言。每个人回答3个问题，1我昨天做啥了，2今天打算怎么做，3遇到什么困难。会议时间一定要控制，如果有细节应该会下讨论。scrum会议能保证团队之间互相了解，并且及早发现问题。

4. sprint结尾的review会议非常重要，然后应该紧接着开下个sprint的plan会议。这两个会议是scrum中最最重要的两件事情。

5. 文档要尽量少而精，最好用wiki来维护

6. 虽然文档少，但是可以采用结对编程的方法使新人快速上手，结对编程最好用共享桌面或共享IDE的工具来实现。组员之间也应该采用结对的方式来做code review，最好一老带一新。

7. 第N+1个sprint测试第N个sprint的内容

今天一点体会

DCUT上周终于结束了，虽然还留下几个特费劲的defects. 今天release meeting的时候，老板突然提出我们的实现不够smart，哎~，老板说的确实有些道理，可是怎么现在才提出来啊。这次的开发确实有很多不足：

1. 所谓的迭代根本没起到作用，虽然每个迭代结束都更改了点设计，但是没有认真的做迭代Review和下个迭代的Plan，这两件事至关重要，要是老板的comments上个迭代能提出来就好了

2. 迭代点不能拖延，做不完的任务应该放到下个迭代，每个迭代点是个非常好的调整机会

3. Test team介入的还是晚了，导致他们前期无事可做，现在又赶不上进度

4. Dev Team没有了leader，导致大家讨论太少，code review也做的不够，我应该主动来push

ClearCase & ClearQuest

人称CC+CQ, 原来这才是企业级的软件开发和质量管理控制平台阿