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

前言:

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

本文:

   企业的 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 条评论
登录 后参与评论

相关文章

来自专栏DevOps时代的专栏

DevOps 测试在企业中如何落地?

互联网时代,企业越来越注重产品的快速迭代与交付,当然产品质量也是举足轻重。企业在有限的资源情况下,快速的步调意味着更多的挑战,本次演讲重点在于测试人员如何无缝连...

884
来自专栏Java架构

"2018年Java程序员,风光背后的危机"——你知道程序员的现状吗?

近日网上有一篇关于Java程序员职场生存现状的文章“2018年 Java 程序员,风光背后的危机”,在Java程序员圈子里引起了广泛关注和热议。

551
来自专栏CSDN技术头条

从点线面体谈开发到架构师的转型

我工作十余年,从负责一个模块,到负责一个产品,再到负责整个支付平台的架构设计,包括业务架构、产品架构到应用架构,再到技术架构,是一个从点到面逐渐转型的过程,同样...

1015
来自专栏斑斓

剖析大数据平台的数据存储

数据作为一种资产,若少了存储,就成了无根之木,失去了后续挖掘的价值。在小数据时代,受存储容量与CPU处理能力限制,在现在看来相当小的数据,在当时其实也可以认为是...

3819
来自专栏Linux Python 加油站

面试 Linux 运维工作至少需要知道哪些知识?

作者:defcon来源:马哥教育链接:https://mp.weixin.qq.com/s/ZocozTkCNViMAtZIr7C7ww前言我们已经发过不少 L...

1092
来自专栏Java架构

2018年Java程序员的现状,风光背后的危机!

对于进可攻前端,后可守后端大本营的 Java 程序员而言,虽然供应逐年上涨,但是市场似乎对他们依然青睐有加。这些承担着技术招聘市场中高供给高需求的 Java 程...

261
来自专栏Java架构

阿里巴巴十年Java架构师分享,会了这个知识点的人都去BAT了1.源码分析专题2.分布式架构3.微服务架构专题5.性能优化6.工程化专题7.双11项目架构实战

1524
来自专栏北京马哥教育

运维工程师的职责和前景

运维中关键技术点解剖:1 大量高并发网站的设计方案 ;2 高可靠、高可伸缩性网络架构设计;3 网站安全问题,如何避免被黑?4 南北互联问题,动态CDN解决方案;...

2705
来自专栏织云平台团队的专栏

凤凰涅槃,浴火重生

本文以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程, 浅显易懂,结合自己曾...

1602
来自专栏Java帮帮-微信公众号-技术文章全总结

项目管理——实践入门

项目管理——实践入门 前言: 项目管理的作用对象是项目团队(当然也有项目外部的干系人,本文只针对项目团队),最好的项目管理应该是让团队有清晰统一的目标、亲密无间...

3235

扫码关注云+社区