成熟的敏捷团队该如何看待产品(系统)的缺陷?

何不乐观的看待产品(系统)缺陷?

藉由演算法, 电脑现在可以作曲,
人脸识别, 看病,
预测某人在某个议题上的决策……等等。

所以, 可不可能开发个软件,
经由该软件中的演算法,
会自动的找出产品(系统)中的所有缺陷?

答案是……否定的,
不可能的。

因为, 要能有个软件,
能找出产品(系统)的所有的缺陷,
那就必需先要有个“无缺陷的软件”。

当然, 这是永远不可能的。

所以, 缺陷永远找不完,
缺陷也就永远不可被避免。那我们应如何看待缺陷?

“任何的产品(系统)上的缺陷, 都在试图告诉我们一些事” 。

有的缺陷是在告诉我们,
使用者提的需求太不靠谱了。有的缺陷是在告诉我们,
产品(系统)的软件架构已老矣。有的缺陷是在告诉我们,
咱们在写代码时,
可能还是处于睡眠的状态……等等。

所以, 一个真正成熟的敏捷团队,
会将缺陷当成是一迈向好还更好的 “机会”。

唯有真正成熟的敏捷团队,
才能成熟, 乐观的 "面对"
缺陷, “处理”
缺陷, “放下”
缺陷。

时间: 2024-08-03 07:27:53

成熟的敏捷团队该如何看待产品(系统)的缺陷?的相关文章

一个成功敏捷团队的失败历程

昨天通过微信沙龙,分享到了一个案例,讲述的是从成功到失败的过程. 很多人可能疑惑,很多案例都是从失败到成功,这个怎么反了.很多成功背后都有其原因,可能很励志,但从失败中我们能够获取更多.毕竟我们的知识大多源于失败而非成功. 故事是这样的(括号中的是笔者的情绪表达 :)): (在很久很久以前……)某公司成立了一个团队,开发一款全新的产品.产品的开发模式是产品需求获取和开发同步进行,团队构成为:项目经理带领开发和测试两个子团队,每个子团队各有一名Leader.产品经理在开始仅提出最基本需求,根据内部

软硬件通包的产品级敏捷团队

2015.6.4,在武汉.和比自己聪明的人.一起做产品.永远是种最大的幸福. "软硬件通包的产品级敏捷团队"-- 团队不同角色的协作.建立起软硬件的核心信息,经由软硬件的核心信息,软硬件通包的产品级敏捷团队便能马上-- 分析出在新的硬件规格下,新增的业务场景为何? 在新增硬件的规格下,为提升用户的惬意度.分析出所需的架构的 Qualityof Service 为何? 架构上所需的新的技术验证点为何? 识别在新增硬件现行的进度状态下,可马上投入开发的场景为何? 架构为何? 測试场景为何?

敏捷价值流开发 (产品级敏捷)

许多今天还是明星的科技公司, 却往往因所生产的产品, 对客户不再产生任何的 "影响力", 而面临即将黯然关门, 倒闭的命运? 在这不可预期且淘汰迅速的大环境下, 是否可藉由精益敏捷开发, 而使产品的研发团队, 可以 "以最少的产出, 却对外部的用户, 产生最大的影响与效益" ? 答案是 "肯定的" ! 敏捷价值流开发 (产品级敏捷), 便是以精益敏捷开发的思维, 从外部使用者的视角, 指导著产品的研发团队, 从建构产品级的特性到各版本的研发, 如

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

多个敏捷团队之间的版本控制

http://www.infoq.com/cn/articles/agile-version-control/ 多个敏捷团队之间的版本控制 如果我们有多个敏捷团队在同一个代码库上工作时,如何将彼此之间代码互相冲突的风险最小化?如何确保每个迭代结束时拥有一个干净的.可发布的软件版本?本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在<Scrum and XP from the Trenches>中描述的公司所采纳的方式. 本文并非专为版本控制专家所写,实际上这样

敏捷开发讲义---如何打造敏捷团队

PPT下载链接:http://pan.baidu.com/s/1bncprTd 敏捷开发分享讲义-修改版 第1页:个人信息 就不做自我介绍了,我的基本信息就在PPT第一页.7月26日,也就是上周六,我和会成参加了一天的培训,关于敏捷开发的.参加这次培训我们俩主动申请的,因为这次培训适合的听众除了中高层领导.项目经理.产品经理之外,还适合有软件经验希望往项目管理方向发展的人士."不想当项目经理或者项目主管的IT屌丝是真屌丝",不想成为真屌丝,所以参加了培训.但这次跟大家分享是被婷姐逼的(

敏捷团队转型

敏捷团队转型背景 故事一: 以前在一个很有激情的团队中一起干一番事业.每一个人各自发挥各自的特长,将每一期项目在不加班的情况下准时上线. 后来公司在年后財务原因倒闭.团队解散后每一个人到了不同的公司.工作后都发现原来非常多公司.包含某些大公司.没有使用敏捷开发导致公司存在非常多问题,加不必要的班.效率低,代码质量不高.团队之间协调能力差,团队内部没有热情.甚至沮丧.悲观. 年后又一次在一家算比較成熟的.知名的某视频互联网公司入职后,发现公司内部问题也非常大,甚至一个迭代完毕后没有总结会议. 代码

【 腾讯敏捷转型No.4 】为什么敏捷团队不要超过15人

早期,腾讯公司的架构是比较简单的.从上至下分别是:公司--商业单元(BU)--部门--组--员工,每个部门基本上就是负责一个大的产品,每个组都是按照专业进行分工和管理,例如:产品组.终端组.后台组.设计组.运维组.质量组等等. 草拟一个项目需要在每个小组里面抽调人力,部门的总经理就需要和每个小组的组长沟通,经过沟通以后,确定了该项目需要的人力安排,然后就开始执行项目.执行项目过程中的困难,需要决策,例如:人员安排调整,产品需求变更和是否延期发布等等,都需要总经理和组长们开会协调或者私下沟通决定,

测试在敏捷团队当如何?

Dev(Developer)  :开发 TE(Test Engineer)    :测试 PM(Product Manager)    :产品   敏捷:快速的响应客户(需求),高效的完成开发,不断的追求完善.   TE在敏捷中应该做些什么呢?   流程1-故事分析 角色: Dev.TE 内容: 需求交接前夕,PM将需求上传到文档管理区并邮件通知,Dev.TE分析需求 初步制定测试策略与测试计划 初步安排测试任务 输出: 测试策略.测试计划 测试工作量初步评估 流程2-故事计划 角色: 整个Te