forked from buaase/Phylab-Web
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
dengchuyun
committed
Oct 20, 2016
1 parent
0a9c49e
commit e6cd77c
Showing
2 changed files
with
43 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# 概述 | ||
|
||
最近比较流行OKR,即目标与关键成果法,这是一种定义和跟踪目标及其完成情况的管理工具和方法。在执行上和GitHub的Issues比较相似,正好符合我们团队的管理方式,可以较好地进行实践。目前任务贡献核定遇到了两个问题: | ||
1. 优先级中包含了顺序因素:实际上优先级可以反映任务的轻重缓急,也就是任务的**难度**和**紧急度**,但是由于在优先级中加入了任务间的顺序因素,无法很好地反映以上两点。比如,`吃饭喝水`和`上厕所`在一天的生活中都是十分重要的,优先级应该基本一致,但是由于加入了顺序因素,`吃饭喝水`的优先级肯定是高于`上厕所`的。如果需要进行公平的贡献评定需要分割每个因素,也就是用不同指标标注任务的`难度`、`紧急度`、`预估时长`以及`关联任务执行顺序`,由于指标较多,制定每个任务的指标将变得异常麻烦。 | ||
2. 预计时长估计困难:由于对各个同学的个人实力不是很了解,而且很多情况无法指定量化详细的指标,每个人实际工作时长和预估时长差异较大,任务成果质量和预估时长的工作量不符合。并且有些人可能会刻意谎报任务时长,造成贡献评定中对时间的因素的核定无解。目前只能默认各个组员是在诚实的情况下反馈工作时长。 | ||
3. 任务评价中PM个人倾向影响较大:团队其它组员和PM没有上下级隶属关系,而大部分任务质量的评价就好像语文问答题一样,是一项相对开放的问题,其它组员对PM主观评价可能会出现较大的争议。但是暂时没有更好的客观评价方式,如果对每一个任务进行**选择题**般精确的指标指定是不可能的,一是PM对每个执行者的执行细节不是完全了解;二来这样做工程量巨大,需要花大量时间调研,极可能比任务的执行还要慢很多。 | ||
在参考[前序团队的团队贡献分配计划](http://www.cnblogs.com/buaase/p/4912980.html)后,以三个因素来评定团队贡献值,即`工作成果评分`、`实际工作时长`和`延期情况`,这样较为客观地从各个方面反映了每个阶段任务完成情况。 | ||
|
||
# 评定方式 | ||
|
||
## 计算公式 | ||
|
||
**Issue评分 = ((Issue个人评分×0.4+IssuePM评分×0.6)×0.7+(周个人实际工作时长/周团队实际工作时长)×0.3)×按时完成指数** | ||
|
||
**按时完成指数** | ||
|
||
| 任务优先级 | 未超时 | 超时1天 | 超时3天 | 超时3天及以上 | | ||
| --- | --- | --- | --- | --- | | ||
| priority5 | 1 | 0.85 | 0.65 | 0.5 | | ||
| priority4 | 1 | 0.88 | 0.75 | 0.6 | | ||
| priority3 | 1 | 0.90 | 0.78 | 0.65 | | ||
| priority2 | 1 | 0.92 | 0.82 | 0.6 | | ||
| priority1 | 1 | 0.95 | 0.87 | 0.75 | | ||
|
||
## 参数解读 | ||
|
||
1. Issue个人评分:对自己Issue完成结果的评分,范围为0~1。 | ||
2. IssuePM评分:PM对执行人Issue完成结果的评分,范围为0~1。 | ||
3. 周个人实际工作时长:每周为一个评分阶段,即这一周的个人工作总时长。 | ||
4. 周团队实际工作时长:每周为一个评分阶段,即这一周的团队工作总时长。 | ||
5. 按时完成指数:按时完成指数对照表如上,每个Issue的截止日期置于标签上。 | ||
|
||
## 总贡献计算 | ||
|
||
**每周结束**为Issue评分时刻,也就是说整个软工工作周期一共有8个评分时刻,每个人的Issue评分会进行累积。目前团队有5个人,也就是总共有250分的团队贡献总分,α和β阶段分别占125分,每个阶段的**贡献值=125×(个人Issue累积评分/团队Issue累积评分)**。最后将两个阶段的贡献值加合便是整个软工项目的团队贡献总值。 | ||
|
||
## Issue制定Tips | ||
|
||
* 发布频率:每3天制定发布一次团队Issue。 | ||
* 标签制定:目前Issue有3个任务标签,分别是`size`、`priority`和`deadline`。发布Issue后,如有异议,执行者在12小时之内对PM进行反馈,过时无效。 | ||
* 任务详情制定:任务详情是执行Issue的概述纲领,需要仔细阅读。发布Issue后,如有异议,执行者在12小时之内对PM进行反馈,过时无效。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters