Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
新闻
敏捷团队中，专家能胜过通才么？
作者 Vikas Hazrati译者 郑柯 发布于 2008年6月22日 下午3时52分
在敏捷社区中有一个普遍的共识，那就是要组成包括通才和专家的跨职能团队。Dave Gray在他的blog中发表了一张有趣的图表，试图显示通才和专家之间的关系。Dave认为，通才对多个领域的规则都有基本的理解，他们不一定具备解决问题所需的特殊技能，不过能很好地诠释问题。从另一个方面来说，专家对特定的领域有深入的了解。他们在解决问题和执行计划方面的能力是一流的。Dave认为项目的成功执行需要这两种角色的参与。
Jurgen Appelo强烈反对这种通才加专家的理论。在blog上，他不仅对专家的作用大加赞扬，而且不鼓励组织中的任何成员向通才转变。根据Jurgen的说法：
跨职能团队（一些敏捷专家推荐的方式）完全忽视了社会得出的经验，1776年哲学和经济学家亚当·斯密在他的重要著作《国富论》中曾指出：专家能够带来更高的生产率和繁荣。
JurgenAppelo还说：
当软件开发人员要去设计网站的时候，我都要哭了。一些人几乎分辨不出像素和厘米之间的差异。我见过软件工程师所做的网站功能设计，如果照其执行的话，网站访问者的身体会受到严重伤害。
为了增加说服力，Jurgen引用了David J. Anderson书中的内容：
David J. Anderson在《软件工程的敏捷管理》一书中提到了Capers Jones的研究，说明专家小组的表现通常能优于由通才组成的小组（第272页）。
他认为，使用专家所导致的效率降低不会比使用通才更严重，而通才处理工作的速度明显要落后于专家。
另一方面，敏捷社区中的一些成员坚信：团队应该不惜一切代价避免专家的存在。David Christiansen认为：使用通才而不是专家，这才是王道。在谈到如何组建好的团队时，他这样建议：
应该尽量避免使用专家。他们都是只会一种技能、而且脾气暴躁的家伙，他们对于形成良好的核心团队没有兴趣。此外，他们只做固定的工作，避开其他的任务。为了等待下一个“适合”他们的任务，专家们会耗费上许多时间。所以他们要么造成了项目资金的浪费，要么根本就处在半工作状态。所有这些情况增加了失败的风险，并造成棘手的计划依赖。从另一个方面来说，通才在项目的整个生命周期中一直在增加价值，他们在所有的阶段都能提供帮助，这意味着日程安排不是什么大问题。实际上，如果整个队伍都是由通才组成，能在很大程度上消除项目主要路径对人员安排的依赖。
Scott Ambler采取了中间立场，他认为团队应该由通才型的专家组成。
不妨建立通才和专家都包括的团队，通才在团队内部起到粘合剂的作用，着眼于更宏观的问题；而专家则关注项目中较复杂的细节。这种方式的效果不错，因为通才的长处刚好能平衡专才的短处，反之亦然。通才和专才的结合因为达成了某种平衡，通常很有效。更好的方案是建立通才占多数的团队，并配备一到两个专家——通才型的专家。
Scott认为，通才型的专家能够很好地把握事物之间如何配合，并能够因此更加了解团队工作的内容。
Jeff Atwood的观点与Scott类似，他也喜欢通才型的专才。他认为，太多软件开发人员在一种专业领域内浸淫得越来越深。编程是一个狭窄的领域，工程技术的世界如此广阔，他们应该把自己培养成全面的软件开发者。
总的说来，并不是所有的敏捷社区成员都赞成专家机制。应该根据团队的人员和项目具体情况，来安排通才和专家的比例，或者努力增加通才型专家的数量，他们可以携手并进，推动项目取得成功。
查看英文原文：Do Specialists Outperform Generalists on an Agile Team?
软件工程师所做的网站功能设计，如果照其执行的话，网站访问者的身体会收到严重伤害。
发表人
cao yunfei
发表于
2008年6月22日 下午8时52分
Re: 软件工程师所做的网站功能设计，如果照其执行的话，网站访问者的身体会收到严重伤害。
发表人
小 熊
发表于
2008年6月22日 下午10时43分
我亲身经历了专家加入团队的危害
发表人
西水 源头
发表于
2008年6月23日 上午7时46分
Re: 我亲身经历了专家加入团队的危害
发表人
TAX I
发表于
2008年6月24日 上午11时56分
Re: 我亲身经历了专家加入团队的危害
发表人
Yi Xu
发表于
2008年7月11日 上午3时35分
通才型的专家
发表人
晓雷 赵
发表于
2008年6月25日 上午12时31分
6 条回复
回复