runyon的博客

来到新公司，我挺不习惯的一点是要求写软需文档。之前呆过的公司都不需要写软需。其中还有一家是通过cmm3认证的呢。怎么通过的？临时抱佛脚专人写软需呗。开发不看测试不看。给谁看？评委呗。由此知道国内cmm3认证有多水了吧。既然软需的拥护者和反对者为数都不少。所以我觉得软需是否有用不是个判读黑与白的问题。而是需要权衡弊大于利或者利大于弊的问题。   软需的利简单说就是有章可循，理想情况下开发按照软

1.让整个小组参与。特定活动的主要职责可能会落在某个人或者某个分组身上，例如确定需求的优先级主要是产品所有者的职责。但是，在最求可能具有高价值的项目时，要让整个小组参与进来并做出承诺。例如，我们可以在一条建议中看到这一点，这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个小组做出的估计才是最好的。小组成员分担的职责越多，小组可以共享的成功也就越多。2.

项目进度对于项目管理的重要性不言而喻，不管是领导，还是pm，都很关注它。但我在实践中发现一个悖论：由于重视项目进度，故将其量化作为（项目组or项目成员）重要考核指标的做法，有些情况下反而会影响项目进度。   这是为什么呢？先引入一个定理：事情永远不会在deadline前完成。认为为简单任务分配个相对宽裕的时间，则项目组/项目成员会提前完成并继续做下一个任务的想法有点过于理想主义。少数开发者也

我是单元测试的实践者和拥护者，我将单元测试引入项目并持续推进它，督促代码的提交者编写相关测试代码。我也确实从单元测试中得到好处：更高的代码自信心；更好的软件质量；更快的开发速度——正如大多敏捷方法论者许诺的。   但我和大部分敏捷方法论者不同，我并不是单元测试的狂热者。单元测试不是有利无害的万能药，更不可能解决软件开发中遇到的一切问题。也许他们的本意是好的。但是过分吹捧反而不利于单元测试真正

scrum: 一种敏捷开发框架，可以避免经理问你在管理上做了啥功课时回答做了冥想。scrum和xp的参考网站：http://agilemanifesto.org/http://www.mountaingoatsoftware.com/scrumhttp://www.xprogramming.com/xpmag/whatisxp.htmbacklog：订单/故事，一个或一组需求，从客

这是一本很有趣的书，让我经常在公车上傻笑，不枉推荐人的强力推荐+免费送货上门。   学到一些东西，比如要装B应该找些比设计模式复杂的东西。他选择的是递归函数论。以前有句古话：五十步笑百步。在现代社会可以改成八十步笑五十步兼笑百步。他在书中一边抨击java、设计模式太简单，不能体现智力差别；一边说动态数理逻辑不够实用，不能用来实现真正有用的东西，所以他不读计算机科学的研究生。嗯。他觉得合适的点是