主题：【原创】关于日本的一些杂感：规范 -- 铁手
家园 需求和设计是不能分开的 需求和设计是不能分开的，设计是要实现需求所要求的功能，需求也是在现在技术条件许可下的对期望值的折中。
所以，我们在开发中，设计和需求是混在一起进行的。设计文档有两种，Feature Design，这个可以说是功能设计，也就是类似与原来软件工程中的需求分析吧，另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析，通常一个一年的项目，这个Feature Design也就5-6页文档量而已，基本上就是非常粗略地大颗粒地描述要实现的功能而已。
至于费时的详细设计，通常由程序员完成的，在敏捷开发中是真正省略了，是依靠代码的可读性来实现。
另外，敏捷开发讲究的轻量快速迭代。
也就是需求和设计实际上在一起进行的，进行的同时几乎就开始写代码。有了一个模糊的需求，就有一个前进的方向，例如可以写一些框架代码，定义一些消息机制和自动机的状态等，写一些接口类，基类，制定设计模式等。细一些的需求出来，就可以写一些派生类和执行逻辑。就这样逐步细化。
敏捷开发中有迭代（Iteration）和里程碑（milestone）的概念，实际上开发的过程是和用户不断交流的过程，每个迭代基本上指实现一个或几个小Feature，甚至是Feature中的一个部分，但是保证每个迭代出来的产品是能够使用和能够测试的，这样就可以有基础和客户交流获得进一步详细的需求。
每个Milestone可以根据时间来划分，更多是按功能实现的需求的来划分，也就是每个milestone能够推出一个部分满足客户一些需求的产品。
敏捷开发有一个论点，我感觉不错，也就是：绝大多数客户实际上并不了解他们的需要，也不清楚他们想要什么产品。这一点，我相信在传统开发过程中，为不断的需求变更头痛的人一定是有体会的。
所以在开发中，敏捷开发是一个小量递增，小步快走的过程，需求是逐步细化，设计也是逐步深入的，代码这是伴随这个过程不断生长的。
在我们的开发过程中，很常见的情况是最初的feature design只实现了其中70%的功能，但是却另外添加了起初没想到的30%的功能。
所以不是没有需求分析，而是需求分析是一个交互的过程，是在整个过程中和design/test混合在一起。
通宝推：季侯,
家园 日本的软件是生产出来的 沿用的还是工厂生产管理的流程，要求可继承，可明确，可追溯。这种方式对黑盒测试很依赖，而不贴近白盒测试，非致命性的错误很少，一旦有问题就是整个系统的崩溃。（这次日本Mizuho银行的崩溃，很可能就是系统理论富余度和实际富余度的不符造成的。）正因为这个问题，所以更要求生产过程中的规范化，目的就是能迅速找到原因，不受其他因素的干扰。
就我个人经验，同样的1万行左右陌生的代码，从解读-〉理解-〉确定-〉设计-〉修改，按日本规范编制的代码速度最快。
说完好的了，说说不好的：
1 新技术的对应慢。
我这里很多东西还是VB5 6做的，等到Win8平台一推出就彻底的要推倒重来，成本很高。
2 对设计人员的束缚过大
因为可移植性太好了，所以很多东西还是延续20年前的设计思路，执行的效率和资源利用程度都很低，最近看了看内部的模块代码仓库，结构性更新的基本上全是我们这群空降来的八国联军搞的。
3 过于控制成本造成含金量不足，对以后的发展有束缚。
关键词(Tags): #编程(说了就走)， 通宝推：铁手,家园 其实日本这种死板背后的一大原因是为了推卸责任方便 守规矩是好事，但不分轻重缓急死抠规定，有一个重要原因，就是为了日后好推卸责任。面对突发事件，很多情况是没有最优解的，也就是说怎么做都会有风险，都会挨骂，唯有什么都不做，按规定来，可以作为日后推卸责任最强大的理由。
这个情况不光日本有，也不光政府有，很多大公司都有这样的问题。情况一切正常的时候这叫规范化，一旦出点什么事，各部门的第一反应是想办法把自己摘出去，解决问题的过程更是步步为营，紧跟规定走，最大限度的避免自己的部门承担额外的责任。我最近就碰到这么一件事，事情明明很紧急，解决方法明明很容易，偏偏各部门为了不承担额外的责任，把一个一天就能解决的问题拖成两周，回头写出来给大家看看。
家园 事急从权 男女授受不亲，礼也；嫂溺援之以手者，权也。
菅直人首相再三说，这是六十多年来的最大危机，日本从上到下，还那么淡定的按部就班，真是一个神迹。
家园 真想把日本的问题放在经济版里好好讨论一下 真想把日本的问题放在经济版里好好讨论一下：
举个我个人到现在还耿耿於怀，总搞不明白的例子：
创造了被那样推崇和推广的“精益制造”神话的丰田，那次搞大批回收车并公开道歉的悲剧，竟会起源於一个没有见到经过“重复验证”的有关报道的，所谓的“高速公路踩刹车时发现加速现象”的美国客户的投诉。至今也不知是不是当时那位仁兄儿的“幻觉”？听说最后还发现也许根本不需要回收那些车，因为实在找不到同样的投诉了！
我们这些对突发事件搞“诊断”和应对的同行都很疑惑。因为，凡是查那个“事出有因”的都会习惯来尽力“回放”和模拟当时的现状，如果是抓住了真“凶”的话，那么同样的条件应产生相同的后果，“重复验证'是基本手段。他们会那样忽视吗？
也许还有什么其他的猫腻儿，自己就无法想像和理解了。
家园 好像这是个政治事件 当时这个事情闹得沸沸扬扬，在时间上，直到日本屈服并召回和赔款，直到美国消费者不再对日本车有信心为止——于是美国的正式调查报告也就出来了——9起事件中有8起事件都是另有原因，只有1起事件是可以确认的，并且在这个调查事件期间，最亲华和反美的鸠山首相下台了。于是美国人的效果已经达到了，至于日本车到底有没有问题，who cares？
家园 曾经有结论出来，但是没有几家新闻报道 至少没有象刹车门的时候那么报道。总的来说，那些所谓的意外加速，多半是人为失误，或者是踩油门当刹车了。
具体内容可见： http://en.wikipedia.org/wiki/2009%E2%80%932011_Toyota_vehicle_recalls
On February 8, 2011, the NHTSA, in collaboration with NASA, released its findings into the investigation on the Toyota drive-by-wire throttle system. After a 10 month search, NASA and NHTSA scientists found no electronic defect in Toyota vehicles.[30] Driver error or pedal misapplication was found responsible for most of the incidents.之后，破产的通用又活过来了。
家园 真的没有同样投诉了？ 在规则至上的日本第一企业，难道没有投诉的核查制度？仅凭一个没有见到经过“重复验证”的外国客户的投诉就收回几十万辆汽车？我不太相信。
如果真是这样，我觉得只有用“阴谋论”来解释了，那就是在老美的压力下，丰田为国家政治行为来买单，也就是你说的猫腻。
家园 丰田在00年前后搞了一个千禧年成本压缩方案 一定程度上已经摈弃了传统的与供应商长期合作的思路，极其强调压低成本。之后的事件恐怕与此有关
家园 消息来源是公开报道和质管同行的质疑，很希望知内情者爆料 我的消息来源是公开报道和质管同行的质疑，很希望知内情者爆料。
附“猜想”之一：
隐患是确实存在，而且有普遍效应，根源於精（偷）工省（减）料。因此要亡羊补牢。但死鸭子也要“硬”在嘴上，赖账（故称无同例，无大危害）。
此猜想的老话重提是因为这次核电又“狼来了”。
再加一句：
日产的内产内销产品和外产外销的同型同牌的产品，从设计，材料到质控，都不像一个父母的孩子，早就有人质疑了。
家园 这个还有质疑呀？ 日产的内产内销产品和外产外销的同型同牌的产品，从设计，材料到质控，都不像一个父母的孩子，早就有人质疑了。这个还有质疑呀？
早20年日本人都公开说了
家园 处理这种人命关天的大灾大难，跟打仗差不多！ 还能按“规范”走？没有制定过规范，所以无所适从，那日本人都是机器人？
惊诧之余，我所能想到的唯一解释就是：遵守规则，遵守规范。哪怕是火烧眉毛，哪怕是前所未见。小日本制定过应对海啸的规范吗？制定过应对核事故的规范吗？没有！那从何谈起“遵守规则，遵守规范”？你的结论逻辑上非常不严密。—— 怪不得你们做项目 bugs 多！
