标签:系统 文档 net verify size 封装 导致 nbsp 好的
这是我们的第四个Sprint了。因为上一个迭代周期的失利,Leader群发邮件这样描写叙述道:“对任务的乐观预计,导致Sprint 3没有如期完毕。
我们须要在这次Sprint计划中细致评估各自任务,并又一次调整计划。
”
周一上午九点半准时启动我们的计划会。Leader简单说明当前工作情况,并把剩下的任务罗列出来。找出须要这一期完毕的任务。
以下,就要为这些任务找到主人。
第一个任务是HR的服务程序。
这是周权和我在上一个Sprint遗留下来的。权哥负责逻辑部分,而我负责WIN8上面的服务程序的调研。所以此任务还是被我俩领走了。
逻辑部分代码编写须要大家一起评估时间,而评估时间就是大家如果任务由自己来做,须要花多少时间。
然后就像做游戏一样,每人把自己评估的时间写在纸上,由Leader组织游戏,依次亮出自己的答案。最后。Leader权衡大家的时间,决定此任务最后的DeadLine。
周权对此任务了解较深,他先对任务说出自己的设计想法和一些背景信息。然后大家陷入了思考。
当我大笔一挥在纸上写下“6”时,旁边的測试MM笑了。我问她笑什么。她说:“这是拍脑门子想出来的啊!
”事实或许就是如此,每一个人都是从自己的逻辑角度和经验来思考这个问题,写下自己觉得可能的时间,事实上不就是拍脑门子嘛。
第二个任务是原有架构设计中FACADE模式的实现。
客户提供驱动接口文档,为了封装和隐藏原有系统,齐天准备用FACADE模式来做。这样会使架构的韧性更好。
当然,江涛提出了自己的疑问:“我们非要再次封装吗?”
“假设不想封装也能够,直接调原来系统的方法或许。
假设时间不够。不封装就不封,反正我无所谓。
”齐天退步了。
”还要按原有架构走,没有重大问题轻易不改原有设计。“Leader还是从大局出发。大家就这样讨论起来,你一言我一语,最后,还是原有计划不变。
在讨论的当儿,我的思绪回到了几年前高哥给我们培训设计模式时讲的故事:
他原来公司有个项目,须要使用第三方商用库来开发。
他的头儿在接到这个第三方库时,自己把全部接口都封装了一遍。当时大家也不理解为什么这样做,多麻烦啊。他给大家画了一幅图并解释到,我们的项目调用我封装好的接口,假设第三方库有变化。仅仅须要我改动一下封装层,我们的项目都不用变。
这第三方库也十分给面子,在第二年就公布了重要版本号,改动较大。
公司得到这个新库之后,大家都唏嘘不已。假设没有那次封装,后果真是不堪设想。
思绪回来,继续我们的会议。
半个多小时,基本上任务都有主人了。墙上的Task板也进行了调整。Task从TODO不断移动到In Process中。接下来的一周要把它们向To verify和Done中迁移。
Story都已经定下来了,结局怎样。还要看我们这一群人的努力。一定会圆满的,由于我们是A Team。
标签:系统 文档 net verify size 封装 导致 nbsp 好的
原文地址:http://www.cnblogs.com/wzzkaifa/p/7220450.html