|
|
移山之道 作者
-
魔方的故事 大概是在我小学五年级的时候, 大家开始玩魔方，我们家也买了一个。 我和几个小孩折腾了一会, 没搞出什么名堂。我哥摆弄了好一会, 嘿! 弄出一面一样的颜色。后来我也琢磨出来怎么把一面颜色拼出来。 再后来我才知道魔方有一些模式和一些口诀， 按图索骥, 依口诀而行, 就会从一面玩到一面再加一层， 再到加两层, 然后把最上层四个角的颜色搞对, 然后再按照一两个口诀翻十几下, 六面就做好了! 我玩着玩着就把各种模式和口诀都掌握了。 上初中的时候, 我还在课间表演过, 赢得一些男同学的好评 , 女同学似乎对此不感兴趣。 要在当时, 我的简历上一定会在“技能”一栏写上: “精通玩魔方”。 后来我就不玩魔方了，这样过了二十多年。 几年以前我在一个实习生的桌上又看到了魔方。 我拿起来，似乎不用想, 当年的口诀就在手上. 转啊转，一面, 一层, 两层，那个男实习生露出崇拜的目光。。。 直到最上一层, 嗯, 口诀是什么来着? 我试了几种可能, 好像都不行。我看到周围的女实习生似乎不感兴趣, 那就算了吧。 看来我的简历要改写成: “精通玩魔方到第二层”。 后来我想, 把第二层拼好, 我只知道找到某个模式, 按照某个口诀执行即可。 但是我并不了解为什么这个口诀能把第二层拼好, 同时又不打乱第一层的结果。 我更不知道如果在执行中走错了几步， 如何随机应变, 挽回局面。离开了口诀的话, 我只能把魔方的一面拼出来。从这点看来, 我的魔方技能应该是 “能够还原一面, 其他看口诀可搞定”。 那我的这真实的“技能”还值得写上简历么? 看样子是上不了台面了, 那什么是“技能”呢? 要知道技能, 谁能告诉我技能的反面是什么? 技能的反面 计算机人机交互领域的科学家 Bill Buxton 1995 年的一篇文章提到了 “The Opposite of Skill”: | Before reading on, think for a moment, and tell me what is the opposite of skill? I'll even give you a hint: I'm not looking for "unskilled." | [大家可以花10多分钟先读一读] [10 分钟就过去了? 您还是读一下吧] Bill 说技能的反面是 ”Problem Solving” – “解决问题”, 这个听起来有点绕， 我们看看IT 人士熟悉的一个例子吧。 一个IT 专业的大学生来面试, 简历上写 “技能: 精通 Visual Studio C# 编程”。 于是面试官请他实际用VS IDE 写一段程序 (冒泡排序)。 一个 “不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。 例如: · 嗯, 怎么开始一个C# 的命令行程序呢? · 定义数组是怎么弄的? 是 “int [] arr” 还是 “int arr[]”, 还是 ArrayList， 还是 Array <T>。 哦, 我平时都是上网查的. 哦, 我不知道还有 MSDN 网站。 · 嗯, 为什么编译没过呢, 哦, 这里少一个分号。 · 嗯, 怎么设断点? 怎么定义命令行参数? 额, 我要查一查… 你发现他把时间都花在“解决 (低层次) 问题”上了, 你想考察的“算法技能”、 “C# 程序设计技能” 都无暇顾及。注意, 这是在他认为非常精通的编程工具和编程语言中出现这样的问题。 你要这样的员工么? 那怎么提高技能呢? 答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。 
年轻学生都志向远大, 上了一些课, 就很想解决高层次的问题。我最近碰到一些学生就非常想做高层次的“科研”， 觉得“工程”是基础, 没意思。而且我 “已经知道怎么做了”， 从科研， 或者理论的高度上说, 所有的“技能”都能总结成简单的 ”已经知道怎么做了”: 例如: 下围棋怎么做？ 每一步都占据全局价值最大的一点, 直到终局, 即可获胜。 打乒乓球怎么做？ 把对手打过来的球都打回去, 直到对手的球出界或下网, 即可获胜。 再举一个例子: 我给一些同学出了一个题目：怎样在一年内做好一个博客网站: 北大 《领导力与职业发展》课程同学们的设想: http://blog.sina.com.cn/s/blog_840494da0100stf7.html （半年内达到3000万用户,下半年目标达到2亿1千万）
http://blog.csdn.net/jkl_sadly/article/details/6591856 http://blog.csdn.net/zhao_di/article/details/6627665 http://www.cnblogs.com/PkuCL1/archive/2011/07/24/2115378.html 看看几乎同时发布的, CSDN 项目负责人（8年以上工作经历）在CSDN的一年总结: http://robbin.iteye.com/blog/1136859
我们列表对比一下 | 大学学生 构想在一年时间打造最好的博客/微博网站 | CSDN 项目负责人（8年以上工作经历）在CSDN的一年总结 | | http://blog.sina.com.cn/s/blog_840494da0100stf7.html 半年内达到3000万用户,下半年目标达到2亿1千万 | http://robbin.iteye.com/blog/1136859 用户数应该无明显变化 回顾这一年多的工作，觉得自己取得的成绩有以下方面：
1、打造了一支积极进取，配合默契，对工作有责任心，执行力高的团队，
2、在部门内部树立了规范的制度化管理，
3、打造了一支专业的产品设计团队，
4、已经做了一些成功的产品，
亦留下不少遗憾和不足 | | 第一阶段: 打造团队, 产品设计, 上线 | 1, 整顿, 提高士气, 但员工流失严重 | | 第二阶段: 重在推广, 产品升级 | 2, 招人, 团队融合, 加强沟通和交流， 清除鸡肋 | | 第三阶段：进行调整, 吸引投资, 拓展业务 | 3, 规范流程, 攻克困难的项目 | | 第四阶段: 高效的领导与管理 | 4, 扭转困难局面, 各部门分工合作 |
在理想情况下, 谁不想专注于“高效的领导与管理”呢? 谁不想增加用户量呢? 但是在实际项目中, 有很多具体的问题要解决。解决这些问题, 就花了大半年的时间。 谁更有“领导力”这一个技能呢? 如果真的把 CSDN 任务交给这些热情高涨的同学们, 他们的第一年恐怕是在“解决(低层次) 问题”中度过, 估计很多人都过不了第一年。 [Bill Buxton 的文章还提到了不少值得深入讨论的观点, 我们暂且按下不表。 ] 魔方和模仿 为了玩好魔方而背一些口诀没什么问题, 至少能说明这个人记忆力不错。 最近我在网上看到大家评论一些国内的团队完全拷贝国外网站的设计，例如 “点点” 完全照搬国外的网站的设计。 
有好心人说这些copy/paste作品 是在“微创新”，可以吸引天使来投资等等。 我不同意, 这种 “微创新”论调是对创新的侮辱，对大众智商的鄙视, 对天使的亵渎。 抛开道德和法律方面的问题不谈, 我认为这种模仿的行为其实就是“背口诀”, 希望按照口诀执行之后, 魔方会同样出现一个神奇的结果。 这些 copy/paste 的方法作为自己团队的练习 （参加上面提到的“不断练习”）, 是可以的。 你听说飞人乔丹每天练习1000 次投篮, 而且扣篮的时候吐舌头, 你也每天练习1000 次, 并吐舌头, 这并不犯法。 但是你只凭这个就去找NBA 球探来谈 NBA 选秀的事情， 我觉得不大靠谱。 练习之后， 如果真想把模仿的产品推向市场, 有两个问题: a) 口诀是公开的, 你可以抄, 别人也可以抄。 如果都是一个口诀, 大家背得都差不多, 那我们怎么才能竞争过别人呢？ 我的核心竞争力在哪里？我怎么才能比上一个背口诀的人更能说服投资者？ （见上一篇博客） b) 各地市场和用户需求往往不一样, 按口诀执行之后, 会出偏差。这时候如果能把口诀改改, 解决本地客户的问题, 也是不错的能力。问题是, 有这个能力么? 一位同学举出了背口诀背得水土不服的例子: 
回到魔方 魔方的技能有哪些层次呢? 下面是我粗浅的看法: 1. 听说过魔方的玩法, 理论上了解 (已经知道：通过扭动魔方的各个层面， 直到六面出现一样的颜色为止) 2. 对口诀知其然, 能在实践中根据某种口诀玩成六面 (楼主在这里) 3. 对口诀知其所以然, 能够根据情况加以变化 3. 同上, 唯手熟尔。 几十秒就可以搞定的 (学校冠军们在这里) 4. 同上, 但是转得特别特别特别快, 十几秒就能转好的那些人 (世界冠军们在这里) 5. 能够设计出新型的魔方 那怎么才能考察出一个人 “精通”魔方呢? 我想了这样一个办法: a) 给面试者一个各面打乱颜色的魔方 b) 要求他把六面还原 c) 如果还原了, 要求他把魔方恢复成我最初给他那个混乱的局面, 必须一模一样。 精通魔方的同学, 来吧。
|
-
最近我和一些同学们讨论了一些有关 “创新” 的问题。 我不由得想起王屋村发生的一个故事。 
王屋村原来没有人玩过魔方. 有一年开学, 一个叫果冻的同学从爪哇国带了这个新奇玩意到学校。 他口里念念有词, 转来转去, 居然能把魔方从凌乱的颜色还原成六面整齐的颜色。 哇, 太神奇了! 班上的同学都很好奇, 课间的时候都看他表演。一些同学托果冻给他们买魔方, 而且求果冻教他们玩，果冻采取”口传心授, 不立文字” 的方式教育, 很快获得了魔方大师的称号，并且成了魔方的唯一代理。 有创新当然很好, 但是怎么保护创新呢？ 就像你的城堡一样, 有护城河 (moat) 来保护么? 果冻是学校里第一个学会了魔方口诀的, 在学校这个小范围里姑且算一种创新, 但是你的竞争力有护城河么 – 你能否保持只有你会背这个口诀? 如果没有, 那有可能大家都来学, 然后人手一个魔方, 很快就有人超过你了。 对于后来者, 一个赶上的办法就是把别人的优势变为大路货 commodity， 怎么办呢? 别的同学也不示弱, 另一个同学小飞花了一笔钱, 复印了一百份魔方口诀表, 只要通过他买魔方, 他白送口诀。不想买魔方的, 他也先赠送口诀。 这样魔方口诀就成了大路货, 大家就不用求果冻传授口诀了, 有些人就买小飞的魔方。 有意思的是, 同学发现小飞的口诀 (号称 C# 方法) 和果冻的“秘诀”(号称Java 秘诀) 有很大的不同, 虽然它们都能最后达到六面, 但是小飞的口诀是一层一层地实现六面; 而果冻的秘诀是先把每一面中间的十字做成同一颜色, 然后再解决四角的问题。 小飞为此和果冻在 <王屋村学报>, <移山新技术> 上展开了持久的论战, 争执孰优孰劣。 与此同时, 一旦口诀成了大路货, 大家都知道魔方的玩法, 各人能差异化的, 就是执行力 – 就是看谁扭得快。课间的时候, 一些同学都在咔嚓咔嚓地转魔方，激烈的竞争让有些同学玩魔方手都酸了, 退出了竞争。大家通过实践发现, 无论是小飞的方法还是果冻的秘诀都不是关键, 手劲巧, 魔法转得快, 加上一些运气, 就玩得快。 围观玩魔方的女同学渐渐少了。 竞争分几个阶段, 当大家都拥有类似的技术, 大家都能够搭云梯越过别人的护城河, 在各自的城堡中短兵相接, 竞争进入了白热化, 大家比的就是执行力。 这时候, 竞争者有好几个选择: a) 进入一个封闭的天地去卖魔方, 例如一个用 GFW 高墙围起来的神奇小学, 那里的同学不知道外面的世界。 b) 依赖自己别的优势或垄断, 把魔方绑定在优势项目上销售, 例如团支书要求团员必须去团支部购买魔方。 c) 开发有差异化的新东西, 体现独特的价值。 这时另一个同学大牛出现了。 大牛同学虽然不是第一个玩魔方的， 但是他热爱魔方, 精通两种方法, 练得比果冻、小飞还要好, 但是他俩的名声已经在那里了, 怎么办? 大牛经过思考, 决定要 “change the game”， 改变游戏规则! 他开始琢磨一些花样, 经过刻苦练习, 他可以把两手放到屁股后面翻魔方, 能把一面给还原了。大牛的典型场景是这样的, 他跟同学说 - 看我表演魔方吧! 然后就转过身去, 两手在屁股后面翻魔方，这一创新也吸引了不少同学。 当市场处于饱和状条, 这时的后来者 (second mover) 要赶上领先者, 必须要花很多心思改变游戏规则。 这个场景滑稽在于 – 大牛这么努力, 但是他却看不到同学的面， 同学们渐渐对他的屁股也没兴趣了。 悲剧的结局发生在一天中午, 大牛碰到隔壁班的女孩小芳, 他激动地演示这一绝招, 但是事先没解释清楚, 就撅着屁股开始玩。 小芳大叫一声 – 耍流氓! 路过的老师把大牛拉到教导处训了一通, 没收了魔方。 大牛的“屁股魔方”渐渐成了一个传说, 一般人也看不到了。 大牛很失落, 原来还可以跟小芳搭上一两句话, 现在小芳走路都绕着他… 他意识到小芳其实就是他玩魔方的目标用户。 竞争力还有一种是“对用户的了解”, 你现在会背口诀了, 魔方玩得也不错, 你甚至还可以各种花样, 但是你发现只有男生在围观, 你的目标用户 – 女生并没有感兴趣。 你努力的方向和目标并无交集。 你的网站成了 geeky 的网站，但是你很失落。 过了不多久, 班上看似木讷的二柱同学回收魔方, 把六种颜色的塑料片挖掉, 换成各种小公主的塑料片, 再卖给同学们。 二柱还体贴地同时送一张口诀表。嘿, 居然一半的小女生都跑到二柱那里去订购他的新型公主魔方, 当然这样的魔方很花钱的, 但是小女生们似乎不在乎钱, 她们只要一个自己独特的魔方! 每天二柱一到班上, 就有几个女生主动打招呼, 问她们定制的魔方怎么样了, 有些小姑娘还娇嗔要求二柱先满足她的要求, 隔壁班的同学们也闻讯赶来, 成为二柱的粉丝, 小芳也在其中… 
几个旁观的男生不相信他们的眼睛。 “我靠!” 果冻愤愤不平地抱怨， “我果冻才是第一个会玩魔方的! ” 小飞也气炸了 – “那些口诀都是我花钱复印, 免费发给大家的! 免费, 侬晓得伐…” 大牛更不屑 - “搞什么搞，二位别生气了… 二柱这玩意技术含量太低了, 这小子压根还不会玩六面呢!” 很多同学热衷于技术和技术的创新, 但是当大家在埋头搞技术的时候, 是否注意到自己是用屁股对着目标用户? 
|
-
在 《移山之道》里, 我提到移山软件学院的游戏: 阿超的课都是下午两点钟，这时班上不少的同学都昏昏欲睡，为了让大家兴奋起来，阿超让同学玩一个叫“黄金点”的游戏： N个同学（N通常大于10），每人写一个0~100之间的有理数 (不包括0或 100)，交给裁判，裁判算出所有数字的平均值，然后乘以0.618（所谓黄金分割常数），得到G值。提交的数字最靠近G（取绝对值）的同学得到N分，离G最远的同学得到－2分，其他同学得0分。 玩了几天以后，大家发现了一些很有意思的现象，比如黄金点在逐渐地往下移动。 如果你和其他20 个聪明人玩这个游戏, 你会选择什么数字呢？ [现在请记下你的数字, 以后不能改] 你会想, 如果大家随机报数的话, 0-100 的平均数是50, 50 * 0.618 = 31. 那我就来个 31。 但是其他人也不是傻子, 他们肯定也想到了这一点。 如果大家都选 31 附近的数, 那我得选 31*0.618 = 19; 但是这些人肯定也想到了这一点, 那我要选 19 * 0.618 = 12… 然后 12 * 0.618 = 8 … 最后干脆选 0.0001 好了！ 0.0001 是正确答案么? 这取决于参与游戏的所有成员。 这个游戏不是我发明的, 我曾经在网上看到过一两篇博客提到这个游戏的来历, 其中一篇在 live space 的博客提到这最早是英国某报纸给读者出的一道题目， 现在 这篇博客随着live space 的消逝再也找不到了 (sigh!)。 我第一次实际玩这个游戏, 是2006年和华宏伟老师，黄雪斌老师 在清华软件学院的一个 （MS^2）培训班上， 两年后, MS^2 的网站连同许多同学的博客也消失了 (sigh!!). 尽管如此, 这个游戏成了我“现代软件工程”课的固定节目, 在不少大学的计算机系都玩过。 有一年春节 一个叫 nullgate 的同事抽中夏威夷旅游大奖， 但是他决定让出, 我们部门也使用这个办法来决定幸运者。 根据我多次观察, 第一次游戏的获胜数字一般离这个数字不远: 17 看出来同学们进行了平均两次的 （0.618）迭代。 如果继续玩下去, 这个数字会变么? 虽然说两次游戏之间没有任何联系, 是概率中的独立事件, 但是前一次游戏的 G-number 给了所有参与者一个强大的暗示， 以后游戏的G-number 一定会向下走。 下面是清华2008 年秋季学期一个叫 “贝爷” 的 TA 给连续12次游戏做的记录，从趋势看, 数值会逼近0, 但是变化也不是一帆风顺的, 每次触底之后, 就会小小反弹一下 。 
对于这个游戏, 不同的人有不同的领悟。 我也贡献几点: 赢者通吃 这个游戏规定第一名得到全部的分数, 第二名（不管多接近）到倒数第二名都是 0 分，最后一名还要倒扣分。 软件行业就是一个赢者通吃的坏境, 最后一名还要把自己的身家倒贴进去。 螳臂当车 在游戏中, 经常有一两个同学逆历史潮流, 提交一个 99.999 之类的分数。 但是从大趋势来看, 这些捣乱分子对大局影响不大。 我经常看到几个同学面带微笑小声商量， 一起提交几个最高分来搅局，但是G-number 还是由大多数人决定。 另外不是所有口头同意搅局的同学最后都 “守约” 提交了大数字… 这也是“囚徒的困境”的一种。 只先一步 参加游戏的人都是在top N 的大学生, 或者IT 从业人员, 数学足够好, 都是聪明人。 我把题目公布之后, 一些人马上就说 – 这肯定收敛到0啦！ 他们交上来一个 (0.00001 ) 的答案 (提交的数字必须大于 0 )。 遗憾的是, 一起玩游戏的人其他人不这么想。 一个小团体, 或者一个小社会的社会共识 (consensus) 从来不是最激进的, 每个个体发出自己看似随机的声音, 它的进步是缓慢的, 有时还倒退一下。 如果只看微博上的发言, 你会觉得德先生和赛先生早已是国人的共识; 如果只参加最前沿的科技沙龙, 你会觉得明天大家都会用人体嵌入智能芯片同时会同步电子书邮件微博SNS再加GPS再有云计算， 你如果不推出相应产品就会被淘汰… 但是社会作为一个整体还没有进步得这么快。 那些成功的企业只是比大众的平均值先走了一小步 （平均值 * 0.618）, 就是这一小步, 让大部分人看到了产品的“相对优势”从而接受产品。 关于技术创新, 一些趋势（例如社会网络）， 大家早就看到了, 也有一些产品推出, 但是往往最后成功的产品成功在时机上。 一本很有名的书 - cross the chasm 描述了大众对新技术接受的曲线, 曲线下面的面积大致对应人数。 大众平均值的0.618 就在 “Early Adopter” 那里, 有时一个崭新的技术, 推出的时机太早 (它的值比G-number 小一点), 它就跨不过那道沟 (Chasm).
做前沿研究的人, 可以早于其他人很多年提出新想法, 但是这些想法一般都是在 “Innovator” 那个圈子里有影响, 这些想法要等若干年才能由成功的企业家看准时机推向大众市场。 Technology Hype Cycle 说到时机, 任何新技术都有一个自身发展的规律， Gartner 的 Jackie Fenn 写了一个很有意思的报告, 提到了 Technology Hype Cycle。 随着一个新技术经历不同的阶段, 公众对它的期望值, 炒作值也有很大的差别. 1）技术触发期 （技术走出实验室, 天使投资, 第一轮产品出现, 尝鲜者试用） 2）期望膨胀期 （博客/微博/媒体炒作, 泡沫达到最大, 大众开始跟进, 负面报道出现） 3）迷茫期 (开始整合, 第二/三轮融资, 但是只有 5% 的目标用户正式使用产品，第二版产品出现) 4）低调发展期 （漫长的低调发展, 最佳的方法和实践开始出现, 第三代产品出现, 易用性, 和其他产品的整合更好 ） 5）主流发展期 (成为成熟的技术, 市场以20-30% 的速度成长)
很多大家正在使用的“新颖“产品, 往往是经历了迷茫期之后的二代产品, 那些在泡沫最大的时候匆忙出现的第一代的产品大多数都没有等到这一天 (电子书, 平板电脑， 社会网络等)。 现在技术圈子里大家都在吹的那些技术 SoLoMo， Cloud等等, 它们处于哪一个阶段? 你应该贸然出手么？ 和上图相对应的是一个高科技公司股价变化图, 炒股票在短期内是一个群体在估计下一个数字的游戏。 从图表中你可以看到sell off, media, enthusiasm，greed, fear， dispair 等种种因素在起作用, 耳语效应， 从众效应都在推波助澜，根据这个表, 你心仪的公司处于哪一个阶段? 你要买入还是抛售? 
(图表来源: http://weibo.com/1454560380/eCwDqDN28ta) 群体对马前卒的反作用 社会的趋势或者说“风尚”有时候也是无情的, 当年以“革命军中马前卒”写出 <革命军>的激进分子邹容， 为他的理想献身二十多年后, 就被列为 “落伍者” (见鲁迅先生的 “革命军马前卒”和“落伍者”)。 八十年代, 一个叫朱逢博的艺术家开了一个 轻音乐咖啡厅, 结果被主流媒体抨击为“资产阶级自由化“的表现。小朱同学在写检讨的时候感慨地说 – 我往往是走早了一两步… 她现在要再开此类生意, 估计有些人会嘲笑她落伍。 但是一个群体如果没有这些马前卒, 它平均值不会向前移动，群体如果没有提供一定的宽容, 那也没有这些马前卒生存的空间。 历史上有 the tyranny of the majority, 大家投票把自己不喜欢的人驱逐出境。 例如我们把游戏规则改一下: 除了获胜的同学之外, 所有数字小于最后g-number 的同学一律扣分, 你会看到怎样的g-number 曲线? 遗憾的是在大多数群体中， 冒着枪林弹雨冲在前面的人往往还会遭到来自后面的冷箭。某些暮气沉沉的群体 (国家/企业/学校) 就是这样。 Interpersonal Awareness & Social Awareness 说着说着就扯远了, 进入了我不熟悉的领域，大家姑妄听之。。。 科学家认为，俺们人类有别于其他动物的最大特点是俺们大脑里有发达的部分，处理“别人在做什么“ 和 ”未来会发生什么“ 这些事情。能摆脱 [自我/当下] 而考虑到 [别人/将来], 从而主动地为群体和将来行动， 这是人和其他动物不同的地方（来源: http://www.pbs.org/wnet/humanspark/ ）。能在一个群体中审时度势, 拉帮结派，尔虞我诈，选择时机出手, 俺们人类的确太擅长了。 在微软, “Interpersonal Awareness” 是员工素质的一个重要部分, 把它放到“黄金点游戏“ 这个场景中, 你得了解一屋子的同学大概是在想什么 ，你如何影响他们, 你才能有获胜的希望。每个人独立埋头推导公式, 是得不出获胜的数字的。 国外还有Social awareness + emotional skills = successful kids 的说法, 据说此类教育在小孩到了高中甚至成年都有积极的影响。他们没有提到“奥数“ 对小孩将来的影响, 我国政府深表遗憾。 反过来看, 天朝的同学们从小就被灌输 “搞好自己的学习就可以了“， ”把考试考好, 以后就好了“ – 但是从来没有让同学们考虑目前的死记硬背和将来是什么关系。 一个软件团队, 如果大家都不考虑“别人“, “未来”， 光是每个人独立地搞自己眼前的一摊事, 是不行的, 把自己的代码重构出花来也不行，把SCRUM （史克朗姆）玩到极限也不行。 这也是我觉得聪明的同学们欠缺较多的地方。 所以《现代软件工程》课包括了很多 ”两人合作”, ”黄金点游戏“, 还有 ”估算工作量“ 等练习。 实验 在这篇文章的开头, 我要求你记下一个数字, 请把它诚实地填在后面的评论中吧, 希望它最靠近G-number, 所有数字的平均值的 0.618倍. 你常在这里混，Social Awareness 很强的, 这个应该不难。
|
-
在一个神奇的国度里生活着许多动物, 其中有猪, 鸡, 和鹦鹉。 它们每天搞头脑风暴, 琢磨如何创业, 最后鹦鹉提议它们合伙开一个早餐店: 
具体分工如下: 猪: 提供猪肉, 做熏猪肉 (bacon) 鸡: 提供鸡蛋, 做煎蛋 鹦鹉: 提供咨询, 它会每天阅读大量博客, 给其他团队成员提供建议, 例如最新业界趋势, 最新术语, SaaS, N-层架构, 创业明星当年的轶事, 等等。 看上去是一个搭配很合适的组合, 但是这项创业对三个动物的负担是一样的么? 它们应该各自占多少股份? 一旦创业失败, 猪, 鸡, 和鹦鹉会各自失去什么? 在一个团队中, 不同的成员来自五湖四海, 为了一个共同的目的, 走到一起来了 (至少表面上是这样). 在一起吃饭的时候大家意气风发, 群情激奋，但是不同的人对于团队的承诺是不一样的 - 有些人是 猪 - 他们或者辞掉了工作, 投入创业中; 或者这一门软件工程课是他们的必修课, 他们一定要拿到高分, 才能提高自己的GPA, 申请到好学校。 对他们来说, 要想项目成功, 他们要拿出自己身上的肉, 背水一战; 一旦失败, 自己的老本也赔进去了. 他们的投入级别是 - 全身心投入 (committed). 有些人是 鸡 - 他们能做重要的贡献, 但是项目一旦失败, 他们的损失并不大, 他们的生活还可以继续下去。例子: 有些人周末来给项目帮忙, 平时自己上班; 或者是选修软件工程课; 或者他们已经保研, 只要这门课混及格就行。 他们的投入级别是 - 参与 (involved). 有些人是 鹦鹉 - 他们有漂亮的羽毛, 能说会道, 联系广泛, 能提出很多建议, 很多点子. 但是他们不执行, 除了一些人云亦云的观点和一些关于架构的空谈之外, 他们没有其他投入. 他们和你谈项目的时候, 会不时地回短信. 他们也写博客, 但是博客上充满了未注明来源的转载。 一旦项目失败, 他们就会飞到另一个项目中去。 他们的投入级别是 – 围观 (bystander). 一个人可以同时做很多事, 这些事情对每个人的轻重缓急各不相同, 有些事情只能业余帮一些忙, 这无可厚非。 加入一个团队时要弄清楚自己在团队中投入的级别是什么, 别人的期望值是什么. 不要拿着卖白菜的钱, 操那卖白粉的心 - 太不值得。 人可以在 n 个地方做鸡, 或者 n*m 个地方做鹦鹉, 但不可能在两个地方同时做猪。 很多牛人, 例如 BillG 同学和 MarkZ 同学, 就只好在学业和事业中抛弃一个, 全身心地投入另一个。 把一件事情做成需要很多人的帮助, 创业者要不拘一格吸引人才。 但是我们也要分清楚团队成员的投入/承诺/责任是属于哪一个级别, 哪些是猪, 哪些是鸡, 哪些是鹦鹉。 最坏的情况是找到一群鹦鹉, 大家叽叽喳喳, 来回扑腾, 好不热闹。 但是最后大家做鸟兽散, 只落得一地鸟毛。 在竞技体育, 商业竞争中, 如果一个队伍的队员都是猪, 另一个队伍的队员都是鸡, 那谁胜谁负, 就很清楚了, 鹦鹉可以做拉拉队, 但是并不决定最后的胜负。 驱动和责任在项目管理中是很重要的因素。 有责任, 有投入, 有期待, 才有回报。 在<现代软件工程>这门课中, 我也要求同学们在自己的团队中给每个成员决定一个 “团队贡献分”, 一般来说, 贡献和投入是很相关的。 你的团队中, 有多少猪, 有多少鸡, 还有多少鹦鹉? //注: 猪和鸡的故事在这里也有: http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
|
-
软件工程的历史虽然说只有短短的四十多年时间 （1968 年提出）， 但是软件工程的主体 – 人类 – 已经出现在世界上好些年了。 人还是那些人，事儿还是那些事儿, 好的，坏的，可笑的模式同样会出现。 我看到同学们在分析前面的学生的软件项目的时候， （link1, link2）我不禁想起一个相声 – 画扇面。 我们不妨拿它和软件工程做个比较: | 画扇面 | 做软件工程团队项目 | | 相声是一门说学逗唱的艺术… 甲: 我刚买了一把纸扇 乙: 哦， 拿来看看，一把白纸扇… 上面空空如也太可惜，拿不出手啊。 如果能画上画就更好了。 我这几天也没什么事, 我就给你免费画画！ | 软件工程讲究的是需求分析, 项目管理, 开发, 测试和维护… 甲: 我觉得咱们团队项目做一个好用的小工具就好了, 我已经做好了一个原型。 乙: 这想法固然好, 但是我们这么些个编程高手, 就做这么小的一个工具, 未免拿不出手。我们要把它搞大! | | 甲: 太好了，您能画什么? 乙: 画个美女图怎么样? 美女出浴图, 或美女春游图都可以考虑。 甲: 我激动ing… | 甲: 那我们做什么呢? 乙: 我们扩展一下, 把所有工具都实现了，一统天下。几种工具结合起来! 甲: 我激动ing… | | 过了几天, 甲问: 我那美女画好了么? 乙: 喔，美女, 画好了！你看这美女的小脸蛋儿, 眼睛稍稍大了点… 但是, 我不如给你改成张飞算了！都是人体, 我可以很快重构一下, 我画张飞最拿手了，过几天就好。 | 过了几星期… 甲: 通过调研才发现, 这么多工具都有自己独特的需求, 不同需求互相冲突怎么办? 乙: 我们可以做成一个通用的工具，统一需求, 解决用户从头到尾的问题。 | | 过了几天, 甲问: 我那张飞？ 乙：张飞？！ 喔对的， 张飞也画得差不多了, 嗯, 你看这张飞的胡子， 这身躯… 是粗了点… 要不咱们画成山水，这张飞马上就可以变成一块怪石！ | 过了几周… 甲: 通用的工具听上去很好, 但是太通用了, 怎么写代码呢？我们到底要实现哪些具体功能呢? 乙: 我们可以做成一个开发式的平台！这样所有人都可以做一个插件, 来实现这个平台的一些功能！而且别人还可以用我们这一个通用的框架开发任意别的软件。 甲: 我激激动ing… | | 过了几天, 甲问: 我那山水? 乙: 啊，山水… 我也画好了。 你看那巨石，很巨大, 很给力吧… 构图有点那啥… 容我再改改。 甲: 您什么时候画好? 这夏天都快过了。 乙: 要不然这样, 我把扇面全涂黑了, 你再找人往上写金字好了！ 甲: 您真是大师呀! | 过了几周… 甲问: 项目发布时间到了, 我们的平台还没有，工具还没连起来，怎么办? 乙: 咱们可以我们目前能编译通过的模块都封装成一个“库”，把没写完的东西都叫“中间件”，然后把项目开源到网上, 建立一个网上社区！ 有很多开源的朋友闲得没事， 可以给我们的代码写一些注释, 写一些单元测试等等。这是我们对开源运动作的巨大贡献啊。
甲: 我们太伟大了… 不过老师会给我们多少分呢? | 很多学生学了一些编程语言, 读了一些技术博客, 一般都豪情万丈. 他们做一个项目恨不得展现自己平生所学, 再加上前沿技术, 做一个轰动性的创新。 这固然值得鼓励， 但是经验显示, 这些往往都不能成功。 我们看看成功的例子, 他们是怎么开始的, 例如Linux 刚开始的时候: I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones... (source) 我们还看到管理学大师 Peter Drucker 的忠告 – Those entrepreneurs who start out with the idea that they'll make it big – and in a hurry – can be guaranteed failure. (source) 解决大问题固然让然感觉美妙, 但是把小问题真正解决好, 也不容易, 我们回头看看博客园, csdn 等IT 人士云集的网站, 每天都有很多巨大的新想法、惊世骇俗的评论冒出来, 争论美女/张飞/巨石的重构问题, 对一些通用的框架/平台发出一些人云亦云的评论, 等等。 这些文字, 大多数会转化为墨水, 把扇面涂黑, 让后人在上面写下金字。
|
-
-
-
下面是各个项目小组的情况, 每个小组有 6 – 10 名同学组成: 这些学生大多数是来自于一个叫交叉信息研究院的地方, 江湖上人称姚班。 他们都是祖国的小花朵, 在博客园安了家。
|
-
上课时间地点: 周一下午 1:30 – 4:50, 六教 6A/201 暂定时间表 (会根据学校放假, 老师/学生的具体要求变化): | Week | Date | Lecture (授课) | Talk (辅导/交流/演示) | Project | blog requirement | | 1 | 2/21 | Intro (课程简介, 分组), number game, iPad, team project, assignment of I-project.
Software Engineering (软件工程概论) | | i-project (个人项目) | set up team blog, intro of team members, link to http://cnblogs.com/xinz | | 2 | 2/28 | Unit Test (单元测试), Personal Software Process (个人软件流程 PSP), Code Quality (代码质量的各种标准)
Innovation and Myths of Innovation (创新的迷思). | | | rough assignment of team (dev, pm, test) | | 3 | 3/7 | Experience Sharing (Qiufeng, Guangping, Hao) | P1 review | pair project (1) 结对项目 (1) | | | 4 | 3/14 | Testing (测试) (Pairu) | | | | | 5 | 3/21 | collaboration (两人合作), influence (影响说服别人的多种方式)
team project: NABC (项目可行性分析) | | pair project (2) 结对项目 2 | first round of team project review | | 6 | 3/28 | Team-CMMI (团队结构, 文化, 成熟度模型 CMMI) Development Process (软件开发的各种模式)
Agile Process | | | 博客: 项目的NABC 分析, 软件所在的行业分析, 项目目标, 人员分配 | | 7 | 4/4 | 团队项目陈述 | P2 review | Team Project Kick Off 团队项目开始 | (move to 4/2) 博客: 典型用户是谁? 请用Persona 表现出来。 典型的场景是什么, 软件的各个功能是如何结合起来完成这一场景的?
博客: 小组的测试计划, 要测试什么, 计划怎么测试? | | 8 | 4/11 | Agile Proj. Mgmt w/ TFS (用TFS 进行项目管理) (Cherry) | | Milestone 1
(里程碑 1) | | | 9 | 4/18 | Spec and PM (软件规格说明书, 项目经理) Estimation, WBS | | daily scrum | 博客: 每天一篇博客, 显示scrum 结果和TFS 上的进度 | | 10 | 4/25 | Scenarios (基于场景的设计) | | daily scrum | 博客: 每天一篇博客, 显示scrum 结果和TFS 上的进度 | | 11 | 5/2 | Release (软件的发布)
MSF (微软软件解决方案框架)
Dev-History (微软软件开发管理的历史) | UI/UX report | alpha release, Review/BugBash | 博客: 主要功能描述, 软件Alpha 版本下载及使用说明 (如果可能外部下载的话) | | 12 | 5/9 | Risk Mgmt (软件项目的风险管理) | Review | Milestone 2 (里程碑2) | 博客: BugBash 的结果报告 (TFS 截屏).
博客: 各自团队的 Alpha Release Postmortem | | 13 | 5/16 | Book Report | | daily scrum | daily scrum, 博客显示每天进度 | | 14 | 5/23 | Book Report | | daily scrum | daily scrum, 博客显示每天进度 | | 15 | 5/30 | | | beta release | 发布beta 版本 | | 16 | 6/6 | Postmortem (项目的回顾与反思) | Final Review (最终汇报, 复审) | (move to weekend) | | | 17 | 6/13 | | ship party | | | | 18 | 6/20 | | | | | 书籍推荐: http://yishan.cc/blogs/xin/archive/2009/01/25/1014.aspx 2009 秋季学期的成绩统计: http://yishan.cc/blogs/xin/archive/2010/01/23/thu.aspx 2008 年秋季学期同学的项目: http://yishan.cc/blogs/xin/archive/2009/03/29/1046.aspx 2007 年秋季学期同学的项目: http://yishan.cc/blogs/xin/archive/2007/12/27/826.aspx
|
-
我们自从 2008 年出版了<编程之美> 后, 销量还不错。 作者们把获得的版税捐出来做一些公益活动, 帮助了两个欠发达地区的中学, 福建漳平一中和湖北五峰县一中。 两年时间过去了, 我们和这些学校也相忘于江湖。 最近我们得知 - 漳平一中的同学们在计算机比赛中获得好成绩, 有13个学生参加NOI, 12个获奖, 创福建龙岩地区最好成绩. http://www.zpsedu.gov.cn/wzzx/jygl/zxjy/201012/2140.html 这些成绩和我们当初的捐赠有联系么? 也许有, 我想大部分是来自老师和同学们自己的努力。 不管如何, 我们送了下面的书籍作为祝贺。五峰县一中的同学也得到同样的一批书。 这些书籍是我们的编辑周筠老师挑选的, 每书3-5本, 沉浸在理科学习和计算机信息学比赛的同学们, 可以好好换换脑子。 | 1 | 梁漱溟 | 朝话：人生的省悟 | | 2 | 傅雷 | 傅雷家书 | | 3 | 路遥 | 平凡的世界 | | 4 | 司汤达 | 红与黑 | | 5 | 汪曾祺 | 汪曾祺集（杨早选编） | | 6 | 沈从文 | 边城 | | 7 | 费曼 | 发现的乐趣-走进费曼丛书 | | 8 | 费曼 | 你干嘛在乎别人怎么想 | | 9 | 马丁·伽德纳 | 啊哈，灵机一动 | | 10 | 乔治·伽莫夫 | 物理世界奇遇记 | | 11 | 原研哉 | 设计中的设计 | | 12 | 蔡康永 | 蔡康永的说话之道 | | 13 | 李欧梵 | 我的哈佛岁月 | | 14 | 何兆武 | 上学记 | | 15 | 蒋梦麟 | 西潮与新潮 | | 16 | 刘瑜 | 民主的细节 | | 17 | 胡江堂 | 我是一只IT小小鸟 | | 18 | 李笑来 | 把时间当作朋友 | | 19 | 刘墉 | 我不是教你诈 | | 20 | 派克 | 少有人走的路（一套3本） | | 21 | 戴尔 | 你的误区 | | 22 | 茅于轼 | 生活中的经济学 | <编程之美> 的版税在经济发达地区实在算不得什么, 但是中国这么大, 还是有些地方可以发挥一些作用的。 如果你知道有需要的中学, 请和我们联系。
|
-
这次 <现代软件工程> 的4 个团队要做下面的项目: 第一组: 一个BBS 的通用客户端 第二组: 挖掘学术圈内的师承关系 第三组: 真人拳皇 - 把你老板的照片变成对手, 然后给他一顿痛打 第四组: 一个叫呆呆的东东。 他们缺什么呢? 缺一些有实际经验的人给他们拍砖. 所以如果你做过一些项目, 手里有几块砖, 那就拍上去吧。
|
-
全国历年参加高考人数和录取人数统计 (1977年～2010年) 
| 时间（年） | 参加高考人数（万人） | 录取人数
（万人） | 录取率
（%） | | 1977 | 570 | 27 | 4.7% | | 1978 | 610 | 40.2 | 6.6% | | 1979 | 468 | 28 | 6.0% | | 1980 | 333 | 28 | 8.4% | | 1981 | 259 | 28 | 10.8% | | 1982 | 187 | 32 | 17.1% | | 1983 | 167 | 39 | 23.4% | | 1984 | 164 | 48 | 29.3% | | 1985 | 176 | 62 | 35.2% | | 1986 | 191 | 57 | 29.8% | | 1987 | 228 | 62 | 27.2% | | 1988 | 272 | 67 | 24.6% | | 1989 | 266 | 60 | 22.6% | | 1990 | 283 | 61 | 21.6% | | 1991 | 296 | 62 | 20.9% | | 1992 | 303 | 75 | 24.8% | | 1993 | 286 | 98 | 34.3% | | 1994 | 251 | 90 | 35.9% | | 1995 | 253 | 93 | 36.8% | | 1996 | 241 | 97 | 40.2% | | 1997 | 278 | 100 | 36.0% | | 1998 | 320 | 108 | 33.8% | | 1999 | 288 | 160 | 55.6% | | 2000 | 375 | 221 | 58.9% | | 2001 | 454 | 268 | 59.0% | | 2002 | 510 | 320 | 62.7% | | 2003 | 613 | 382 | 62.3% | | 2004 | 729 | 447 | 61.3% | | 2005 | 877 | 504 | 57.5% | | 2006 | 950 | 546 | 57.5% | | 2007 | 1010 | 566 | 56.0% | | 2008 | 1050 | 599 | 57.0% | | 2009 | 1020 | 629 | 61.7% | | 2010 | 947 | 657 | 69.4% | 附：1977年高考录取通知书一份。
| 入学须知
在全国人民紧跟党中央战略部署，深入揭批“四人帮”的大好形势下，经过统一招生，你被录取到我校学习，我们满怀深厚的无产阶级感情，表示热烈欢迎！
凡我校录取的学生，毕业后都要服从党的需要，到祖国最需要、最艰苦的地方工作。
学生来校途中，应提高革命警惕。
新生报到时，必须带户口迁移证和粮油关系转移证及商品供应关系，必须每人一张，要注明原地区停止供应时间，从三月份开始由学校供应。
| 1978年，610万人报考，原计划招生29.3万人，后增加近11万人，共录取40.2万人。新生当年秋入学。
1979年，全国高考首次统一在7月7—9日三天进行，共有468.5万人参加高考，录取了28.4万人，录取率为6.1%。 1980年，预选制后，大约只有40%的学生有资格参加高考。 报考本科院校的考生外语成绩按30%计入总分。考试成绩只通知考生本人，不张贴公布。取消考生查阅试卷的规定。当年高考共有333万人报考，共录取28万人。一些省、市、自治区扩大招收自费走读生7000多人。
1981年，理工农医类加考生物，按30%计入总分。当年高考共有259万人报考，共录取28万人。
1982年，共有187万人报考，共录取32万人。
1983年，全国统考时间调整为7月15—17日。当年高考共有167万人报考，共录取39万人。
1984年，全国统一考试时间恢复为7月7—9日。当年高考共有164万人报考，共录取48万人。 一个叫 “马云” 的小伙子考上了杭州师范学院英语专业。
1985年，176万人报考，共录取62万人。
1986年，191万人报考，共录取57万人。
1987年, 228万人报考，共录取62万人.
1988年，272万人报考，共录取67万人。
1989年，266万人报考，共录取60万人。 (有人回忆当年录取人数比上年少了很多)
1990年：录取 60万
1991年：录取 62万
1992年：录取 75万
1993年：录取 92万
1994年：录取 90万
1995年：录取 93万
1996年：录取 97万
1997年：录取 100万
1998年：录取108万人，“80后”进入大学校园.
1999年：全国高校大规模扩招始自1999年. 按当年统计, 全国普通高校招生160万人,比1998年增加了52万人,增幅高达48%. 总体录取率首次突破50%. 据说领导们提出了产业化的口号, 后来又否认此事。 与此同时, 大部分大学的教师数量, 质量, 教学环境没有得到相应的提高。
2000年：录取221万
2001年：录取260万人
2002年：录取320万人
2003年：录取382万人, 扩招之后的第一批大学生离开学校, 走向社会。
根据外国媒体报道, 2003-2009年, 中国农民工的工资上涨了 80%, 同期大学毕业生的第一份工资没有变化 (尚未考虑通货膨胀因素). 这就是扩招的后果之一.
2004年：录取447万人
2005年：考生877万，录取504万人
2006年：考生880万，录取530万
2007年：高校计划招生567万人，与30年前报考人数极其接近，但是录取比例约为2:1。
2008年：考生人数达到空前绝后的1050万，高考招生人数也创新高，计划录取599万人，录取比例57%。
2009年：考生人数 1020 万, 录取629 万.
2010年：报考人数 947万, 录取人数 657万. 部分资料来源: http://gaokao.eol.cn/kuai_xun_3075/20100125/t20100125_444378.shtml http://www.msnbc.msn.com/id/40626200/ns/world_news-the_new_york_times
|
-
屈指一算, 我已经讲了3年 <现代软件工程>, 教了 4 个班。
2007 - 2009 清华大学理论计算机科学研究中心 (姚班)
2009 北航计算机系
还有在北大合作的教学:
2007 - 2009 北京大学软件学院 (课程名叫 - 微软软件实现技术, 我是讲师之一) 由于反响不错, 今年秋天开始, 我给中科大的学生上课. 软件工程牵涉的范围很广, 同时也是一般院校的同学反映比较乏味的课程。 但是软件工程的技术对于投身IT 产业的学生来说是非常重要的。 经过几年的探索, 我总结了在17周的时间内让同学们通过 “做中学 (Learning By Doing)” 掌握实用的软件工程技术的教学计划。 这是给中科大 《现代软件工程》 的课程安排： 开始: 2010/11/1 结束: 2011/3/14 教学计划总长: 17 周 (扣除放假之后) 授课: 14 次 老师授课 辅导课: 9 次 (辅导/交流/演示) 学生主动汇报进展, 心得, 提出问题, 老师及专业人士给予辅导。 学生项目: 个人项目, 结对编程项目 (两个), 团队项目 | Week | Date | Lecture (授课) | Talk (辅导/交流/演示) | Project | | 1 | 11/1 | Intro (课程简介, 分组) I-project 个人项目介绍 | | i-project (个人项目) | | 2 | 11/8 | Software Engineering (软件工程概论), Unit Test (单元测试) | | | | 3 | 11/15 | Personal Software Process (个人软件流程 PSP), Code Quality (代码质量的各种标准) | SilverLight | pair project (1) 结对项目 (1) | | 4 | 11/22 | collaboration (两人合作), influence (影响说服别人的多种方式) | P1 review | | | 5 | 11/29 | Team-CMMI (团队结构, 文化, 成熟度模型 CMMI) Development Process (软件开发的各种模式) | | pair project (2) 结对项目 2 | | 6 | 12/6 | Innovation (软件业的创新) Myths of Innovation (创新的迷思), Innovator's dilemma (创新者的两难) | P2 review | | | 7 | 12/13 | NABC (项目可行性分析) Spec and PM (软件规格说明书, 项目经理) | Book Report | Team Project Kick Off 团队项目开始 | | 8 | 12/20 | Testing (测试) | | Milestone 1 (里程碑 1) | | 9 | 12/27 | Proj. Mgmt w/ TFS (用TFS 进行项目管理) | | daily scrum | | 10 | 1/3 | Scenarios (基于场景的设计) | | daily scrum | | 11 | 1/10 | Release (软件的发布) | | alpha release | | 12 | 1/17 | MSF (微软软件解决方案框架) | Review | Review/BugBash | | 13 | 1/24 | Dev-History (微软软件开发管理的历史) | feedback | Milestone 2 (里程碑2) | | n/a | 1/31 | Holiday | | Holiday | | n/a | 2/7 | Holiday | | Holiday | | 14 | 2/14 | Risk Mgmt (软件项目的风险管理) | Book Report | daily scrum | | 15 | 2/21 | | | daily scrum | | 16 | 2/28 | | UI/UX report | beta release | | n/a | 3/7 | Postmortem (软件项目的回顾与反思) | | | | 17 | 3/14 | | Final Review (最终汇报, 复审) | | 教材 (3本, 同学选择一本, 同时借阅另外两本) : 1. Rapid Development Steve McConnell (ISBN 1-55615-900-5) 中文版 快速软件开发 斯蒂夫·迈克康奈尔 著 译者: 席相霖 等 ISBN 9787505372856 2. Code Complete (2nd Ed) Steve McConnell ISBN: 9780735619678 中文版 代码大全 (第二版) 斯蒂夫·迈克康奈尔 ISBN: 7121022982 3. 移山之道 – VSTS 软件开发指南 邹欣 (ISBN: 9787121071485) 主要参考书: Dreaming in Code by Scott Rosenberg, ISBN: 9781400082469 中文版《梦断代码》, 译者 韩磊, ISBN: 9787121066795 其他参考书见书单 <link>
|
-
作为 <现代软件工程> 的一个作业, 我要求同学们把 英文的敏捷开发原则 翻译成中文并解释。 大部分同学都提供了持续重构, 不断提高的版本。 技术翻译专家余晟老师也对其中较难翻译的三条原则提了很好的建议。 下面是我的尝试, 翻译要做到 信 达 雅 很难, 而且中国的软件工程实践有自己的特色, 别家的格言警句有时候未必能引起共鸣。不管如何, 我们先得有一个靶子, 然后大家才能拍砖, 是不是? 欢迎提意见。 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 翻译：尽早并持续地交付有价值的软件以满足顾客需求。 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage 翻译：敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale 翻译：经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。 (Team1 MicroTeam 的翻译) 4: Business people and developers must work together daily throughout the project. 翻译：业务人员和开发人员在项目开发过程中应该每天共同工作。 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 翻译：以有进取心的人为项目核心，充分支持信任他们 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 翻译：无论团队内外，面对面的交流始终是最有效的沟通方式 (Team2 ASE 的翻译) 7: Working software is the primary measure of progress. 翻译: 可用的软件是衡量项目进展的主要指标 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 翻译: 敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去。 9: Continuous attention to technical excellence and good design enhances agility. 翻译: 只有不断关注技术和设计才能越来越敏捷. (由于某种尚未明了的原因, Team3 没有翻译这一段, 他们翻译了4-6, 10-12, 但是就是没有翻译 7-9). 10: Simplicity--the art of maximizing the amount of work not done--is essential. 翻译: 保持简明 - 尽可能简化工作量的技艺 - 极为重要 11: The best architectures, requirements, and designs emerge from self-organizing teams. 翻译: 只有能自我管理的团队才能创造优秀的架构, 需求和设计. 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 翻译: 时时总结如何提高团队效率, 并付诸行动。 (Team4 CodingCrazy 的翻译)
|
-
敏捷开发, 谁不会呀, 不就是 没文档, 出活快, 用户说啥都能改? 下面是一个笑话, 王屋村的大牛说 - 我最近转手接了一个活, 完事能挣四五万, 我拿过图纸一看, 不就是盖一烟囱吗? 我们是敏捷 (Agile) 的团队，没文档, 但是出活快, 马上甩开膀子开始干活！ 
都快盖好了， 客户来检查，把我打了一顿！我冤枉啊！ 
原来, 图纸看倒了，人家让挖口井。 不过, 我们是敏捷的团队, 被客户打了也要拥抱变化, 好不容易砌好的烟囱不能这么废了, 要不断重构, 代码重用。 于是我们在地上挖了一个大坑, 然后把重构后的烟囱强力插入, 终于把这口 “井”做好了! 我在《现代软件工程》这门课上讲到了敏捷开发流程, 其中内容比 “没文档, 出活快, 用户说啥都能改” 要多得多。 下面把敏捷宣言网页中提到的大意转述如下: | 现有的做法 | 敏捷的做法 | | 流程和工具 | 个人和交流 | | 完备的文档 | 可用的软件 | | 为合同谈判 | 与客户合作 | | 执行原定计划 | 响应变化 | 我们认同“现有的做法”有其价值, 但是我们更倾向于“敏捷的做法”。 关于敏捷软件开发的 12 条原则, 仁者见仁, 智者见智. 我的翻译在这里。
|
|
|
|