我记得在自己参加的某大型的数据仓库项目中,我当时做了一个任务列表,在我们小组讨论和分配任务之后,我要求他们,自己来填写任务的开始时间和结束时间.并且在完成任务的过程中,他们可以以工作为目标,调动各种资源,来完成任务.有不足也有突破,当时,我在早晨开始工作的时候,有时候,会给他们召开stand-up的会议,赞扬他们所具备的能力和取得的成果,这一点,也是有突破的,我觉得,应该stand-up是每天可以召开的,在项目的后期,我的感觉是项目的发展已经呈现出自己的很合理的节奏.自己小组的所负责的模块已经在自己的控制范围之内.完全可以成功.我觉得,我们当时的小组,应该是一个敏捷的团队,当然还有很多的需要改进的地方.
有时,在早晨刚开始上班时,是我把两位召集到格子间的中间,来开始今天的工作。那段时间,有时候下班后,总是会想到一句话,I think i can fly,想对他们说,但最终却只有简短的赞扬。
我们小组在讨论问题时,是借助于稿纸,来做分析的,当然如果有白板的话,沟通会更加的有效率.
我们小组在自己的开发机器上有自己独立的开发环境,在经过自己和测试人员的测试之后,再发布到运行环境,当时我们也提到了在系统活动不频繁的时间,再进行有规律的发布.
在开发的过程中,和其它小组的配合是平稳的.
在小组撤离现场的时候,对用户做了比较专业的培训,并提交了有关业务模块和系统配置的详细的配置说明文件和清单.
我的小组成员完成任务是有效率的,不需要加班.
上述是个人的总结,现在想来敏捷中的stand up(站立式会议), 最好控制在十五分钟以内比较好,stard-up不应该是考核的一种形式,而是一种开发者进行交流的形式。