问:我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
答:问题和需求明确,但是典型用户,典型场景好像只是只是口头说说了。
问:是否有充足的时间来做计划?
答:我们觉得需求和计划是这次实践中最重要的问题,当然有。
问:团队在计划阶段是如何解决同事们对于计划的不同意见的?
答:貌似没人用银弹。但是大家都很河蟹啊。不同意见集合讨论一会儿就相同了。
问:你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
答:基本做完,有几个没做完。没做完的原因是:不懂怎么做。比如内存消耗过大和tag编辑界面的调整(后边这个问题看似容易,实则复杂,不好表述)
问:是否每一项任务都有清楚定义和衡量的交付件?
答:对于一些美化工作是有的,但是对于一些增加功能的工作只是实现功能,之后才讨论的怎样确定最终成果。
问: 是否项目的整个过程都按照计划进行?
答:没有。每个人总有每个人的事,计划赶不上变化啊!
问:在计划中有没有留下缓冲区,缓冲区有作用么?
答:没有。导致了上面那个问题的发生。最后就赶啊赶
问:将来的计划会做什么修改?(例如:缓冲区的定义,加班)
答:细化任务,增加缓冲区。
问:我们有足够的资源来完成各项任务么?
答:图书馆加网络是无敌的。
问:各项任务所需的时间和其他资源是如何估计的,精度如何?
答:根据个人能力,让任务执行者估计所需时间,精确到天。
问:用户测试的时间,人力和软件/硬件资源是否足够?
答:基本是谁有时间谁测。测试做的不好,需要加强。
问:你有没有感到你做的事情可以让别人来做(更有效率)?
答:肯定有。但是人的精力是有限的,尽力就好。
问:每个相关的员工都及时知道了变更的消息?
答:有时没有。tfs用起来太麻烦。
问:我们采用了什么办法决定“推迟”和“必须实现”的功能?
答:河蟹讨论。
问:项目的出口条件(Exit Criteria)是否得到清晰的定义?
答:完全不知道这个是什么。
问:对于可能的变更是否能制定应急计划?
答:没有考虑过这个问题。现在想起来,貌似可以,加班加点就是了。
问:员工是否能够有效地处理意料之外的工作请求?
答:这都什么问题啊,没考虑过。
问:设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
答:开始的时候,一个人负责,大家一起想,一起提意见,我们觉得这个方法很好。
问:设计工作有没有碰到模棱两可的情况,团队是如何解决的?
答:先放着,实践可出真知。
问:团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
答:只有手工测试。测试亟待加强!
问:什么功能产生的Bug最多,为什么?
答:基本都是改进,bug都不多。最多的还是上面说过的tag编辑功能,完全就是一大泥球。
问:代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
答:貌似没人考虑了这个问题。
问:团队是否有一个测试计划?为什么没有?
答:没有。低估了其重要性。
问:是否进行了正式的验收测试?
答:大家一起手动用了一下全部功能算么?
问:团队是否有测试工具来帮助测试?
答:没有。
问:团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
答:这个问题被大家无视了。
问:在发布的过程中发现了哪些意外问题?
答:没有。
最后附图一张。
ps:组长在照相。。。