老翅寒暑

摘要： “什么是需求的最初形式？”这是和网友讨论的时候引发的问题，我的观点是：最容易理解的需求描述形式就是需求的最初形式。如果你是一个需求分析师（BA），客户嘴里说出来的需求被称为是“原始需求”，这一类原始需求是没有经过整理的，而且是没有章法、次序颠倒甚至逻辑混乱的。BA需要把这些原始需求整理成一个各方都可以接受并理解的需求描述形式。 这是正规需求过程的第一个产出，如我在“需求与设计过程（1）”中讲的那样，人脑处理是非线性过程，大家千万不要在原始需求整理的时候只出一个东西，你可以并行出N个东西，比如数据词典、类图、用例图等，想到什么就做什么。需求的整理只是主要工作之一而已，不是唯一的工作。 一般在原. 阅读全文

摘要： 1.前言 看过太多的称得上“三无”的软件，就是无需求、无设计、无注释。严格的说来，他们的需求和设计其实还是有的，只是没有用文档记录下来而已，但是注释确实真的没有。这些软件从大到小都有，但是他们都有一个共同的特点，就是“难维护”。前几天和同事聊天，听说一个XAML的实现要重写了，用本地协议代替，然后再去考虑和XAML兼容。虽然我没有看过这个项目的代码，但是我知道这个项目基本也是“三无”。当然这个情... 阅读全文

摘要： 项目进度控制是项目经理的一项重要职责。俗语说的“时间就是金钱”在这里体现得再明显不过了。项目管理和自驾车回老家过年是相同的，实际上按照项目的定义，“自驾车回老家过年”也是一个不折不扣的项目，只是它更贴合大家的生活，更容易引起共鸣，我们就拿它来做例子说明。从乘客的角度，如果坐车很久，但是没有达到预期的目 的地的时候，就会产生疑问，一般都会去询问司机“到哪里了”，如果司机的回答没有那么令人满意，这个疑问就会积累。积累到一定程度，就会开始怀疑是否迷 路，如果这个疑问一直无解，最终就会要求停车问路。如果坐的是出租车，就会导致乘客下车，换车继续前进。项目进行过程中同样如此，因为软件项目的“不可见”特性， 阅读全文

摘要： 项目管理沙龙第十二次会议纪要本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法。这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。 阅读全文

摘要： 项目管理沙龙第十一次聚会纪要本来这次聚会要讲一下项目管理的流程概貌，同时对第一个阶段进行一次试探性的深入探讨。可惜这次缺席人数太多，变成了“锵锵三人行”，原定想要谈的内容，也就弱化了。其实每周一次的沙龙，并不需要太多的负担，就当是每周一次的茶会吧，大家紧张了一整周，放松个90分钟，也是应该的。不过“三人行必有我师焉”，只要有意愿，肯定能够谈出新话题来。今天分享的知识是“Dreyfus模型”，全称是“Dreyfus技能获取模型(Dreyfus Model of Skills Acquisition)”，是两兄弟研究人工智能时候得到的成果。这个模型把人对知识的学习过程分为几个阶段：新手(Novic 阅读全文

摘要： 项目管理沙龙第十次聚会纪要会议一开始，就有人跟我们分享了一个名词，“分析瘫痪”，意思是不断地追求完美，结果始终在设计状态，无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。与会者都有同感。而破解“分析瘫痪”的诀窍，就是“敢于行动”，因为人就是在不断的错误中学习并改进的，不犯错，当然也就谈不上改进了。如果用沙龙常用的术语说，那就是“敏捷”。今天的敏捷话题是分享AOM的敏捷过程。AOM是一个基础平台产品，在实施敏捷之前，采用周计划的模式来管理，即每周定制计划，组 阅读全文

摘要： 项目管理沙龙第九次聚会纪要前不久在腾讯举行了2011敏捷大会，但是因为加班或者报名的原因，沙龙里只有一个人参加了敏捷大会，所以本次聚会由夏勇分享参加大会的心得。对大家印象比较深刻的首先是雅各布森给出的一系列敏捷卡片，我们拿到的这一系列卡片有四组，基本覆盖了敏捷过程的方方面面，对于敏捷过程的指导作用还是比较强的。所以我们决定接下来将这个卡片电子化一下，让每个人都可以看到。QZone的产品经理的演讲还是挺让人感兴趣的，他号称是QZone每周五天可做到约二十次发布。在这种情况下，如何保证项目成果的质量稳定，是需要一定的水平的。QZone前台使用php，后台使用C++，所有模块集中发布。他们有一个专门 阅读全文

摘要： 项目管理沙龙第八次聚会纪要本次沙龙依然是NSEC的敏捷经验总结。这次依然谈到了客户与需求的问题。因为客户和开发组不在同一个地区，所以客户完全没有参与到项目的开发工作，所有的沟通都通过项目经理来进行。从开发人员的角度看，需求变化最大的问题是开发人员无法确定是否真的是对客户有用的。客户首先是自己有很多的想法，变来变去，PM也因为距离的关系，无法和客户面对面沟通，所以也就只能拍脑袋和猜谜语。结果开发人员心里没底，做不出成就感，心情自然也就好不起来。引出的问题就是：开发人员到底怎么办？面对这种情况，经过讨论，大家认为首先还是要充分信任PM，但是PM也有责任去和客户充分沟通。这个时候，我们一直强调的“原 阅读全文

摘要： 项目管理沙龙第七次聚会纪要本次沙龙的主题是由NSEC项目组介绍他们的敏捷实践经验。作为公司第一个实施敏捷的项目，他们的成绩给整个公司带来了震动，也是公司其他项目实施敏捷的参考和基础。因为时间是所限，这次沙龙虽然只来得及只讨论了NSEC的四个问题，不过逐个问题讨论的过程中，我们涉及到了更多的方面。上次沙龙提出的“代码秀”在NSEC实施了一周，效果不是很好，首先是频率问题，上次沙龙谈到的代码秀周期是“周”或“月”为单位，NSEC的实践证明以“天”为单位确实是太频繁了；其次是项目组太忙了，没时间总结，而且分散独立提出各自的代码片段，如果没有专人汇总收集的话，分享起来还是不太方便；另外出现的问题是，程 阅读全文

摘要： 项目管理沙龙第六次聚会纪要--模式“苹果酒屋”《项目百态》模式36名字叫“苹果酒屋”。大意是说，苹果酒屋是工人们下班之后的聚会场所，他们经常在吃完饭之后，一起爬到房顶上去乘凉，喝啤酒。于是女主管就制订了苹果酒屋规则，基本上就是“不许爬到房顶上”，“不许喧闹”等诸如之类的规定。可想而知，这种“苹果酒屋规则”不会有人遵守的。因为规则的制定者从来不会在苹果酒屋住宿，也当然不会知道屋顶上是那里唯一凉快的地方。这种“局外人”制定规则的情况在企业内部非常常见，最终的结局也都和“苹果酒屋规则”差不多。会上列举了几种常见的推广场景，一种是“强推法”。比如“空降”到项目组或公司的能人，经常会不顾公司的现状，强行 阅读全文