敏捷开发文库-优秀公司的实践(一)：Facebook的工作方式.pdfVIP

刊主：袁 斌， Andy Yuan ，资深敏捷开发咨询顾问，来自－迅思威尔（ ） 迅思威尔（AgileDo）－ 企业级敏捷开发转型解决方案提供商，帮助客户“以正确的方式构建正确的产品” 优秀公司的实践（一）：Facebook 的工作方式 本文介绍 Facebook 如何工作。文章摘自网络，在文章的结尾会注明所有的出处。文章的目 的是分享成功的公司的成功经验。成功经验很难单一复制，但思路值得思考。 1) 工作方式 a) 公司最大的两群人是技术开发人员和实施人员(Ops),各自有 400～500 人。这两部分 人占去了公司构成的 50% 。 b) 产品经理跟技术人员的比例大概是 1：7 到 1：10。产品经理有很大的独立性和自由 度，影响力的产生关键在于和技术经理建立好良好的关系，需要有足够的技术知识 来避免自己提出愚蠢的建议。 c) 所有的技术人员都要通过 4 到 6 周的“新兵训练营”培训，培训中他们通过修改 bug 来了解 Facebook 系统，听资深/终身司职技术人员做演讲。每次训练营培训大概会 有 10%的学员不能通过考核，会被淘汰出公司。 d) Facebook 的企业文化对产品的管理工作是十分重视的。所以，产品管理这个角色并 不是可有可无的。并且，这个公司的企业文化是让“每一个员工”都感到对产品有责 任。 e) 一个功能特征是否值得做，通常的判断方法是用一周快速实现，然后在抽样用户里 测试它，例如找 1%的内华达州用户进行测试。 f) Facebook代码产生的过程包括写代码（write code ），测试代码（test code ），审查代 码（review code ），提交代码（check in code ），发布代码（release code ）。写代码指 在自己的开发机器上做好修改，这些修改只存在于自己的开发环境中；测试代码指 在本地端测试自己的修改以保证修改不引入明显的问题；审查代码指找合适的工程 师同事来查看待提交的代码；提交代码是将经审查的代码提交到服务器端的代码库 之中；发布代码是将提交的新代码同步到所有的服务器端让最终用户使用新的功能。 g) 我们实际上是有 QA 的，只是不是一个正式的QA 团队。每一个在办公室或能连接 到 VPN 的员工都能看到一个包含所有的变更内容的、下次将要对外发布 的网站版 本。这一版本的网站更新的十分频繁，你能比世界上其他人提前 1～12 小时看到这 个即将发布的版本。公司鼓励所有员工积极的报告发现的任何问题，对 于问题会做 出快速的应变。 h) 我们有自动化测试，包括每次软件发布前必须通过的“push-blocking“测试。我们根 本不相信所谓的”大部分的开发人员都有能力写出没有 bug 的代码“ 的说法 i) 很吃惊产品经理会没有影响力/控制权—产品经理有很大的独立性和自由度。影响力 的产生关键在于和技术经理建立好良好的关系。需要有足够的技术知识 来避免自己 刊主：袁 斌， Andy Yuan ，资深敏捷开发咨询顾问，来自－迅思威尔（ ） 迅思威尔（AgileDo）－ 企业级敏捷开发转型解决方案提供商，帮助客户“以正确的方式构建正确的产品” 提出愚蠢的建议。除此之外，产品经理建立开发路线/Backlog 不需要任何的批准或 通过任何的审查。产品经理的数量相当较少，但他们都认为对 公司里非常重要的、 自己感兴趣的一个区域负有重要的责任。 j) 一般情况下，所有提交的代码会每周一次的打包发布(周二) ；如果努力些，本周做 的修改也可以在同一天发布。如果在特定的周期里没有足够的时间把功能开发出来， 这个问题不大(除非有硬性的外部依赖)—功能会在完全完成后打包发布。 k) 周二程序发布时，所有在本周有提交过代码的程序员都要求在现场留守 l) 在发布开始前，所有的开发人员的需要在特定的 IRC 频道里等候“点名“，如果没到 的话，将会得到一次公开的批评。 m) 员工不会因为制造了 bug 而被开除。他们只会因为当有他们的代码被发布，有问题 需要他在现场出现，但却没有出