黄玉的大作，收藏啦
上周五，metlife的老大过来了，找所有team”训话”,旁边站一位微微秃顶的中国人，猜想应该是美国那边的二老大，一副要说点什么的样子。我当时对他的好奇远远大过那个”训话“的老大。可最后也没说一句话。
现在对印度人一点都不感冒了。之后就是一通政治和历史，原来这位也是元老级人物。所谓”metlife老大“，不是美国metlife公司的老大，只是cognizant的负责这个客户所有项目的老大。我问他，他所看到的中国团队有什么比其他美国，印度团队不一样的地方，老头居然说他眼中所有的团队都是一样的 - energetic, passion.Come on! 一共就来几天就看出energetic,passionate。这样的回答显然是不会让人满意的，可最后也还是让他蒙过去了，谁让人家是老大呢？
那我看看不一样吧，只比较中国和印度的团队建设，一家之言。只有有比较，有不同，才会发展嘛。（之前似乎也比较过，算是新的认识吧）
1.团队发展，可能是国内这些年IT行业发展的太快，竞争太激烈，很难看到有可以发展超过5年的完整团队，大多数都是零零散散2，3年就各奔前程了，大多数人都不会考虑对团队的其他人负责，其他人也都可以认同他的选择。想想原因应该和中国人天生缺乏安全感有关系，而且现在这个时代也确实无法让人有安全感，万一出点意外什么的，真的想都不敢想。说远了，团队永远都没有成熟的时候，而一个成熟的团队恰恰是成功产品和项目的基础。
2.团队精英，中国人认为团队精英应该是那些技术过硬的牛们，而印度人则比较倾向于思考方式以及沟通能力。就我个人的经历看到的，也许他技术一塌糊涂，没有人喜欢维护它的代码。但他写的东西不会很复杂，是个人给点时间都可以知道怎么回事，怎么维护。但是他和客户还有manager说话就是很得体，“显得”很专业。是啊，代码谁回去看呢？除了自己最多就是一两个人，赏识你又怎么样，客户又不会看。
我相信代码写的好看的人同样可以把沟通做的很好，因为这二者都是一样的 - 怎么把东西做的好看。
3.侧重点
上面这一点也说了，侧重点的问题。我再说说后果，印度的软件工程师因为更注重沟通和某个行业的领域相关知识，所以在业务分析能力上要比国内的“纯”软件工程师强很多。所以要么经常看到的就是傻乎乎的印度菜鸟，要不就是看到什么都搞得定的印度大象。俺们的偏科有点严重。
（露怯了，那个中国人是这边新来的boss，一年真的是，可以发生很多事，回来要update的东西很多）
如果只单纯的从程序设计的角度去理解模式是不够的。
有时候看看那些封装，抽象和接口定义很容易有一个想法 - 何必呢。大师都说这是为了解耦，因为软件管理终归是依赖的管理，模式的背后同样是为了更好的管理依赖。
依赖管理的好坏从模块之间的划分就可以看出，最终的好处体现在开发,测试以及最后的整合的简化。从软件工程的角度可以很容易的体会出依赖管理的重要性。
说说抽象工厂模式，最常用的就是DAOFactory，可以有很多方法创建各种DAO对象。例如
DaoFactoryIF{
UserDaoIF getUserDao();
MemberDaoIF getMemberDao();
}
DaoFactoryImpl{
UserDaoIF userDao;
MemberDaoIF memberDao;
UserDaoIF getUserDao(){return userDao;}
MemberDaoIF getMemberDao(){return memberDao;}
//setters
}
DaoFactoryImpl通过类似spring这样的框架的帮助下注入所有的依赖，即真正的UserDaoIF,MemberDaoIF的实现。
这样的好处是什么呢？从DaoFactoryImpl这个类看，它并没有依赖任何具体实现。在发布时，所有的接口被发布为inf.jar，而各种实现 impl1.jar,impl2.jar…则是都只依赖于inf.jar。常见的错误做法是做成all.jar，也就是不管3721发布到一起，这么做也不能说绝对的不好，但如果要更大程度上的复用，避免局部的copy/paste，还是要把依赖划分的清楚一点，虽然这样做要求一些集成（integration）的能力。
今天读到一篇文章 - Anatomy of a runaway IT project
作者只是以一个虚拟项目 - FUBAR.罗列出问题,实例和风险,而并没有提出他的解决方法.似乎FUBAR项目的这些问题并不是像常见的软件问题一样 - 用工具就可以解决. 很多情况下都是掺杂了一些政治因素.比如经理的升职,表面文章,以及一些人情因素,比如情绪化,leader缺少个人魅力…有几条比较”伪”,过于政治了.
QUALITY OF WORK AND EFFORT(工作质量和投入)
问题:太多的东西要搞(算法设计,源代码,系统配置,设计架构文档,测试,缺陷跟踪,计划任务),太多而无法确保其符合标准和保证质量.
–其实这些问题可以通过流程化来避免,当然流程化还是需要很多文档.这个一直都是让人很头疼的问题.AUP似乎是一个方向 - 通过快速迭代,直接反馈,TDD来控制,同时减少不必要的artifacts.使用正确的工具和最佳实践,避免搞一些自己独有的东西.
PROJECT PLANNING AND EXECUTION(计划和执行)
问题:项目的计划和执行完全是建立在不现实/不可能的”政治考量”或美好愿望,而缺乏确凿依据(bottom-up grounding).必要和有用的事情反倒因为”没有时间”而被推迟或取消. — 结果往往并没有因为取消这些事情而节约时间.
–这个应该是认知的问题,知识决定了是否可以在决定之前可以知道做这件事是否有价值.如果没有知识和经验,自然不会去冒险,”没有时间”是最好的搪塞.
QUALITY ASSURANCE AND PROCESS(质量控制和过程)
问题:质量控制(QA)的优先级总是很低.有过程却不遵守.缺少专门的人来评判软件是否是可接受的和管理产品发布.
–也是认知的问题,只看到表面的东西,而看不到潜在的可能.软件的复杂性导致软件很难被检验.而这个时候更应该重视QA而不是回避.觉得QA老是跟自己过不去.当然也有可能是QA太烂,让别人不得不忽略它们. 得!又是人和人的问题.
ARCHITECTURE(架构)
问题:缺少一个合理稳定的架构设计
–这个是老生常谈了.看架构师了.
APPLICATION PERFORMANCE(系统性能)
问题:架构设计时没有考虑到性能需求
–也看架构师的经验和能力
STAFFING(团队)
问题:大多数的人员不是很胜任,经验不足
–这个不是什么问题,有点像是借口.
PRINCIPLES(信念)
问题:开发者都被灌输:好心情,真诚,付出可以战胜一切.但真诚往往最终被用来评判缺乏责任感和承担后果.
–后面那句确实有点意思,有时候真诚反倒成为被别人利用.还是人和人之间的问题.难道真的无法避免囚徒困境吗?为什么会造就出这样的博弈??
INTELLECTUAL HONESTY(不明智)
问题:项目经理不愿意听到坏消息和问题,只愿意听好消息.
–也是人的问题.没什么意思,看人了.
查了一下wikipedia,FUBAR: fxxked up beyond all repair(recognition….)
“FUBAR has sometimes been used in software development in the almost opposite sense: “Fucked Up But All Right,” meaning that […]
作者:DavidAnderson 原文
翻译:ZhangV 2007-11-26
之前，在描述我在corbis的管理和领导软件工程的方法时 ，我曾经提到我引入看板系统来维持项目运行。因为它的引入，我们现在每个月平均发布两个新的版本。然而，这些并没有使用传统的敏捷开发方法如两周迭代（two week iteration)或快速迭代（sprint)。而是用看板系统来管理变更请求（CR-Change Request）。当CR被完成时，它被设在准备发布状态，并在每周三被发布。
尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR，但基本上的日常工作，我们都是使用白板作为看板来跟踪所有CR，把Post-It当作看板卡。
我们的支持过程是由一组常见的软件工程资源驱动的，没有一个专责维持或维修团队。通过设置看板，我们可以向管理层保证 - 我们正在履行我们的承诺，我们使用了一定的资源来进行支持活动，而不需要特别指出是谁在负责。
每天早会上所有团队成员会围绕看板来进行当天的工作安排，讨论进度和当前存在的问题。达伦戴维斯，作为项目经理，会主持会议，并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID，及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing)，但每天都会验证它的有效性。
一些关键概念是值得的描述的。红星表示，这个项目是严重超时的，超过28个工作日服务水平协议（ sla ），通过该系统。这使”迟到”的项目能够自我加速，不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片：黄色-客户提出（customer-valued)的CR;蓝色-客户提出（和要求）的bug;绿色-IT维护项，如：的sql 2005的升级;橙色-新增（或额外）的bug;粉红-issue。
看板限制卡片最多只能有20张，分为不同阶段，系统的分析，开发，测试，构建/合并，部署。此外，我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候，我们会减少这个数量，或者干脆不要。此外，还有两个维护项，这让我们能解决固定分配一些资源到大大系统维护和升级，例如API版本升级，与平台的升级。 如net2.0或sql server 2005 。
该看板系统使我们能够提供对三个成功的要素：减少“正在完成工作(work-in-progress)”， （讽刺的是，这些事情本身会限制工作的完成） ;量入而出（如果有新的CR，首先看看板上有没有足够的空间） ;和确定优先顺序。我们每周和公司的技术总监（vice president-应该是负责人，而不是副总裁 - 译者）开会讨论，决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考一下一个，两个，或三个最重要的事情。看板强迫他们给出优先等级。
该看板系统，也把我们从定时迭代的压迫（constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新的版本，大的负责的任务可以在系统中最多可以存在60天。那些对于“一（两）周迭代”来说太大的任务同样可以放到看板里而不需要特殊的关照。
最后，看板解放了我们，我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理，除非有特殊情况出现，如需要加快请求或因环境或系统的维修问题变更发布时间。
technorati的标签：敏捷，朱+安德森，精益生产，看板，软件+工程
顺便问一下customer-valued怎么翻译？