2015-08-31 22:09:31 jnqqls 阅读数 5937
  • SCRUM敏捷开发视频教程

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

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

      

        在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.

 

        通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解.

 

        第一个要说的角色是PO

 

         敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。

 

        在我们的团队中PO是行方的专门业务人员担任并执行PO角色,本身并不开发.跟她打交道的一方面是我们这边的开发团队,另一个方面是行方的业务团队,她作为开发和业务的桥梁.

 

        PO主要是确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品负责。是维护产品需求清单( product backlog )的人.详细的职责为一下七点:

 

1、确定产品的功能;

 

2、决定发布的日期和发布内容;

 

3、为产品的ROI负责;

 

4、根据市场价值确定功能优先级;

 

5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

 

6、接受或拒绝开发团队的工作成果;

 

7、参与ScrumPlanning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 SprintRetrospective Meeting(Sprint回顾会)

 

 

        结合我们的团队的PO来说一下实际的情况,在项目的初期我们的PO基本上上是神龙见头不见尾,很少有机会见到他的面,因为他本身还担任行里的其他职务,总是来也匆匆去也匆匆,所以导致了前期开发中很多不可避免的问题.之后行方安排了专职人员担任项目组的PO,整个项目组20个人分成两大组,两个PO负责我们这两个大组的任务和计划.

      

       随后经过团队的磨合,PO也越来越专业,开始进行原型设计,挖掘业务,更融洽的跟开发人员进行沟通和交流.

 

      一个迭代的成功与失败完全由PO说了算(在相对比较理想的情况下),总结就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

2016-01-24 22:44:24 yzsind 阅读数 8990
  • SCRUM敏捷开发视频教程

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

    10414 人正在学习 去看看 CSDN讲师
敏捷开发中测试角色的窘境


先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇:


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

测试妹妹:需求文档在哪里?
码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲一下吧。
测试妹妹:好吧,懂了,那我开始测了。

测试妹妹:测试完了,有5个bug,我都提交了,你看看吧。

码农哥哥:好的,还有一个新需求,再和你讲一下。

测试妹妹:终于测完了,全部测试通过了,恭喜啊
码农哥哥:sorry,刚我改动了一个小点,你再重新回归测试一次吧,这次应该OK了。
测试妹妹:终于回归完了,又发现一个问题...

产品经理:客户反馈了一个bug,你赶紧看看
码农哥哥:不可能啊,这个功能我都测过的,我看看
码农哥哥:真晕,线下测试是好,线上有问题,有个配置错了,另外这个客户的数据比较奇怪,测试也没有验证过这种场景
产品经理:XXXXXX,客户已经提故障了!
码农哥哥:下次线上发布一定要叫上测试妹妹仔细回归

码农哥哥:今天晚上12点产品更新,到时要你来回归验证啊
测试妹妹:好吧
测试妹妹:你们发布完了吗?都凌晨2点了,我什么时间可以回归验证啊?
码农哥哥:再等等,还有一个小问题在搞。
测试妹妹:现在好了吗?
码农哥哥:sorry,没搞定,发布要回滚了,今天不需要回归验证了,你先回去吧
测试妹妹:你妹啊!!!

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

故事讲完了,以上就是一些项目敏捷开发中很常见的问题。

敏捷开发强调的是快速迭代,通过快速迭代发布并验证产品是否满足用户需求来减少产品风险,而不是像传统软件一个花一年甚至几年才发布。敏捷开发在互联网行业里非常流行,大型网站基本每周都会有发布,甚至一周发布几次,超大型网站的应用都是分布式的,一天都可以发布上百个feature。
互联网的需求变化很快,有些产品也是实验性的,所以更需要快速迭代,这也会导致许多产品在一些小的需求都没有需求说明书或者设计文档,全是靠产品经理与研发同学沟通需求,然后就快速发布上线了。这种模式在传统软件里是不可能,传统软件都会有很强的产品版本概念,并且会对每次升级都要制定详细的设计、开发、删除与发布计划。 

面对互联网这种快速迭代,并且还有时缺少需求与设计文档的背景下,我们测试同学如何跟上节奏。如果按传统模式,测试与研发是不同的人员负责,那么必需要有清晰的需求设计文档,否则测试基本靠感觉。并且产品经理与研发同学还要与测试同学沟通需求,沟通项目计划与资源协同。第二,今天互联网的研发同学普遍比测试同学多很多,有些产品甚至是10:1以上或者是没有测试角色,这样的团队测试同学根本来不及了解需求细节,只能做一些核心主功能验证,对于边界测试没法顾上。总体看起来独立测试角色在敏捷开发里有点力不从心。

经过几十年的发展,测试类型也细分成很多种,有白盒测试、黑盒测试、灰盒测试、单元测试、功能测试、集成测度、性能测试、压力测试、自动化测试、回归测试、灰度测试、安全测试、恢复测试等等概念。 当前业界的测试工具眼花缭乱,有QTP/UTF、LoadRunner、JMeter、Selenium、TestDirector、QACenter、Rational系列等知名产品,也有很多JUnit、TestNG、RobotFramework、gtest等测试框架,还有更多如网络、数据库、硬件等专业领域的测试工具。

这些产品,除了JUnit、JMeter这类程序员可以轻松掌握的轻量级产品框架外,其它产品在敏捷开发中都感觉力不从心,主要原因是大部份产品为测试角色开发的,研发角色有学习成本,并且研发同学更喜欢白盒测试。

如果测试的工作由研发来完成,这会更符合敏捷开发思想,大大减少沟通成本。但是问题来了,研发同学并不擅长使用各种测试工具,研发同学更多只会完成单元测试。如果能有一个专门面向研发同学的测试工具,岂不是很爽,那一个面向研发同学的测试工具应该是什么样的呢?我先说说程序员自测的一些现状:
1.单元测试:目前JUnit、TestNG加各种Mock基本还能应付,就是测试代码写起来很多
2.功能测试:这个很头疼,如果软件有界面,可以通过软件操作来完成核心功能测试,如果没有界面,就自己模拟软件对外API接口规约来模拟测试
3.性能测试:这个要么使用JMeter这样专业工具来完成,实在不行,要不就自己再单独写一个程序或脚本来压测
4.回归测试:不好搞,面对各种运行环境,人工回归太不靠谱了,真心需要一个全自动化的工具
5.安全测试:太专业了,估计搞不定
6.边界测试:写各种边界值来搞死自己,想到的就试试,没想到的就当不存在了
7.bug管理:都自己测试了,还提个毛bug啊,自己老老实实把屁股擦干净

从上面看起来,要是交给程序员自测也不靠谱啊,完全是靠感觉,凭经验测试了。

如果有一款面向程序员自测的专业测试工具,它会是什么样的呢,我列了几点:
1.学习成本低
上手很容易,如果是框架,不要超过JUnit这样的难度吧,如果是产品,那应该有一套简单易用的界面,并且不要冒出很多测试概念,不要动不动就来1GB的安装文件,最好能免安装了。
2.功能测试用例编写简单
编写功能测试用例,不要只是简单的像bug管理那样写一堆文字描述,测试用例应该是可以运行的,编写完后就能直接运行、验证
用例编写的语言应该非常简单易学,或者是直接用程序同样的语言(如JAVA、C、Python等),不要让我去学习一套新的语言或规范
测试用例的代码应该很短,不要是我的业务程序写了100行代码,结果测试用例写了300行代码,这会很奔溃,可能会导致我花了大量的时间在调试测试用例脚本是否正确,如果测试代码小于程序代码的1/5就挺好。
3.功能测试用例能同样显示测试代码覆盖率等信息
单元测试可以比较简单的看到测试代码覆盖率,查看未测试到的代码。这个很有用,功能自动化测试希望也能看到这个,这样可以确认哪些地方没有测试到位。
4.可重用,可扩展
    有些组件是已经写好的,测试用例应该能直接复用,比如java中一些标准jar包函数,或者是自己产品里封装的组件。这样对于编写测试就更高效了。
扩展性要好,自己也可以封装一些测试组件,供别人使用或者模块公用。
5.可以自动化回归测试
面对各种环境:开发环境、测试环境、预发环境、生产环境A、生产环境B,自动化回归测试太重要了,最好是功能测试用例编写完后可以直接用在回归测试里,不要又单独写一套回测试用例。
6.能自动造测试数据
造测试数据很花时间,有时还需要造各种随机数据,另外各种边界数据也能自动化最好了,靠人想有时不靠谱的
7.能支持UI自动化测试
现在UI测试基本靠人工,Selenium之类的产品IDE比较简陋,语法也需要重新学习,学习成果不低,而且有点地方写起来很难受。需要能有更高效的UI自动化测试支持。
8.调试方便
  编写测试用例脚本要有方便的调试功能,用例运行过程希望能显示详细的输出日志,特别是在用例运行失败的情况下,不然找问题很花时间。
9.免费、开源
你懂的

最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
2015-09-29 22:21:25 jnqqls 阅读数 7538
  • SCRUM敏捷开发视频教程

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

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

        

        通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster.

 

Scrum Master(SM)

 

        敏捷开发中的SM即ScrumMaster,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

 

       Scrum Master是团队的导师和组织者,与ProductOwner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

 

       ScrumMaster并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 ScrumMaster是规则的执行者,他是Scrum团队中的服务型领导。

 

       这一点在实际项目经验中是很难达到的,因为想要达成自我组织的团队并非一朝一夕,尤其是新组建的团队,本身团队就是一个磨合的过程,只不过我们是通过哪种方式可以磨合的更快,更有效率.如果SM这个角色能够很好的担当和把控,非常有利于整个团队的磨合.

 

Scrum Master主要工作职责

 

      确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

 

1、保证团队资源合理利用;

 

2、保证各个角色及职责良好协作;

 

3、解决团队开发中的障碍;

 

4、作为团队和团队外部的接口,协调解决沟通中的问题;

 

5、保证开发过程按计划进行,组织ScrumPlanning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint ReviewMeeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

 

            结合我们项目中的实践,SM的角色一直处于变化的过程中,大概在项目进行半年之后才稳定下来,前期因为变更着,导致项目整体比较混乱,没有一个主线.SM稳定之后,整个局面有好转,但是并没有预期的效果好.

 

        总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

 

2015-09-29 23:23:16 jnqqls 阅读数 3299
  • SCRUM敏捷开发视频教程

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

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

        

      在敏捷开发中除了POSM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.

 

      因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个新的团队磨合成敏捷开发所要求的自组织团队是一个比较难得过程,尤其是在实际的开发进度和需求等不定因素的影响下.

 

     因此提高Team的凝聚力是创建自组织团队一个 重要因素.

 

    团队的凝聚力来自于大家都在为一件事而努力,每天都在做,而且经常有提高。

      为了提高团队凝聚力,有很多途径可以实施,例如在每天的站立会议,Team成员除了介绍每天的工作,还可以做两个额外的事情:

 

        一个是快速形成某个团队级别的决议,例如将某个方法作为公共模块,临时调整资源等,解决阻碍团队的重大问题;

 

          另一件事情是代码分享或者代码复查,每个人都会拿出昨天最核心的功能代码,讲给大家听,只包括外部模块的耦合,业务逻辑,大家进行讨论,结果不是发现了漏洞,就是发现了某个人的代码更加规范,其他人都会和他保持一致。当然,因为涉及到具体代码此过程在站会的时候进行可能会耽误比较长的时间,项目团队可以根据实际情况,每天留下固定实际来进行此项操作,因为是良性的,所以会越来越好.

       

 

       Team成员每天进行集体沟通,每个人都有机会发言,每个人都不只是听客,每个人都可以感受到其他人对项目的贡献,每个人都有是整个项目和产品的主人翁的感觉.

 

       为了让整个Team的沟通有效率,因此每个敏捷团队人数不易太多,如果有很多人,首先站会就会浪费大家很多时间,也同时因为人数太多,大家的关注点就开始分散起来,不利于高效的去解决问题.

 

       所以在实践过程中,我们原先的20多人的团队分开成两个敏捷团队,每个团队都有各自的PO,SMTEAM.每天的站会分开两部分进行.如果需要两个团队共同来解决公共问题,则还有站会的站会,每个Team派代表来给项目经理说明问题,进度等.

 

       至此,整个敏捷项目的角色基本上全了,PO+SM+TEAM.


2018-11-27 15:33:36 wangqiang9x 阅读数 306
  • SCRUM敏捷开发视频教程

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

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

第一篇中介绍了敏捷角色的划分及职责但是写的太粗了,我觉得这点特别重要有必要给大家细划一下:

PO (project manager)

性格要求: 能忍受孤独、是个辨才
种种标签表明,这是个利益相关者,通常情况下与团队成对立面
用户故事经常被团队排斥并且在项目中是独立的,所以PO一定要经得住这种场景。但是产品在这方面更重要的是要有优秀的沟通技巧、愿意与团队相互相互渗透了解、愿意与团队打成一片
角色标签:
是个可以“掐脖子”的人
关注“投资与回报”
管理产品(backlog)
要有愿景
需要时能被团队找到
可以接受或退回成果
决定发布的日期和内容
获得授权去做决策

团队

性格要求: 勇气、求真相、与PO做理性碰撞

本着人人都是产品经理的原则,团队千万不要变成编码的工具,程序员还是很聪明的,很多时候可以为产品提出建设性的想法

标签:
专才 (具备专业的技术)
跨职能(敢于跨职能挑战)

SM (scrum master)

性格要求: 有影响力、人格魅力、愿意奉献、责任心强
通常SM还是一个团队的成员,不但要做好本职的工作还要保证scrum的运行,协调、移除障碍、保护团队。。。等。

角色标签:
确保scrum运用的有效性
变革的代理人
公仆式的领导者
确保scrum被理解和遵循
引导
确保scrum价值观、原则和规则被彰显
培训/辅导
保护团队
移除障碍
苏格拉底式的提问者
没有权力
好的聆听者
scrum价值观的典范

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