过去的一周，团队进行了第一个迭代。从形式上说，计划会、每日站会已经有了，迭代评审会和回顾会还没有开，今天上午需要快速把这两个会议开了，让整个团队获取反馈，并且确定改进方向；从内容上说，第一个迭代规划的内容没有全部完成，因为不出所料的，迭代中有新增的任务插进来，我们没法拒绝，只能调整任务优先级，另外有些任务的初始估算可能是不准确的，每个人的工作被打断以及在不同任务间切换的成本没有充分考虑到。这个完全符合教练说的规律，所有团队在开启第一个迭代的时候都会存在过度承诺的现象，很可能会完不成。需要通过几个迭代的磨合才能知道团队自身的速率情况，为后续的工作计划提供基础数据。
这里引发一个疑问：如果每个迭代团队都能确保完成任务，如何见证团队的成长？我了解有的开发团队的状况是每个迭代都会多安排一些任务，所以迭代的任务总是完不成的。有点类似定义120分的目标，我们能够完成到100分，如果定义100分的目标，可能只能完成80分。这两者如何平衡？还是交由团队来讨论决定吧，看看哪种方式团队工作更有动力。
本周的计划：
1. 完成《大规模敏捷开发实践——HP LaserJet产品线敏捷转型的成功经验》的阅读，并输出读后感。周末已经读了一点了，也许可以在社区中做一次案例分享；
2. 输出《管理3.0》的第二篇读后感。第一篇无人评论，没有收到任何反馈，有点小沮丧。没有反馈就没有进步，无论是正面的或是负面的反馈，我都期待和欢迎；
3. 尝试在团队中使用JIRA，简化日常事务跟踪的工作量。从团队的任务情况和组织形式来看，可能还是使用看板方法会比Scrum更合适一些。再运转一周看看吧。
我是有底线的
