看板与组织重组 1
2016-07-08 00:44
204 查看
看板与组织重组 （一）
今天，我想把最近一段时间，我所属的小组的变化情况回顾一下。在这个过程中，有不少的变化，并非如大家设想的那样。
先描述一下涉及到的组织吧。
A部分：没有经历过敏捷开发
B部分：经历过敏捷方法，可以归于SCRUM
C部分：没有经历过，陆续加入
组织是变化的，也会经历新生、成长、变化、解散的过程。现代的公司中，完全新成立一个部门的机会不是很多，更多的变化形式是重组。
也说说，重组的原因啊，这个和组织的变化，有直接的关系。说的直白点，就是成绩，也就是KPI完成的情况。记得有次听一个讲座，说到，开会的时候，业绩不好的，就只能坐在门口，有时候，可能连座位都没有。
回头，我们看看这三部分。很显然，有一部分，在新的一年里，没有“拉到”项目，这样一来，这部分人力，就必然会重新分配到人力不足的项目中。这也为以后各部分的发展埋下了伏笔。
我们可以想想一下，在各部分之间的互动过程中，各方有什么期待，以及会采取什么策略。
第一个大家能想到的，应该是需求的问题。这个好理解，客户至上啊，原来A部分已经和需求，建立了紧密的联系，他们最需要的是人力，而不是架构师或者需求分析人员。B部分，尤其B部分以前的负责人，更希望参与需求。
这样，很自然的，B部分希望A部分加入敏捷，更希望A部分加入到已有的敏捷过程中来。A部分，则希望按照原来的流程，继续下去。
这点，可以说明，敏捷有一个非常强大的作用：共享信息，加快沟通频度。
这个效应，来自每日站会。站会上，每个人，都对自己的工作，做出说明，也接受其他人提问。客户上起到了Review 和 Check 的作用。
这个时候，有人可能说，我只听，我不说，我只接受别人的信息。
随着敏捷过程的深入，大家会发现，影响力朝着信息频繁流动和互动的地方移动。也就是说，交流越深入的几个人，他们对彼此的工作更熟悉，也更能获得话语权。
在实际的运作过程中，这部分，耗费大量的时间和精力。各方，都需要调整，不能着急。博弈的结果，是互相融和，开展敏捷这一项，获得了大家的赞同，但是SCRUM方法，没有被采用，而是采用了看板方法。
第二个重要的问题，就是，谁主导项目的问题。在这点上，充满了“政治斗争”。无论是谁负责和客户沟通，谁做计划，谁制订文档，以及采用什么样的部件结构，都充满了博弈。
但是，这里要把握一个原则，那就是需求和客户。
就第二个问题，涉及到SCRUM 和 Kanban 更适合什么样的项目的问题。
后续再谈。
今天，我想把最近一段时间，我所属的小组的变化情况回顾一下。在这个过程中，有不少的变化，并非如大家设想的那样。
先描述一下涉及到的组织吧。
A部分：没有经历过敏捷开发
B部分：经历过敏捷方法，可以归于SCRUM
C部分：没有经历过，陆续加入
组织是变化的，也会经历新生、成长、变化、解散的过程。现代的公司中，完全新成立一个部门的机会不是很多，更多的变化形式是重组。
也说说，重组的原因啊，这个和组织的变化，有直接的关系。说的直白点，就是成绩，也就是KPI完成的情况。记得有次听一个讲座，说到，开会的时候，业绩不好的，就只能坐在门口，有时候，可能连座位都没有。
回头，我们看看这三部分。很显然，有一部分，在新的一年里，没有“拉到”项目，这样一来，这部分人力，就必然会重新分配到人力不足的项目中。这也为以后各部分的发展埋下了伏笔。
我们可以想想一下，在各部分之间的互动过程中，各方有什么期待，以及会采取什么策略。
第一个大家能想到的，应该是需求的问题。这个好理解，客户至上啊，原来A部分已经和需求，建立了紧密的联系，他们最需要的是人力，而不是架构师或者需求分析人员。B部分，尤其B部分以前的负责人，更希望参与需求。
这样，很自然的，B部分希望A部分加入敏捷，更希望A部分加入到已有的敏捷过程中来。A部分，则希望按照原来的流程，继续下去。
这点，可以说明，敏捷有一个非常强大的作用：共享信息，加快沟通频度。
这个效应，来自每日站会。站会上，每个人，都对自己的工作，做出说明，也接受其他人提问。客户上起到了Review 和 Check 的作用。
这个时候，有人可能说，我只听，我不说，我只接受别人的信息。
随着敏捷过程的深入，大家会发现，影响力朝着信息频繁流动和互动的地方移动。也就是说，交流越深入的几个人，他们对彼此的工作更熟悉，也更能获得话语权。
在实际的运作过程中，这部分，耗费大量的时间和精力。各方，都需要调整，不能着急。博弈的结果，是互相融和，开展敏捷这一项，获得了大家的赞同，但是SCRUM方法，没有被采用，而是采用了看板方法。
第二个重要的问题，就是，谁主导项目的问题。在这点上，充满了“政治斗争”。无论是谁负责和客户沟通，谁做计划，谁制订文档，以及采用什么样的部件结构，都充满了博弈。
但是，这里要把握一个原则，那就是需求和客户。
就第二个问题，涉及到SCRUM 和 Kanban 更适合什么样的项目的问题。
后续再谈。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 华为的IPD流程
- 重构之重与敏捷之轻---身份证号重构回顾
- 《高效程序员的45个习惯》读后感
- 不要只在字面上理解敏捷开发
- 《高效程序员的45个习惯：敏捷开发修炼之道》摘记一
- 敏捷一定就比不敏捷好么？
- Scrum框架-Scrum入门基础系列
- 敏捷估算--Scrum入门基础系列
- Scrum工件-Scrum入门基础系列
- 产品列表梳理（需求梳理）--Scrum入门基础系列
- 敏捷团队建设，非常精彩，欢迎下载参考
- 敏捷自动化测试(1) —— 我们的测试为什么不够敏捷？
- 敏捷自动化测试（2）——像用户使用软件一样享受自动化测试
- 敏捷自动化测试（3）——让断言不再成为自动化测试的负担
- runescape游戏介绍
- 倡议:终身的开源项目!
- 二次开发之我见
- 软件设计原则
- 敏捷软件开发模型--SCRUM
- Taiga 敏捷项目管理工具