![](https://img-blog.csdnimg.cn/20201014180756926.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
项目管理
mykktian
这个作者很懒,什么都没留下…
展开
-
对敏捷的误解
1,敏捷开发意味着可以不需要文档,设计和计划2,敏捷只是一些优秀实践,或者是优秀实践的结合3,敏捷只适用于小项目4,敏捷只会对研发产生改变5,引入敏捷只需要按照既定的步骤去做就可以了6,敏捷是CMMI的替代品,是另一种流程7,敏捷只注重特性的快速交付,在敏捷下框架不重要了...原创 2011-02-25 15:24:39 · 243 阅读 · 0 评论 -
敏捷项目操作手册(29)
4 其它敏捷实践介绍4.1 一体化团队PO、开发、测试、资料要融合,但也要职责分明。另外,每位成员不仅要了解自己的职责是什么,同时也要清楚其它团队成员的职责,只有这样大家才能有效地协同作战。4.2 状态墙状态墙的字段推荐(非强制,项目组可自行选择):初始化/分析、等待开发、开发中、开发完成、SDV测试、缺陷修改、资料Review、完成。...原创 2010-09-30 13:11:20 · 150 阅读 · 0 评论 -
敏捷项目操作手册(28)
3 SIT(发布测试)迭代结束后,在正式对外发布前,建议将历次迭代实现的所有Story再做一次测试,测试的主体在测试人员,包括FT、NFT,并要给出测试报告。这个活动就称为SIT或发布测试。如果Story 测试、迭代SDV测试都自动化了,则本次测试主要是执行自动化用例、如前面有测试不充分,则补充测试,以及详细性能测试。如果用例自动化程度不高,则本次测试会刷选部分用来进行测试。最后,项目PL...原创 2010-09-30 13:10:07 · 226 阅读 · 0 评论 -
敏捷项目操作手册(27)
2.8 迭代的收尾工作迭代评估及回顾会议。对本次迭代做一个评估和总结,及时吸取经验教训,同时增强团队信心和提高团队效率。迭代评估模板请参见《迭代评估报告模板.doc》。迭代回顾会议,通常是在迭代结束时侯,召集项目团队成员,每人发不同颜色的几种便签纸(比如红、黄、绿),分别独立写下本次迭代做得好的,存在的问题,改进的建议,然后归类汇总每个人的意见,通过全体成员投票选择最需要下个迭代改进的几个...原创 2010-09-30 13:09:27 · 140 阅读 · 0 评论 -
敏捷项目操作手册(26)
2.7 迭代ShowCase综合公司实践,目前有三种类型的ShowCase:(1)开发人员在开发过程中随时将完成的功能演示给PO、团队成员看,形式不限,可能只花15分钟,目的有两个,一方面可以听取大家的意见,另一方面让团队所有成员了解项目的进展;(2)在迭代的SDV阶段PO或测试人员将当前迭代内实现的功能向客户代表做一个全面演示,充分听取客户的反馈,对于客户反馈的问题可以选择在当前迭代...原创 2010-09-30 13:08:59 · 206 阅读 · 0 评论 -
敏捷项目操作手册(25)
2.6 迭代SDV测试迭代SDV是针对当前迭代内所有Story的完整测试(也会有针对前次迭代的回归),包括FT、NFT。SDV测试的主体是测试人员,项目也可能根据实际情况调整人员一起完成本迭代的SDV测试。SDV测试在Story测试(ST)的基础上,增加针对Story之间的依赖相关的用例和测试代码,当然测试的前提条件也是所有Story的AT和ST要能全部测试通过。对实现了测试自动化的项目这个阶...原创 2010-09-30 13:08:31 · 127 阅读 · 0 评论 -
敏捷项目操作手册(24)
2.5 确保迭代周期内的需求稳定每次迭代开发过程中,PO的主要任务之一是为下一次迭代开发准备好Story。Story可能会随时更新,以反映客户需求的变化,但是,当前迭代正在开发的Story一般不允许变更。敏捷重要实践之一是:当开发团队确认承诺任务后,PO在此迭代期间不可以添加新的需求。这就意味着在某次迭代的中途,PO不能添加新要求到本迭代中,只能调整后续迭代所要开发的需求。如果一个外部情况出现...原创 2010-09-30 13:08:01 · 125 阅读 · 0 评论 -
敏捷项目操作手册(23)
2.4 针对单个Story的测试ST,全称Story Test。ST测试的主体在测试人员,是针对某个特定Story所进行的测试,包括FT、NFT。测试的前提条件是这个Story的AT要能全部测试通过,否则测试人员可以拒绝接受测试。对实现了测试自动化的项目,这个阶段的工作量可能不会太多,但如果无法自动化,那只有手工进行测试。◤提示:Story测试重点◢ 1、Story测试重点关注非性能测...原创 2010-09-30 13:07:16 · 121 阅读 · 0 评论 -
敏捷项目操作手册(22)
2.3 Story签收每个Story开发完成后,转入Story测试前,需要进行Story签收,这是转Story测试的条件,Story签收的标准是AT是否通过,形式不限。建议开发认为可以转Story签收,则有测试单独执行该Story的AT用例,所有AT用例通过,则完成签收,进入Story测试阶段,否则打回给开发继续开发。为规范化签收,通过邮件的方式进行,相关验收用例通过后,SWE发邮件给TE...原创 2010-09-30 13:06:18 · 123 阅读 · 0 评论 -
敏捷项目操作手册(30)
4.3 每日站立会议(晨会)这是在每个工作日特定的时间举行的短小(15分钟)的会议,开发团队的每一成员都将参与,通常可以选择在早上或者下午下班前进行。为了保证其短小精悍,与会成员都保持站立(所以叫“站立会议”)。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。一个接一个,每个团队成员回答三个问题式的报告进展:从上次会议之后完成了哪些工作,在下次会议之前准备完成哪些工作,在工作进行...原创 2010-09-30 13:11:50 · 162 阅读 · 0 评论 -
敏捷项目操作手册(31)
晨会讲解模版供参考:―――――――――――――――――――――――――――――――――――――Story名称( Story责任人)开发的进展情况:在 [设计 | 编码 | 联调] 阶段,完成该阶段XX%,预计XX时候完成该阶段。与计划差异, 关键路径在哪里?测试的进展情况:在[用例设计 | 用例编写| 用例执行] 阶段,完成该阶段XX%,预计XX时候完成该阶段。与计划差...原创 2010-09-30 13:12:31 · 92 阅读 · 0 评论 -
软件外包KPI全景图
软件外包KPI全景图原创 2011-02-24 09:50:34 · 425 阅读 · 0 评论 -
敏捷项目操作手册(38)
PO Product Owner 产品所有者CI-CO CI Coordinator 持续集成协调员UT Unit Test 单元测试,开发人员做的FT Function Test 功能测试,测试人员做的NFT Non Function Test 非功能测试,测试人员做的TDD Test Driven Development 测试驱动开发ATDD Application T...原创 2010-09-30 13:17:45 · 123 阅读 · 0 评论 -
敏捷项目操作手册(37)
开发成员 1.评审Story 2.Story估计和对Story开发做出承诺3.负责主持头脑风暴会议,包括接口、设计方案、测试方案以及用例的评审4、Story实现的简单设计和开发5、Story的实现(代码review、开发者测试)6、组织Story演示会议7、参与项目相关会议和相关review测试成员 1.评审Story ,参与制订STORY的ATC2...原创 2010-09-30 13:17:03 · 113 阅读 · 0 评论 -
敏捷项目操作手册(36)
项目PL(含Scrum Master职责) 1.辅导团队用正确的敏捷方法做事(计划会议、每日站会、回顾会议等等)2.为团队引入实践和建立规则,输出PPL(项目计划、沟通计划等等)3.保护团队不受打扰4.推动解决团队遇到的障碍5.对团队的交付质量、过程质量、活动/实践质量负责6.项目可视化管理和度量数据的收集,7、迭代的BACKLOG任务分配跟踪、项目管理工具比如JI...原创 2010-09-30 13:15:46 · 162 阅读 · 0 评论 -
敏捷项目操作手册(35)
4.7 简单设计简单设计并不代表就不做设计,也不是代表只做粗粒度设计、或简化设计,而是指只针对当前需求做设计,不做冗余设计或过渡设计。设计的方式和输出形式可以不限,但一定要思考设计。 ◤提示:◢ 所有模块,在Story时间阶段,默认需要有简单设计,如要省去简单设计,则需要和MDE确认;建议是否输出简单设计,在头脑风暴会议上确认。...原创 2010-09-30 13:14:41 · 78 阅读 · 0 评论 -
敏捷项目操作手册(34)
4.6 统一文件夹结构(Unified Folder Structure)项目组成员应将本地文件夹结构与配置库保持一致,本地构建的脚本要在项目组内统一。另外,IDE环境也要保持统一,包括各类常用的工具和插件,版本号也要一致。...原创 2010-09-30 13:14:11 · 81 阅读 · 0 评论 -
敏捷项目操作手册(33)
4.5 结对编程结对编程指的是两位程序员在一台电脑前工作,一个负责敲入代码,而另外一个实时检视每一行敲入的代码。结对编程有助于提升代码设计质量、大幅促进团队能力提升和知识传播。负责操作键盘和鼠标的程序员被称为“驾驶员”,负责实时评审和协助的程序员被称为“领航员”,领航员检视的同时还必须负责考虑下一步的工作方向 ,比如可能出现的问题以及改进等。结对编程小帖士:(1)程序员应经常性地在...原创 2010-09-30 13:13:31 · 236 阅读 · 0 评论 -
敏捷项目操作手册(32)
4.4 回顾会议字面的意思就是“回看过去,分析问题、明确措施、进行改进”。回顾会议是全体团队成员聚集在一起分析过去的表现、明确改进措施并达成集体改进协定的交流平台,客户、产品、团队和组织都将从中获益。在回顾会议上,每个人都可以贡献和讨论想法,会上大家的建议会更容易被接受。 如果没有回顾,团队就会不断重犯同样的错误。建议的回顾会议过程如下:1. 每个人发几张小卡片,总结本轮迭代哪些地方做得好...原创 2010-09-30 13:13:04 · 109 阅读 · 0 评论 -
敏捷项目操作手册(21)
2.2.5 Story 演示在开发人员完成Story后,转测试签收前,由开发责任人组织开发人员、测试、资料、PO、UCD等人员进行Story演示,特别是有界面的Story,演示一些基本功能,并收集相关人的意见,相关人对界面以及相关功能的操作达成一致,如有问题,则要把相关问题修改后才能进行Story签收。◤提示:小建议◢1、该演示可以分多次进行,每次Story演示时间建议不超过30分钟...原创 2010-09-30 13:05:51 · 112 阅读 · 0 评论 -
敏捷项目操作手册(20)
2.2.4 资料开发(资料人员)资料开发可能会分成两类:一类是针对单个Story的资料写作,它需要伴随Story开发同步提交,如果可能也要加入到持续集成环境中;另一类是无法随Story同步提交的端到端资料开发,此类任务需要在迭代前准备阶段明确并体现在E2E迭代计划中。输出的资料必须得到PO、开发、测试以及资料人员的Review。...原创 2010-09-30 13:05:21 · 87 阅读 · 0 评论 -
敏捷项目操作手册(19)
2.2.3 测试用例设计和测试脚步开发(测试人员)测试的主要任务是设计FT和NFT测试用例,同时要开发自动化测试代码或测试脚本,代码和脚本要得到Review,并应该要调测通过能够运行,最后才能check in到配置库加入到持续集成环境中。用例设计前可能需要考虑必要的测试策略和测试方案。(关于FT、NFT,也许你的项目现在还无法实现测试自动化,此时的主要任务还是在设计和完善测试用例上。但...原创 2010-09-30 13:04:54 · 145 阅读 · 0 评论 -
敏捷项目操作手册(8)
◤提示:项目PL绩效管理◢ 1、 项目PL要对团队成员的工作情况实时进行记录,每月把成员的工作情况反馈给LM,让LM了解成员的情况,同时可作为成员绩效评价的参考。2、 对于不能在项目中全部投入的成员,每周要进行一下人力投入情况的审视;...原创 2010-09-30 12:58:22 · 120 阅读 · 0 评论 -
敏捷项目操作手册(7)
1.5 一体化团队组建一体化团队成员包含:Product Owner(以下简称PO)、敏捷教练、项目PL、开发人员、测试人员、资料人员、CI Coordinator(以下简称CI-CO)。PO:负责收集相关于产品的所有信息,从客户或产品的最终用户、开发团队成员、以及其他利益相关人中获取,并将这些信息转化为User Story,并进行优先级排序。PO建议由SE担任,或由TL、项目骨干等担任,...原创 2010-09-30 12:57:45 · 219 阅读 · 0 评论 -
敏捷项目操作手册(6)
1.4 输出项目SOWPM和LM沟通项目人力情况,确定项目PL,确定项目的范围和进度要求。根据每个Story的优先级和工作量、商业价值进行排序得到优先级,最高价值的Story优先级排在前面,另外还可以考虑这几种因素:客户紧急程度、需求稳定性、依赖程度、对系统架构的影响、风险等,一般来说,客户急迫的、相对稳定的、依赖性强、影响系统架构的需求应该优先做。 PM把项目SOW和产品特性列表(...原创 2010-09-30 12:57:01 · 117 阅读 · 0 评论 -
敏捷项目操作手册(5)
1.3 概念和架构设计敏捷开发中,注重概念和架构设计,而轻详细设计。这里的概念设计,可以看成是为什么要做这个产品或模块,强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计,则是具体的设计和做法、API接口等。一个产品,特别是面向行业的产品,概念设计和架构设计非常重要,...原创 2010-09-30 12:56:22 · 123 阅读 · 0 评论 -
敏捷项目操作手册(4)
1.2 Story评审评审的形式不限,建议由非PO人员讲解,PO确保开发、测试和资料人员对该Story理解的正确性。如果Story分析的过程,PO、开发、测试、资料已经作了充分的沟通交流,所有人已经达成了对需求的一致理解,则评审不是必须的。注意,输出Story不是目的,是否真正理解了需求(系统要实现什么)才是关键。◤提示:Story评审通过标准◢ Story评估通过的标准是系...原创 2010-09-30 12:55:33 · 102 阅读 · 0 评论 -
敏捷项目操作手册(3)
independent(独立性)一定要保证Story是功能上独立的,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试,曾经有敏捷试点项目由于Story划分太细、依赖关系复杂而造成后期测试无法开展的情况。 testable(可测试的)要从可测试性考虑需求,同时要考虑能够独立测试。另外要注意,伴随Story要同时输出可接受性测试用例(Acceptance Test Ca...原创 2010-09-30 12:54:17 · 138 阅读 · 0 评论 -
敏捷项目操作手册(2)
User Story是敏捷开发和管理的核心,要确保Story的输出质量。根据目前的公司现状,Story的记录文档化,至少要保证团队成员都能理解、无偏差。User Story输出责任人是PO,不建议由开发人员组织分工去写作Story,如果实在无法避免,则PO要总体把关,并且端到端地去跟踪确认。迭代前准备阶段要分析项目的整体需求,至少应将迭代一要实现的Story正式输出,并符合质量要求;而迭代一以后的...原创 2010-09-30 12:53:18 · 157 阅读 · 0 评论 -
敏捷项目操作手册(1)
迭代前准备的活动包括:Story写作、Story评审、估计、一体化团队组建、办公环境布置、现状评估、计划制定、项目启动会议、、持续集成环境准备、概念和架构设计等活动。有些活动可能在项目启动前就准备好了,例如Story输出,这是一个持续的活动,在需求接纳后,如设计部有人力,就把该需求转换为Story;在这里把这些项目活动统一放到迭代前准备阶段。...2010-09-30 12:50:28 · 145 阅读 · 0 评论 -
敏捷项目操作手册(9)
1.6 办公环境布置安排一体化团队成员围坐在一起工作,目的是便于大家的沟通和交流;但目前大部分办公现状无法改变,所以只能让一体化团队成员尽可能的靠近,尤其不要出现开发和测试不在同一楼层的情况。 合理布置项目状态墙和开晨会的位置。...原创 2010-09-30 12:58:54 · 114 阅读 · 0 评论 -
敏捷项目操作手册(10)
1.7 可视化管理可视化管理可以清晰、简单和有效的组织和展示工作状况,可视化管理的目的不仅仅是为了“可视化”,更重要的是利用这样的一种方法,打造一种精益式的、Just in time方式的软件开发环境和系统。可视化管理的方式目前有很多种:Story Wall(状态墙)、Burn Down Chart燃尽图、项目组计划墙、特性墙等等。建议项目组准备1-2个白板、Story卡片等用于可视化展示...原创 2010-09-30 12:59:34 · 139 阅读 · 0 评论 -
敏捷项目操作手册(18)
2.2.2 Story功能实现(开发人员)功能代码实现:一对pair(两名开发人员)开始实现功能代码,做好UT,并及时重构。有条件的可以按TDD方式开发。关于结对编程、TDD请参阅其它资料,本文不再赘述。这里要特别强调的是开发人员要做好工具的检查工作,包括:代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复代码检查、UT测试覆盖率分析等。本地构建:构建前一定要将配置库...原创 2010-09-30 13:04:21 · 89 阅读 · 0 评论 -
敏捷项目操作手册(17)
2.2.1 头脑风暴会议在每个Story开发前建议都有这个头脑风暴会议,该会议由Story责任人组织和跟踪,形式不限;PO和对应这个Story的开发人员、测试人员、资料人员做一个沟通,大家要在这个Story的理解上达成一致,大体的实现方案,并且要思考如何测试这个Story,这也体现了测试先行的理念。测试项不需要象以前的测试用例那样详细,模板可参见《Story测试项模板.xls》,测试类型包括功...原创 2010-09-30 13:03:51 · 87 阅读 · 0 评论 -
敏捷项目操作手册(16)
2.2 单个Story的完整开发在迭代开始后,通常以一个一个Story分别完成开发的。单个的Story开发以头脑风暴会议开始,然后开发、测试、资料同时行动,各司其职。◤提示:一些优秀实践◢ 1、对于每一个Story,可以指定Story负责人,该Story负责人类似Story PL,负责该Story相关的监控管理和接口等工作,为该Story服务。当然Story相关涉及人员,也不要依赖St...原创 2010-09-30 13:03:10 · 127 阅读 · 0 评论 -
敏捷项目操作手册(15)
2.1 迭代计划会议(1)重新讨论、确定本次迭代需要实现的Story,达成共同理解;(2)若有必要的话,则继续细化Story;(3)对Story进行优先级排序;(4)开发、测试、资料人员认领任务,估计工作量并做出承诺,这是敏捷Scrum的重要实践之一:开发团队决定承诺完成工作量的多少,而不是由PO或项目PL安排工作量。(5)共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详...原创 2010-09-30 13:02:40 · 89 阅读 · 0 评论 -
敏捷项目操作手册(14)
2 迭代开发迭代前准备工作完成后就正式进入迭代开发,一次迭代周期建议是2到4周,每次迭代后期要有单独的SDV测试,对每次迭代版本质量的要求是要能够达到版本发布的程度。SDV测试是针对本次迭代完成的所有Story的整体测试,当然也会包括前次迭代的测试回归。每次迭代是以迭代计划会议开始的。◤提示:关于迭代的交付质量◢ 强调达到版本发布的程度并不是要求每次迭代都要进行对外的版本发布,而是强调...原创 2010-09-30 13:02:03 · 116 阅读 · 0 评论 -
敏捷项目操作手册(13)
1.11 制定测试策略测试TSE负责制定测试策略,用于指导迭代开发中各层级测试工作的开展,明确各层级测试重点,提升测试覆盖,降低测试冗余,保证迭代测试活动的质量。TSE根据版本迭代计划,结合产品风险分析,给出迭代测试策略初稿,作为总体测试策略的一部分;TSE组织PM、SE评审迭代测试策略。迭代开发需要有如下不同层级的测试活动策略:LLT(包括UT/IT/MST)测试、Story测试、迭...原创 2010-09-30 13:01:23 · 165 阅读 · 0 评论 -
敏捷项目操作手册(12)
1.9 项目启动会议所有团队成员参加,类似于项目开工会,团队成员介绍、项目背景介绍、项目目标、大致的计划时间点,以及迭代前准备阶段的安排和任务分工等1.10 建立持续集成环境项目PL指定项目组的CI-CO人员,协调CMO创建项目文件夹,并初始化配置库;CI-CO要负责搭建持续集成环境。持续集成是最有价值的优秀实践,是敏捷开发的基础,要求持续集成环境必须在迭代开始前准备好,工具推荐使用I...原创 2010-09-30 13:00:55 · 119 阅读 · 0 评论 -
敏捷项目操作手册(11)
1.8 现状评估、计划制定项目启动时建议项目PL和敏捷教练一起对一体化团队的状况做一评估,包括:团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评估的结果,输出一个较粗的E2E迭代计划(迭代前准备阶段后期,和每次迭代结束后,都可细化或调整该计划),同时要对迭代前准备阶段的活动有一个详细计划,包括:对评估发现的问题尽早采取一些措施(例如培训)、Story分析、...原创 2010-09-30 13:00:22 · 100 阅读 · 0 评论