惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
The Cloudflare Blog
J
Java Code Geeks
大猫的无限游戏
大猫的无限游戏
雷峰网
雷峰网
WordPress大学
WordPress大学
Jina AI
Jina AI
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
博客园 - 聂微东
有赞技术团队
有赞技术团队
V
Vulnerabilities – Threatpost
博客园 - 司徒正美
L
Lohrmann on Cybersecurity
P
Privacy International News Feed
S
SegmentFault 最新的问题
C
Cisco Blogs
V
V2EX
博客园 - 三生石上(FineUI控件)
Apple Machine Learning Research
Apple Machine Learning Research
I
Intezer
人人都是产品经理
人人都是产品经理
博客园_首页
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Cyberwarzone
Cyberwarzone
Know Your Adversary
Know Your Adversary
酷 壳 – CoolShell
酷 壳 – CoolShell
Security Latest
Security Latest
V
Visual Studio Blog
S
Schneier on Security
宝玉的分享
宝玉的分享
博客园 - 【当耐特】
腾讯CDC
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
博客园 - Franky
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
K
Kaspersky official blog
T
The Exploit Database - CXSecurity.com
G
GRAHAM CLULEY
量子位
S
Securelist
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
T
Tenable Blog
阮一峰的网络日志
阮一峰的网络日志
博客园 - 叶小钗
T
Troy Hunt's Blog

博客园 - 老翅寒暑

AI模型的回调能力的理解和实现 关于AI时代的程序架构的变化 关于需求规范和需求评审的一点看法 关于低代码和无代码---喧嚣背后的致命问题 为Jekyll静态网站添加PlantUML插件 企业要为现金流建模 关于通用框架的一些想法 XenServer 5.5 断电重启虚拟机磁盘丢失的修复 Fix catalyst driver in Ubuntu 13.04 / 13.10 Preserving Remote IP/Host while proxying 异步javascript的原理和实现 需求的最初形式:12306ng的需求小说 需求与设计过程(1)-用例 项目进度控制的技术 项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候 项目管理沙龙第十次聚会纪要-AOM项目的敏捷实践 项目管理沙龙第九次聚会纪要 项目管理沙龙第八次聚会纪要 项目管理沙龙第七次聚会纪要
项目管理沙龙第十二次会议纪要--为没有共识的项目组定制敏捷方法
老翅寒暑 · 2012-01-05 · via 博客园 - 老翅寒暑

项目管理沙龙第十二次会议纪要

本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法。这是一种普遍存在的情况,和其他的新事物一样,总会有一些人对“敏捷”这两个字比较敏感,究其原因,无外乎偏见、误解和不了解(无知),部分人则是恐惧或自大。当然,不了解是绝大多数人的原因。

但是,面对“没有共识”的人们,到底是说服之后再实施敏捷呢,还是先实施敏捷再用实际效果展示给他们?这是一个问题。我们倾向于后者,即先实施让人们看到效果。理由很简单,因为人与人之间的知识和经历的差异很大,要全部说服的时间成本太高,甚至于不可能,如果面对是一个有一定经验的人,要想说服他抛弃原先的经验来接受一个新事物,难度恐怕会更高。所以,“暗渡陈仓”或“偷梁换柱”地实施敏捷,是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字,那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。

之所以我们要探讨这种情况,因为我们坚信“敏捷不会把事情变得更糟”,既然敏捷肯定不会“砸场子”,肯定“效果>=现状”,所以“暗渡陈仓”就是有价值的,也是可行的一种推广方法。

我们的目标项目组情况是这样的:团队成员之间技术水平差异较大,但是工作热情高涨,气氛较好,而且项目组感觉“陷入泥潭”已经很久了,看着一堆难以维护的代码,大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧,不支持也不反对,但对敏捷始终保持着足够的距离,既不拒绝,也不欢迎,更不去深入了解。在管理方法上,项目组采用月计划和周计划相结合的管理方法,即每月定一个计划,本周的计划细化到可执行。但是可想而知,管理比较混乱,计划也经常不准确。

面对这样的项目现状,我们首先讨论的是实施策略:

1. 绝口不谈敏捷两个字,也不谈敏捷相关的什么术语,避免反弹。
2. 选取敏捷方法中最有价值的几个行为,改良项目组的管理现状。
3. 在达到效果,取得大家的认同之后,全面实施敏捷方法。

经过讨论,我们总结出的敏捷成功的要素有如下几个:

1. 管理上的PDCA循环。通过Plan-Do-Check-Adjust形成一个不断改进的循环。
2. 工作的可视化。通过将工作以可视的形式展示出来,让团队对进度有切身的感受。
3. 任务的定量化。所有的任务在阶段开始前就已经定好,一般不再改变。
4. 沟通。定期、按需沟通,保持信息流转的顺畅。信息包括:任务,进度,问题等。
5. 团队工作。团队的每个人都知道所有的事情,了解一致,当然就没有歧义。
 
事实上,敏捷的这几个要素纳入到任何一种管理方法中,这种方法也就立刻符合了“敏捷”的规范,因为“敏捷”本身就是一种“价值观”,在同一个价值观下,可以有N中不同的方法。“老酒”兑“新水”自然也是可以的。

讨论之后的具体实施方法如下:

1. 沿用原来的“月度计划”和“周计划”结合的管理方式。 用敏捷术语就是一个“迭代”长度为1月, 但是考虑到一个月时间太长, 不容易出效果, 所以在每个月的15日加入一个局部总结会议。 实际上把一个月分为上下两个半月,即2周一个迭代。这个也是目前公司敏捷经验中推荐的初期迭代长度。

   a) 每月月初开“每月例会”,内容就是规划本月的工作, 并且将工作细分为可分配的任务, 颗粒度粗一点没关系, 但是要保证一个月够用, 不需要中途再加。 例会上所有的工作都要进行讨论, 保证大家都对工作没有分歧, 其次要对每个工作进行评估,评估的单位采用传统的“工作日”。 只有所有工作都进行了评估, 才能评估任务的进度。

   b) 每月15日左右开“月中总结会”,负责总结一下上半月的工作情况, 讨论改进措施, 并根据进度,酌情调整下半月的任务进度安排。

   c) 每月月末召开“月度总结会”, 负责总结整月的工作情况,并讨论改进。 月末总结会议一般不要和月初的例会合在一起开。

2. 开始实行每日例会。会议上监控如下的几个问题:

   a) 每个人当天的工作状况是否都已经更新

   b) 对停滞超过2天的工作要询问原因,可考虑进一步细化和分解。

   c) 鼓励在例会上交流,慢慢形成交流的气氛。

3. 所有的工作和进度,在白板或者wiki上展示,统一管理。

   a) 初期的工作任务描述可以简单,但是要在计划和总结会议上形成口头共识,防止歧义。 在实施过程中逐步精细化,慢慢达到敏捷对Backlog的要求。

   b) 暂时不考虑使用敏捷工具,避免反弹。

 
在实施过程中,还有一些技巧需要酌情使用:

1. 任务评估由具体执行人给出评估时间,然后乘以相应的系数,作为实际的任务期限。

2. 某些需要形成共识的地方,可以故意引导对方出错,然后给出相应的正确方法。 比如代码难看难维护, 可以先采用“每周代码show”的方式, 逐渐形成集体对代码质量的重视, 达成共识之后,进而引入“代码评审”的方法。
 
接下来的沙龙时间里,我们会持续跟踪这个方法的实施效果。
 
考虑到目标项目是真实的项目,为了保证实施的隐蔽性,本次沙龙会议纪要仅在沙龙成员和特邀嘉宾内部发布,请勿外传!