11 2011 档案
摘要：环境：asp.net mvc3 vs2010当使用多Area工作时，为了能在Area之间共享Shared目录，需要注册各自Shared地址。在Global.asax.cs，需要如下添加不同Area的Engine： public class MvcApplication : System.Web.HttpApplication { ... protected void Application_Start() { RegisterRoutes(RouteTable.Routes); ViewEn...
阅读全文
摘要：前几日，又收到一名大二学生的来信，就大学退学的想法咨询我，我了解他的大学是正规本科后，力劝他必须想方设法拿到学历，如果能保住学历，又能出来培训的话，考虑其家庭经济困难，建议他参加中关村黑马程序员的“不交一分学费即可入学、不3k就业不给一分学费”的培训。在征得他的同意后，将来信内容公布出来：张老师： 你好！ 我是一名大二的学生，学的也是软件工程专业，这个专业我挺喜欢的。但是我学的很烂，很烂。我尝试着听老师讲课，很快发现，这样的效果还没有我自学的好。可是慢慢的我发现太吃力了，一点感觉都没有。完全凭记忆做题。有一段时间我非常的郁闷，在想，我是不是不适合学软件开发。为什么我会一点感觉都没有，为什么做.
阅读全文
摘要：如果有各种动物，比如Dogs/Cats/Cows/...，都有不同的Age方法，若想从其基类用相同的方法ShowAge来显示这些不同的Age，自然就可以借用基类Animal的virtual函数，比如：public class Animal
{ public virtual Age { get {....} set {....} } public ShowAge() { Show(Age); }
} public class Dog : Animal
{ public override Ag...
阅读全文
摘要：本文是敏捷开发产品管理系列的第五篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）粗估会议是一个较少使用的敏捷实践，但其作用还是很明显的。WhyScrum里边，有两个关于需求的比较头疼的问题。一个是PO不太懂技术，不知道故事大约需要多久才能完成。为什么PO要知道？因为如果划分的颗粒度不好，会导致有的故事太大或太小；而且如果不知道故事的大小，就比较难大致预测未来的几个迭代能做完哪些故事，版本计划不好做。二个是如果只依赖短暂的Sprint Planning Meeing，往往团队对故事的理解不够
阅读全文
摘要：是的，可以自己磨望远镜镜头。这件事情听起来不可思议，但实际上第一个反射望远镜是牛顿在400年前发明的。大数定理完美的反射望远镜，是抛物面的，就是无穷远处的星光无限接近水平光，在反射后会成像聚焦于一个点，重现为无限小的星点。用放大镜（目镜）观察它，就是反射望远镜了。但是抛物面很难制作，所以一般用球面代替。怎样制作完美的凹球面呢？大数定理。当两个原形的玻璃无规则、无数次摩擦后，有两个可能：得到两个完美平面（几乎不可能），或得到一个完美的凹面和凸面各一个。如果通过偏移重心的方法摩擦，则上面一个肯定是凹面，下面一个肯定是凸面。通过几十万次的“天之道，损有余而补不足”，只有两个完美球面会出现。400年前
阅读全文
摘要：高中时喜欢上天文，厮磨硬缠买了个望远镜，但是只有镜头和镜筒，没有镜架，需要自己做一个。地平式，赤道式镜架分为地平式，赤道式两种。地平式结构简单牢固，就是一个水平转动的轴，加上一个垂直转动的轴。为什么不做这个呢？因为地球自转是倾斜的，所以太阳和星星并非东升西落，而是东升，去南方，然后落到西方。这就产生一个问题：为了跟踪移动的星星，就要同时转动水平轴和垂直轴，操作很麻烦。不能不“跟踪”吗？不能。地球自转的速度很慢，本来是几乎看不出来的，但是望远镜的放大率往往达到100倍，也就是可以理解为星星只需要24小时/100也就是大约15分钟，就要围绕地球转一圈，这个速度很快，刚对准星星，只要1分钟，星星就会
阅读全文
摘要：这是敏捷开发般若敏捷系列的第八篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）正法，像法，末法任何事物，都会经过这三个阶段，有的短至几年，有的长达几千年。正法时代一般是原创者掌握话语权的时期，因此能正确地解释和传播。正法时代传播的是智慧和般若，而不是知识（方法，具体的实践等）。本人先是学习了敏捷开发的方法，之后一年多才有幸读到Ken Schwaber的图书，其中一本大量介绍了以往他推广敏捷开发的案例 http://product.china-pub.com/37172#ml。这本书中介绍Scrum实践的篇幅很小，但后面的案例很多。从案例中可见，并非所有项目都完整彻底地使用了Scru
阅读全文
摘要：这是敏捷开发般若敏捷系列的第七篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九） 重新认识CMMICMMI其实是一种敏捷开发方法，何以见得？CMMI是由美国军方的甲乙双方密切配合产生的国防部招标标准，在美国国防部招标的时候使用这个标准，既没有多余的让某方别扭的，也没有缺少的让某方担心的。CMMI还是不断改进的，一个涉众如此之广的产品能以这个速度改进，已经很难得了。在招标过程中发现问题，随时都会提交到变更委员会。所以在CMMI里边，充满了无我之心，无住之法。但是，那里的我和那里的法，不是我们身边的我身边的法。互联网行业、消费电子行业把CMMI当作起点寻找适合自己的终点，就像北京人去天津
阅读全文
摘要：这是敏捷开发般若敏捷系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）说了这么多，五六七这三篇与如何推广敏捷有什么关系呢？推广CMMI过程中的失误在回答如何推广敏捷敏捷之前，先回顾一下推广CMMI中存在的失误。本人在3家企业内部推广过CMMI，为10多家企业从外部做过咨询和培训，CMMI肯定对企业有帮助，但是并没有想象中那么好。试点项目完成后，证书拿到，多数企业并没有在其内部完整推广，甚至试点项目都发生了退步。究其原因，莫过如下：1. 各利益单位的目的不同，利益不统一（执着于我，人，众生）一次CMMI认证的主要受益者包括：政府/软件园涨面子，企业/市场/销售部门有证书能拿单
阅读全文
摘要：这是敏捷开发般若敏捷系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）敏捷开发中有几个地方相当创新，或者说尽管之前的方法中可能也有涉及，但却从来没有像敏捷开发这样提升为“根本大法”来对待。一个是“拥抱客户价值，拥抱变化”，一个是TDD/结对编程/自动化测试为代表的开发与测试的融合，一个是“团队协作/结对编程/共同估算/代码共同所有制等自组织团队实践”，还有一个则是认为协作重于流程，沟通胜于文档。传统开发的困局在敏捷开发之前，尽管没有成文的说法，但客户与开发人员整体是个博弈的关系，双方要小心谨慎相处。比如需求要签字确认才能开发，计划要提前敲定并监督完成；而变更要走严格的变更流
阅读全文
摘要：这是敏捷开发般若敏捷系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。平衡空与有非常困难，这是本篇的内容。法与空法与空的对立统一由来已久。吴伯凡老师举了个例子：“一切事物都是相对的”这句话有什么问题？这句话看似相当辩证，无懈可击，但它本身就“非常绝对”，有一种内在的矛盾。软件界的法与空是否经常听到程序员说这种话：“世界上没有完美的软件，我的代码缺陷是多，但是要让我编写没有缺陷的软件，也是不现实的。”“你说你的方法好，但我觉得我的方法也不错的。方法本身没有好坏，我们就别争了。”“世界上没有完美
阅读全文
摘要：这是敏捷开发般若敏捷系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）所谓无住，包括两个含义：不住于法，不住于空。前者比较好理解，后者会在下篇详述。不住于法，就是不执着于具体方法的意思，就是所使用的方法应该基于实际情况作出判断，而不是认为世界上有最好的方法，必须遵守。法执对法的执着，称为法执。典型的法执，是很多企业使用CMMI的方法。本人曾经做过10多家企业的CMMI培训、咨询，所需工作日从41天～43天不等。你能想象这么多企业，起点不同，终点不同，人员不同，行业不同，能用相同的咨询工作量完成CMMI改进吗？我和我所在的公司都不是不负责任的公司，我们因此而丢失了几乎所有的要
阅读全文
摘要：这是敏捷开发般若敏捷系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）作为预热，之前的智慧敏捷系列中提到，多数情况下敏捷实践应该如何，都要“看着办”而无有定法，但每次思考又有“避免浪费”等相对确定的思维方向，总是徘徊在虚实之间，难以把握。智慧受到因缘（内因，外缘）所限，所以每次答案都各有不同；而各有不同背后的更高层的相对永恒的东西，则是“大智慧，妙智慧”，就是般若（佛教语，音“波惹”）。缘起本系列将尝试解决几个终极问题：1. 什么是敏捷？2. 怎样知道我是否敏捷了？3. 应该怎样推广敏捷？4. 我是否适合敏捷？5. 敏捷未来会怎样？简单地说，若在解决这些问题前附加上前提条件
阅读全文
摘要：这是敏捷开发智慧敏捷的第六篇。（之一，之二，之三，之四，之五，之六）写多了，才发现前几篇文章中有几篇都落下个章节，就是除了“看着办”之外的一些常见做法，这里总结一下。所谓常见做法，就是为了防止“看着办”看走了眼，而提前可以参考的方法，可以作为起点，但未必真的正好合适，更很难永远合适，所以不是终点。为了阅读方便，在原文中也添加了，这里仅做归纳。“写不写文档”的常见做法常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：信息长期/短期有效的文档 长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图…… 长期文档适合详细描述，
阅读全文
摘要：陈勇转载注：本文很短，但总结性很强。冬吴相对论的一期基本上完整描述了第一篇《半成品时代的生存逻辑》，MP3地址位于：http://www.21cbr.com/html/multimedia/audio/201107/04-8357.html。其他文章没有找到。作者：程然Henry，原载于：http://henrycheng1973.blog.techweb.com.cn/archives/3.html 2011年对“移动互联网”来说是非常重要的一年，在“无线互联网”的概念艰难走过近10年之后，重生为“移动互联网”，而且超越了原本单一互联网范畴，统合了相关的信息科技、媒体和通信行业，以至于我们现
阅读全文
摘要：本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）这里所指的新产品研发，不是指自己企业的新产品，而是特指那种在行业中初创，前途不明，尚需市场检验的新产品。敏捷开发可以在很大程度上帮助这种产品的开发过程。新产品的第一要务策划新产品的第一要务是：谁会买这种产品？为什么？开发新产品的第一要务则是：它与以往产品的核心差异是什么？这个听起来不难理解，但是做起来有困难。因为一般产品开发往往是先做“最重要的功能，最基础的功能，最影响架构的功能”，这很容易在很久以后，才能看到
阅读全文
摘要：总目录问题系列：之一，之二，之三，之四，之五，之六，之七，之八这句话的意思不是不读书，而是读书之外，先要思考，甚至是思考优先。开始中国有一段时间“特中国”，就是春秋战国时代。现在我们所见的儒、道思想，以及潜移默化还在的墨、法思想，都是那个时代出现的。后来虽然尚有汉唐宋这些鼎盛朝代，但思想的类型整体没有突破。而且春秋战国虽然久远，为人所记的人物事件却多得出奇，春秋五霸且不说了，商鞅苏秦张仪孙子孙膑庞涓管仲乐毅荆轲扁鹊……虽然并没有《三国演义》这样的通俗文学传诵，但是仍然知名度很高。曾经和一位朋友讨论此事，他笑笑说，应该是因为当时的人不像咱们这么忙碌着上班，尤其那些连地也不用种的闲士，一天有数不完
阅读全文
摘要：这是敏捷开发智慧敏捷的第五篇。（之一，之二，之三，之四，之五，之六）缘起（立项时）甲：“你们的设计文档打算怎么写？”乙：“到时候再说。”甲：“应该有规范的开发流程和模板，才能写好设计文档。”乙：“预先定义的流程和模板未必适用，敏捷开发崇尚推迟决策，只有在具体工作之前才能决定是否写，怎么写最好（maximizing the amount of work not done）。”甲：“你们组才3个人，能比组织级定义的流程和模板还好吗？”敏捷开发定不定流程和模板？先把话说绝点：敏捷开发不定义流程，不定义模板。为什么呢？因为如果预先定义了流程，比如“必须写需求，需求评审过了才能写设计……先检查测试环境，
阅读全文
摘要：这是敏捷开发智慧敏捷的第四篇。（之一，之二，之三，之四，之五，之六） 缘起甲：“我们每日立会会开不起来。”乙：“嘿，我们每日立会开起来了，而且越开越长了，一开就是1个小时，净是些技术细节。”甲：“别人等着他们讨论，那多耽误时间啊……”乙：“我也觉得是，但是看他们交流得那么热烈，讨论的也是正事，到底应该打断还是不打断呢……”为什么每日立会只开15分钟？我们说绝点：每日立会只能开5分钟，而不是15分钟。这5分钟说点什么呢？应该说必须开会才能说明白的东西。先看两个团队，他们有什么是需要开会说明白的。第一个团队，10个人，平时分工细致，各干各的，谁也不干扰谁。这个团队，开会的时间肯定不短，因为所有交互
阅读全文
摘要：这是敏捷开发智慧敏捷的第三篇。（之一，之二，之三，之四，之五，之六） 缘起甲：“敏捷不应该写架构设计，应该每个迭代都是相同的，才能达到自相似性（这是Ken Shweber说的）。”乙：“如果不写架构设计，很容易返工，早晚还得重来。”甲：“大不了重构，这是敏捷开发重要的实践。”乙：“重构？重构的成本很高的，做几个迭代，后面重构都重构不过来了。”甲：“架构设计写了很容易过度设计，而且在编码的时候还很容易全部推翻重来；。”……这个架构文档要不要写呢？写，为什么？不写，为什么？写，怎么写？不写，怎么不写？为什么敏捷不做架构设计？先把话说绝点，敏捷就是不写架构设计。那为什么不写架构设计？还是为了减少浪费
阅读全文
浙公网安备 33010602011771号