应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
使用投标申请书（RFP）聘雇敏捷团队
作者 Deborah Hartmann Preuss 译者 顾全 发布于 2009年7月28日
这是个很普遍的场景：一个敏捷团队发现自己与一家外包的传统（读作“非敏捷”）合作伙伴/厂商/供方为伍，而互相间做事规范的错配浪费了双方大量的精力。本月早些时候，我们报导了 ScrumDevelopment邮件列表上的一次讨论，其中敏捷从业者探讨了如何（以及是否）响应固定价格招标请求。另一位资深从业者则提炼了他在这一主题上的经验所得，提供了创建更佳招标申请书（Request For Proposal，简称RFP）的策略，以吸引从事敏捷的团队们，这就是Scott Ambler近期撰写的“以敏捷的方式撰写投标申请书——采购部中的恩怨情仇”。
虽然敏捷专家们通常同意，固定价格（隐含固定范围）合同助长了效率和产出低下的行为方式，但是诸多项目还是如此这般进行，这也是事实。凭藉独到视角，Ambler审视了整个流程的现实情况，不仅是服务提供商的应标，也包括了撰写招标申请书：
首先是敏捷式外包的好消息：敏捷项目团队能增强透明度，令利益相关方更易于进行监管……坏消息是，它假定客户...有能力发出反映敏捷开发实情的招标申请书，这也是本通讯要讨论的主题。
噢，问题的症结在这里：招标申请书的撰写方式，经常是要杜绝迭代的、适时的估计，而许多敏捷团队根本就不对这些招标申请书应标。这里关键性的潜在假设是，如果供应商交付了写明的需求，就万事大吉了。Ambler归纳了众所周知的问题：“客户无法精确定义他们想要的东西，就算能，也要花上太长的时间，以至于他们的需求总是会有所变化。所以，要供应商提供哪怕是稍稍靠谱的建议书，实际上也是不可能的。” Ambler将这种猜谜游戏视为“不道德”，并且建议，为对客户公平起见，敏捷供应商必须为客户提供其他的、更有效的选择来处理工作，同时告知优劣取舍和风险。
但是，让我们回过头来，深入查看问题根源。在该文中，Amber详细阐述了如何撰写招标申请书：
... 现实情况是：你所在组织中，的确有（些）人正处在这个位置。所以，如果你不能改变你们的工作方式，那么请你将本通讯电邮给他们，并要求他们考虑我正要描述的敏捷策略。不迈出这第一步，你就不可能改善你们的采购流程。
Ambler展示了如何在此适用一些根本原则：敏捷宣言，软件工艺宣言和精益开发治理。（该文末尾包括了一份含有如上及其他资源的阅读清单。）接着他概述了，要有效地采购敏捷开发团队的服务，招标申请书应该是什么样子。文中提出，基于“对供应商时间材料(T&M)的较低费率及持续交付高质量、潜在成品软件的奖励”，以风险分享的策略代替“固定价格，固定范围”。
Ambler承认，这一策略会承受一些潜在挑战，但他坚称这些挑战相对易于克服。
- 供应商通常不会让员工待命，...所以他们可能很难预先就确定说出谁会在某一项目上，尤其是在客户决策缓慢的情况下。（他会建议客户对人员配备做合理的期望，但对以次充好的偷梁换柱手段要保持警惕。）
- 客户需要对自己的决策承担责任，并积极参与项目监管——这非常有别于过去或许常用的“甩手掌柜”式做法。（Ambler坚称“要让外包可行，客户必须采取事必躬亲的方式，积极监督和指导项目。”这显然不是省钱的地方——项目脱轨的风险太高了。)
现在，这一清单很有价值，因为开发人员通常不（真正）明了如何撰写一份招标申请书，而采购部门也搞不清Jira与JUnit的区别。 使用Ambler的清单作为讨论的基础，也许就有可能开启流程，将重要信息反馈给那些为组织采购有价值资源的人。Ambler暗示，当团队将其协作原则扩展到他们的采购人员时，他们就可能会在那里发现开诚布公的对话机会：
采购人员...都是聪明人，他们完全知道他们的流程有毛病。不巧的是，他们经常觉得无力改变招标申请书流程，原因要么是他们对其管理层言听计从，要么是他们以为其所共事的供应商无意以敏捷方式工作。
敏捷团队正在发现制造业者早在上个世纪就已知道的同一样事情：不要自扫门前雪，与邻互助才会真正获益——在这一例子中，他们的邻居就是内部采购职员。阅读全部原文以了解招标申请书可包含的细节，以吸引敏捷团队上门。
英文原文Using the RFP Process to Hire Agile
没有回复
关注此讨论 回复