敏捷开发交付的文档_敏捷 与交付文档 - CSDN
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...

    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。
    一.什么是敏捷开发
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
    换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。相对于瀑布开发模式,敏捷开发更加灵活可操作。
    二.敏捷开发方式及流程
    敏捷开发有很多种方式,如scrum,XP,LSD,FDD等,其中scrum是非常流行的一种。
    scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
    scrum的基本流程如图所示:

    po(product owner指产品负责人)负责整理user story,形成左侧的product backlog(按优先顺序排列的一个产品需求列表)。
    发布计划会议:po负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,叫做sprint backlog。
    迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,最终每个任务都有明确的负责人,并完成工时的初估计。
    每日例会:每天sm(scrum master指项目负责人)召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
    演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
    回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
    敏捷流程中的三个关键要素是:product backlog(产品需求)
    sprint backlog(本期迭代任务)
    burn-down chart(燃尽图,进度的体现)
    呈现了任务下达-拆分-推进的整个过程。

    三.“轻文档,重沟通”的敏捷
    我们知道,瀑布开发是以文档为驱动,文档是一切工作的核心,po需要写非常多而复杂的文档,例如:需求文档、设计文档、API文档、验收文档等等。
    敏捷宣言说,“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法,而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见,敏捷开发是更实际,更注重操作性的开发方式。
    但这并不意味着敏捷开发完全抛弃文档,敏捷开发遵循“轻文档,重沟通”的原则。
    “轻文档”体现在,敏捷开发只关注文档中的重要点,尽可能的简化文档,或者用软件工具呈现另一种形式的文档。
    以传统文档来说,一个PRD(产品需求文档)中包含对多个成员的诉求,比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐,而且在实际工作中,很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的,但是要看过才知道是否与自己有关,这在无形中就造成了时间的浪费。
    敏捷管理中采用了用户故事的方式进行product backlog的呈现,“用户故事(称作user story)”是采用用户熟悉的术语来表达需求的一种方法,是用户讲给开发人员的故事(实际由po搜集用户需求并整理成用户故事)。
    例如“作为禅道用户,我希望能实现自动登陆功能,这样能更方便的登陆系统。“这就是一个具体的需求描述。
    在这个需求描述中,涉及到三个要素“用户角色(禅道用户)”、“达成的目的(自动登陆功能)”、“开发价值(更方便的登陆系统)”
    当然除了这三个要素,还需要涉及到验收标准、优先级、评审人等。

    借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分,导入到项目管理软件中,相关人员只需要按照需求目录一条条执行即可,不再需要一页一页的看PRD了。后端只需要与提供接口相关的,前端主要看与功能相关的部分,而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢?沟通!
    “重沟通”体现在以结果为导向,以人为核心。通过面对面沟通的方式快速反应,推动进度。
    你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

    任务看板一般包含未完成、正在做、已完成的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度可能出现了什么问题。

    如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式,禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面,成员完成某项任务后即可从进行中拖拽到已完成列,跟实体看板的作用如出一辙。

    比起传统开发模式,敏捷更加强调去流程化,文档不再必须,变得可以简化和被取代。因为在敏捷开发中,最简单的解决方案就是最好的解决方案,最高效的工作方式就是最好的工作方式。

    相关观点及图片来源:
    敏捷开发-百度百科
    禅道-开源项目管理软件
    谈谈我理解的敏捷开发-许大虾

     

    展开全文
  • 敏捷开发流程

    2020-07-08 23:30:45
    敏捷开发流程,经验分享,敏捷开发流程,经验分享,敏捷开发流程,经验分享,
  • 敏捷开发需要哪些文档? 需求说明 对功能、交互方式、出错或边界情况的表现进行总体描述 1.画面图 2.数据图 3.需求说明 来源张永光的博客

    敏捷开发需要哪些文档?

    需求说明
    
        对功能、交互方式、出错或边界情况的表现进行总体描述
    
    1.画面图
    
    2.数据图
    
    3.需求说明
    

    来源张永光的博客

    展开全文
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为...

    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。

    一.什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。

    换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。相对于瀑布开发模式,敏捷开发更加灵活可操作。

    二.敏捷开发方式及流程

    敏捷开发有很多种方式,如scrum,XP,LSD,FDD等,其中scrum是非常流行的一种。

    scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

    scrum的基本流程如图所示:

    f_0fd8695b8a9e7e60fe3fef3603c1d733&t=png

    • po(product owner指产品负责人)负责整理user story,形成左侧的product backlog(按优先顺序排列的一个产品需求列表)。
    • 发布计划会议:po负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,叫做sprint backlog。
    • 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,最终每个任务都有明确的负责人,并完成工时的初估计。
    • 每日例会:每天sm(scrum master指项目负责人)召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
    • 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
    • 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
    敏捷流程中的三个关键要素是:

    product backlog(产品需求)

    sprint backlog(本期迭代任务)

    burn-down chart(燃尽图,进度的体现)

    呈现了任务下达-拆分-推进的整个过程。

    三.“轻文档,重沟通”的敏捷

    我们知道,瀑布开发是以文档为驱动,文档是一切工作的核心,po需要写非常多而复杂的文档,例如:需求文档、设计文档、API文档、验收文档等等。

    敏捷宣言说,“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法,而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见,敏捷开发是更实际,更注重操作性的开发方式。

    但这并不意味着敏捷开发完全抛弃文档,敏捷开发遵循“轻文档,重沟通”的原则。

    “轻文档”体现在,敏捷开发只关注文档中的重要点,尽可能的简化文档,或者用软件工具呈现另一种形式的文档。

    以传统文档来说,一个PRD(产品需求文档)中包含对多个成员的诉求,比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐,而且在实际工作中,很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的,但是要看过才知道是否与自己有关,这在无形中就造成了时间的浪费。

    敏捷管理中采用了用户故事的方式进行product backlog的呈现,“用户故事(称作user story)”是采用用户熟悉的术语来表达需求的一种方法,是用户讲给开发人员的故事(实际由po搜集用户需求并整理成用户故事)。

    例如“作为禅道 用户,我希望能实现自动登陆功能,这样能更方便的登陆系统。“这就是一个具体的需求描述。

    在这个需求描述中,涉及到三个要素“用户角色(禅道用户)”、“达成的目的(自动登陆功能)”、“开发价值(更方便的登陆系统)”

    当然除了这三个要素,还需要涉及到验收标准、优先级、评审人等。

    借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分,导入到项目管理软件中,相关人员只需要按照需求目录一条条执行即可,不再需要一页一页的看PRD了。后端只需要与提供接口相关的,前端主要看与功能相关的部分,而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢?沟通!

    “重沟通”体现在以结果为导向,以人为核心。通过面对面沟通的方式快速反应,推动进度。

    你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

    任务看板一般包含未完成、正在做、已完成的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度可能出现了什么问题。

    f_cb103833a116aca8e24b8a2daa6947ae&t=png

    如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式,禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面,成员完成某项任务后即可从进行中拖拽到已完成列,跟实体看板的作用如出一辙。

    比起传统开发模式,敏捷更加强调去流程化,文档不再必须,变得可以简化和被取代。因为在敏捷开发中,最简单的解决方案就是最好的解决方案,最高效的工作方式就是最好的工作方式。


    相关观点及图片来源:

    敏捷开发-百度百科

    禅道-开源项目管理软件

    谈谈我理解的敏捷开发-许大虾

    1Q8Zf40c5UhKFO.gif
    展开全文
  • 敏捷开发之设计文档

    2019-07-22 03:57:16
    对于设计文档的一点体会就是,明确需求、精简语言、图文并绘、代码相辅、易于沟通。 ... 在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。...敏捷开发宣言 ...

    对于设计文档的一点体会就是,明确需求、精简语言、图文并绘、代码相辅、易于沟通。

    下文援引:http://blog.csdn.net/zzhdi/article/details/50929828

    在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。团队成员要花费很多精力去维护众多的文档,甚至有“兄弟,我替你写代码,你替我写文档”的无奈。

    敏捷开发宣言
    * 个体和互动 胜于 流程和工具
    * 可以工作的软件 胜于 详尽的文档
    * 客户合作 胜于 合同谈判
    * 响应变化 胜于 遵循计划

    敏捷宣言的第二条“可工作的软件胜于详尽的文档”,很多人理解为敏捷开发不重视文档,甚至以此为借口逃避写文档。同样,在对待”敏捷开发是否需要架构设计”的问题上也有类似极端的看法。

    敏捷宣言在写什么样的文档以及如何写方面并没有给出任何刚性的指导原则,那么在敏捷管理的项目中我们该如何编写文档呢?

    首先,我们需要理解敏捷宣言背后的思想。
    敏捷4条宣言都是在强调“价值”、“快速交付价值”、“为客户提供价值”的理念。换句话说,研发团队要把精力放在能够为客户带来价值的地方,避免在不产生价值或者ROI(投入回报率)低的任务上浪费时间。

    其次,我们要理解文档的作用是什么?文档是用来准确传递信息,帮助理解事物,沉淀知识。

    基于以上理解,在遇到是否要写文档的疑问时,可以通过回答两个问题来判断

    • 是否有比写文档更高效传递信息的方式?
    • 简陋的文档是否满足需要?

    从文档的读者来划分

    • 读者是项目组外人员
      这类文档往往是需要编写的而且不能“简写”的。例如:用户手册、验收文档、API文档等。

    • 读者是项目组内人员
      这类文档能省则省,能简则简。如果能够在每天站会上沟通的,就可以不写。建议高层的系统架构图、内部API文档可以简写。
      如果项目Leader通过类似EasyPM这样管理工具能够查询到的信息,可以在周报中简写甚至省略。


    对于可以“简写”的文档,可以考虑使用Markdown格式。

    Markdown是一种简单易用的标记语言,用户可以使用这些标记符号以最小的输入代价生成极富表现力的文档。

    EasyPM 的文档编辑器使用Markdown语法,并且实时保存/预览、支持代码高亮、文档评论以及全文搜索。在版本管理上,支持手动和自动进行版本管理。文档评论也支持@功能,可以高效地对文档进行评审。

    转载于:https://www.cnblogs.com/Jashinck/p/7084129.html

    展开全文
  • 公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293 MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...
  • 公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...
  • 敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记 版权声明:原创内容,如需转载请联系作者。 https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发和DevOps都是一种理念。他们的理念相似,...
  • 在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码...
  • 2.3 规范敏捷开发原则 为了帮助人们更好地理解敏捷软件开发的真正含义,敏捷开发联盟的成员们将他们宣言中的主要观点精炼为12条原则。我们改动了其中一些(改动之处用楷体显示),并且新加入了三条。这15条规范敏捷...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 软件交付项目管理的特殊性在于其管理对象是软件交付,虽然其基本管理思想和管理方法都跳不出通用项目管理范畴,但其面临的全球化、复杂性和治理等方面的独特问题,迫使相关人员不断地去思考和创新软件交付方法和...
  • 作者:陈勇 出处:blog.csdn.net/cheny_com 自相似性是指一个事物的局部与其更大的局部...从大的方面看,敏捷开发具有重视客户价值,提倡持续交付等思想。但一般而言,Product Owner常常具备相当好的客户价值意识,而
  • 敏捷开发和DevOps都是一种理念。他们的理念相似,都是为了更好更快的发布产品,但又不完全相同。 而CI/CD是实现这两者理念的一种方法。 敏捷开发 前言 传统方式开发前有一份详细的开发文档,程序员照着需求直接敲...
  • 公司项目需要利用敏捷开发模式进行开发,故在CSDN上进行相关资料的查找搜集。27个资料,293MB,花费了150多积分.现将所有查到的文档进行分包压缩,贡献给大家。因为实在花的积分过多,请原谅我不是无偿的。每个...
1 2 3 4 5 ... 20
收藏数 14,842
精华内容 5,936
关键字:

敏捷开发交付的文档