专栏首页Cloud Native - 产品级敏捷精益敏捷外包开发--- 信息传递篇

精益敏捷外包开发--- 信息传递篇

前言:

    本文主要是在讲述精益敏捷外包开发, 为何应舍弃 “过重的文档”, 而应改采 ”视觉化的看板”, 方能有效的整合来自不同企业,位于不同办公区的软件外包人员, 而能共同高效的完成高质量的交付◦

本文:

   企业的 IT 部门, 将产品的系统, 外包给不同企业, 位于不同办公区的开发与测试人员时, 所面临的一个最大的难题之一便是: 版本交付的质量与效率, 往往无法满足企业内, 业务部门的期望与要求◦

   之所以会形成这一致命的问题, 其主要的原因便是来自于 “过重的文档”

   企业的 IT 部门与外包人员之间, 或许因各自的立场不同, 或许因外包人员对企业 IT 部门的业务或系统的不熟悉, 而使得企业 IT 部门的需求分析/ 设计人员, 需将一数十页甚至上百页的需求/ 设计规格书, 交与外包的开发与测试人员后, 外包的开发与测试人员, 才会开始进行相关的开发与测试工作◦

   而这一看似必要且理所当然, 应该由企业 IT 部门的需求分析/ 设计人员, 所交付的需求/ 设计规格书, 往往却是造成企业 IT 部门, 在版本交付效率与质量上, 大幅滑落的最主要原因之一◦  其根本的原因便是在于:

1. 数十页甚至上百页的需求/设计规格书, 将造成许多无谓的等待时间:

        企业 IT 部门的需求分析/ 设计人员, 编写需求/ 设计规格书时, 往往需耗费 1-3 个月的时间; 有的版本甚至还耗费更久的时间◦

        而在这段长达一个月甚或数个月的时间, 外包的开发与测试人员也就只有“等待”◦

       然而, 这段 “等待”, 是绝无可能获得企业内业务部门的理解与谅解的◦ 版本交付的日期, 并不会因有这段的 “等待”, 而获得延期◦

       也就是说, 外包人员的开发与测试的时间反而会因为这段的 “等待”, 而被 “压缩”; 举例: 本来在整个版本中, 应有 3 个月的时间进行开发与测试, 却被压缩成只剩下两周◦

       当外包人员的开发与测试的时间被压缩时, 外包人员将别无选择, 只能把手头上的工作先交付出去, 至于 “质量”…..被逮到了再解决唄◦ 

   2.  数十页甚至上百页的需求/设计规格书, 其实可读性与指导性是很差的:

         从许许多多的项目中已获得验证, 数十页甚至上百页的需求/ 设计规格书, 只会使不熟悉企业 IT 部门业务或系统的外包人员, 更加的不理解需求, 更加的宛如坠入到五里云雾中◦

   3.  数十页甚至上百页的需求/设计规格书, 往往会使外包人员被动,过于保护自己:

        外包人员只针对需求/ 设计规格书的内容, 来进行开发与测试, 而不愿意再进一步主动的去思考, 该做些什么? 以能真正的满足使用者的要求◦

        当外包人员已丧失了主动思考的意愿与能力时, 版本交付效率与质量的低落, 便是可以预期的◦

    所以, 我们应从另一个角度来看待产品软件外包…..

    “当面对来自不同企业,位于不同办公区的软件外包开发与测试人员时,首要且最重要的工作, 便是建立起一高效的信息传递机制;而不是文档◦”

    这一高效的信息传递机制, 需能满足以下的条件:

  1.  简单:

        在任何的工作环境下, 均可轻易的被建置起来使用◦

        将复杂, 艰涩难懂的理论隐藏, 封装起来◦ 而使任何人均可轻易的直接上手◦  

    2.      可视化:

        可视化的呈现, 产品软件开发周期内的信息; 包括: 需求分析, 架构设计, 测试用例等的信息◦

    3.      团队协作:

        可使企业 IT 部门与来自不同企业, 位于不同办公区的外包人员充分且直接的协作◦

    我便是以 “看板”的型式,在精益敏捷外包开发中, 建构一高效的信息传递机制◦

    我所设计的以特性为纬度的 “看板”, 包括:

1.   需求看板:  使企业 IT 部门与外包团队, 可视觉化的识别特性的基本场景, 扩展场景, 异常场景与质量属性◦

2.  架构看板: 将设计Rest Oriented Architecture (ROA) 所需的架构实体类型与架构设计流程, 融入至看板中◦ 而使企业 IT 部门与外包团队, 可更轻易且直接的协作, 共同设计出特性所需的 Web API◦

3. 测试用例看板: 将使特性测试结果产生差异的纬度与各纬度上使测试结果产生差异的变化点, 融入至看板中◦ 而使企业 IT 部门与外包团队, 可共同且客观的识别特性所需的 测试用例◦

 结论:

   需求看板, 架构看板, 测试用例看板, 已在许多各类型的项目中, 真正使企业 IT 部门与外包团队, 高效的传递信息◦ 而使项目中的待确认事项, 风险, 最佳的设计与测试方案, 均可及早的被识别出来◦ 因而, 使项目开发的效率与质量大幅的提升◦

   后续的文章, 将会再进一步的详细介绍需求看板, 架构看板与测试用例看板◦

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • CMMi, RUP (Rational Unified Process)与产品级敏捷在工程实践上有何不同?

    ★ CMMi, RUP 的开发模式,强调的是 “垂直型” 的 “专业分工”;明确界定各个不同的角色;BA, SA, 架构师,开发人员,测试人员;什么时间? 该...

    Ken Fang 方俊贤
  • 外包模式下的精益敏捷开发 (人员能力篇)

    前言:    本文主要探讨在产品外包的模式下, 精益敏捷开发如何能迅速, 有效的提升外包人员的能力◦ 本文:    许多的产品当采用外包的开发模式时, 所面临...

    Ken Fang 方俊贤
  • 流程对一企业、团队最大的伤害是什么?

    我喜欢有流程,有规范的企业。 因为,这些流程、规范使得我在和其它部门打交道时,有了一明确的游戏规则,也使得我会很容易的了解到,其它部门的同事,将会如何的看待我的...

    Ken Fang 方俊贤
  • 芯片设计的职业病

    前些天看到一篇文章,讲低容错率的职业对一个人性格的影响。文中拿常见的路怒症举例,把从事低容错率工作的人形容为经常在拥堵路段中开车的驾驶员,长期下来,容易形成敏感...

    icsoc
  • 一种TreeView组件分页异步加载的方法

    笔者在工作中遇到了一个web环境需要展示100w级目录节点treeview的需求,本文重点介绍笔者设计的一种treeView分页的方法。 1、无限滚动长列表 ...

    腾讯VTeam技术团队
  • win10 uwp 退出程序

    作为一个微软的程序员,如果用户说一个功能好用,那么要在下一个版本去掉这个功能。如果用户觉得我的应用好用,我就需要立刻关闭我的应用。

    林德熙
  • 【未完成】7-7 迷宫寻路 (30 分)

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 ...

    韩旭051
  • Django-xadmin+rule对象级权限的实现

    要求做一个ERP后台辅助管理的程序,有以下几项基本要求: 1. 基本的增删改查功能 2. 基于对象的权限控制(如:系统用户分为平台运营人员和商家用户,商家用...

    菲宇
  • 看看人家那后端API接口写得,那叫一个牛逼,再看看我的,像坨屎!

    在移动互联网,分布式、微服务盛行的今天,现在项目绝大部分都采用的微服务框架,前后端分离方式,(题外话:前后端的工作职责越来越明确,现在的前端都称之为大前端,技术...

    架构师修炼
  • 通过Betalist 分析近年创业项目

    本文通过Dyson Web数据采集器实现对Betalist的网络数据爬取,并通过简单的统计分类,对近年来发布在Betalist的创业项目进行了统计分析。 

    探码科技

扫码关注云+社区

领取腾讯云代金券