FT 软件项目：

以Feature Team形式组织起来的软件研发项目。项目是临时组织不是长期组织。人员临时组织起来，无组织汇报关系。大家需要充分理解和认同项目的目标，通过项目获得技术、经验、认知、和心灵的成长，除此之外，不能承诺任何的物质与金钱激励，所以沟通方式也是直接高效，不玩虚的，就事论事，直奔结果。

feature team形式与organize team的异同很明显。

典型的FT， 7~10人，优点：高效，迅速。

软件项目管理：

软件项目管理者

技术项目管理者通常也是架构师，需要深入了解技术细节，提出合理的技术选型和架构设计，为项目成员提供合理的建议，仲裁意见冲突，把人员有效地串联起来，并且及时发现和解决项目进度有关的重大风险和潜在问题。

在技术项目管理中，项目负责人在领导力方面，作为导航者作用应该是很突出的（领导力21法则）。

软件技术项目管理

“软件技术项目管理”，通常更多是一种信息管理。

项目管理更多的是依赖“清晰有效的信息组织”和“高效的人员组织”。

项目管理的目的是按计划交付

项目管理的途径是让每一个成员有明确的整体大目标和各自的小目标。用一个个的小目标的积累达成大目标。

项目管理的手段是通过组织机构，和项目安排，让每个成员有peer 压力，构成互相推动，互相支持的团队合力，促使整个团队共同向大目标前进。

项目的生命周期

启动立项阶段，计划阶段，实施阶段（开发，测试）收尾阶段（交付，验收）维护阶段（迭代）。

项目组织机构形式

我比较喜欢facebook的团队组织形式。代表了高效，平等，信任，自我驱动，和peer pressure。我们现在的团队就是这种组织形式。

项目管理三要素

时间，质量，成本。通常技术项目管理者不能在质量和成本上做太多妥协，唯一可能管控的就是时间。

项目进度控制

项目进度控制是依据项目基准计划对项目进行监控，使项目能够按时完成。当项目的实际进度滞后于计划进度时，项目管理者应首先发现问题、分析问题根源并找出妥善的解决办法，采取纠正措施。

经常用到的进度计划的方法有：1. 关键路径法；2.关键链法；3.资源平衡；4.假设情景分析；5.利用时间提前量与滞后量；

最简单的：项目的每一个工作任务和活动，责任到人，明确计划开始时间，计划完成时间，活动启动的前置条件或依赖。找出项目进度的关键路径，保证关键路径上的资源，非关键路径上的资源机动调配。

技术分享图片

以上是一个项目的活动网络图，问项目关键路径是什么，项目需要历时多少天。

工作项优先级管理

同样一件事情的重要性在不同背景的人眼里是不一样的，而且，同样的事情在业务的不同发展阶段里，重要性也会不一样。但最好的优先级还是跟着业务走。

确定用户需求的优先级，需要跟用户充分沟通，优先保障用户核心需求。
通过投入产出比，还有人力，确定优先级
不要追求技术上的完美设计。满足质量要求的情况下，采用最简单、最快速、设计方案。技术方案上优先考虑功能，其次考虑稳定性和准确性、适当地考虑扩展性和通用性。

技术分享图片

重要但是不紧急的这个象限经过分解任务指定计划后，又可以生成了一个新的四象限法则图。

项目风险管理

执行计划的风险：项目规划时，合理评估工作量，并考虑延期风险，预留少量的时间buffer，但所有成员应努力按照项目基准计划行动，不使基准计划延期，这样预留的时间才有意义。否则就会进入不断延期的循环。
需求变更的风险：需求增加时，应增加人力投入，或者增加项目交付时间。
突发事件，成员请假，团队解散，或者其他风险：很遗憾，这些对于技术管理者经常是无解的。
可能发生延期时的解决方案：
1. 加班或加人。很不幸，通常加班是最有效，最常见的手段。临时加新人，短期内不能融入项目，还带来更多的学习和沟通的成本，甚至影响到原，有人员的工作效率，解决不了进度问题。
2. 砍功能：从项目目标中拆解出来的二级项目标，应该确定优先级。如果时间不够，资源不够，延期优先级低的二级目标，保障最主线的功能开发
3. 求得谅解：充分沟通，管理好需求方的预期，但一定要保证满足需求方的核心需求。

项目管理模型

瀑布模型（源自传统项目）：瀑布模型是最早出现的软件项目管理模型
1. 优点：
  1. 可控：为项目提供了分阶段的检查点
  2. 简单：当一个阶段完成后，只需要关注下一个阶段
  3. 可迭代扩展：可以用于迭代开发模型，每次迭代产生一个版本。每次迭代经过质量和集成测试。
2. 缺点：
  1. 贵：各个阶段的划分固定，阶段之间存在交付行为，需要产生大量的文档，增加了工作量和成本。而且后期测试阶段才能发现前面阶段的错误，导致阶段之间交付的文档失效，导致 "最有效的文档就是代码"
  2. 慢，由于开发是线性的，依次进行，只有进行到最后一个阶段才能看到效果，项目风险比较大
  3. 不灵活，不能适应用户需求的变化。虽然变更需求在任何开发模型里都要付出较大的成本，但对于瀑布模型而言变更需求的代价远远高于其他开发模型。
3. 瀑布模型更适合需求变更不频繁，整体项目时间压力不大，可预测，计划强的的业务场景，比如一些针对重资产厂商的软件开发，硬件相关的软件开发。
敏捷开发方法， scrum会议。应用非常广泛的软件开发模型，极大的提高了软件开发的工作效率，成功的让软件项目组里的所有角色都忙个不停，天天加班。瀑布模型里QA忙的时候， RD闲着， RD忙着时候QA闲的情况不复存在。
1. 我个人认为重要的几个原则（还没体会到的先不写，例如“用story编写可测试的需求”，我没有特别体会得到）
  1. 简单（简单的模型，简单的设计，简单的工具）
  2. 拥抱变化
  3. 最小价值原型，小增量
  4. 并行建模（对比，瀑布模型的串行工作模式）
  5. 把项目的可持续性发展作为第二个目标（第一目标是按时交付项目给用户）
  6. 公开展示模型。所有的设计文档用wiki管理，全体成员可见
DEVOPS理论，需要频繁交付的企业需要用到Devops，例如互联网业务开发部门。用于促进，开发、运营、和QA之间的紧密协作，保障软件产品和服务的按时交付。
1. 使用DEVOPS方法的组织采一般采用敏捷开发模型。
2. 业务负责人要求加快软件交付的速率
3. 使用DEVOPS方法的软件发布的风险应该很低。
4. 关键是持续交付，持续集成、持续部署、持续运营
  1. 开发：微服务，容器化，
  2. 构建：自动化构建工具
  3. 部署：自动化部署，回滚
  4. 测试：自动化测试，白名单测试, AB测试。
  5. 发布：预发布，蓝绿发布，灰度发布
  6. 运营：监控报警，日志组件，高可用（异地双活，降级，切流，熔断），性能，安全，服务发现
传统软件项目开发与互联网软件项目管理方法的异同

项目管理工具

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 软件项目管理