2013-06-27 22:52:11 doubleuto 阅读数 2856
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
 1、需求梳理下一个sprint的会议:(每个sprint中抽5%--10%时间)

    目标:预览需求、提供全貌
              精华故事、加深理解
              整体估算、高层设计
              发现问题、理出风险
  • 参加人员:全体成员
  • 讨论有价值的细节
  • 每个sprint中抽5%--10%时间,每次1个小时
  • 2--3次
  • 开会得频率会慢慢的减少
  • 未来的事情,最好先做一些准备(贴纸、文档)
  • 头脑风暴:鼓励大家胡思乱想、异想天开、多多益善、见解无专利
  • 列出风险、(可以先设置最多时间研究、在拆解任务)
2、敏捷估算
   
    目标:以估算驱动高层设计
  • 每个人每15分钟会有一次干扰
  • 消耗时间、理想时间:大家估算的是理想时间
  • 延迟时间,不在估算时间考虑
  • 相对估算
  • 集体估算(复杂度)
  • 包含设计
  • 使用估算扑克(估算用户故事,不是任务):估算时间最多、最少的人出来讲自己的方案,等他们2争论完成后,重新估算(鼓励讨论)

2015-02-25 21:10:24 jjavabboy 阅读数 2274
  • SCRUM敏捷开发视频教程

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

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

Scrum入门基础系列之产品列表梳理(需求梳理)

产品列表梳理会议是Scrum中非常重要,而很容易被忽略的一个会议。说它重要,是因为Scrum开始之前就需要有准备就绪的输入,这个输入就来自于产品列表梳理会议的结果,即初始的产品列表。而对于刚开始转型敏捷的团队,往往会忽略掉产品列表梳理会(需求梳理),从而造成迭代计划会时间过长,或者无法准时开始迭代等等问题。要想解决这个问题,需要首先明确为什么在迭代开始之前要进行梳理会议,以及谁需要参加这个会议,在这个会议都有哪些活动等。

产品列表梳理会议,是迭代就绪的很好的指示,即只有产品列表准备好了,才可以进入迭代。另外,梳理会议是由产品负责人发起或负责,可以召集开发团队参与,也可以只有相关的开发团队成员或相关的利益干系人参与。

产品列表梳理会议的内容可以总结为如下几个字:增删改。首先需要明确一点的是产品列表不是固定不变的,它是可以随着新需求的出现而变化的(即好的产品列表符合DEEP原则,参加博文http://bobjiang.com/2013/11/24/product_backlog_user_story/)。

  1. 增:那么当出现新需求的时候,就需要增加一条产品列表条目,并且针对新的条目也需要符合良好用户故事的标准(INVEST)。
  2. 删:某条需求如果已经不再需要,或者市场条件变化后该需求就可以删除了。
  3. 改:产品列表的修改还可以分为以下几类:
    • 重新估算用户故事大小、
    • 重新排用户故事的顺序、
    • 用户故事拆分等。
    • 调整发布计划

Scrum入门基础系列:

2011-06-28 10:45:00 dollybol 阅读数 431
  • SCRUM敏捷开发视频教程

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

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

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中"轻架构设计"的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 # G1 Y% K2 ~; ]; q% w
首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。
% |, e: q! f' v
但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。
3 X0 E9 @' y3 U7 Q3 W7 Z& i( P1. 敏捷开发中架构设计的方式
# A% @' L0 j2 U1 M这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。
! Z" C( n# {" Q5 C% p/ f( _# E* K! D/ d
下图描述了敏捷开发前和后架构方式:
8 y6 m) |/ n6 m1 Q* f/ d' c1 |

下载 (6.72 KB)

2009-7-7 09:16


0 O4 n& l& n+ H0 a8 ?# `

: L, I# ^$ I4 W" N1 [
上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中
, ?6 p/ I. K& X  A+ E* v! l; M( T& [看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。
' ]7 e) n  S3 }9 j7 I2 X; H
"马克威茨资产组合理论"中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。
6 L! n8 L1 Y0 {" J9 m这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。
) A( S  q$ q2 h2 Q. Q如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:
5 a; D' m$ |( V% C) c! R; f
(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。
: c! o* y3 b+ _1 Z(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生
2 [% J6 y7 N8 u* k2 V. y7 F(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。
; D5 k2 h, N1 O  D(4)其他
! Y( d3 z: @7 L- D所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。
: u% U" c8 a+ W* h$ k: m! x4 |! _0 X
2. 敏捷开发中架构设计的内容
' T+ w: V# K+ X/ z; a
传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。
+ F2 }* |9 {% J3 f# W; L出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:
/ a& A6 R! ]: Z(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生,需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。
. w. v& o) r6 /0 N. V; I+ J8 b
(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。
/ {9 L$ U7 |& @3 g& E
基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计
) P/ {$ P/ r+ }' l5 d(1)敏捷开发的架构保留架构部分
; V; W4 _8 V0 y
(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。
! {4 L, B4 B, r1 o2 ~7 ~! z( [5 e
分离后,敏捷开发中的架构就轻装上阵,内容可以包括:
' k$ [0 G0 C! e9 }" [
(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。
! I" v  ^9 E$ Z. D(2)产品和技术选型
2 p+ X/ B' D3 r& D; T3 T
(3)各个组件的结构,以及的关系
) v6 Q6 [( x2 ~
(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。
" K. @# D& _$ C' z# R5 Z/ /9 o4 T! W(5)….
& /6 i8 c) d5 T" w
而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现
; y( @+ P" X; l3 u0 f所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。
8 H7 [' e# d+ v0 V5 e/ H
3. 敏捷开发中架构设计的人员
6 u& h: A4 D, {3 i& J% l. [
敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。
5 `$ n  r+ K+ f
这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。
% V2 /4 K- E4 ~1 L1 x, v& }/ j+ X
这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。
, |7 h* r  U! R. @/ M0 f* C总结
8 X: n' g8 j) W. ~  c, r" Y架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

2019-05-07 13:10:31 weixin_41433717 阅读数 26
  • SCRUM敏捷开发视频教程

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

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

一、开发模式

我们团队用的是Scrum敏捷开发模式,这个模式的优点就是比传统的瀑布式开发灵活,但是对于团队中每个人的要求又比较高。

Scrum中有三个角色,分别由PO、Scrum Master、项目成员组成。那我在这边就是Product Owner的角色,也就是项目的负责人。一般产品经理在需求分析、确定需求之后可能就开始做原型设计和写PRD文档了。但是在这个开发模式下,我是不写PRD文档的,我会把所有想法体现在原型上,再加上相应的备注,如果说开发人员遇到问题就会找到我问清需求。因为Scrum的最关键的点就是多沟通,用沟通来替代文档。

当然,如果在开发的时候直接扔个原型给开发,那他们肯定一脸懵逼然后想把你打一顿。为了产品经理的人身安全,所以这就涉及到我接下来要说的五个会议。Scrum的五个会议由需求澄清会、计划分析会、站立会、评审会和回顾会组成。

需求澄清会,顾名思义,就是澄清需求,但是人家就会问了,你没有PRD你澄清什么需求。对的,我准备的是User Story,也就是用户故事,如果说我是这个产品的用户,我要实现什么功能。这边的功能描述可能就是“我想要有XXX增删改查的功能”而不是详细到“我的提交按钮要放在哪里”。简单点说,就是这个用户故事是有一定的颗粒度的,但是它在所有产品的设计者、开发者和使用者的理解下是没有歧义的。只要我们大家都确定了,我们要做的就是这样的一个东西那就没有问题。因为用户故事都比较多,我们一般会把用户故事排一下优先级,然后根据优先级把用户故事分成几次sprint来做,就是不断地迭代。每次迭代的周期很短,一般是一周或者是两周,还有迭代出来的一定是一个可以使用的产品,可能功能有点缺陷,但一定是可以正常使用的产品。

计划分析会,就是根据原型还有用户故事分task。这个会议一般由SM来主持,当然这里的SM不是你想的那个SM。因为之前已经开过需求澄清会了,开发人员也知道了需要开发什么样的产品,这时候就可以根据每个用户故事对着原型分任务了。需要注意的是,这里的每个任务都是开发人员自己分给自己的,比如后端开发看到这个页面,需要写几个接口,每个接口大概需要多少小时,需要前端人员如何配合,这都是需要在这个会议搞清楚。所以为了后续的正常开发,这个会议一般都会比较长,大概需要4-5个小时左右。

站立会,这个是每天都需要开的会议,每个项目成员都说一下自己昨天做了什么工作,今天做了什么工作。这个会议的话主要是前端开发和后端开发之前的互相配合,就是为了避免前端已经撸好了一个界面但是没有接口对的尴尬情况。

评审会,主要是本次迭代的功能评审,对照用户故事,我们是不是已经完成了这几个用户故事所说的内容。

回顾会,这次迭代我们团队有什么优点、有什么缺点、可以怎样改进,产出对应的改进措施。

敏捷宣言:个体和互动高于流程和工具;工作的软件高于详尽的文档;客户合作高于合同谈判;响应变化高于遵循计划。

二、第一次迭代遇到的问题及改进方案

1、Task漏项

在第一次使用该模式开发的时候,遇到的最大问题就是task漏项。这说明了我们在开计划会的时候并没有把task分好,缺乏沟通可能是导致这个问题的主要原因。
解决问题的方案就是我们的前端和后端在领取task的时候需要考虑任务的优先级,先做哪个后做哪个,多沟通。如果说有某个task工作量大于8小时的话,我们建议将这个task再细分,尽量做到每个task的工作量都在一天之内,这样把task分得更细的方法也是可以避免task漏项的。毕竟在开发的时候发现漏task了,那只能是通过加班来解决了。

2、接口文档未及时更新

这个锅直接甩给了后端开发小哥。当然解决方案就是接口文档及时更新和署名。

3、用户故事漏项,原型不够细致

当然,迭代出问题,PO也是要背锅的。在没有详细的PRD文档的情况下,原型成为了开发人员的主要参考对象。如果用户故事漏项并且原型画得不清不楚的话,导致的问题就是开发人员无法开发。即使我们使用的是敏捷开发模式,核心就是沟通,但是这也会大大大大增加了沟通成本。

所以,对用户故事的把控、对原型设计的理解还有对业务流程的思考应该算是对刚使用敏捷模式的产品经理最大的挑战。

4、测试不规范

在没有测试人员的情况下,产品经理就是项目中最好的测试。其实这样子说并不是最准确的,产品经理应该把控住测试的最后一道关卡,而不是在开发人员开发完一个模块还未自测的情况下就把这个模块丢给你测。这样不仅增加了产品经理的工作量,还可能会导致项目延期。

所以说敏捷模式其实非常考验每个人在整个团队中的能力的。

5、在sprint之前未确认好资源

像我们初创的小团队,我们不仅没有测试,也没有UI。如果我们需要UI的话就需要向外部申请资源,要是我们在迭代之前未考虑到这点,那我们的页面做出来有可能真的会不忍直视。

三、总结

作为一个刚出生不久的产品经理,我对于敏捷的理解还是在持续的工作中不断加深的,从最开始Mike Cohn的《用户故事与敏捷方法》一书中了解到的理论内容,再到实际开发中的一点点实践,敏捷的思想也在慢慢成长。

2019-12-12 22:43:41 weixin_43258908 阅读数 4
  • SCRUM敏捷开发视频教程

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

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

《敏捷开发》测验解析

1.哪个场景对应敏捷开发(B C)
A.计划、需求分析、设计、编码、测试、维护,六个基本活动相互衔接
B.小型发布版本,快速反馈,逐步反馈
C.产品经理和项目团队紧密合作,定义目标、梳理产品清单,确立优先级后,制定迭代清单
解析:
A 选项,属于瀑布开发模型

2.以下不属于 XP 的价值观内容的是(C)
A.有效沟通
B.相互尊重
C.持续集成
D.反馈和勇气
解析:
XP 的 5 个价值观:沟通、反馈、简单、勇气、尊重

3.下列做法符合 scrum 的是(D)
A.产品经理与开发人员进行有效沟通,变更产品需求
B.制定计划和产品路线图,并严格按照计划去执行
C.产品经理按照谈判的合同进行产品设计,以合同的标准推动项目的进行
D.欢迎需求变化,尽早、持续地交付有价值的软件
解析:
A 选项, scrum, 应该是项目经理与开发人员进行有效沟通
B 选项, 严格按照计划执行是错误的,应根据实际进行过程中适当调整, 使产品产生最大价值
C 选项, 客户合作高于合同谈判, Scrum 旨在促进协作。团队成员互相协作,以找到构建和交付软件(或其他可交付成果)的最佳方法。一个团队,尤其是产品负责人,与利益相关方合作,检查和调整产品的视觉,使产品尽可能的有价值。

4.产品经理和项目经理的职能说法正确的是(B.D)
A.产品经理需要掌握技术知识,来面向开发提出需求变更及改进
B.项目经理要拆解产品经理的需求,转化成一个个 task,然后安排给不同的工程师
C.项目经理需要和市场部、运营部等合作,采访用户后,根据调研情况转化成需求文档D.产品经理负责做正确的事,项目经理负责正确地做事
解析:
A 选项,项目经理需要掌握技术知识,面向开发提出需求变更及改进
C 选项,产品经理需要和市场部、运营部等合作,出需求文档

敏捷产品需求

阅读数 7

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