FT 软件项目管理
Posted realzjx
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FT 软件项目管理相关的知识,希望对你有一定的参考价值。
FT 软件项目:
软件项目管理:
软件技术项目管理
项目的生命周期
项目组织机构形式
项目管理三要素
项目进度控制
项目进度控制是依据项目基准计划对项目进行监控,使项目能够按时完成。 当项目的实际进度滞后于计划进度时, 项目管理者应首先发现问题、分析问题根源并找出妥善的解决办法,采取纠正措施。
经常用到的进度计划的方法有:1. 关键路径法;2.关键链法;3.资源平衡;4.假设情景分析;5.利用时间提前量与滞后量;
最简单的: 项目的每一个工作任务和活动, 责任到人, 明确计划开始时间,计划完成时间, 活动启动的前置条件或依赖。 找出项目进度的关键路径,保证关键路径上的资源, 非关键路径上的资源机动调配。
以上是一个项目的活动网络图, 问项目关键路径是什么, 项目需要历时多少天。
工作项优先级管理
同样一件事情的重要性在不同背景的人眼里是不一样的, 而且,同样的事情在业务的不同发展阶段里, 重要性也会不一样。 但最好的优先级还是跟着业务走。
- 确定用户需求的优先级, 需要跟用户充分沟通, 优先保障用户核心需求。
- 通过投入产出比,还有人力, 确定优先级
- 不要追求技术上的完美设计。满足质量要求的情况下, 采用最简单、最快速、设计方案。技术方案上优先考虑功能, 其次考虑稳定性和准确性、适当地考虑扩展性和通用性。
重要但是不紧急的这个象限经过分解任务指定计划后, 又可以生成了一个新的四象限法则图。
项目风险管理
- 执行计划的风险: 项目规划时,合理评估工作量, 并考虑延期风险, 预留少量的时间buffer,但所有成员应努力按照项目基准计划行动,不使基准计划延期, 这样预留的时间才有意义。 否则就会进入不断延期的循环。
- 需求变更的风险: 需求增加时,应增加人力投入,或者增加项目交付时间。
- 突发事件,成员请假,团队解散,或者其他风险:很遗憾,这些对于技术管理者经常是无解的。
- 可能发生延期时的解决方案:
- 加班或加人。 很不幸,通常加班是最有效,最常见的手段。 临时加新人,短期内不能融入项目,还带来更多的学习和沟通的成本,甚至影响到原, 有人员的工作效率, 解决不了进度问题。
- 砍功能: 从项目目标中拆解出来的二级项目标, 应该确定优先级。 如果时间不够,资源不够, 延期优先级低的二级目标, 保障最主线的功能开发
- 求得谅解: 充分沟通,管理好需求方的预期, 但一定要保证满足需求方的核心需求。
项目管理模型
- 瀑布模型(源自传统项目):瀑布模型是最早出现的软件项目管理模型
- 优点:
- 可控:为项目提供了分阶段的检查点
- 简单:当一个阶段完成后, 只需要关注下一个阶段
- 可迭代扩展: 可以用于迭代开发模型, 每次迭代产生一个版本。 每次迭代经过质量和集成测试。
- 缺点:
- 贵: 各个阶段的划分固定, 阶段之间存在交付行为, 需要产生大量的文档, 增加了工作量和成本。而且后期测试阶段才能发现前面阶段的错误, 导致阶段之间交付的文档失效, 导致 "最有效的文档就是代码"
- 慢,由于开发是线性的,依次进行,只有进行到最后一个阶段才能看到效果, 项目风险比较大
- 不灵活, 不能适应用户需求的变化。 虽然变更需求在任何开发模型里都要付出较大的成本, 但对于瀑布模型而言变更需求的代价远远高于其他开发模型。
- 瀑布模型更适合需求变更不频繁, 整体项目时间压力不大, 可预测,计划强的的业务场景, 比如一些针对重资产厂商的软件开发, 硬件相关的软件开发。
- 优点:
- 敏捷开发方法, scrum会议。应用非常广泛的软件开发模型, 极大的提高了软件开发的工作效率, 成功的让软件项目组里的所有角色都忙个不停, 天天加班。 瀑布模型里QA忙的时候, RD闲着, RD忙着时候QA闲的情况不复存在。
- 我个人认为重要的几个原则(还没体会到的先不写, 例如“用story编写可测试的需求”, 我没有特别体会得到)
- 简单(简单的模型, 简单的设计,简单的工具)
- 拥抱变化
- 最小价值原型, 小增量
- 并行建模(对比,瀑布模型的串行工作模式)
- 把项目的可持续性发展作为第二个目标(第一目标是按时交付项目给用户)
- 公开展示模型。所有的设计文档用wiki管理, 全体成员可见
- 我个人认为重要的几个原则(还没体会到的先不写, 例如“用story编写可测试的需求”, 我没有特别体会得到)
- DEVOPS理论, 需要频繁交付的企业需要用到Devops, 例如互联网业务开发部门。用于促进, 开发、运营、和QA之间的紧密协作, 保障软件产品和服务的按时交付。
- 使用DEVOPS方法的组织采一般采用敏捷开发模型。
- 业务负责人要求加快软件交付的速率
- 使用DEVOPS方法的软件发布的风险应该很低。
- 关键是持续交付,持续集成、持续部署、持续运营
- 开发: 微服务, 容器化,
- 构建: 自动化构建工具
- 部署: 自动化部署, 回滚
- 测试: 自动化测试, 白名单测试, AB测试。
- 发布: 预发布,蓝绿发布,灰度发布
- 运营: 监控报警, 日志组件,高可用(异地双活,降级,切流,熔断), 性能,安全,服务发现
- 传统软件项目开发与互联网软件项目管理方法的异同
项目管理工具
JIRA, bugzila。 team concert。 project, excel。
我们用wiki和JIRA, 还有email管理。
工具越复杂,使用的成本就越高,运用到项目中的机率也越低。只要达到“有效组织项目信息”的目的就够了。小团队并不需要复杂的项目管理工具。
FT项目管理制度
- 项目启动会议(1~2小时, 全体组员参与)
- 每日站会(每天早晨,10~20分钟, 全体组员参与), 同步项目进展, 提出问题, 当天工作安排。
- 小组讨论(按需要,随时, 相关组员参与)
- 每周周会(每周五, 全体组员参与),一周工作总结, 规划下周计划和目标
- 项目演示会议(项目验收后, 全体组员,并邀请领导和业务方参加)
- 所有会议在wiki里都有纪要,有todo, 可track。
项目管理的具体流程
- 项目启动阶段: 一定要经过充分调研和讨论,明确项目的目的和目标,项目收益(使命愿景价值观)工具:mindmap,project,技术选型, 需求分析, 确定系统角色。
- 项目顶层设计和计划阶段: 资源计划,依赖条件, 可能遇到的问题和风险, 整体架构设计, 组件设计。概要设计, 确认模块woner, 任务划分。
- 项目模块设计和计划阶段: 确定各个模块的目的、外部接口, 完成内部设计, 详细设计。
- 项目开发阶段: 注意记录, 注意高效沟通, 站会安排日计划, 周会总结安排下周计划。 碰到问题立刻解决, 不拖延。
- RD联调测试阶段: 各个模块联调测试, 打通数据和调用链路
- QA测试验收阶段: FVT, SVT, GVT,
- 交付验收阶段: demo dry run。 交付业务方使用。
- 维护阶段: 支持业务方对接, 修bug。
以上是关于FT 软件项目管理的主要内容,如果未能解决你的问题,请参考以下文章
此应用DCloud appid 为_UNI_DAD3FT8,您不是这个应用的项目成员。1联系这个应用的所有者,请求加入项目成员(https://dev.dcloud.net.cn “项目成员管理“
此应用DCloud appid 为_UNI_DAD3FT8,您不是这个应用的项目成员。1联系这个应用的所有者,请求加入项目成员(https://dev.dcloud.net.cn “项目成员管理“
此应用DCloud appid 为_UNI_DAD3FT8,您不是这个应用的项目成员。1联系这个应用的所有者,请求加入项目成员(https://dev.dcloud.net.cn “项目成员管理“