2018-08-16 03:56:12 pbyang_love 阅读数 476
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

敏捷开发的流程:转载自https://blog.csdn.net/fangxin_321/article/details/48139375

 

概要设计就是设计软件的结构,包括组成模块,模块的层次结构,模块的调用关系,每个模块的功能等等。同时,还要设计该项目的应用系统的总体数据结构和数据库结构,即应用系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。

概要设计阶段通常得到软件结构图
详细设计阶段常用的描述方式有:流程图、N-S图、PAD图、伪代码等

2019-05-11 19:34:29 jnshu_it 阅读数 1612
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

这里是修真院后端小课堂,每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析后端知识/技能,本篇分享的是:

【什么是敏捷开发流程 】

这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
一. 先说一下官方的定义:

敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

  1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

  2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

  3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

  4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

  5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

二. 然后是我理解的敏捷

主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

Story划分(产品+UI+开发)
产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

人员划分(leader+开发)
主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

方案设计(数据库设计文档、接口设计文档、方案设计文档)
先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

方案评审(所有人员)
对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

禅道任务拆分(开发人员)
方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

开发(项目日报+工作日报+进度邮件)
每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

端对端(接口)测试(开发人员)
前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

压力测试+集成测试
系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

Demo
对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

 

 



 

【欢迎加IT交流群565763832与大家一起讨论交流】

2019-10-14 10:36:21 AA5279AA 阅读数 117
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

如果想知道敏捷开发是什么,以及敏捷开发的流程,请参考我另一篇文章: scrum敏捷开发流程介绍和心得

 

敏捷开发的优势:
1.短期目标明确

开发的最终意义就是为了完成目标,而如果一个目标过于长远,那么就容易造成短期的盲目乐观,认为工期还早,从而造成短期的任务完成不及时,从而最终导致接近项目交付时工作量暴增,甚至出现延期交付的情况。

有短期的目标,开发目标明确,知道什么节点该做什么。每一期的任务目标会不断的鞭策开发,督促开发及时完成任务。如果某个节点造成耗时过多,也可以及时暴露出来,及时解决。

 

2.按照优先级去完成任务,优先做高优先级的。

有时候会遇到这样的一种场景,产品提了一堆需求,我们依照顺序去做。但是有些价值不高的需求因为先提出来,导致开发会优先去做。快速迭代的过程中,这种低优先级的需求很有可能会出现刚开发到一半就被告知不需要做了的场景。敏捷开发可以很好的避免这种问题。


3.拆分大需求,方便开发。

敏捷开发需要开发去评估工作难度,分别为1,2,3,5,8,13。如果一个需求超过13,那么必须拆分为若干个小的需求去做。就好比吃一只全羊时有可能无从下手,但是拆分成多个部分时,吃起来则舒畅多了。

4.避免无用开发。

相对于瀑布流开发的一个人完整的跟一个需求,敏捷开发要求每个需求必须在开发前时明确的。

传统瀑布流的话,哪怕需求不明确,仍然可以继续开发,当做到不明确的点的时候,再去和产品确认。而这时候如果发现所做的并不是产品想要的,那么之前所做的工作就白费了。

敏捷开发的话,做需求前必须先明确需求要做什么,计划会上先介绍规划,这样就等于和产品再过了一遍需求,确认做出来的就是产品想要的。

5.这是一个自组织的。砍掉了技术经理任务安排这个环节,自然效率会高。同时也锻炼了成员的沟通能力

 

敏捷开发的劣势:
1.需要开发熟悉各个模块的逻辑,难度较高,同时,这也对代码规范清晰度提出了要求。
2.需要开发backup其它平台的开发,需要开发人员对全栈开发有一定的掌握。

3.需要较好的团队协作。

4.澄清会和计划会需要开发测试全部到场,会议时间有时候会持续很长。但是某些需求大多数人实际上并不参与,造成工时上的浪费。

5.一般来说,技术经理不会参与到所有组的敏捷开发中,所以比较难对某个成员的贡献作出客观的评价。
 

2017-04-07 20:10:00 weixin_30607659 阅读数 11
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

一、什么是敏捷开发?

在软件工程的语境里,“敏捷流程”不是指某一种具体的方法论或过程,而是一系列价值观和方法论的集合。

二、敏捷开发的原则

 1.  尽早并持续地交付有价值的软件以满足顾客需求。

 2.  敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。

 3.  经常发布可用的软件,发布间隔可以从几周到几个月,能短则短。

 4.  业务人员和开发人员在项目开发过程中应该每天共同工作。

 5.  以有进取心的人为项目核心,充分支持信任他们

 6.  无论团队内外,面对面的交流始终是最有效的沟通方式

 7.  可用的软件是衡量项目进展的主要指标

 8.  敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去。

 9.  只有不断关注技术和设计才能越来越敏捷.

 10.  保持简明 - 尽可能简化工作量的技艺 - 极为重要。        

 11.  只有能自我管理的团队才能创造优秀的架构, 需求和设计. 

 12.  时时总结如何提高团队效率, 并付诸行动。

三、敏捷开发的流程

    敏捷开发的具体方法论有哪些呢?Scrum,极限编程(XP),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development)等等。这里我举以Scrum例的开发流程:第一步,找出完成作品所需要做的事情,估计好工作量。第二步,决定当前的冲刺需要解决的问题,团队人员进行主导任务的估计和分配。第三步,冲刺,进行每日立会,依次报告昨天做了什么,今天要做什么,遇到哪些问题。第四步,得到软件的一个增量版本,发布给用户,在此基础上又进一步计划新功能的改进。

   敏捷的团队要求十分简单:自主管理(自己挑选任务,每次sprint结束后,总结不足,提出改进并实施)、自我组织(所有人联合起来对项目负责)、多功能型(每个人全面负责,自己搞定规格说明书、测试)。

 

  

转载于:https://www.cnblogs.com/ly97/p/6673318.html

2019-05-21 10:11:30 jnshu_it 阅读数 15920
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10428 人正在学习 去看看 CSDN讲师

这里是修真院前端小课堂,本篇分析的主题是

【互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?】

前言================================================

1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。

第一篇对IT职业做了一个相对深入的介绍,给了想从事互联网职业的人一个了解各个职业的机会,已经有4000+赞了,我想是真的帮助到了很多人。 IT行业都有哪些职位,初学者(0基础,新人)该如何选择,才能够快速进入这个行业? - xdyl 的回答

第二篇是对敏捷开发和项目管理做了一介绍,这篇贴子还没写完,其实它的价值远远大于第一篇走马观花的介绍。只是大家还没有到能够理解敏捷开发的时候,所以我想了很久,决定暂时不写了。互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么? - xdyl 的回答

 

这是第三篇,写这个贴子的动机是因为,在修真院有不少人在问,我要学到什么程度才能找到工作,我是零基础啊,有没有视频和教程可以教我。有哪些IT初学者(新人)成长为技术大牛的真实经历? - xdyl 的回答

 

2.本回答和第一篇不同,纯属分享,并不需要有任何的广告。3.但是,本人依然不对分享出来的任何内容的可信度负任何的责任,也根本不保证是一篇公正,客观,完美的回答。4.这个回答,是任何一个初级或中级甚至是高级的程序员,产品经理,Leader都可以认真去思考和尝试的,某种程度上,这个回答比写两行代码更有效果。

5状态:未完待续

 

正文========================================

 

首先讲为什么需要敏捷开发。在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多。总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求。

怎么办?继续改。这一改又是半年多的时间过去了。马丹用户的需求还再改,怎么办?

这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大。文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多。

不仅仅在几万年前,就是在现在,也是经常会有团队出现这种问题。不相信,你可以看看是否遇到了以下这些问题:

1.需求总是在变动,反复变动,无限拖延。

2.开发工程师做出来的项目,bug不但多,而且经常改不好。常常是改了一个Bug,出现另一个Bug,好不容易把一个Bug改好了,过了没多久又重现了。原本好好的功能,反而会因为改Bug导致出现的问题更多。

3.做出来的东西完全不是产品经理想要的样子,沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的。

4.项目延期不是最坏的结果,最坏的结果是还从不知道项目倒底会延期多少,根本没办法去衡量工作量,团队的成员都在加班加点,然而完全看不出来问题出在什么地方。

5.开发文档,产品文档,接口文档,测试报告和真实的代码从没有完美契合过。产品经理设计出来的原型和UI设计出来的页面和程序员开发出来的代码完全是一种不同的体系,三位一体的故事从没有真正发生过。代码的实现和接口文档根本不一致,最后索性干脆不看接口文档,完全口头交流。出错的时候各种撕逼扯皮,谁也分不清倒底谁错了。

6.Team的战斗力和凝聚力不强,经常是对着干,对分配的任务总是各种报怨,出现问题之后第一反应是这个不关我的事,不是我的问题,是后端前端设计QAPM的问题。

 

如果你遇到了这种情况,或者说你不甘于这种现状,那么恭喜你,你可以真的需要敏捷开发流程了。

第二,敏捷开发包括了哪些内容

 

敏捷开发总的流程如下:1.需求规划和分期2. 需求评审3. 需求讲解4. 方案评审5. 每日晨会6. 性能测试7. CodeReview8. Demo9. 测试阶段10.线上Bug修改流程

表跟我说哪些东西不应该包含在敏捷开发流程里,如果你不喜欢,跟你的观念有冲突,你可以把敏捷开发这四个字换成任意四个字。总之,如果要解决这些问题,这是我目前看到的最佳实践,每一个节点都非纸上谈兵,而是经过无数个尝试和失败总结出来的。

如果你是一个IT公司的管理者,如果你不知道该怎么去管理自己的团队,我强烈安列你按着我说的这种标准化方式去做,放心,出了问题我保证不会负一点责任。

确切的说,我说的敏捷开发流程,并不仅仅是开发团队的事情,它背后隐藏着更多的理念。我可能整理的不够清楚,毕竟这是第一版。

1.产品和开发必须是一个Team,大家只是分工不同,角色不同,并不是两个对立的团队。

如果你的公司是把产品和开发分成两个部门,那么恭喜你,产品和开发之间的纠纷一定无限多。

在所有我带的Team中,自始至终强调的理念就是:出了问题,别跟我说这是产品设计出来,这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任,这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题,那么也只是为了避免下次出现同样的情况,用户只会知道是一个公司出了一款垃圾产品,没有人关心到底是产品还是开发的锅。

这是做敏捷开发的大前提。或者不仅仅是产品和开发,责任共担,One Team这个理念是贯穿始终的。这并不是说,大锅饭,而是说,面对不好的结果,所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景,以避免后续会出现同样的情况。

 

产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候,会提高的。实际上,需求分期如果没做好,敏捷开发只能流于形式。

需求分期怎么做,这是MVP的事情,另一个话题。简单来说,每一期都要有一个提前的预测,这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

 

2.职责明确,每个人要负责的事情必须清晰无误,谁该做哪些事情,必须要提前讲清楚。

开发团队的推荐角色应该是这样的。 PM 1个 UI 1个 CSS/js 1~2个 Java 2~4个 Android 1~2个 IOS 1~2个 QA 1个

这是一个相对平衡的模板,这样的一个8~10人的小Team,是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式,可以支持五到六个小Team同时启动。

在讲到最后多Team并发协作的时候,我也会提到的。 除了这些项目小组的角色,还有各个Team的Leader。我比较推荐小组分成如下几种: 1.产品Team 产品团队 2.用户体验 Team 传统的UI团队升级为UE,升级为整个系统甚至是公司的用户体验师。 3.后端Team 苦逼的后端 4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起,我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入,但是普通的项目上手还是应该没有问题的。 5.QATeam QA只需要做功能测试,回归测试,边界测试,并不需要做性能测试。这里也会在后面提到。



 

那么来描述一下每个角色的不同职责。这些不同的角色牵涉到团队并行开发,所以并不是简单的随便扒拉到一堆就好了的。

PM : PM的职责并不是画原型,而是去分产品的分期,确定产品要做的功能和优先级。 对于产品来说,最大的职责并不是将原型画出来,而是要证明自己要做的功能是合理的。 如果你证明不了自己要做的功能是合理的,是值的尝试的,就是产品经理的失职。

可以参考MVP,有无数的办法可以提前验证,如果不能够提前验证,那么就证明这是有风险。做为PM,一定要有这种风险的意识,要知道自己身上担负的责任,PM花了两周时间设计的原型,8人的开发团队要折腾近三周左右的时间。

原型和产品文档都是辅助的东西,我甚至不推荐产品经理去做原型设计,只拆分Story。 原型设计交给传统的UI更合适。然而在真实实施的过程中,因为很少有UI具备原型的设计能力,所以实施起来会有一些难度。这个不算特别重要,慢慢培养。

PM不需要为开发进度负任何的责任,这很重要,不要把PM当成项目管理来使用,如果你让PM去做了项目管理,恭喜你,Game 近乎 Over,产品经理没有时间再去思考如何做功能了。

PM的职责就是把功能设计好,优先级排好,给开发团队讲清楚需求,结合Story优先级和功能实现的大概时间点去做排期。

开发工期交给开发团队去做,Bug会和QA,开发团队一起来定。记着要在开发团队开发项目的时间里,去做好下一个产品迭代的设计。

 

小组Leader:需求评审会的成员应该包括PM组的Leader,前端组的leader,后端组的leader,测试组的Leader,或者是其他公司的中层骨干。

这应该是一个公司所有应该为这个项目负责的人的评审会,在评审会上的结论,就应该被坚定的执行下去了。不参与评审会的人,不应该再对需求指手画脚。

需求评审会的目标就是确定原封不动的需求,所以在这里要格外的注意,PM拿出来的方案设计,一定是完整的,而且必须评细节。如果说,一个公司的中层骨干经过需求评审会议,仍然需求乱成一比,那就没什么可说的了,继续努力提升自己的水准,或者是补充真正的中层。

而PM的目标就是吸引需求评审会的意见,尽量让自己的需求和设计通过评审。各个小组的Leader还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。

小组的Leader还应该负责项目中风险的调控,考虑是增加人手,安排加班,项目延期,还是调整功能。

与些同时,应该去审核最后的性能报告,看看是否达到系统的期望值,遇到了疑难问题如何解决。

 

开发组成员:项目进入真正的开发阶段后,开发组的成员就应该是主动去控制项目的进度,和风险,以及主动去测试项目中存在的问题,在这个阶段,除了一些需求不明,或者是发生变动的情况出现,不应该去打扰产品经理。不要让产品经理做开发团队的保姆。

开发组的成员的目标就是做好项目的进度控制,有风险就及时反馈给Leader,确保自己理解的需求是明确无误的,确保自己的测试是完整和严谨的,确认自己写出来的代码是可以维护的。

一定要理解清楚,一旦PM通过Story讲解,将需求交付给开发组成员,那么开发组成员就应该主动而独立的为这件事情负责。

当项目完工以后,开发组成员应该交叉去做CodeReview,并且出性能测试报告,以及组织Demo。

 

测试组成员:测试级成员的职责不是做功能性的测试,也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成,除了一些特别麻烦的,需要各种极端条件才能复现的,正常的操作过程中出现的问题,都应该是有开发组承担。性能测试同样是开发组人员自行完成,各小组Leader只需要知道一件事情,测试报告是否能够通过。

所以测试组的主要做的就是准确的记录,以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

回归测试是需要做的,但是也不是完全必须要做。如果能够积累足够多的自动化测试用例,就去正常使用它,如果不能,就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚,他们往往更清楚,什么地方容易出问题。

接受线上的反馈并且记录也应该是QA的职责,如果Team足够细,可能会有运营或者是客服统一对外收集,然后交给QA,QA再负责录入Bug系统中。

基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情,其中的很多小细节,都照顾到了每个角色的职责和义务。理论上来说,如果有一张图的话,可以更清楚的画出来不同角色的功能。

这种职责的划分,和传统的职责会有一些不同,反正,在我带过的Team中,这是最高效的,也是最能发挥出团队的能力的方式。你可以信,也可以不信,这中间的每一个细小的调整,都是经过无数个日日夜夜的验证而得来的,我还未曾看到过比这种职责划分方式更高效,更合理的做法,虽然我接触的Team也不够多,爱信不信~

3.每个人必须学会主动去为自己的事情负责

当有了第二条,你很快就能发现团队中,谁是能够尽守职责,更主动的人。第3条很难做到,特别在很多公司,并不注重对于团队凝聚力的培养,也不会注重和他们之间的交流,不知道他们想要什么。

所以这也是我一再强调的,敏捷开发并不仅仅是一个开发流程,更是一种管理的方式,他牵涉到绩效考核,公司福利,上下班制度等等你看不到的东西。

如果说你的团队成员并不能做到为自己的事情负责,那么你需要的就是,要么就是去更换团队,要么就是想办法去激励团队。这是另一个话题了,我心情好的话,可能会在这里提到,如果心情不好,可能会在下一个文章里,也可能根本就不会写了。

这件事情其实也不算难,第一,明确这种职责的分工是合理的,第二,Leader都需要了解自己的团队的状况。第三,不断的去强化和培养这种做事的习惯。

就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提,而不是说,有了这三点,敏捷开发就一点能做好了。

在具体的实施上,还有无数的细节是需要去整理和落地的。

隔了好几天没写,我已经忘记了自己原本的思路是什么了,先写到这里再说。

 

========未完待续,进度15%========================

 

敏捷开发

阅读数 2946

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