如何在开发资源不足情况下进行敏捷开发？.pdfVIP

如何在开发资源不足情况下进行敏捷开发 ？ 许多产品经理可能会经常面临这样 问题 ：公司现有技术资源不足以支持自己 产品设计和迭代 周期 ，导致不得不妥协。而Boss或客户还不断要求采用 『小步快跑 ，快速迭代』 方式看到产品 成果 ，这时作为产品负责人 你该怎么办呢 ？ 让我们设想这样一个背景 ，并以此展开讨论 ： 某个产品 研发团队是由1位3年经验 研发Leader带队 ，加上3位0.5~1年经验 新人组成。 要求 ：敏捷开发模式 ，并以此制定每个版本 里程碑和发版计划 ，通过以往 经验你明白该 团队远低于正常配置 ，但时间紧任务急资源少 ，你只有上路。 抱怨解决不了问题 ，以项目周期为时间段 ，在项目执行前、执行中从容应对 ，通过合理 控制和管 理尽可能 达到目 。 项目前期 明确状态 ，获取理解和支持 在评估完时间 ，资源和可行性后 ，PM需要做好充足 心里准备 ，分别列出最坏 ，适中和最好三个 结果。这其中又以 『最坏』为重中之重 ，因为这很可能就是真实 结果。PM应当明确告知领导可 能出现 后果 ，打好预防针。如涉及到对外合作项目 ，还要在内部达成一致如何对客户进行告知。 不要隐瞒后果期待奇迹发生 ，更不要企图自己承担后果。P.S.有职责较为明确 公司 ，该工作会由项 目经理承担。 做最后努力 ，争取 （额外 ）资源 有给力 研发负责人带队 ，一方面可以对团队把控 ，也可以让年轻人发挥主观能动性快速成长 ，也 许他们未来都是公司 财富。如果团队中不具备这样 人 ，发挥人脉关系哪怕借一个来 ，都是非常 有必要 。还是不行 ？不如放弃敏捷开发模式或重新衡量项目可行性 ，以免拖垮团队毁掉声誉。 制定可 的迭代周期 迭代周期不要过短 （团队HOLD不住 ，时间都会浪费在代码分支合并 ，冲突检测 ，发版上 ），也不 要太长 （否则失去了敏捷开发 意义 ），每次发版时间在可以在标准值基础上+30~50%时间 ，给不 成熟 团队留出充分 容错时间 ，所以需要具体情况具体分析。这时作为产品经理 你 ，需要和研 发负责人探讨每个里程碑实现程度。请考虑以下两方面 ：1.是否会影响你 产品设计节奏 ；2.在每次 交付时能否满足领导或客户 预期。 明确开发背景 ，不走回头路 包括开发框架 ，网站架构 ，语言数据库服务器部署要求等等 （尤其设计到客户 ，一定要确定清楚 ， 必要时有合同 ，邮件为证 ）。不要进行到一半发现完全跑偏 ，团队接收不了这样 惊喜。在此环节 ，产品经理 参与主要体现在明确表述在与需求方 接触过程中 ，对方有何 『硬性』要求都要提出 ，以供整个团队做设计背景。 项目执 阶段 部门间彼此配合 ，适当的对结果打 『折扣』 由于资源局限性 ，部门间更需要彼此理解和对目标认可。根据现实情况 ，在产品设计上做一些妥协 ，给功能列表减负 ，优先级低或者 『令人尖叫』 功能先砍掉。举个极端 例子 ，注册验证码都搞 不定 人 ，就干脆去掉验证这步吧。如果是对已有产品进行大 版本更新 ，就要考虑更多 兄弟 部门和联动意义 ，比如去掉某功能是否会影响该部门开展业务活动 ，作为PM不可能令谁都满意 ，只 能考验自己 平衡和交流能力了。 会议的重要性 这点所有敏捷开发都会强调 ，包括通过站会汇报各自进度情况。能力不足更要保持信息畅通 ，不要 让成员自钻牛角尖再给项目雪上加霜。产品经理在项目执行过程中 ，始终会保持与需求方 沟通。 如果出现产品变更或需求变化 ，也要在会议上及时提出 ，如此反复修正复合当前情况 开发计划 ， 并保证可行性。 适当的说不 在项目执行过程中 ，团队难免会受到各种各样 干扰和额外 工作要求 ，比如客户会要求你帮助部 署服务器 ，测试线路等等。如果合同中有对应要求 ，可以协调兄弟部门作支持。但原本就超负荷 研发团队 ，最好合理 拒绝 ，避免再牵扯更多精力。 巧妙的进 汇报 虽然定期汇报项目情况是项目经理 工作 ，但产品经理需要通过在方案中植入相对感性化 描述 ， 来弥补项目不足和客户 体验。举例来说 ，在重要又枯燥 数字 （完成度 ，开发率等 ）之后 ，适当 可视化工作状态 ，比如放一些成员加班 照片 ，攻克问题 数字及内容和对下阶段 产品设想。 核心思路是体现项目进度虽有一些延后和不尽如人意 ，但整体仍未失控。 额外 ：感情安抚 能力不足往往是团队年轻 ，但年轻人充满活力 ，加班到凌晨不眨眼 ，虽然解决 问题看似都 『不值 一提』。但长期如此消耗势必对团队成员 心里产生巨大 折磨和影响。端茶倒水零食饮料不能少 ，如果有 『程序员安抚师』……想多了 ，有这预算不如在