|
现在的商业环境复杂多变，从IT系统项目管理的角度来说，存在着多种模式的项目管理。敏捷开发的概念已经不新鲜，但是在实践中还是没有得到广泛应用。 在我们最近做的一个项目中，就引入了敏捷开发的一些思想。本文以这个项目为例，介绍了一些敏捷开发项目管理的实践经验，希望为大家提供一些思考和借鉴。 项目要求，不到4个月的时间内，要完成PC端，APP的产品开发，并且在6月30日上线。为了应对未来大数量高并发的需求，项目采用分布式开发和分布式部署方式。在开发模式上，采用了敏捷开发的模式。 下面就具体讲讲我们是怎么完成这个项目的。 遇到的第一个问题：需求的问题。 由于项目不是标准的瀑布式开发模式，而且类似互联网公司的产品化开发。一开始，只有一个需求列表。我们没有专门的需求人员，客户充当需求人员。然后我们的UI人员就和客户一起设计APP的页面，之后我们根据demo页面进行数据库设计和系统详细设计。 由于系统整体的组织架构，以及数据权限的问题，导致项目的组织权限体系比较复杂。另外，由于不熟悉业务，程序员在理解上有困难，接收起来比较慢。 对策：
遇到的第二个问题：团队协作的问题。本项目的交付团队包括3个团队，一共15个人，如果加上短期驻场和已离场的人员，得有20多个人。项目组分为服务端团队、主数据团队、APP团队。各团队之间有协作关系。服务端团队不仅要开发PC端的业务，还要给APP提供接口。 团队来自于不同的部门，彼此之间的关系并不紧密。怎样让这只队伍凝聚起来，完成目标，是有些难度的工作。 我们采取了分级管理的做法。主数据团队、APP团队各自有负责人，他们负责下面团队的开发管理。主数据团队人比较少，就由项目经理直接管理。UI也是PM直接管理。 我们每周五召开项目例会，项目总监、PM、团队负责人、客户方项目经理一起参加，总结本周的工作，讨论问题，并确定下周的工作计划。 从实际结果来看，虽然一开始经历了动荡期，但是后来还是到了成熟稳定的阶段，大家彼此合作愉快，进展顺利。 敏捷开发经验分享一、 tower上进行工作任务的跟踪。Tower是一款多人协作工具，从界面设计到功能实现都遵循了“大道至简”的原则，主要面向20人以下的小团队。在Tower中，你可以在里面创建项目，并基于项目发起讨论、创建并管理任务、上传并共享相应文件。Tower作为一个“轻量级”的工具，可以协助我们完成项目管理日常70%-80%的工作。 通过Tower，可以掌控你的项目。告别冗长的会议、拖沓的进度和繁复的邮件，快速、高效地完成任务。我们将project的计划细分到人，在Tower上列举每一个任务，明确责任人并跟踪进展情况。Tower还可以关联微信端，这样，我们在微信上也可以方便地查看任务，分派任务等。并且微信端的Tower还提供了代办任务和任务过期提醒功能，非常方便好用。 Tower还可以查看项目进度版，可以一览项目的整体情况。 二、 敏捷开发最少需要维护哪些文档？软件或者系统产品终归是人来维护的，业务知识和技能的传递就成为产品可持续发展的一个重要因素，这就需要有知识性的沉淀，需要有文档的产出。 实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档，因此太多的文档只会消耗团队有限的时间，并不能带来多大的好处；敏捷开发照样重视文档的作用，也重视文档的维护。 文档宜少且精炼，需要根据实际情况确定需要编写哪些文档，比如： 《产品需求规格说明书》 也即PRD：定义产品应该具有的功能、边界描述等，它作为产品团队之间共同的讨论基础，并在设计和开发过程中不断的更新维护，并记录所有的需求变更； 我们这个项目比较特殊，实际并没有一个需求文档存在，只有需求跟踪矩阵。具体的需求主要是通过demo页面体现。 《系统设计说明书》 开发人员编写的技术设计，包含数据库E-R图，架构设计等：说明产品如何实现，内部之间是什么关系; 本项目由于没有完整的需求文档，所以设计文档也充当了需求文档的作用。另外，我们还是坚持如果有需求变更或设计变更，先改设计，然后落实开发的过程控制。 虽然这一点不太像敏捷的做法，但是为了避免设计开发的失控，我们还是要坚持的。 《测试用例》 由测试人员编写：设计所有功能的测试用例，指导测试工作； 针对我们项目的特殊情况，交互系统繁多，接口交互复杂，所以针对集成测试，我们专门编写了集成测试用例，用以整体指导集成测试工作，避免遗漏。 三、 敏捷开发是否需要系统设计？一个完整的项目包括：需求、设计、开发、测试、发布各个过程。 我们先做大力度的概要设计，然后根据迭代计划，做每个迭代的详细设计，然后在逐步实现的过程中逐渐深入展开、细化。 传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。 四、 敏捷开发是否需要项目计划？敏捷开发把整体拆分成许多个体，产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。 我们需要有一份总体的项目计划，先按照大的迭代分开，然后逐步细化每一个迭代的内容。每个迭代的推进情况都会影响到后续迭代的任务安排。 每个迭代的计划是一个短程计划，根据未实现的功能情况、前一个迭代或版本的反馈和组织目标制定开发计划；唯有这样才能不断的融入新的需求变更； Project上的计划颗粒度可以较粗，比如一周。但是细分的计划必须体现到tower上。周五的时候，我们对总体计划做回顾。 一方面，通过Tower的项目看板，可以知道当前已布置的工作的完成情况。 另一方面，对于本期迭代的进度情况或总体开发计划的进度情况，我们可以在Project上进行跟踪查看。 当然，如果说项目比较小，或者运维阶段，没有Project的计划，有任务的计划安排也是可以接受的。 五、 敏捷开发为何提倡小版本？小版本有哪些优势？小版本的目的就是分解复杂度、降低风险，改善团队士气等；小版本有众多优势： 1、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布； 2、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现； 3、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例；发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug；开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作； 六、 敏捷开发的迭代周期大概多长？敏捷开发的迭代周期没有硬性的规定，结合项目里程碑、目标、功能实现情况、产品稳定性综合决定，如果产品用户活跃、功能实现难度小、维护复杂度低，建议以周为周期。 对于规模比较大、维护复杂度高的产品，考虑以2周-6周为周期发布较为合适；频繁的发布会降低用户的期望并提高用户成本，也会给项目组带来更高的成本。 在本项目中，产品发布前我们分成了3个迭代，每个迭代2-3周。在产品发布后，我们基本上采用了一周一个迭代的方式。迭代太频繁会极大降低项目组的开发效率，开发、测试、发版交杂会让项目组人员不知所措或者打乱原有的开发计划。 七、 敏捷开发与重构的关系敏捷开发以重构为基础，时时刻刻处于重构过程中； 由于一开始项目组在赶进度，重构的工作不多。在后续迭代开发过程中，我们逐渐抽出时间对关键的代码进行了重构。优化了代码结构，进行统一的业务收口。 尽早进行重构，可以节约后续的业务优化和改进的时间。 八、 敏捷开发为何强调团队人员的参与、用户的参与？敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果。 良好的团队氛围和协作关系可以促进团队之间的沟通，并使消息有效传达。 有客户参与的沟通，一方面客户对于整体进度情况也更了解，能够站在项目组的角度上考虑问题，为整体进度推进出谋献策或帮助内部协调解决问题；另一方面，也有利于项目组成员工作的责任感和紧迫感。 九、 敏捷开发对于传统的瀑布式开发管理，有哪些借鉴意义？一个项目是否可以采用敏捷，首先还是要看项目的立项基础：合同及客户需求。 如果是一个固定总价的合同，同时，时间、范围不能调整，客户的IT系统建设经验不是很成熟，那么建议还是采用传统的管理方式，严格进行需求管理和变更控制。合同中约定的里程碑节点和交付物及验收标准，很大程度上约束了我们采用哪种管理方式。在现今中国的形势下，也许ODC项目或者甲方自主开发的项目，采用敏捷开发方式才是最佳的选择。 全套的敏捷管理方式也许不可用，引入一些敏捷的思想，采取一些敏捷的做法，是较好的选择。 没有一成不变的项目管理，只有人品、能力的锤炼，以及技巧、工具的巧妙应用。 因时因地因人而变，最大程度上减小风险，保证成功交付，是项目管理永远的追求。 来源：网络 |
|
|
