阳光VIP

少壮不努力,老大徒伤悲。平日弗用功,自到临期悔。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理
上一页 1 ··· 112 113 114 115 116 117 118 119 120 ··· 139 下一页

2011年7月27日

摘要: 原文:http://apple4.us/2010/10/zhouhongyi-on-jobs.html里边很多话未来都将是名言,周鸿祎厉害。[独家]与周鸿祎谈乔布斯michael on 2010-10-17, 21:21 Comments Off 十一之前,我有机会和周鸿祎坐下来聊聊乔布斯。 这是奇特的一对。两人一中一洋,未曾谋面;两人分属消费电子和互联网两个领域;两人中一个执掌着市值近 3000 亿美元的公司,另一个还从未打造过一家上市公司⋯⋯但他们在某些方面又是类似的:充满争议性、富攻击性、与众不同。我无意标榜周鸿祎,但与他长叹三小时的过程的确酣畅,周心思敏捷,又富商界经验,便不乏有趣的见 阅读全文

posted @ 2011-07-27 18:06 阳光VIP 阅读(114) 评论(0) 推荐(0) 编辑

2011年7月21日

摘要: 本文是敏捷外包工程系列的第三篇。(之一,之二,之三)下面的很多外包场景以国内的外包为例,因为往往这些项目更加严苛。外包合同常常是固定价格固定工期固定需求(一般称为定额合同),这个时候“拥抱变化”的敏捷感觉意义不大,那么敏捷开发是否就无用武之地了呢?其实不然。下面的一些用法,是利用敏捷开发来促进这种固定合同的达成。在提出这种“如果……,不但……,而且……,那又怎么办呢?”的限制性问题时,不能期待完美的答案,因此下面这些方法有些能用,有些不能用,有些需要在现实环境中加以变形才能使用。而如果发现哪一种方法都没用,企业极有可能运行在高危状态,不是敏捷开发或其他开发方法能解决得了的,应该从市场、销售、定 阅读全文

posted @ 2011-07-21 23:22 阳光VIP 阅读(155) 评论(0) 推荐(0) 编辑

摘要: 本文是敏捷外包工程系列的第二篇。(之一,之二,之三)敏捷开发整体上适合小团队、产品研发(所以才有product owner一称)的环境,而外包软件开发中常常存在的则相反,因此在创建团队的时候要充分认识到这一点。Product Owner产品负责人的人选听到无数次有人说“我们的Product Owner就是客户,因为所有需求都是客户提的”,其实这样做极度危险。Scrum开发理念提出前的环境大致如此:一小群开发人员(3~9人),内有项目经理发号施令,外有销售人员指手画脚,团队加班加点苦不堪言。因此Scrum提出了要自组织的概念,接下来发生的故事大致如此:自组织需要代价;结果导致分权;开发组获得的权 阅读全文

posted @ 2011-07-21 16:14 阳光VIP 阅读(262) 评论(0) 推荐(0) 编辑

摘要: 本文是敏捷外包工程系列的第一篇。(之一,之二,之三)本系列是中科院研究生院《软件工程硕士-外包方向》的《敏捷外包工程》课程的课外扩展阅读材料(本人是此课程讲师)。同时也适合软件外包公司在本公司推行敏捷开发时参考。 定义这里的“外包”指广义的外包,包含了传统的欧美外包、对日外包,也包含国内以销售合同驱动的项目型外包,如政府、银行、电信项目。由于整体上外包工程属于管理活动,除了需求开发部分会借鉴XP的实践之外,本文所提到的“敏捷开发”一词多指Scrum方法。“敏捷外包工程”整体上包含两个部分:交易过程和交付过程,本系列中两者均有涉及,当前以后者为主,前者会较晚推出。前者包含市场宣传,客户接洽,合同 阅读全文

posted @ 2011-07-21 12:59 阳光VIP 阅读(168) 评论(0) 推荐(0) 编辑

2011年7月19日

摘要: 2012-02-24:新版本发布,新增敏捷计划5页由于原定发布时日期2012-02-29在外地培训,提前发布;本期内容由原定的产品管理改为较为基础的敏捷计划,建议下载。预告:下一更新日期:2012-04-30。您可以在非商业场合免费使用(详见文档最后的授权页面):作为培训前的预习阅读。打印并张贴在公司走廊上。作为企业内部小组培训教材使用。请大家跟帖多提意见和要求,以便及时更新。下载请点击(无需积分):2012-02-24版:CSDN下载,无需积分,需要注册:http://download.csdn.net/detail/cheny_com/4086672115网盘,不用注册:http://11 阅读全文

posted @ 2011-07-19 14:04 阳光VIP 阅读(112) 评论(0) 推荐(0) 编辑

2011年7月15日

摘要: 已经正式发布,请转至:http://blog.csdn.net/cheny_com/article/details/6616794最近几天没写博客,一方面因为有几次培训和会议占用了时间,另一方面在编写一个免费敏捷教材及宣传材料。最后有几张已经完成的草图。编写到初衷有两个:1. 希望每次培训课前,大家已经对基本概念有所了解,而不是从头听,这样有限的时间就可以用来解决真正的“敏捷如何应用”的问题而不是“敏捷是什么”的问题。花钱去听基本概念是很亏的一件事情,但要找一本书(尤其是2小时就能看完的)来了解敏捷基本概念还挺难。国外如goodaigle有一些类似材料,但是不完全对外公开。2. 去过几家企业, 阅读全文

posted @ 2011-07-15 13:16 阳光VIP 阅读(123) 评论(0) 推荐(0) 编辑

2011年7月11日

摘要: 本文是“松结对编程”系列的第六篇。(之一,之二,之三,之四,之五,之六,之七,之八)松结对编程是小型团队的实践,大约运行在1个师傅+1~3个徒弟的尺度上,当面临更大尺度的时候,就需要大型团队模型。这里推荐139团队模型,因为它不但可以让松结对编程运转顺利,还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂,将另有系列博文描述,这里只描述与“松结对编程”相关的内容,以保证本系列博文的完整性。基本概念139团队就是1个项目经理,3个师傅,9个徒弟的简称,当然实际上未必正好凑够13个人,也未必正好每个师傅都有3个徒弟。在第一篇里边已经提到过三个层级的工作关系,下面是一些深入 阅读全文

posted @ 2011-07-11 22:40 阳光VIP 阅读(127) 评论(0) 推荐(0) 编辑

2011年7月9日

摘要: 本文是“松结对编程”系列的第五篇。(之一,之二,之三,之四,之五,之六,之七,之八)松结对和紧结对不一样,两个人不是总坐在一起随时发现问题解决问题,而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个:一是看结果是否符合需求(做什么),而是看代码是否存在问题(怎么做),后者就是代码检查。代码检查(也称代码审查Code Inspection)是一种由来已久但是很神秘的东西,最初引入是在一些生命攸关、重大财产相关的软件开发中,典型的就是SSOS(美国航天飞机的软件),其每段代码都交由6个人审阅,方可入库。成果就是在1989年之前(之后笔者没有数据),SSOS在太空中失效次数只有一次。笔者亲身 阅读全文

posted @ 2011-07-09 14:10 阳光VIP 阅读(98) 评论(0) 推荐(0) 编辑

2011年7月8日

摘要: 各种思路和顺序都试过。最开始时先编写Model,毕竟Model是所有一切的基础,再说没有Model,Controller里边用到该怎么办。后来改成先编写View,View才是用户能看到的东西啊,不知道用户看什么,怎么知道应该提供什么Model。现在先编写Controller。在讨论哪种次序最好之前,必须弄清楚“好与不好”的标准。开发次序好与不好的标准1. 顺畅比如编完Model的10个方法,再编Controller的10个方法,再编10个View是不顺畅的。从敏捷的角度看,就是同时开启了多个故事,而这些故事要等到最后才能同时完成,属于不好的实践。而先编controller中的1个方法,然后马上 阅读全文

posted @ 2011-07-08 12:27 阳光VIP 阅读(149) 评论(0) 推荐(0) 编辑

2011年7月7日

摘要: 本文是“松结对编程”系列的第四篇。(之一,之二,之三,之四,之五,之六,之七,之八)团队中常见的一种情况计划、估算、设计的时候大家还在一起,但编程的时候就会分开。分开看似是安全的,但是却充满隐患。2001年,一位招聘考试前三名(一共120员工)的程序员的两个月的成果被彻底放弃重写,原因是里边包含3000多个常数,而且很难修改(码流参数),重写的人座位距离他只有4米,重写也只花费了2周;2002年,一位月薪7000(那时候北京房价才3000多)的程序员编写了一个月的4000多行代码,在一个下午被重写为50多行,座位距离他只有5米的项目经理疑惑加惊讶地问:“你真的没学过c++ template?” 阅读全文

posted @ 2011-07-07 14:39 阳光VIP 阅读(129) 评论(0) 推荐(0) 编辑

上一页 1 ··· 112 113 114 115 116 117 118 119 120 ··· 139 下一页