Software Engineering

“A,B,C一起开会”未必比得上”A找B,再找C,又找B…”

如果一件事要三方一起沟通,惯常的作法是三方一起开会,这样效率比较高,因为说话人说一遍,就可以让其它两方同时知道(广播式)。  如果不这样而是采用点对点模式的话,A跟B说完之后,还得再跟C说一遍。 但有些经验表明,这并不是绝对的。有些“人”的因素,可能会使第二种模式效率更高。三方同时沟通在“人”的方面有一些缺点:   1. 三方碰头开会可能只允许有两三个小时的时间,因为这样往往会漏掉一些关键的东西,得出的解决方案很有可能会有可行性的问题。   2. 如果没有强势的主持人,三方沟通可能意味着七嘴八舌,会议无组织,效率反而更低   3. 多数压倒少数效应。如果B和C意见一致,气场强大,则A可能会有点退缩,怕大家觉得自己笨而不敢乱发言。   4. 如果A和B,C并不平等, 则A需要注意的礼节禁忌也会多一些   5. 以上缺点随着参与方的数目和每方人数的增加而增加。 在这种情况下,还不如换用点对点模式。按谁受益,谁主动的原则,让其中一个人来穿钻引线,不厌其烦地打扰其它各方:   1.其它人就像分时系统,一边回应,一边可以做自己的事;因此不会觉得时间有太大浪费。你也可以因此问的细一点,做出的方案更靠谱一点。   2.一对一模式下,你可以从容引导沟通的进程。因为只有你主动,别人都被动。   3.其它的一些人的因素也减轻了很多。 不过,你仍然要时不时地发一起阶段性的结论出来,发给所有人:to make sure all are on the same page, 这样可以弥补点对点沟通的一个缺点:无法当场取得所有人的一致。

Trust Nobody

“你这个怎么做的?” “你们已经有这个接口了吗?” 不要轻信对方的回答。如果他没查代码,他给你的回答在一定概率上是不准确的。 你可以做的是:   a. 问对方具体是哪个类里的哪个字段,自己校验一下。   b. 对于一个接口,既要问提供者,也要问当前的使用者;如果他们两个口风一致,可信度才高 不过,这过程中尽量不要让人觉得你不信任他。这需要技巧,这方面我还很弱。

自底向上地给出解决方案

自底向上地给出解决方案: 先看看现在有什么,再考虑怎么弄   1. 做方案之前先看看系统中对类似问题是否已有方案. 这个方案说不定你可以直接用,甚至不用再开发任何东西   2. 全面地了解你可能用到的子系统、模块,然后再去找相关的接口人;这不是为了评估对方所说是否正确,而是为了更好地倾向对方,避免自己产生似是而非的理解。

项目管理中的Units, Work, Duration

我是看了这个PDF才明白的: http://pmpspecialists.com/WhitePapers/PMP_Specialists_Task_Types.pdf. 本贴里我再用自己的语言复述一下. Units, Duration, Work是什么? Units就是参与任务的"人力", 如果一个人100%干, Units就是1; 如果两个人各50%干,Units也是1 (2 * 50%) Duration就是任务完成所花的时间. 如果一个任务从周一干到周五, 那Duration就是5天 Work则是一段时间内所有人实际投入的"汗水",也就是"工作量".  如果两个人各100%一共干了5天,那Work就是10天. 简单地说, Work =  Units * Duration Fixed Units, Fixed Duration, Fixed Work MS Project里的任务类型必定是Fixed Units, Fixed Duration, Fixed Work其中一种.那又分别是什么意思? 1. 先说一个最容易理解的, "十月怀胎"这种任务就是典型的Fixed Duration. 一个女人生一个孩子要10个月,十个女人只生一个孩子还是要10个月!  那投入十个女人后,上面几个参数会怎么变呢?    a. 一个女人的时候,  Work =  Units * Duration = 1个月 * 10人 = 10 人月   b. 十个女人的时候, Work …

项目管理中的Units, Work, Duration Read More »

project 2007学习笔记 — 草稿状态

project 2007 notes 1. 给定计划后,就要把它当作一个baseline,以后的追踪就是基于实际执行情况与baseline的比较 2. 追踪并调整计划 — 这时baseline怎么办? Project 2007的作用:    1. 计划       a. 查看重大变更对项目的影响       b.  在取舍资源与进度时帮你做一些计算       c. 设置任务优先级       d. 找出critical path(关键路径)       f. slack (摩擦损失时间)    2. 资源管理    3. Trackiing    4. Reports    Project 2007中的工具:    1. Gantt chart    2. Network Diagram: 体现从一个任务到另一个任务的流动    3. Resource Grpah & …

project 2007学习笔记 — 草稿状态 Read More »

神奇的代码覆盖检视工具:Emma

凭借Emma,你可以看到:当你的java webapp被访问一段时间后,哪些代码被执行到了,哪些没有。 这可以帮助你判断你的测试覆盖率是否足够高,也可以在生产环境上帮你找出热区代码(它的额外开销不算大,因此不用担心它影响系统性能) 它的原理是:"instrument your classes prior to deployment".改变后的字节码会生成coverage文件,然后可以用Emma分析这些文件,得出html格式的报表。

项目管理体会之四:系统换版前要征得合作方同意

系统换版前要征得合作方同意    1.换版可能失败,这会导致合作方的业务受阻。所以要先打好招呼。    2.合作方的系统跟你的系统存在交互,你的系统升级时要让对方跟你一起升级。    3.不管是测试环境换版还是生产环境换版,都要先征得合作方同意。测试环境对他们来说可能有重要的意义。

收藏一本书:《高效程序员的45个习惯:敏捷开发修炼之道》

目录 第1章 敏捷——高效软件开发之道  第2章 态度决定一切   1. 做事   2. 欲速则不达   3. 对事不对人   4. 排除万难,奋勇前进  第3章 学无止境   5. 跟踪变化   6. 对团队投资   7. 懂得丢弃   8. 打破砂锅问到底   9. 把握开发节奏  第4章 交付用户想要的软件   10. 让客户做决定   11. 让设计指导而不是操纵开发   12. 合理地使用技术   13. 保持可以发布   14. 提早集成,频繁集成   15. 提早实现自动化部署   16. 使用演示获得频繁反馈  . 17. 使用短迭代,增量发布   18. 固定的价格就意味着背叛承诺  第5章 敏捷反馈   19. 守护天使   20. 先用它再实现它   21. 不同环境,就有不同问题   22. 自动验收测试   23. 度量真实的进度   24. 倾听用户的声音  第6章 敏捷编码  …

收藏一本书:《高效程序员的45个习惯:敏捷开发修炼之道》 Read More »

Pair Programming — 亲身体会1: 对付小BUG时PP很好用

今天为一个小Bug尝试了一下Pair Programming, 感觉确实不错。《The Costs and Benefits of Pair Programming》中提到了很多好处,我今天体会到了三点:     1.对一个方案,有更多的解空间。今天正是因为Pair Programming, 我们才想到了一个既简单又健壮的方案。   2.充分防止了“粗心”或者“没想到”。多一个人,问题就会考虑得更全面。   3.如果不搞PP,那么可能会在代码评审时才发现问题;那样是有挫折感的。而PP避免了这个问题。 那时间成本怎么样呢? 像《The Costs and Benefits of Pair Programming》说的一样,的确占用了两个人的时间,但由于两个人一起弄时想的方案很简单,实现起来比较快,所以总的(人*时)并没有增加。 最后说一个缺点。 当一个人在做一些事务性操作时,另一个人就只能发呆;比如签入签出代码、改变缺陷状态、编译、启动Tomcat时,另一个人会感觉得时间很浪费。