|
|
|
项目经理成长记-8：XX项目往事
2011年我来到了一家新IT公司，做软件项目经理一职，这是我人生事业上的新起航。而下面我想介绍的就是我在这家公司的第一个软件项目。
我姑且叫这个项目为A项目。A项目是公司为了加强公司信息化程度而立项的一个公司内部项目。项目费用由总公司承担，项目最后运用在全国多个的地区公司总部以及分部。一句话介绍，A项目就是一个在线签核系统。因为公司比较大，涉及的地区也比较多，而公司在开发过程中有严格管理规范，那么既定的文档在线签核就是其中很重要的一块。因此公司为推行无纸化办公而成立此项目。
初接项目，老板给我的指示很简单，“用敏捷方法把这个项目做好，这个项目就是敏捷的试验田，你可以做任何你想做的，我不会干扰”。可能因为是公司内部项目，而我又是公司新进员工，不会被公司现有制度或开发流程或羁绊，所以老板想放手一试。当然我也绝不能辜负老板的一番心意。下班后回家恶补敏捷Scrum。
接下来就是我的敏捷奇妙之旅了。当然仅是一些片段，不然太长了。
Sprint Plan， 最开始的几次Sprint Plan真的非常的糟糕。首先是User Story，我们还是按照需求的方式把他直接转换为User Story，仅仅是一堆的列表而已，看起来大大小小杂乱无章，这给开发带来了不小的困扰。一来给估算带来的麻烦，二来不知道这些User Story的关系，三来User Story写的非常简单，理解上也很难把握。其次我们没有完全按照Agile要求把Story分解为2-16小时的Task。或者说我们根本就没有分解。而是把完整的Story估算成为时间。基本上都是5天3天这样的时间。因为大家都认为Story太简单了，不必在会议上分解的这么细。几天后问题出现了，我完全无法跟踪项目进展，Sprint都快要结束了，可是一个Story都还未完成，也不知道Story完成了百分之几。
Sprint Planning Improve，经过几次计划会议后，我们进步不少，首先是User Story的改进。上面也说到之前写User Story只是简单的列表。后来查阅一些文章才发现其实User Story也可以和MVC结合，按照大小一致的粒度去编写。分为数据(史诗级User Story)和操作(一般User Story)这样更便于与开发的沟通和理解。比如史诗级User Story可能是系统管理员做用户管理，他的操作可以分为增、删、改、查用户这么四个小的User Story。
The first Stand-up Meeting，总所周知站立会议上我们只用说三件事或者说是回答三个问题，“昨天已经做了什么?遇到了什么问题?今天将要做什么?”说起来很简单，但做起来并不是那么容易。大家表现依然糟糕，站立会议上大家都是在向我汇报，有的人忘记说今天将要做什么，有的人忘记移动任务墙，有的人你不问他，他就不说昨天碰到了什么问题，有无解决。
Stand-up Meeting Improve，进过几次改进后，我制定了以下几条规则：1. 当你汇报情况时，首先移动任务墙，你可以选择一次性全部移动好，也可以一边移动一边说。但不要忘记这是你的第一件事情。2. 在说昨天做了什么任务时，一定要补充一点，你的任务完成率是多少。比如，我昨天做了增加用户这个Story，完成了80%，还有一点点单元测试未完成。3. 说遇到了什么困难时，如果是你已经解决的困难一定要说出大致的解决方法。如果是你未解决的方法，请立刻寻求帮助，停顿一下，看谁能主动举手帮忙。如果一段时间内无人能协助，就请SM记录下来，会后找更多资源帮忙。项目管理者联盟
刚开始在憋大家的习惯的时候真的很痛苦，大家不是忘记这个就是忘记那个，后来我采取的方法是，让每一个人说完后，其他人指出他有什么地方说的不对的。指正之后，再让汇报人重新再说一边，直到大家都认为他说的很好为止。变态的招数，但效果还不错。
通过几次Sprint Review会议，我们做了很多的改进。首先在准备上我们更加的从容，我们在Iteration Review之前我们就把我们做的软件打包发布可在本机运行的版本。那么在会议上就可以马上进入Demo环节，避免浪费大家的时间。第二个改进，我们在回顾上一个Iteration我们那些做的好，那些做的不好，那些需要改进的环节，我们不再由我一个一个的点人来回答。而是用事先准备好的小字条，让大家把自己的想法写下来，每人至少要写一条好的方面，一条不好的方面。写完之后每个人依次上台来向大家分享，并且要求就每一条分享举出在上一个Sprint中的实际事例出来，这样的分享更有价值。我觉得效果非常的好。最后我会就好的方面做一个总结，让大家在下一个Sprint对好的方面继续发扬。不好的方面，我选出了其中最重要的2-3条做了一下分析，大家一起讨论提出了一些可行的解决方案，并且我要求他们在下一个Sprint进行改进。总之，个人认为不要把会议流于形式，而要真正发挥其作用，那么才有意义。不让就是浪费所有参会人员的时间，那是一件非常可怕的事情。
经过近6个月的奋战，虽然我们这个团队人手不足且新人很多，虽然我们运用了从未使用过的开发流程，虽然公司对项目的重视度也不是很高，虽然我也只是一个新入职的项目经理。不过很幸运的是，我们的项目顺利的验收了，而且还得到了客户的好评(当然客户就是总公司信息部)。我觉得这都得益于敏捷的管理方法，我们快速的迭代，每次迭代完成后给客户演示及时得到反馈意见，灵活的变更以适应与客户的真实需求。做出来的真正是客户想要的。
至此，再次感谢我的团队对我的大力支持和配合。也感谢我的公司和领导，能给我一次这样的机会，让我能又一次刻骨铭心的奇幻之旅。还感谢我的老婆和家人在我背后默默的支持。
上一篇：关于用户需求的那点事儿
下一篇：项目经理成长记-9：YX公司项目往事 |
|
service@step365.com
0571-87357690
狗仔卡
发表于 2013-7-3 15:49:38
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡