敏捷流程思考

一、前期准备阶段

有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展.

二、方案评审

这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时

三. 项目启动会议

我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

时间: 2024-08-03 19:12:18

敏捷流程思考的相关文章

每日站立会议——敏捷流程scrum实践

每日站立会议是敏捷流程scrum中的很重要的一个制度之一. 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展. 2.给每个人一种精神压力,信守承诺.这是一种面对面的精神压力,直面项目进展. 3.培养团队的文化,让每个人意识到:我不是一个人在战斗,我们是一个团队. 站立会议的目的: 1.让所有人了解其他人在做什么,当前项目计划进展如何 2.帮助大家解决那些阻碍做事情的问题,以及共享承诺这些都非常有利于提高团队合作精神的. 注意要点: 1.主题明确,不能掺杂其

敏捷主义,关于敏捷的思考和启发

这片文章是我这些日子以来通过读书获得的一些关于敏捷开发的思想,以及这些思想对我的启发. 这篇文章不会讨论具体的敏捷方法,而是讨论一下敏捷和早期开发方式在原则和逻辑上的区别.这些区别也是我们在实践敏捷中最容易忽视的,我们很容易就能记住每一个敏捷方法的特点,但是对于敏捷开发别后的原则和哲学,却甚少深思. 在传统的瀑布式开发方式中,前期的分析和设计是最重要的,项目中的代码不过是按照这个设计严格制造出来的产品,而项目中的程序员也只是按照已经做好的设计进行生产的代码工人而已.传统的瀑布式开发方式是把软件也

敏捷流程

流程简介 第一步:找出完成产品需要做的事情--Product Backlog 第二步:决定当前的冲刺需要解决的事情--Sprint Backlog 第三步:冲刺 第四步:得到软件的一个增量版本,发布给用户 敏捷流程的问题和解法 第一步:在计划中体现依赖关系 第二步:技术能力和交流能力 第三步:定义好任务 第四步:得到一个增量的软件发布 敏捷的团队: 自主管理 自我组织 多功能型 敏捷流程的经验教训: 敏捷宣言表明的是一些优先级 Scrum Master不是一个官,而是一个没有执行权力的沟通者 一

敏捷流程的理解

1.敏捷流程的含义 "敏捷流程"是一系列价值观和方法论的集合. 敏捷的方法论比较有名的有:爱抚弟弟(FDD-Feature Driven Design).史克朗姆(SCRUM).极限编程(XP) 敏捷开发的原则是:(1)尽早并持续地交付有价值的软件以满足顾客的需求: (2)敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势: (3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短: (4)业务人员和开发人员在项目开发过程中应该每天共同工作: (5)以有进取心的人为项目核

《构建之法》学习(6)——敏捷流程

<构建之法>学习(6)--敏捷流程 1.敏捷的流程        "敏捷流程"是一系列价值观和方法的集合.   1.1敏捷开发原则   尽早并持续地交付有价值的软件以满足顾客需求 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 业务人员和开发人员在项目开发过程中应该每天共同工作 以有进取心的人为项目核心,充分支持信任他们 无论团队内外,面对面的交流始终是最有效的沟通方式 可用的软件是衡量项目进展的主要指标

构建之法---初识篇(团队、流程和敏捷流程)

这周主要是看了第五章和第六章,主要内容包括团队和流程以及敏捷流程. 首先来说什么是团队?团队有一个集体的目标,团队要一起完成这个目标,一个团队的人,不一定要同时工作,团队成员有各自的分工,互相依赖合作,共同完成任务.此外,团队的模式也是多种多样的,我觉得不管什么样的流程,只要有一个合理的机制,有一个合理的规则就是可以的,我觉得还是要有一个人去领导整个团队,其实对于现在的我来说,我更喜欢主治医师模式.但是必须保证大家不是打酱油的,要每个人都有贡献. 关于开发流程,瀑布模型是单项的,不可逆的生产过程

构建之法学习(第六章 敏捷流程)

第6章  敏捷流程 本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法. 1.敏捷的流程 定义:"敏捷流程"是一系列价值观和方法论的集合. 现有的做法 敏捷的做法 流程和工具 个人和交流 完备的文档 可用的软件 为合同谈判 与客户合作 执行原定计划 响应变化 2.敏捷开发原则 尽早并持续地交付有价值的软件以满足顾客需求 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 经常发

敏捷流程的学习

本周我学习的是敏捷流程的内容 敏捷,显而易见,是高效率用尽可能少的时间完成任务.敏捷流程是一系列价值观和方法论的集合.敏捷开发原则有挺多的,主要体现在高效率,简明,可持续发展等方向上.敏捷的步骤有四步: 1.找出完成产品需要做的事情--Product Backlog 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog 3.冲刺(Sprint) 4.得到软件的一个增量版本,发布用户. 总的来说,工作量最大的步骤在第三个步骤上,在这个步骤上,要进行每日构建,每个人要反馈

第六章 敏捷流程

6.1 敏捷的流程 现有的做法 敏捷的做法 流程和工具 个人和交流 完备的文档 可用的软件 为合同谈判 与系统合作 执行原定计划 相应变化 敏捷开发的原则:1.尽早并持续地交付有价值的软件以满足顾客需求.     2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势. 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短. 4.业务人员和开发人员在项目开发过程中应该每天共同工作. 5.以有进取心的人为项目核心,充分支持信任他们. 6.无论团队内外,面对面的交流始终是最有效的沟通