2019-08-27 00:33:42 seagal890 阅读数 102

敏捷开发中如何提高开发质量

问题:敏捷开发中如何提高开发质量?

敏捷开发中采用Scrum过程框架是常见的开发方式。最近上校经历的几个开发项目均采用了Scrum过程框架开发,团队规模从5个人到12个人不等;开发周期从2个月到8个月也不同。项目进行中和项目结项时,都不同程度的存在质量问题:

  • Sprint “带病迭代”
  • 开发周期 Delayed,系统不能如期交付和发布
  • Sprint Test 不能满足度量指标要求
  • 系统阶段性发布后,存在缺陷
  • UTA测试阶段,缺陷率过高
  • Product Owner 频繁变更系统需求,导致Sprint迭代过程中开发范围蔓延
  • 使用SonarQube检测,系统 Defect 和 vulnerability 过多,不能满足 Code Quality要求
  • 系统存在安全漏洞,使用 Security Testing 工具检测后,需要修复漏洞
  • ……

以上质量问题同样也困扰着各种开发团队。

那么如何在敏捷开发中提高开发质量?这个话题成为了讨论的焦点。

上校任务,质量的改善需要从三个方面入手:

Scrum团队自身的开发质量改善活动

需要从Scrum团队管理、技术、沟通、个人能力等4个方面做出改善。

[以下内容未归类,更新后归类]

  • 首要任务是根据项目的重要程度和优先级,组建Scrum团队,合理优化人员能力 —— 从团队下手
  • 树立良好的开发规范并且Scrum团队共同遵守
  • Scrum Master需要真正的起到Scrum规则确保和维护的作用,必要时需要和Product Owner “谈判”
  • Scrum Master要逐步在 Product Owner和其它干系人(Stakeholders)中提高威信力
  • Scrum Planning Meeting 时,根据团队能力和经验数据,做好合理的估算(偏差不要超过20%)
  • 敏捷不代表不需要文档,必要的文档一定要按照规范按时完成
  • JIRA管理一定要每日检查并更新,保证信息的最新状态
  • 双向反馈要及时,除了邮件共享信息之外;项目相关的信息都需要采用JIRA管理
  • Scrum团队需要正确理解Product Backlog,正确理解 User Story,不清晰的需求要及时澄清;
  • Scrum团队提高Coding能力,尤其是一定要基于 Security Checklist 的要求Coding
  • Scrum团队做好Unit Test,提高 Unit Test 的覆盖率
  • Scrum团队内部确保沟通畅通,信息共享
  • Scrum团队中的成员要遵守承诺,具有“契约精神”,遵守DoD规则
  • Scrum Master真正的在Product owner和Scrum团队之间做好沟通“桥梁”
  • Scrum Master收集每个Sprint的度量数据,及时做出分析,实施改善活动
  • Scrum Master带领Scrum团队做好Retrospective活动,改善团队气氛

 

独立的测试团队加强测试和缺陷分析

 

QA采取有效的行动做好质量保证

  • 过程控制(Process Control)
  • 定量管理(Quantitative Management)
  • 持续改善(Continuous Improvement)
  • 缺陷预防(Defect prevention)

(持续更新中……)

2006-06-20 23:25:00 tyrones_mc 阅读数 1384

SQA why要保证质量?在全面质量管理中将质量管理定义为“能够持续地有能力的完成工作”。而质量保证就是要保证具备这种能力。SQA的工作也应该基于此定义开展。

who拥有这种能力?这个问题的答案就和产品开发团队的组织结构密切相关,可以根据产品开发团队中不同的角色定义相关的质量职责。这也是全员参与质量工作的最佳方式,同时也可以培养质量优先文化。组织结构中,SQA不应该和开发团队同级,而应该做为它的辅助组成部分。

what能力就要根据不同的角色来定义。而SQA也应该同时具备这些能力,可以在角色需要时给予指导。

how持续的拥有这种能力呢?实际上这需要很好的处理显性和隐性经验,便于经验的利用和传承。显性只是可以通过checklist先来收集,然后通过自动化工具完成再利用的过程;隐性知识的传播可以通过组织的宣传,成员的沟通,专家的培训等方式。

when使用这种能力呢?对于过程来说,有输入和输出,现在我们的工作多数都通过定义阶段性质量目标来关注输出,其实应该更多的关注输入,那才是真正的质量预防工作,但质量保证工作更应该发生在过程之中,目标便是提高过程有效性。比如,当PL制定PPL时,为了保证PPL的质量,SQA可以通过人员能力评估来考察PPL中人员安排是否合理;当进行代码检视时,通过检视有效性工具察看检视效果。

最后,我们还要将这种能力的总结向我们的领导部门(比如质量部,过程改进组)汇报,从而有效指导质量方针的制定。

这就是我第一天当SQA开会的心得,一句话总结:协调和产品开发团队的关系,高度重视周边满意度。

 

2018-12-26 16:36:19 Y673582465 阅读数 93

在这里插入图片描述项目总结:
1.几种常用的软件开发模型:边做边改模型、瀑布模型、增量(迭代)模型、快速原型模型、螺旋模型、敏捷原型等。
2.软件开发要符合SQA质量管理。
3.开发过程中注意代码的健壮性、稳定性、安全性、高效性等。

2010-09-15 09:09:00 nijp2004 阅读数 312
下午,PM和DPM一边商量一边把需求分解成任务,我和SQA MM都没有参与,我在座位上看着禅道上一条条任务新增者,心理还在想着如何才能让Team的效率更高些,减少需求是一方面,日常沟通、行动上还是有诸多问题,有必要寻找相对容易解决、成本较低的方法。
培训老师讲的Team成员的强分工和弱分工一直在我脑子里转,之前看《轻松Scrum之旅-敏捷开发故事》中那些主人公,随便什么时候工作都可以置换,虽然质量有高低,但都可以上手。实际情况可以这样么?
我从头到尾思考自己从业来看到过的项目,但好像没有一个象书上讲得这样真正实施弱分工。
最典型、最常见的分工是按模块分工,比如一个C/S的财务系统,设置初始化、账务处理、结算、报表、系统管理、……,每个模块都落实到人,复杂模块落实多人,而这多人再通过模块分解功能来分工
后来,曾经观察过移动业务系统的开发,涉及到Web应用了,前端页面框架、Javascript、后端存储过程、后端设备监控、桌面管理,而需要的工具也更多。
弱分工可以解决我们的问题吗?至少我们现有的产品开发的技术类别并没有大型系统产品来的这么多,我们怎么来实践弱分工,什么时机切入?
找SQA MM,想交换下这方面的想法,结果她说:“刚刚我发了消息问PM能不能试试看弱分工,结果她立马答复不行,没法考虑这个。说我们不具备这个条件”(那次培训,我、SQA MM、PM、DPM、以及老大都去听了)。
“唉,这是屁股决定脑袋,PM原本不做开发的,结果做了PM后,开发思维越来越明显了,拒绝的动作响应很快。”,我感叹一把,请SQA MM去作战室讨论(最近我们越来越爱去作战室讨论问题,容易出想法,况且作战室隔壁就是老大办公室,我相信只要他有空,一定能把他吸引出来
我们到底能不能逐步弱化分工,给工程师更多自治机会?
从PM的表现看,应该对这个有否定的态度了,我无语的想着。
冷不丁的,SQA MM来了句:“我想起来6月份的一个培训:不可能完成的任务”,对啊,那个培训的讲师就是我们的PM同学。更无语了
好吧,我先换位思考下
如果我是PM,我想尝试弱化分工
首先:把投放在外围模块的资源逐步释放出来,也就是面前新员工MM在做的一些模块有个了解后抽身出来
其次:主要精力放在核心框架上,新老员工结对编程,逐步使得新员工的能力得到培养,逐步增加他们的工作量,然后老人可以慢慢增加关注范围,逐步能够覆盖到新员工所做的
再次:再一个模块中把任务分解,每天让新员工和老员工自己选择任务,新员工独立完成任务,老员工帮忙review代码。再过段时间可以新员工review老员工代码
根据这样的方法每个模块完成在Sprint中的目标。

这样慢慢的从一个人负责一个模块到2个人负责两个模块。逐渐增加这种工作带宽,使得所有开发工程师都可以覆盖所有工作。
……
这样可行吗???(不要说不可能,方法总比困难多,成功学到底是不是糟粕啊
老大果然出来了:“怎么样,你们后来有没有和PM讨论?
我应了下,哈哈,要的就是你的态度:“还没有呢,她正忙着和DPM分解任务呢,我们现在想讨论弱分工的利弊,你有什么建议?”
老大表情淡定,说:“你看到了弱分工带来的收益,但同时你也应该评估下弱分工的风险,起码我对如何明晰责任表示怀疑。从趋利避害的本性来说,责任不清会导致潜意识的质量要求降低。”
对啊,如果两个人共同完成一个功能,那有麻烦的bug落实给谁。而且,现在软件工程的角色越分越多,应该是一种趋势。这和弱分工是背离的。
老大飘出去了,显然他对我这个讨论话题不感兴趣。
那培训老师讲的、《轻松Scrum之旅-敏捷开发故事》写的,都是一种脱离现实的理想状态?
我不甘心,把我的换位思考逻辑重新拿来思考
首先:把投放在外围模块的资源逐步释放出来,也就是面前新员工MM在做的一些模块有个了解后抽身出来(这个只是优先级调整,不是问题
其次:主要精力放在核心框架上,新老员工结对编程,逐步使得新员工的能力得到培养,逐步增加他们的工作量,然后老人可以慢慢增加关注范围,逐步能够覆盖到新员工所做的(这时候,责任如何分割,按常识来说,老员工这时候承担了类似师傅的责任,出了问题应该是徒弟承担
再次:再一个模块中把任务分解,每天让新员工和老员工自己选择任务,新员工独立完成任务,老员工帮忙review代码。再过段时间可以新员工review老员工代码
根据这样的方法每个模块完成在Sprint中的目标。(这时候,责任分割比较独立,review代码的人只是提供帮助,或者,还是徒弟未出师前的临界状态,这样的话还是应该师傅承担责任
这样慢慢的从一个人负责一个模块到2个人负责两个模块。逐渐增加这种工作带宽,使得所有开发工程师都可以覆盖所有工作。(到这里,责任就有点模糊了,如果工作两个成果,拼接不到一起,谁该加班留下来做?)
 
这样看,我应该还没有找到钥匙。
感谢群里面的讨论,anone拿了他以前的项目来证明弱分工是可行的,而恰恰从TA的举证中,我更觉得弱分工也许是个假想的方向。
有必要考虑下弱分工的目标是什:弱分工是为了确保Team可以真正的按照优先级来逐个完成Backlog,这样,即使Sprint没有完成整体目标,项目也应该有可以交付的成果,也就是说达到可用的递交物。
如图所示:先完成第一个Backlog的所有任务,首先Deposit这个Backlog是完成的,然后依次把第二个,第三个Backlog的任务拿出来做。
这样的好处是即使后面两个由于各种原因失败了,起码Deposit是可用的

那弱分工需要更多投入哪些:

学习成本:每个人要多出几倍的知识要学习,要能够实践,而只是为了可以把别人的工作衔接过来做。

沟通成本:每个任务都有前置和后置任务,环节越多,沟通成本也就越多,每个任务都需要沟通、需要知识传递的时候,会使得项目沟通所需的开销大大增加。并且沟通中无法避免信息丢失。

弱分工可能得到的机会

替代机会:人员流动的影响更小

质量机会:一旦形成弱分工,任务间衔接质量一定会自觉不自觉的提高,因为质量不好会导致没法衔接上。

我丝毫不敢预测的

自治能力:也许弱分工给工程师时刻“准备着”的内在动力和压力会提高工程师的自治力,但也有可能想法,劣币驱逐良币,导致最终不得不更多的自上而下的管理破坏自治。

工程师粘度:当大家随时可以做同样的事情,使命感会更强还是更弱,对组织的要求是更高还是更低,我有太多不知道

我的怀疑

因为弱分工的概念我是从讲师这边听来的,而且在网上搜索到这方面相关的除了我的,就是另外一个做游戏产品的,而且是在我问讲师后得到的解答,并没有出现在他展示的PPT上。

难道这是Scrum的一个前提假设,仅仅是为了完整Scrum框架而引入的一种理想状态

或者是国内讲师的一种错误理解?

----------------

问题太多,留待后来

2016-12-25 22:55:50 macan789 阅读数 1072


基于CMMI的软件工程实施 高级指南?

CMMI+敏捷整合开发--更快改进性能的案例与实用技术?

没有更多推荐了,返回首页