分类 工作 下的文章

敏捷项目管理需要知道的五类图表

轻量级的报表、文档可以有效地帮助敏捷团队更好的将工作可视化、辅助和客户的沟通、清晰的展示进度并且对风险进行把控,对项目管理有很好的作用。在过去的项目管理经验中,个人认为有五类图表是项目经理需要了解并且可以在日常工作中频繁使用的。

敏捷的价值观强调可工作的软件更加重要,但也不能否认文档的价值。

燃尽图 ( Burndown Chart )

燃尽图是敏捷项目中最频繁使用的一类图表,它是在工作完成前对于进度的一种可视化表示。我们经常会利用迭代燃尽图来监控用户故事是否如期进行,当然也可以利用Feature燃尽图来监控MVP的完成情况。如下图:
1.png

该图横轴是时间,纵轴是剩余的用户故事点,灰色线是按照团队平均速率用户故事应该被完成的情况(水平部分是周末),蓝色线是实际情况。通过此图我们可以很清晰地看到该迭代团队的开发速率高于期望并且差距不是很大,项目处于很健康的状况。如果蓝线一直高于灰线或者蓝线偏离灰线太远,项目经理就需要注意了,有可能的原因包括迭代计划不合理、团队开发速率出现了问题等,这会导致团队在迭代后期Backlog不够或者迭代结束不能正常完成计划的点数,所以需要项目管理者和团队一起分析具体的原因并且尽快采取措施。

速率表 ( Velocity Chart )

敏捷开发以迭代为周期开展工作,在每个迭代开始之前都会按照团队的平均Velocity来安排迭代计划,所以持续地关注团队的Velocity便于更准确地了解团队的交付能力,更合理的做迭代计划。项目经理通过Velocity表可以从总体上分析团队的开发速度是否正常、迭代计划是否合理以及对于剩余的Scope是否有交付的风险。如下图:

2.png
该图表横轴是迭代,纵轴是完成的用户故事点数,绿色表示实际完成的故事点数,灰色表示按照团队能力应该完成的故事点数。通过该图我们可以看到绿色和灰色虽然有时不同但一直比较接近,团队处于很健康的状况。如果绿色和灰色某一次或者总是差距很大,有可能的原因包括某一段时期的feature复杂度提升、团队内频繁的人员调整或者各类会议增多导致的开发时间减少等,这时候项目经理就要意识到团队可能有交付风险或者需要调整迭代计划了。

甘特图 ( Gantt Chart )

甘特图也叫横道图,是项目管理领域最常用到图表形式,一般用来展示活动或者事件随着时间和费用的变化,通常会包括活动清单、活动日期、进度期限和每天的进展。在敏捷项目管理中,我们可以借助甘特图来可视化某个特定项目(包含一系列的子活动)的进展。如下图:

3.png
该图拿数据迁移这一事件为例,横轴是时间,纵轴是完成数据迁移需要的一系列活动,相同颜色代表同样的活动,灰色表示还没有完成的工作。通过该图可以看到数据迁移的大部分工作已经完成,只剩下最后的POC2的数据分析,并且能看到各项子活动的实际耗时,便于之后类似活动的计划和安排。在敏捷项目中我们还可以借助甘特图来管理Epic用户故事的进展、预算的花费情况等,如果发现某些子活动没有进展,或者消费超过预算太多,项目经理就要考虑采取一些措施推进某些子活动或者消减某方面的投入了。

日报 ( Daily Update )

以上三类是通用的一些图表,很多项目管理软件已经支持,比如 Jira, Mingle 可以自动生成燃尽图和速率表,甘特图有专门的绘制软件。而日报是我们在离岸交付项目长期摸索的过程中使用最频繁也最重要的一个图表,对于每日的沟通非常有用。如下图:

4.png
该图分为三大块,首先是每天的用户故事进展,然后是已有的Backlog的情况,最后是开放性问题,绿色背景是每天内有变化的故事卡,黄色是由于各种原因被block的故事卡,该报表的目的不是为了汇报工作,而是为了让异地的团队和客户对于每天的进展都能一目了然。虽然我们有项目管理工具比如Jira等,但是对于离岸团队来说,通过这样的图表更能清晰地看到每天的变化,让不和我们坐在一起的客户增加信心,也便于我们把遇到的blocker可视化出来。

红黄绿报告 ( RAG Report )

RAG是Red,Amber,Green的缩写,该报告采用了和交通灯一样的呈现方式,简单易懂,可以用来做项目、人员等的健康度报表,拿项目健康度报表举例,项目经理可以按照自己项目需要关注的维度制定该表,然后定期监控每一项是否健康,对于敏捷团队来说,一周一般就可以了。如下图:

5.png
该图横向是项目是否健康需要考虑的几个维度,纵向是时间,每一个单元格里的颜色采用了RAG,红色表示该项出现了严重的问题,如果不尽快采取措施,会有不能接受的影响;黄色表示有一定的影响,团队已经在通过一些方案减小影响;绿色表示该项如期进行。通过该图可以看到该项目在过去的三周没有严重问题,总体来说比较健康,People方面虽然在第一周遇上了一些问题但是通过采取措施已经完全解决,Legal方面目前还在尝试解决。如果发现有红色出现或者某项持续绿色,项目经理就需要马上找相应人员采取措施了。

总结

任何一个报表都只是辅助工具,如果绘制或者更新报表的过程非常繁琐,那么这样的报表读起来也一定不会轻松。本文推荐的五类报表是我在敏捷项目管理过程中认为简单易用并且很有帮助的一些报表,通过使用他们,可以辅助我们管理进度、高效沟通、预知风险。当然,除了本文提到的五类报表,项目经理还需要了解一些其他的报表,比如基本的财务报表等,这部分跟团队开发模式没有太大的关系,所以没有加入到本文的范围。

说实话,去一家小公司从 0 到 1 搭建后端架构,真难~

  1. MVC
  2. 服务拆分
  3. 微服务架构
  4. 领域驱动设计

总结

来腾讯之前在前公司做了3年的后端开发, 经历一款SaaS产品从0到10(还没有到100, 哈哈哈)的过程, 3年间后端的架构逐步演变, 在微服务的实践过程中遇到的问题也越来越多, 在这里总结下.

产品是一款服务于人力资源的SaaS在线服务, 面向HR有Web Android/iOS 小程序多个客户端, 后端采用RESTful风格API来提供服务. 主要使用Python语言, 方便快速迭代.

架构的演进经历了4个大的阶段: 1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计.

1. MVC


项目刚开始的时候, 后端同事不超过5个, 这个阶段主要的工作是实现产品的原型, 没有太多的考虑架构, 使用Django来快速实现功能, DB的表结构设计好之后, 抽象出功能View, 由于产品设计也很不完善, 后端需要很多的预留设计, 避免产品逻辑的变更带来整个表结构的变动, 在这个阶段代码上最重要的是确定适合团队的代码规范, 代码检查规则.

1.jpg

整体上架构如上图, Nginx负责负载均衡, 分发流量到多个Django服务, Django处理逻辑, 需要异步任务就交给Celery, 然后数据量比较大的地方使用Redis做缓存. 同时还有实时消息通知的需要使用了Nginx Push Module.

问题与优化方式:

  1. Django并发性能差 使用uWSGI Master+Worker 配合 gevent 携程支持高并发
  2. Redis连接数过多 使用redis-py自带的连接池来实现连接复用
  3. MySQL连接数过多 使用djorm-ext-pool连接池复用连接
  4. Celery配置gevent支持并发任务

随着开发的功能越来越多, Django下的app也越来越多, 这就带了发布上的不方便, 每次发布版本都需要重启所有的Django服务, 如果发布遇到问题, 只能加班解决了. 而且单个Django工程下的代码量也越来越多, 不好维护.

2. 服务拆分


随着后端团队的壮大, 分给每个同事的需求也越来越细, 如果继续在一个工程里面开发所有的代码, 维护起来的代价太高, 而我们的上一个架构中在Django里面已经按模块划分了一个个app, app内高类聚, app之间低耦合, 这就为服务的拆分带来了便利. 拆分的过程没有遇到太大的问题, 初期的拆分只是代码的分离, 把公用的代码抽离出来实现一个公用的Python库, 数据库, Redis还是共用, 随着负载的增加, 数据库也做了多实例.

2.jpg

如上图, 服务之间尽量避免相互调用, 需要交互的地方采用http请求的方式, 内网的调用使用hosts指向内网地址.

问题与优化方式:

Nginx Push Module由于长时间没有维护, 长连接最大数量不够, 使用Tornado + ZeroMQ实现了tormq服务来支撑消息通知
服务之间的调用采用http的方式, 并且要求有依赖的服务主机配置hosts指向被调用的地址, 这样带来的维护上的不方便. 以及在调用链的过程中没有重试, 错误处理, 限流等等的策略, 导致服务可用性差. 随着业务拆分, 继续使用Nginx维护配置非常麻烦, 经常因为修改Nginx的配置引发调用错误. 每一个服务都有一个完整的认证过程, 认证又依赖于用户中心的数据库, 修改认证时需要重新发布多个服务.

3. 微服务架构


3.jpg

首先是在接入层引入了基于OpenResty的Kong API Gateway, 定制实现了认证, 限流等插件. 在接入层承接并剥离了应用层公共的认证, 限流等功能. 在发布新的服务时, 发布脚本中调用Kong admin api注册服务地址到Kong, 并加载api需要使用插件.

为了解决相互调用的问题, 维护了一个基于gevent+msgpack的RPC服务框架doge, 借助于etcd做服务治理, 并在rpc客户端实现了限流, 高可用, 负载均衡这些功能.

在这个阶段最难的技术选型, 开源的API网关大多用Golang与OpenResty(lua)实现, 为了应对我们业务的需要还要做定制. 前期花了1个月时间学习OpenResty与Golang, 并使用OpenResty实现了一个短网址服务shorturl用在业务中. 最终选择Kong是基于Lua发布的便利性, Kong的开箱即用以及插件开发比较容易. 性能的考量倒不是最重要的, 为了支撑更多的并发, 还使用了云平台提供的LB服务分发流量到2台Kong服务器组成的集群. 集群之间自动同步配置.

饿了么维护一个纯Python实现的thrift协议框架thriftpy, 并提供很多配套的工具, 如果团队足够大, 这一套RPC方案其实是合适的, 但是我们的团队人手不足, 水平参差不齐, 很难推广这一整套学习成本高昂的方案. 最终我们开发了类Duboo的RPC框架doge, 代码主要参考了weibo开源的motan.

4. 领域驱动设计


4.jpg

在这一架构中我们尝试从应用服务中抽离出数据服务层, 每一个数据服务包含一个或多个界限上下文, 界限上下文类只有一个聚合根来暴露出RPC调用的方法. 数据服务不依赖于应用服务, 应用服务可以依赖多个数据服务. 有了数据服务层, 应用就解耦了相互之间的依赖, 高层服务只依赖于底层服务.

在我离职时领域驱动设计还在学习设计阶段, 还没有落地, 但是我相信前公司的后端架构一定会往这个方向继续演进.

总结
架构的设计, 技术的选型, 不能完全按照流行的技术走, 最终还是服务于产品, 服务于客户的需求. 设计过程中由于团队, 人员的结构问题, 有很多的妥协之处, 如何在妥协中找到最优解才是最大的挑战.

Service Mesh这种新一代的微服务架构正在成为主流, 虽然现在的工作与微服务无关了, 但是也还会继续关注学习.

CTO 要我把这份 MySQL 规范贴在工位上!

因为工作岗位的原因,负责制定了关于后端组数据库的规约规范,作为所有产品线的规范,历经几版的修改,最终形成下边的文本。

规范在整个后端执行也有大半年的时间,对于整个团队在开发阶段就减少不恰当的建表语句、错误 SQL、错误的索引有积极的意义,故分享出来给大家参考。

下边分为建表规约、SQL 规约、索引规约三个部分,每部分的每一条都有强制、建议两个级别,大家在参考时,根据自己公司的情况来权衡。


建表规约

【强制】: ① 存储引擎必须使用 InnoDB

解读: InnoDB 支持事物、行级锁、并发性能更好,CPU 及内存缓存页优化使得资源利用率更高。

【强制】:②每张表必须设置一个主键 ID,且这个主键 ID 使用自增主键(在满足需要的情况下尽量短),除非在分库分表环境下

解读: 由于 InnoDB 组织数据的方式决定了需要有一个主键,而且若是这个主键 ID 是单调递增的可以有效提高插入的性能,避免过多的页分裂、减少表碎片提高空间的使用率。

而在分库分表环境下,则需要统一来分配各个表中的主键值,从而避免整个逻辑表中主键重复。

【强制】:③必须使用 utf8mb4 字符集

解读: 在 MySQL 中的 UTF-8 并非“真正的 UTF-8”,而 utf8mb4”才是真正的“UTF-8”。

【强制】:④数据库表、表字段必须加入中文注释

解读: 大家都别懒。

【强制】:⑤库名、表名、字段名均小写,下划线风格,不超过 32 个字符,必须见名知意,禁止拼音英文混用

解读:约定。

【强制】:⑥单表列数目必须小于 30,若超过则应该考虑将表拆分

解读: 单表列数太多使得 MySQL 服务器处理 InnoDB 返回数据之间的映射成本太高。

【强制】:⑦禁止使用外键,如果有外键完整性约束,需要应用程序控制

解读: 外键会导致表与表之间耦合,UPDATE 与 DELETE 操作都会涉及相关联的表,十分影响 SQL 的性能,甚至会造成死锁。

【强制】:⑧必须把字段定义为 NOT NULL 并且提供默认值

解读:

NULL 的列使索引/索引统计/值比较都更加复杂,对 MySQL 来说更难优化。
NULL 这种类型 MySQL 内部需要进行特殊处理,增加数据库处理记录的复杂性;同等条件下,表中有较多空字段的时候,数据库的处理性能会降低很多。
NULL 值需要更多的存储空,无论是表还是索引中每行中的 NULL 的列都需要额外的空间来标识。

【强制】:⑨禁用保留字,如 DESC、RANGE、MARCH 等

解读: 请参考 MySQL 官方保留字。

【强制】:⑩如果存储的字符串长度几乎相等,使用 CHAR 定长字符串类型

解读:能够减少空间碎片,节省存储空间。

【建议】: ⑪ 在一些场景下,考虑使用 TIMESTAMP 代替 DATETIME

解读:

这两种类型的都能表达"yyyy-MM-dd HH:mm:ss"格式的时间,TIMESTAMP 只需要占用 4 个字节的长度,可以存储的范围为(1970-2038)年,在各个时区,所展示的时间是不一样的。
而 DATETIME 类型占用 8 个字节,对时区不敏感,可以存储的范围为(1001-9999)年。

【建议】:⑫当心自动生成的 Schema,建议所有的 Schema 手动编写

解读: 对于一些数据库客户端不要太过信任。


SQL 规约

【建议】:①为了充分利用缓存,不允许使用自定义函数、存储函数、用户变量

解读:如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL 库中的系统表,其查询结果都不会被缓存。

比如函数 NOW() 或者 CURRENT_DATE() 会因为不同的查询时间,返回不同的查询结果。

【强制】:②在查询中指定所需的列,而不是直接使用“ *”返回所有的列

解读:

读取不需要的列会增加 CPU、IO、NET 消耗。
不能有效的利用覆盖索引。

【强制】:③不允许使用属性隐式转换

解读: 假设我们在手机号列上添加了索引,然后执行下面的 SQL 会发生什么?

explain SELECT user_name FROM parent WHERE phone=13812345678;很明显就是索引不生效,会全表扫描。

【建议】:④在 WHERE 条件的属性上使用函数或者表达式

解读: MySQL 无法自动解析这种表达式,无法使用到索引。

【强制】: ⑤禁止使用外键与级联,一切外键概念必须在应用层解决

解读: 外键与级联更新适用于单机低并发,不适合分布式、高并发集群;级联更新是强阻塞,存在数据库更新风暴的风险;外键影响数据库的插入速度。

【建议】:⑥应尽量避免在 WHERE 子句中使用 or 作为连接条件

解读: 根据情况可以选择使用 UNION ALL 来代替 OR。

【强制】:⑦不允许使用 % 开头的模糊查询

解读: 根据索引的最左前缀原理,%开头的模糊查询无法使用索引,可以使用 ES 来做检索。

索引规约

【建议】:①避免在更新比较频繁、区分度不高的列上单独建立索引

解读: 区分度不高的列单独创建索引的优化效果很小,但是较为频繁的更新则会让索引的维护成本更高。

【强制】:②JOIN 的表不允许超过五个。需要 JOIN 的字段,数据类型必须绝对一致; 多表关联查询时,保证被关联的字段需要有索引

解读: 太多表的 JOIN 会让 MySQL 的优化器更难权衡出一个“最佳”的执行计划(可能性为表数量的阶乘),同时要注意关联字段的类型、长度、字符编码等等是否一致。

【强制】:③在一个联合索引中,若第一列索引区分度等于 1,那么则不需要建立联合索引

解读: 索引通过第一列就能够完全定位的数据,所以联合索引的后边部分是不需要的。

【强制】:④建立联合索引时,必须将区分度更高的字段放在左边

解读: 区分度更高的列放在左边,能够在一开始就有效的过滤掉无用数据。提高索引的效率,相应我们在 Mapper 中编写 SQL 的 WHERE 条件中有多个条件时,需要先看看当前表是否有现成的联合索引直接使用,注意各个条件的顺序尽量和索引的顺序一致。

【建议】:⑤利用覆盖索引来进行查询操作,避免回表

解读: 覆盖查询即是查询只需要通过索引即可拿到所需 DATA,而不再需要再次回表查询,所以效率相对很高。

我们在使用 EXPLAIN 的结果,extra 列会出现:"using index"。这里也要强调一下不要使用“SELECT * ”,否则几乎不可能使用到覆盖索引。

【建议】:⑥在较长 VARCHAR 字段,例如 VARCHAR(100) 上建立索引时,应指定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度即可

解读: 索引的长度与区分度是一对矛盾体,一般对字符串类型数据,若长度为 20 的索引,区分度会高达 90% 以上,则可以考虑创建长度例为 20 的索引,而非全字段索引。

例如可以使用 SELECT COUNT(DISTINCT LEFT(lesson_code, 20))/COUNT(*) FROM lesson;来确定 lesson_code 字段字符长度为 20 时文本区分度。

【建议】:⑦如果有 ORDER BY 的场景,请注意利用索引的有序性

ORDER BY 最后的字段是联合索引的一部分,并且放在索引组合顺序的最后,避免出现 file_sort 的情况,影响查询性能。

解读:

假设有查询条件为 WHERE a=? and b=? ORDER BY c;存在索引:a_b_c,则此时可以利用索引排序。
反例:在查询条件中包含了范围查询,那么索引有序性无法利用,如:WHERE a>10 ORDER BY b;索引 a_b 无法排序。

【建议】:⑧在 Where 中索引的列不能某个表达式的一部分,也不能是函数的参数

解读: 即是某列上已经添加了索引,但是若此列成为表达式的一部分、或者是函数的参数,MySQL 无法将此列单独解析出来,索引也不会生效。

【建议】:⑨我们在 Where 条件中使用范围查询时,索引最多用于一个范围条件,超过一个则后边的不走索引

解读: MySQL 能够使用多个范围条件里边的最左边的第一个范围查询,但是后边的范围查询则无法使用。

【建议】:⑩在多个表进行外连接时,表之间的关联字段类型必须完全一致

解读: 当两个表进行 Join 时,字段类型若没有完全一致,则加索引也不会生效,这里的完全一致包括但不限于字段类型、字段长度、字符集、Collection 等等。

基于Thinkphp 系统合集 后续慢慢添加

FastAdmin 是一个基于ThinkPHP5和Bootstrap的极速后台开发框架。一键生成CRUD/一键生成菜单/一键生成API文档,完善的Auth权限控制管理,响应式布局和丰富的应用市场。

ThinkCMF5 一款基于ThinkPHP5和bootstrap3开发的中文内容管理框架。具有灵活的应用机制,框架自身提供基础的管理功能,而开发者可以根据自身的需求以应用的形式进行扩展。

VueThink 是一套基于Vue全家桶(Vue2.x + Vue-router2.x + Vuex)+ Thinkphp5 的前后端分离框架。 脚手架构建也可以通过vue官方的 vue-cli 脚手架工具构建,不仅适用于管理后台或管理系统开发,且广泛适用于 B/S 架构的项目开发,已有许多的商业项目实践。

OneBase 是一个基于ThinkPHP5的免费开源,快速简单,面向对象的应用研发架构,是为了快速研发应用而诞生。遵循Apache2开源许可协议发布。

ApiAdmin 是一个面向API的后台管理系统,前后端完全分离,前端采用Vue构建,后端采用ThinkPHP v5.0.19,支持接口文档自动生成、接口输入参数自动检查、接口输出参数数据类型自动规整、灵活的参数规则设定、支持三方Api无缝融合、本地二次开发友好。

RhaPHP 是一个基于ThinkPHP5.1开发的微信平台管理系统,支持多公众号管理,小程序开发,APP接口开发、几乎集合微信功能,简洁、快速上手、快速开发微信各种各样应用。

EacooPHP 是基于ThinkPHP5开发的一套轻量级WEB产品开发框架,追求高效,简单,灵活。 具有灵活的应用和插件机制,模块式开发,大大降低开发成本。

VaeThink 基于 Thinkphp 和 Layui 的轻量级php内容管理框架。对一般项目所必需的功能进行了基础开发和封装,帮助开发者在开始一个新的PHP项目时能够快速完成基础功能的搭建。vaeThink保留了ThinkPHP和Layui的所有特征,对于熟悉TP5和Layui的开发者尤为方便。

OpenCenter 是一款开源的用户及后台管理系统,具有开发速度快,开发成本低的优势。遵循Apache2开源协议,允许开发者二次开发之后以全新的产品形式再分发。最新3.0版本基于ThinkPHP5.1和LayUI进行了重构。

HisiPHP ★★★ 基于ThinkPHP +Layui 开发的一套开源后台管理框架,默认集成了权限管理、模块管理、插件管理、钩子管理、数据库管理、富文本编辑器(已集成ueditor,kindeditor,ckeditor,umeditor)后台多主题切换,框架布局等常用功能,以方便开发者快速构建自己的应用(已经支持ThinkPHP5.1)。

WeiPHP5.0 是基于ThinkPHP5.1开发的一个开源,高效,简洁的移动应用系统,它实现一个后台同时管理和运营多个客户端(公众号,微信小程序,后续将支持支付宝小程序,百度小程序等)。一套环境,同时解决公众号和小程序。

DophinPHP(海豚PHP)是一个基于ThinkPHP5.0.23开发的一套开源PHP快速开发框架,秉承极简、极速、极致的开发理念,为开发集成了基于数据-角色的权限管理机制,集成多种灵活快速构建工具,可方便快速扩展的模块、插件、钩子、数据包。统一了模块、插件、钩子、数据包之间的版本和依赖关系,进一步降低了代码和数据的冗余,以方便开发者快速构建自己的应用。

Vue-Admin 基于Vue-cli3.0 + Element UI + ThinkPHP5.1 + RBAC权限 + 响应式的后台管理系统。

https://www.itjiale.com/article-131.html

★ ☆ ✰ ✩ ✪ ✫ ✬ ✭ ✮ ✡

一页纸手把手教你怎么做敏捷项目管理

文章来源于聂子云 ,作者聂子


敏捷项目是为应对变化和不确定性而生,作为项目的管理者(PM或者承担项目管理职责的人),在管理的过程中,需要明确项目的目标,带领团队,选择合适的实践,管理干系人的期望,协调和客户的关系,最终以专业的方式交付客户满意的结果。
简单来讲,需要关注四个维度的工作内容,也称为项目管理的 4P 领域。
1.png
People(人):包括客户、团队和自己,工作目标是灵活的调整和切换自己的角色,来协调这三者的关系,发挥1+1+1>3 的作用;
Purpose(目的):项目管理的目标是什么,以什么目的为出发点去进行项目管理;
Practice(实践):选择哪些合适的实践活动来帮助完成上述目标;
Professionalism(专业):做好干系人管理,专业的完成项目交付。

01 People (人) 的管理领域

包括客户、团队和自己,项目经理在这个领域需要灵活的调整和切换自己的角色,通过协调这三者的关系,带领所有人完成项目目标,这个领域的工作内容,可以通过面向团队/个体,是推的方式还是拉的方式将PM的角色分为四种:
2.png
第一个角色是Leader(带头人,领导者),作为Leader,PM 需要拉着团队一起做计划,完成项目交付目标,影响客户,过程中识别、控制并管理交付风险,管理客户关系和客户期望,加强团队的凝聚力,激励团队发挥高效能。
第二个角色是Facilitator(引导者,促进者),作为Facilitator,PM需要组织会议,跟踪行动,推动团队完成会议的行动事项,需要引导讨论,保证讨论和沟通的效率和良性产出,还需要推动并激励团队分享,在团队内部营造一种学习成长的氛围。
第三个角色是Supervisor(指导和督导者),作为Supervisor,PM需要对个体的行为进行监督和指导,提供反馈,帮助个体提升和成长;需要建立机制强化每个个体的正向行为,总结经验反思教训;还需要和相关的角色(比如TL,BA,QA)合作对流程、质量、目标进行管控。
第四个角色是Mentor(导师),作为Mentor,对团队成员要有细致的观察和了解,激励和培养团队成员;帮助团队成员突破局限获得成长;也要认识到个体差异性,基于差异分配任务设置挑战,指导并提供支持。

02 Purpose (目的) 的管理领域

在这个工作领域,PM 需要分析实施当下项目的目标是什么,不是所有的项目都是为了满足同样的目标,也就是说,项目管理是特定目标导向的。
3.png
内环是项目管理要考虑的一些约束,实际项目管理中,PM需要基于现实场景对这些约束下的目标做优先级排序,外环是实施项目可能会带来的整体价值,有时项目真正的价值是外环中的某个目标。
比如,领域经验,有时候我们会遇到一些未涉足领域的项目,这个领域可能是业务长期发展所要拓展的领域,那么组织有可能为了取得这个领域的经验而放低财务目标和成本控制,而投资这样一个项目;
又比如,有时候我们遇到的项目可能会提供很好的机会来培养团队的能力,那我们可能会在团队成长和按时交付上面找到一个平衡点。
总之,上述都是项目管理的目标,PM要做的是对这些目标做优先级排序。

03 Practice (实践) 的管理领域

这个领域有成熟的实践可借用,PM 需要做的是根据项目的实际情况选择合适的实践活动。
4.png
推荐每个PM 都了解一下Scrum 项目管理的 3355 核心要点。

3个核心角色

Scrum Master(敏捷教练):对应敏捷团队的PM(项目经理),职责是促进团队的工作,帮助团队熟悉与掌握 敏捷的价值观与框架,帮助团队排除影响生产力的障碍,保护团队不受打扰。
Product Owner(产品负责人):对应敏捷团队的BA(需求分析师),职责是定义需求,定义需求的优先级,定义需求的验收标准,定义产品发布内容与日期。

Scrum Team(敏捷团队):通常来讲是敏捷的全功能团队,对交付负责,协作开发,可能跨职能部门,自组织式的扁平化团队。

3个工件

产品待办事项 (Product Backlog):即产品视角的需求清单,由 Product Owner 负责维护,包括增删及优先级,用户故事是其中一种最佳实践,每项需求都需要描述其外部价值。
迭代待办事项 (Sprint/Iteration Backlog):即此次迭代周期内规划要完成的内容,由团队评估和选择产品待办事项中中哪些放入迭代待办事项,团队需要一起定义“完成”的标准。
迭代产出成果(也叫迭代可交付产品增量 ,Increment):即迭代结束后可对外发布的产品功能增量部分,需要关注其是可工作的软件功能增量,需要在成果展示会议(showcase) 上进行演示。

5个关键事件

迭代 (Sprint/Iteration):1-4周,固定周期,固定时间开始,固定时间结束。
迭代规划会 (Sprint/Iteration Planning Meeting):核心议题是下一个迭代要实现的目标和范围,对产品待办事项中的事项进行估算,以作为是否放入下个迭代的参考,输入是产品待办事项 ,输出是迭代待办事项。
每日站会 (Daily Standup):站会的目标是促进信息在团队内共享与透明,回答3个问题:本次会议之前,我做了哪些事情?本次会议之后,我准备做什么事情?目前我是否碰到障碍,是否需要帮助?
成果展示会议 (Review/Showcase):在迭代结束开,展示本迭代的产出,团队全体参与,邀请相关干系人参与提供反馈。
回顾会 ( Retrospective):团队一起复盘本迭代的过程,总结经验与教训,并形成切实可行的改进清单。

5大价值观

承诺 Commitment - 愿意对目标做出承诺;

专注 Focus – 全身心都用到承诺的工作上去;

开放 Openness – 团队内所有信息对所有人开放;

尊重 Respect – 每个人都有他独特的价值和经验;

勇气 Courage – 勇于承诺,履行承诺,敢于说不。

04 Professionalism(专业) 的管理领域

这个领域主要指的是如何通过管理干系人,为客户提供专业的服务。
首先,需要做的是对干系人进行分类,干系人分类的方法有很多,下面介绍的这种是基于干系人的权利和对项目的赞同程度来分的:
5.png
针对每一类型的干系人,进行区别管理:

  1. 对于位高权重且立场坚定的干系人,需要做的是建立同盟,邀请决策;
  2. 对于位高权重但容易动摇的干系人,需要做的是管理争议,帮助其坚定信心;
  3. 对于权利较低,左右摇摆的干系人,需要做的频繁沟通,尽量争取;
  4. 对于权利较低,死心塌地的干系人,需要做的是并肩作战,打听情报。

其次,需要在深度了解客户的基础上,通过自己的专业经验和服务态度引领客户做出最优的决策,并且帮助客户落地解决问题。
深度了解客户是提供专业服务的第一步,PM 需要带领团队了解客户业务、行业信息、竞争对手信息等等,切实站在客户的角度思考客户的痛点和诉求。
引领客户是在对客户业务了解的基础上,结合我们的能力和所能提供的服务,在客户的诉求和我们的服务之间建立联系,影响并带领客户去思考解决问题的思路和方向,优化决策的过程和结果。
践行我们的方案,帮助客户落地解决问题,也就是项目实施的过程,利用我们的最佳实践和能力,帮助客户把想法变成结果,做到价值交付。

总结

敏捷项目管理既是一门科学,又是一门艺术,它有规范严谨的理论体系,也有广阔的空间和自由度由管理者基于经验来发挥。真正做好敏捷项目管理,需要管理者在以上维度的基础上做更多深入的思考和总结,希望通过这个简单的总结,和大家共同探讨,一起在这条道路上精进。

/* * @Author: your name * @Date: 2016-09-06 00:00:00 * @LastEditTime: 2020-03-17 18:29:35 * @LastEditors: Please set LastEditors * @Description: In User Settings Edit * @FilePath: \htdocs\usr\themes\default\footer.php */