精益敏捷外包开发--- 思维篇

前言:

本篇主要是在讲述精益敏捷外包开发, 其背后的主要思维?

本文:

许多企业的 IT 部门, 因为人力成本的考量, 同时也为了能拥有更多与更有弹性的人力资源, 而将软件开发与软件测试的工作外包?

然而, 企业的IT 部门在面对来自不同公司的外包人员时, 却往往面临因公司的内部文化上的差异, 而形成许多不必要的沟通, 甚至是不信任? 最终, 往往导致企业的IT 部门, 虽拥有成千上百的软件开发与软件测试的外包人员, 却还是无法高效率的交付高质量的产品?

“精益敏捷外包开发” 便是要以:

1)   团队协作

2)   轻量级的流程

3)   自动化的环境

使来自不同公司, 甚至是身处于不同办公地点的的外包人员, 均能形成一致的共识, 主动且高效的协作, 而能针对版本质量的现况,, 适时的做出适当的决策, 使产品版本的交付, 能符合高效且高质量的要求?

所以, “精益敏捷外包开发” 的主要思维, 便是:

   产品软件的开发,
回归到以 “人”
为本的本质:

经由不同的工程实践与轻量级的流程, 將最接近問題的人, 能緊密的結合起來, 即时的针对问题, 提出可行的解决方案, 解决问题? 避免因不必要的沟通, 而造成人员与时间上不必要的浪费?

    产品软件的开发,
强调的是集体智慧的过程:

产品软件的开发, 不再是单一的角色, 只做单一类型的工作;如: 测试人员只是负责完成测试用例的设计与执行? 而是团队中的各个角色, 各个成员, , 共同的参与, 运用集体的智慧, 共同的完成, 产品软件开发过程中的所有事情; 包括: 需求分析, 测试用例设计/ 架构设计, 制订迭代计划, 识别风险…..等等?

   产品软件的开发,
需能即时反应产品质量的现况:

团队可依产品质量的现况, 做出适当的决策; 如: 依据目前迭代测试的结果, 制订下一轮迭代的迭代计划?

结论:

精益敏捷外包开发的模式, 回归以人为中心的工作模式?在此模式下, 确实能激发外包人员的主动性与自主性? 而使得产品软件的开发, 在此模式下, 可同时具备高效率的开发与与高质量的版本发布?

在后续将有更多的文章探讨这方面的议题? 期待大家的交流?

时间: 2024-11-07 08:59:26

精益敏捷外包开发--- 思维篇的相关文章

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

前言: 本文主要是在讲述精益敏捷外包开发, 为何应舍弃 "过重的文档", 而应改采 "视觉化的看板", 方能有效的整合来自不同企业,位于不同办公区的软件外包人员, 而能共同高效的完成高质量的交付? 本文: 企业的 IT 部门, 将产品的系统, 外包给不同企业, 位于不同办公区的开发与测试人员时, 所面临的一个最大的难题之一便是: 版本交付的质量与效率, 往往无法满足企业内, 业务部门的期望与要求? 之所以会形成这一致命的问题, 其主要的原因便是来自于 "过

敏捷软件开发——重构篇

代码往往会腐化. 随着一个又一个新特性的添加,处理一个有一个的错误,代码的结构逐渐退化. 如果对此置之不理的话, 这种退化最终会导致纠结不清,难于维护的混乱代码. xp(极限编程 eXtreme Programming)团队通过经常性的代码重构来扭转这种退化.重构就是在不改变 代码行为的前提下,进行一系列小的修改,旨在改进系统结构.每个改造都是微不足道的,几乎不值得去做, 但是所有的这鞋改造叠加在一起,就形成了对系统设计和构架的显著的改进. 在每次细微的改造之后,我们运行单元测试确保改造后没有造

09.精益敏捷项目管理——敏捷软件开发中QA角色

00.当从鳄鱼嘴里侥幸逃脱时,你很难机器你的初衷其实只是想排出沼泽中的积水. 01.精益--敏捷软件开发中质量保证(Quality Assurance,QA)的角色展开,涵盖了许多关键问题 *测试人员的作用是防止缺陷,而不是发现缺陷 *开始做开发周期计划时如何发挥验收测试的作用,以做到在最大限度上减少浪费 *在早起不容易去做测试时做些什么 02.质量保证和质量控制 a.质量康芝是确保产品或服务被设计和生产出来,满足或超越客户需求的做法 b.质量保证是指由计划的.系统的生产过程,为产品符合预期目的

精益看板管理和敏捷软件开发 (转)

最近看了InfoQ上关于精益看板在软件开发上的一些实践和应用的文章,敏捷软件开发借鉴了很多TPS精益生产的思想,虽然没有完全提到看板的概念,但是看板在敏捷软件开发实践中是很有必要进行的.具体InfoQ的一些文章请参考: 将看板应用于软件开发:从敏捷到精益http://www.infoq.com/cn/articles/hiranabe-lean-agile-kanban 用“看板图”实现敏捷项目的可视化http://www.infoq.com/cn/articles/agile-kanban-b

敏捷软件开发之原则篇

1.我们最优化先要做的是通过尽早的.持续的交付有减脂的软件来使客户满意. 2.即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势. 3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好. 4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作. 5.围绕被激励起来的个人构建项目.给他们踢空所需的环境和支持,并且信任他们能够完成工作. 6.在团队内部,最距有效果并且富有效率的传递信息的方法,就是面对面的交谈. 7.工作的软件是首要的进度

平安7年精益敏捷转型之路

导读:平安作为互联网金融的领跑者,目前有超过40个APP,传统业务全面互联网化.能够成功转型与敏捷密不可分,平安科技更是整个集团敏捷转型的领头羊.2011年,敏捷开发试点项目大获成功之后,平安科技驶入敏捷推广的加速车道.2012年试点范围扩大到10个团队,引入Scrum.看板(Kanban).持续集成等流行的敏捷方法.2013年“开启敏捷2.0”,在组织架构上成立“敏捷中心”,整合业界优秀实践,形成平安科技自己的敏捷开发方法体系和敏捷成熟度评价体系.2014年,敏捷开发覆盖到公司大约80%的开发

敏捷软件开发简述

前言:由于我读了邹欣老师的<构建之法:现代软件工程(第二版)>,因此对敏捷软件开发有了比较大的兴趣.于是我在网上找了一些论文,比如Requirements Engineering and Agile Software Development.A decade of agile methodologies: Towards explaining agile software development.在读了这些论文之后,对敏捷软件开发有了大致的了解.这篇博文主要是简单介绍敏捷软件开发,重点集中在主

管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人 --浅谈传统软件工程到敏捷软件开发之变革 前言 如果把软件开发过程比作修筑一座建筑的话,传统的软件工程方法对人的管理就像是把人化作一砖一瓦,秩序地堆砌,一层一层构建起摩天大厦. 显然地,人是不同于砖瓦那样的死物的.人作为一种复杂的动物,软件开发者会有喜怒哀乐,枯燥重复的工作内容会使他们提不起兴趣而缺乏激情:客户想法会随变动的现实而一天天有所转变,软件需求很难保持一成不变:开发者与测试者对于项目的认识会存在差异,而差异将导致效率的降低--因而传统的有些"反人类天性"的

敏捷软件开发的最佳资源

请阅读我们的热门文章,这些文章着重讨论了敏捷的过去.现在和未来.-- Leigh Griffin(作者) 对于 Opensource.com 上的敏捷主题来说,2019 年是非常棒的一年.随着 2020 年的到来,我们回顾了我们读者所读的与敏捷相关的热门文章. 小规模 Scrum 指南 Opensource.com 关于 小规模 Scrum 的指南(我曾参与合著)由六部分组成,为小型团队提供了关于如何将敏捷引入到他们的工作中的建议.在官方的 Scrum 指南 的概述中,传统的 Scrum 框架推