敏捷项目管理方法在云化的软件开发架构中的应用探讨

2022-09-11

敏捷项目管理方法的重点还在于项目管理, 因为按照语法设定来看其实“敏捷”仅仅是定语。敏捷是项目管理方法的一种, 了解具体的操做和配合的工程过程及内容之后, 再针对具体的项目和实施团队的特性进行考虑, 其中重点的要素在于强调“敏捷”或者“必须敏捷”, 并非是一种简单的处理方式和态度。

一、敏捷项目管理方法的内容及意义

敏捷方法要求每一个迭代周期和改动都有严格的要求, 这和大家持续的沟通交流也有很大的关系。一些敏捷方法如极限编程等, 甚至使用测试驱动开发 (test-driven development) , 也就是在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

使用敏捷方法进行开发会发现, 最具价值的功能总是被优先开发, 就可以优先进入市场, 这样能给客户带来最大的投资回报率。因为敏捷在变化迅速的项目中优势会更为明显。根据市场需求进行最重要、需求最明确的部分进行进展, 这样能很快地投入开发。另外, 较短的迭代周期使团队成员能迅速进入开发状态。

二、敏捷项目管理方法在云化的软件开发架构中的应用误区

尽管敏捷项目管理方法在项目管理中的应用已经越来越受到重视, 但是笔者经过对部分项目管理方法进行细化分析发现, 敏捷项目管理方法在实际应用中仍然存在着一些不足与缺失, 尤其是在云化的软件开发架构设置中, 很多已经偏离了工作的原始思路:

其一, 混淆了大规模项目与多项目的概念。由于很多专业技术人员对于“云化结构”和“云端架构”的认识不清除, 因此导致了在云化结构中的“多项目”与云端架构下的“大规模项目”形成了认知上的误区。以至于忽视了“多项目”是指Multi-tasking (多任务, 同一批人同时做多个项目) ;而“云端架构”则是指同一个产品下由几个不同团队完成的几个不同Project Portfolio (项目组合) 这一基本特点。在完成不同的项目过程中, 套用同样一个项目管理模式, 这样在项目开发的过程中看似是提高了效率, 但是从宏观决策的角度上来说, 其实是存在重复利用资源或者是浪费公共资源的可能性[1]。

例如, 在软件开发的实际“需求满足”过程中, 几乎所有的软件开发项目团队负责人都提出对“产品”负责, 但是与此同时, 也会对软件开发的过程结合自己团队的实际需求来提出相应要求, 在这个过程中, 他们就忽视了一个问题是, 其实自己提出的这些要求, 本身就是“产品”应具备的特点之一。即便是在相互沟通与交流的过程中讨论一下这些要求怎样去满足, 但是谁都不会涉足非自身团队所负责的那部分内容调整, 以至于最后的软件开发记录和执行都没有任何规则可循, “需求”基本很难落地, 逐渐被遗忘。到下次提出者想起来的时候, 就会再对所有人问一句, “这个需求什么时候能做好?”, 然后没人做答。周而复始下去之后, 尽管所有人都在依旧强调对“项目”调整负责, 但是其实其过程只是在重复的浪费资源, 并没有真正的完成项目改造或者软件基本功能的调整。

其二, 混淆了云化的软件开发架构中多项目管理关联性。是一个典型的多项目管理框架。为什么要把这几个项目联系到一起, 必定有项目之间关联, 做好项目之间的相对评估, 项目之间的输入输出的“拉动”, 其实多半是把项目本身当成一个大的需求。如何建立项目之间的透明、检查、沟通、调整机制, 这是在云化的软件开发过程中所必需要重视的问题。一旦忽视了这些项目之间的关联性, 即便是各个团队按照自己的预设目标实心了基本软件代码的书写, 但是在项目合成的过程中, 也不会突出单一项目中所具备的那些优势和特点, 因为将这些元素综合起来的软件应用, 必须讲求其综合使用效果, 不能单纯的着眼于一个“要素”来诠释整个软件[2]。

例如, 在图1中所示, 在项目完成之前, 几乎所有人关注的重点都放在了“产品要求分析”上, 而“需求细化”这方面的内容则很少有人去专门进行研究, 这样就导致了软件在开发的过程中, 其工作效率较强, 但是在软件成型之后, 其基本特性, 或者说与市场的吻合度之间并没有有效突出。

其三, 混淆了迭代划分的实际作用。迭代划分是指将特性列表拆分形成用户故事列表, 并将其对应的主要任务划分到各个迭代中去, 形成粗粒度的项目迭代计划。之所以形成迭代划分, 是因为在软件开发的过程中, 有些任务内容之间是存在依赖关系的。从图1中可以比较形象的看出来, 有些软件任务的启动前提是要基于前一个任务完成之后才能启动, 也就是说部分软件内容之间是存在存续关系的。如果过度的强调多项目同时管理, 那么不仅有些项目根本不可能有效完成, 而且即便是完成了很多时候也根本不可能投入到软件的整体应用中。

三、敏捷项目管理方法在云化的软件开发架构中的纠偏措施

梳理敏捷项目管理方法在云化的软件开发架构中所存在的缺失可以发现, 并非是项目管理方法在应用的过程中不适合项目管理操作的步骤, 而是因为一些人为因素导致的对项目管理形成的混乱。软件开发讲求的是精准、精确和精细, 为了提高软件开发的效率, 必须有的放矢的采取措施加以解决。

一是, 结合“云化”特点有效区分大规模项目与多项目管理。云化方式的特点是, 所有的计算机都资源池化, 实现计算资源共享。当然这里的计算资源可能还包括网络、IO、存储等。从一开始的分块整体进度时间把控到根据产品需求细分粒度的任务——人员——时间管理, 一个较长生命线的项目和一个50人以上的团队, 人员增加及权限设置交由测试负责人进行梳理和管理, 在产品开发初期, 以产品人员为主, 需求为主导, 以需求划分任务, 粒度小一些, 具体到人员, 产品人员做为任务划分者对接研发人员, 进行一次任务的梳理、优先级排序以及人天预估, 初步建立一个项目开发的里程碑, 后续如果有新增底层开发或者前端需求增加, 再进行随时调整, 比如资源调整等等, 建议每两周进行一次进度收集, 进入项目开发中期后, 由测试人员进行主导, 进行测试模块的测试及BUG的反馈对应相关研发人员, 建议每天进行Bug日报反馈给测试负责人进行汇总, 做到每日Bug数新增及解决都有迹可循, 提高解决效率。

二是, 结合“云化”特点有效融合软件开发架构中多项目管理关联性。云化技术让底层计算机资源实现了重组划分, 那么容器技术的流行, 就是为了计算资源更加细化管理和调度。应用层面越来越技术组件化, 化大为小, 彼此隔离, 横向扩展。计算层容器化, Docker化就越来越重要。这就解释了图1中产品端的应用于信息反馈的循环。因为Docker化的容器打破了虚拟技术中资源共享模式, 容器中不再有操作系统这样重量级的管理系统。而是通过一组进程, 与底层计算机OS开放的API对接, 实现计算资源的共享和重组。

三是, 结合“云化”特点有效完成软件开发迭代划分。在整个资源共享的过程中, 项目决策者必须要高度注意的是任务难度与人员能力相匹配, 对于明显超出能力范围或过于简单的任务容易造成负面影响, 那么就必须要在开发过程中, 每完成一个功能点, 都需要及时的进行开发自测并通知产品策划人员进行验收体验。

综上所述, 对于采用敏捷项目管理方法在云化环境中进行的软件开发, 如果想做好转型, 必须要同步实践, 这样才能基于实践的基础上开发出市场需要的相关产品。

摘要：处于云端的软件开发架构以及应用, 需要涉及到很多比较专业的知识与信息, 常规的项目管理方式与方法可能并不能满足其正常的使用, 或者是在工作效率上并不能有效提高。本文就结合实际情况对敏捷项目管理方法在云化的软件开发架构中的应用进行简析

关键词：敏捷项目管理方法,云化,软件开发架构