从0到1做产品—— 项目敏捷开发管理

2018-08-09 14:44:00
UShowJack
转贴:
简书
315

敏捷开发概念

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。一般分为Scrum和XP。Scrum 团队最佳人数控制在5~9人,一个迭代为四周时间,比较适合目前情况,所以暂定为Scrum模式。

开发框架主要是为了更少的投入更多的产出

人员配置

Scrum Master——项目负责人、项目经理

保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化。

Team——开发人员、测试人员、美工设计、DBA等全职能性团队

团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

Product Owner——产品经理、运营人员

从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。

User——最终用户、运营人员、系统使用人员

很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。


项目周期

一般一个 Sprint 为4周左右时间。


项目产物

User Story、Task(需求模块)——用户故事、任务

用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。

Sprint Backlog(迭代)——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。

在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

Product Backlog(需求池)——Backlog 待开发项,积压的任务。

产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

障碍 Backlog(缺陷)——问题列表,积压的待处理事务。

列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。


会议

会议类型

  • Sprint 需求规划会议

  • 项目立项需求同步会

  • Sprint 功能规划会议

  • 估算会议——根据项目情况合并到 Sprint功能规划会议

  • 每日立会


  • Sprint 评审会议(Review Meeting)——根据项目需要举行

  • 项目复盘会议


会议注意事项

  • 明确会议目的

  • 会议需要提前通知到所有人

  • 根据不同的会议需要准备不同的材料

  • 限制会议时间

  • 规定会议后输出产物

  • 限制会议主题,防止讨论会议外

  • 所有人都有权限参加

  • 责权明确,确定决定方


使用工具或者图标

  • Excel 需求池

  • 任务看板


  • 燃尽图


  • 计划扑克牌


流程规范

原则

User Story划分原则(INVEST规则):

Story概念:

User Story是敏捷开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。

User Story是从用户的角度对系统的某个功能模块所作的简短描述

一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值

ser Story是敏捷开发和管理的核心,要确保Story的输出质量。


  • 独立性(Independent):一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。

  • 可谈判性(Negotiable):Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。

  • 有价值性(Valuable): Story需要体现出对于用户的价值。

  • 可估计性(Estimable):Story应可以估计出Task的开发时间。

  • 大小合适(Sized Right):关于Story的粒度,建议的开发工作量是3-5天(包含针对Story所做的开发者自测工作量),如果Story不能拆分到3-5天的开发粒度,则一定要确保该Story在一个迭代周期内可开发测试完成。

  • 可测试性(Testable):要从可测试性考虑需求,同时要考虑能够独立测试,每个任务都应有Junit Test。另外注意,伴随Story要同时输出可接受性测试用例(Acceptance Test Case,以下简称AT),用于验证Story是否开发完成,可以给测试人员做Story测试。AT用例在Story协作阶段只是对测试要点、场景的描述,在迭代开发阶段可以继续补充和完善。


名词解释

  1. 迭代(Sprint):把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

  2. Scrum:一种敏捷的框架与强调软件开发管理工作。它是专为团队的3到9个开发人员工作分解成可在时间框迭代完成的行动,被称为sprint(30天或更少,通常两个星期)和跟踪进展和重新计划在15分钟的站立会议、每日scrum。1的方法来协调多个scrum团队的工作在较大的组织包括大规模scrum(少),(安全)和Scrum@Scale敏捷扩展框架,等等。

  3. Product Backlog:按优先顺序排列的一个产品需求列表

  4. User Story:从用户的角度对系统的某个功能模块所作的简短描述




文章分类
联系我们
联系人: 郑女士
Email: zhengqiaoyin@cnezsoft.com
QQ: 2987868987