28、 你们每个人都知道出了问题应该找谁么？
应该知道。任何一个特性至少都应该有一个所有者，当然，所有者可以继续指派给其他人。
29、你遇到过有人说“我以为…”么？
要消灭“我以为”。这个其实很复杂，也很难办。但是这是在出现问题的时候推卸责任的一种说辞。既然不明确，那就让问题或者责任明确起来。
30、 你们的进度表是否反映最新开发进展情况？
应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
31、你们的工作量是先由每个人自己估算的么？
应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
32、 你们的开发人员从项目一开始就加班么？
不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
33、你们的项目计划中Buffer Time是加在每个小任务后面的么？
不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。这个缓冲对夯实代码、总结、补充士气都有作用。
34、写新代码前会把已知缺陷解决么？
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
35、你们的程序员厌恶修改老的代码么？
厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
36、你们会隔一段时间就停下来夯实代码么？
要。最好一个月左右一次。这个需要拿出专门时间来进行，消灭代码中的一些隐藏的问题和一些不符合代码规范的地方。
网友评论