- 博客(28)
- 收藏
- 关注
RSS订阅原创 结束项目
结束项目结束项目，项目经理要执行好几种活动：要求发行早期版本，主导beta测试，知道项目走向真正的尾声，项目回顾管理发布早期版本的请求敏捷开发周期不用担心发布早期版本的请求，每个迭代结束都是可以发布的其他生命周期，项目经理需要尽早知道是否需要发布早期版本按功能实现，实施持续集成且开发一个功能就马上进行测试，使得发布早期版本变容易如果不能按功能开发，还是可以让开发人员持续集成， 让测试人员按功能诸葛测试都不行，就要两次结束方案。 一个是早期版本，一个实际发布版本。会让人发疯管理
2020-11-10 10:38:12
224
原创 管理工程
管理工程如果项目是工程协调多个子项目或一系列项目，以达成特定的业务目标项目管理是战术上的，项目经理的职责是完成自己手上的项目，而不会考虑其他进行中的项目；工程管理是战略上的，工程经理要协调多个子项目或是一系列项目工程经理在进行战略管理决策时，要以各个项目之间的依赖关系作为依据。这些依赖关系有时体现为可交付物的形式，还涉及如何在项目组合中调配人员和资金将多个相关项目组织到一个发布版本中确保整个工程以可交付物为重，同时让人们注意如何保证自己的可交付物不出问题工程规划模板综述：产品
2020-11-09 15:27:09
178
原创 在项目中集成测试
在项目中集成测试项目的开始就要做好测试的规划，如果在规划时不打算将测试和开发集成在一起，就没人做测试了；到最后就得作为一个独立的项目任务且启动晚，耗时长，延迟了开发人员得到反馈的过程从一开始，就将 减少技术债 牢记心间可能会先偿还技术债，要跟团队说明该目标； 短期回顾，大家分享和吸收修复问题得到的经验使用小规模测试降低风险单元测试是首选， TDD是实施单元测试的最佳方式，与测试的关系更为紧密开发人员编写代码和缺陷单元测试是发现和修复缺陷最简便的方式，还可以用来阻止同样
2020-11-09 14:00:17
359
原创 管理多地点项目
管理多地点项目一个问题的成本是多少团队坐在一起成本低，尽可能让团队坐在一起识别项目的文化差异体现在人们认为他们可以讨论哪些话题，给予哪些奖励，人们对待彼此的方式整个项目不一定使用同样的生命周期模型，开发手段和具体实践，但整个项目团队必须使用互补的在团队间培养信任帮每个团队制订承诺目标，定义可交付物确保每个地点都有完整的项目可交付物不要创建单一功能团队，也不要创建过于零散的团队要保证每个地点都有一个完整的团队，交付相对完整的功能，通过测试，可以顺利运行的功能如果无
2020-11-06 14:35:00
201
原创 创建并使用项目仪表盘
创建并使用项目仪表盘测量有风险测量项目会面临三个大问题：项目团队花过多时间进行测量，从而影响正常工作；测量项目都是要由项目经理完成，团队成员不应该帮你获得，他们可以协助如需很多人配合，先加强项目在一些基础设施上的支持仪表盘的目的是使用数据来评估项目状态而不是为了花费时间创建仪表盘人们不认真对待测量；原因通常是因为只测量了项目中的一种因素如果只测量一种因素，等于鼓励人们只注重这一件事情（衡量什么，得到什么）确保存在多种测量方式，以评估项目的真正及进度测量人而不是项目
2020-11-05 15:20:55
930
1
原创 管理会议
管理会议取消这些会议对任何人都毫无价值，就取消掉，允许团队成员不参加无法贡献和收获价值的会议， 不参加这些会议是因为团队成员太重要而非不重要， 避免参加毫无效率的会议避免不需要你解决问题的会议不要举行多人参加的顺序式报告会议， 它更像一种注重形式的仪式而非会议； 项目会议不能解决任何问题，就是在拖后腿；如非要开， 则控制时间避免这些会议没有存在理由的会议没有会后行动的会议上层主管的顺序式报告会议，略过会议 告诉别人你的工作进度任何不允许带笔记本电脑的会议举行下列会议
2020-11-04 15:22:26
137
原创 保持项目节奏
保持项目节奏在项目中使用持续集成* 持续集成可以让开发人员马上得到所作工作的反馈，尽早识别出集成风险* 完成了某个功能才签入是按阶段集成。长时间才签入会打断项目节奏：构建出现问题会中断设计和编写新功能的人员的思路。回忆细节是一种同时处理多任务的方式因为思考问题的上下文发生了改变，但不容易发现。* 频繁构建是为开发人员和项目经理准备的，如果可以运行测试就更好了* 持续集成的变种：做一个主代码库的分支版本，在此分支版本上开发且每次签入都与主代码库进行同步，保证分支代码是最新的版本，最后将所有代码合
2020-11-04 10:24:28
192
原创 掌控项目
掌控项目前言制订项目仪表盘，定性和定量的度量方式都需要掌控项目意味着要寻找风险和管理风险，扰乱节奏和可能扰乱节奏的事情都是风险掌控项目的节奏观察节奏是项目经理的职责，要观察那些实践能否帮助项目建立并维持合理节奏，保证项目成功项目周期越接近顺序式生命周期，项目的节奏就越可能随阶段发生变化敏捷生命周期，迭代规划阶段可能有混乱的状态但迭代开始后可以找到节奏打断项目正常节奏的常见问题，要找到解决的办法不知道先完成哪些需求允许项目的需求收集阶段持续时间过长允许GUI随时发生变化，
2020-11-02 14:53:06
167
原创 创建出色的项目团队
创建出色的项目团队招募需要的人角色和负责的工作架构师： 组织并指导整个系统的开发，包括测试系统开发人员：设计，编写产品代码测试人员： 设计，编写测试，包括测试代码技术文案： 设计，编写产品文档业务分析师： 收集，编写需求发布工程师： 设计，编写，维护系统包括与系统相关的任何脚本项目经理： 组织项目工作UI设计师或固件开发人员角色不一定由不同人担任，没那么清晰。关键要有能够胜任工作的人无论他们一人担任几个角色项目经理没有吸引，招募或淘汰团队成员的权力，很可能失败形成
2020-10-29 11:45:11
120
原创 识别和避免日程安排游戏
识别和避免日程安排游戏给我一块石头出资人总希望项目能更早完成。 有时出资人不会认同提出的每一个截止日期–总是离期望值很遥远当出资人希望项目能更快交付但不告诉何时需要或为什么的时候就会玩 给我一块石头的游戏。应对策略：先提问：喜欢短日程或长日程？更多还是更少人？少实现几个功能会如何？先知道什么是最重要的会帮项目经理产生更加合理的解决方案找出什么原因促成了他们期望的截止日期。探寻出项目的战略原因，并搞清楚成功的真正含义让出资人明白所做的选择以及背后的原因为提供的日期说明信心范围提供日期
2020-10-28 13:32:32
252
原创 估算工作
估算工作实用的项目估算方式通过对比历史数据进行估算：也许可行但是项目是非线性的通过Delphi 和宽带 delphi方式进行估算，好于项目经理自己估算Delphi 方式：项目经理把团队召集一起，阐述项目有关事宜，大家提问并且写下自己的任务列表和时间估算，同时注明自己对项目的预设条件。然后收集任务列表并进行复查，看是否可并行。项目经理把估算加在一起，得到项目整体估算宽带Delphi方法：一小组专家会暂时代替项目团队产生任务列表和估算并提交任务列表，预设条件和风险问题：由于每人只负责估算项目一
2020-10-27 16:30:29
900
1
原创 安排项目日程
安排项目日程注重实效的项目日程安排项目规格和日程安排缺一不可项目日程的安排会与项目选择的生命周期有关系，可将生命周期用作指导方针但不是严格的限制条件日程安排和估算是不同的活动。 日程安排是安排工作任务的顺序，展示它们的依赖关系。工作估算要估计某个任务要花费的工时数。二者之间有关联，如何安排日程依赖于任务的估算和需要的特定人员。可供先择的项目日程安排技术自顶向下： 从最高级别的里程碑来组织日程，并制定任务支撑这些里程碑自底向上： 从安排特定的任务开始产生里程碑由内及外： 思维导图
2020-10-26 17:10:05
494
原创 使用生命周期组织项目
使用生命周期组织项目理解项目生命周期生命周期是项目经理和团队组织产品开发的方式。定义需求，设计，开发，测试以及与这些工作同时进行的过程，都是生命周期的一部分整体上组织项目，不要把现实状况理想化。 比如不要在规划时就希望先产生完整的需求。讲求实效性，选择的生命周期要有助于识别项目风险，帮助项目经理交付成功的产品考虑某种生命周期是否实用，不能只考虑内部项目风险。客户和他们的期望也是风险的一部分选的生命周期要很好地应对风险：能否及时发布，缺陷，特性，成本等生命周期概览四种类型的生命周期
2020-10-26 15:54:04
182
1
原创 规划项目
规划项目规划和日常安排两种不同的活动，规划是制定带有发布条件的项目计划；日常安排是对工作项目的有序描述开始规划有了章程就可以对接下来要做什么做些有明确方向的预先规划，可以和项目团队成员一起完成项目规划：未来几天，几周要做什么；或者开始原型化工作，或开始第一个迭代；敏捷开发过程不妨将项目规划看作发布计划使项目足以启动的规划无需完美，只要让项目启动起来；完美会花费太多时间且不稳定用时间盒来限制启动规划活动时间盒：特定的时间长度，个人或 团队用它来完成某项特定的任务
2020-10-26 14:05:34
270
原创 启动项目
启动项目定义项目和项目经理项目的定义： 一个独特的任务或是系统化的流程，其目的是创建新的产品或服务，产品和服务交付完成标志着项目结束。项目都有风险，并且受制于有限的资源。项目的目标：项目启动之前，着手收集信息，了解项目要实现哪些目标产品是项目的核心产品的定义：项目产生的一系列可交付物项目经理定义：被赋予管理项目的权利和责任，并带领项目团队，通过项目管理来达成项目的目标。职责： 负责向团队说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户
2020-10-23 15:13:20
324
原创 敏捷项目管理的十大关键测量指标
敏捷项目管理的十大关键测量指标冲刺目标的成功率成功的冲刺应该有一个可工作的产品，它实现了冲刺目标并且符合Scrum团队对完工的定义Scrum团队可跟踪成功实现冲刺目标的频率，且使用成功率来了解团队是否成熟或是否需要校正方向缺陷：跟踪缺陷测量指标可让开发团队知道预防问题发生的好处，以及何时改进流程构建缺陷：构建层级的漏洞数量， 可知道是否要调整开发流程和环境因素用户接受度测试（UAT）阶段缺陷： 此阶段的缺陷个数可以确定是否需要为了解需求而改进流程，是否有必要调整自动化测试工具发布
2020-10-22 14:22:45
1756
1
原创 敏捷项目管理的十大好处
敏捷项目管理的十大好处更好的产品质量， 下列行动来帮助确保质量采取积极的方法预防产品质量问题追求技术卓越，良好设计和可持续开发即时定义并详细阐述需求，以便对产品特点的认知更清晰为用户故事制定验收的标准，以便开发团队更好的理解以及产品负责人更准确的验证把持续集成和每日测试融合于开发过程中，使开发团队能够将问题解决于萌芽状态利用自动化测试，从开做到白天开发，晚上测试，造成修复进行冲刺回顾，使Scrum团队不断改进过程与工作使用完工的定义来完成工作：已开发，已测试，已集成和已归档更
2020-10-22 11:44:54
1006
原创 确保敏捷成功 - 成为变革代理人
成为变革代理人组织中实施敏捷的步骤：第1步：制定实施策略：实施策略是描述组织将如何转型到敏捷项目管理的计划。自问：现在的流程： 如何运作，优势，存在的问题未来的流程：如何收益于敏捷方法，哪些敏捷方法，组织需要哪些改变，团队和流程会变成怎样循序渐进的计划：如何转型，马上的改变是什么，6个月后的改变，一年甚至更长时间的改变收益： 敏捷为团队以及组织整体提供什么好处潜在的挑战： 最艰难的变革是？哪些部门或人员在使用敏捷困难最大？谁的地盘将会收到威胁？潜在的障碍， 如何攻克这些挑战成功的因
2020-10-22 09:48:40
303
原创 确保敏捷成功 - 构建敏捷基础
构建敏捷基础获得组织和个人的承诺同时获得个人和组织层面的承诺是敏捷转型的关键组织承诺，可通过执行以下工作来实现敏捷转型且转型成功后，组织继续支持聘请有经验的敏捷专家创建一项可行的转型计划，并指导公司实现该计划在公司第一个敏捷项目团队成员的培训上就要开始有所投入为支持敏捷方法，允许Scrum开发团队放弃瀑布式的过程，会议和文件为每个敏捷项目提过所需的Scrum团队成员：开发团队，产品负责人和Scrum主管为敏捷项目团队提供专职的Scrum团队成员鼓励开发团队跨职能工作，提供自动化测试
2020-10-12 16:17:25
161
原创 敏捷管理 -- 质量和风险管理
质量和风险管理敏捷项目质量管理的不同之处质量的定义：某个产品是否可工作并满足项目干系人的需求，质量贯穿整个敏捷项目管理过程敏捷12原则全部直接或间接的指向质量传统项目质量管理和敏捷项目质量管理对比敏捷项目质量管理的另一个不同之处在于项目声明周期内的多次质量反馈循环：开发团队的日常反馈->产品负责人对每个冲刺的反馈->项目干系人对每个冲刺的反馈->客户对每个发布的反馈如何在敏捷项目中管理质量敏捷开发团队对质量负有主要责任，承担质量责任是自管理所伴
2020-10-12 14:13:38
1010
原创 敏捷管理 ---团队活力和沟通管理
团队活力和沟通管理敏捷项目团队活力的不同之处宣言第一项和敏捷原则4，5，8，11，12体现出对项目团队成员以及合作方式的重视传统方法与敏捷方法管理团队的对比团队成员是人而不是资源来表达对团队成员的尊重，敏捷思想体系的核心是人如何在敏捷项目中管理团队的活力走向自管理和自组织敏捷团队每个成员都有机会根据自己的技能，想法和意愿来领导团队前提是团队和团队所在组织建立全面的信任与尊重，团队每个成员要以个人和团队的名义对项目本身和彼此做成承诺，体现主人翁精神项目管理和自
2020-10-09 16:26:05
638
原创 敏捷管理 -- 时间和成本管理
时间和成本管理时间管理和成本管理是项目管理系统中关键的两个方面敏捷项目时间管理的不同之处项目管理术语中，时间一词指的是确保项目及时完成的一系列过程，敏捷原则中1，2，3，8可以更好理解敏捷项目时间管理传统项目和敏捷项目时间管理方法对比敏捷时间管理的一大好处是敏捷项目团队可以比传统项目团队更早的交付产品，在时间或成本限制范围内始终交付高优先级的功能。如何在敏捷项目中管理时间敏捷方法论在进度和时间管理方面，同时提供战略和战术方面的支持早期的计划实际上是战略级的
2020-10-08 16:26:07
1260
原创 敏捷管理 -- 范围与采购管理
范围与采购管理敏捷项目范围管理的不同之处项目范围管理在传统的项目管理活动中占据了很大比重产品范围的定义是一个产品包含的全部特性和需求；项目范围就是指开发一个产品所需要的全部工作敏捷项目允许变更项目，项目范围的变更是合理且有意的敏捷12原则中，1，2，3，10与项目范围管理密切相关传统项目与敏捷项目范围管理对比如何在敏捷项目中管理范围理解项目的范围：通过价值路线图来了解范围管理阶段1-愿景： 产品愿景声明是确立项目范围的第一步阶段2- 产品路线图： 编制路线图时，产品负责
2020-10-07 17:31:34
784
原创 为发布做准备
为发布做准备准备部署产品：发布冲刺发布冲刺： 为了适应发布前的工作并且确保发布顺利进行，团队经常在发布产品之前安排一次发布冲刺发布冲刺中的冲刺代办项包括：为最新版本的产品创建用户文档性能测试，负载测试，安全测试和任何其他可以确保软件投产后正常云新的检查和企业级系统的整合完成发布前必须执行的一些强制性的组织或监管程序准备发布记录–关于产品变更的最终记录准备打包部署，使所有包含产品的代码可以同时迁移到生产环境中将代码部署到生产环境中发布冲刺和开发冲刺的区别：不开发任何来自产
2020-10-07 14:26:33
94
原创 展示工作和集成反馈
展示成果和集成反馈冲刺评审： 是在冲刺中展示并评审开发团队完成的用户故事的会议，任何对冲刺中完成的工作感兴趣的人都可参加，意味着所有干系人都有机会了解产品进展并提出反馈。包括：准备演示：准备工作应该很快，几分钟；产品负责人和开发团队参与准备开发团队在冲刺评审中演示的代码必须是符合完工的定义的冲刺评审会议冲刺评审会议的两项内容：展示Scrum团队已完成的工作和干系人对这些工作提出的反馈意见Scrum团队在各个循环阶段收到有关产品的反馈开发团队每天进程的反馈产品负责人每个冲刺
2020-10-07 13:44:27
211
原创 敏捷项目管理敏捷工作之全天的工作
敏捷团队的日常工作计划每天的工作会议内容：标注已完成的事项；发现困难或障碍， 提出需要Scrum主管介入的事项； 计划当天要做的工作每个成员陈述以上三个内容每日例会不超过15分钟例会原则任何人都可参加，但只有开发团队成员，Scrum主管和产品负责人可以发言会议只关注当前的工作例会是为了促进团队的交流合作而不是解决问题防止会议变成解决问题的专题会，可以创建问题列表来跟踪需要立即处理的问题，会后马上处理例会结束后开专题会来解决问题例会是为了团队成员个体间平等交流合作，
2020-10-07 10:42:40
566
原创 敏捷项目管理敏捷工作之冲刺计划
冲刺计划冲刺的定义： 一个冲刺指一段确定的迭代时间，在这段时间内，开发团队从开始到结束持续创建特定的一组产品功能。在冲刺结束时，开发团队创建的产品应该正常工作且可以进行演示。冲刺的时长：所有冲刺应具有相同的时长。时长一致可以帮助衡量开发团队的表现，更好的计划每次新的冲刺。一般1-4周，不超过四周。冲刺包括的事项：冲刺开始时冲刺计划参与人：整个scrum团队（PO, Scrum主管和开发团队）协同工作，计划冲刺计划冲刺需要做：-【1】为冲刺设立目标-【2】选择支持这些目标的用户故事-【
2020-09-29 15:27:28
3347
原创 敏捷项目管理敏捷工作之发布计划
发布计划发布：指发布出来用于生产的一组可用的产品特性。无需包含所有的路线图的功能，至少要包括最小的可上市的特性集。计划发布：确定下一组最小可上市的特性集，并确认团队能够行动起来将最迫切的产品推出的日期。在创建产品愿景和产品路线图时，产品负责人确定发布目标和发布日期* 发布计划包括两项关键活动+ 修订产品代办列表1. 产品代办列表是与项目相关的所有用户故事的列表。是项目需求的主要来源2. 产品负责人通过不断的添加用户故事和为用户故事排定优先级来创建和维护产品代办列表。3. scrum
2020-09-29 14:06:28
3096
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人