敏捷大会――会后反思

敏捷大会――会后反思

 

周日 12月18号的敏捷大会上，主要参加了敏捷实践分会场。

 

在听的时候，我一直在脑海中，一直试图把演讲老师的经验模式，往自己的团队上“套”。一直以来，在工作交付，需求来源方面，相应的质量方面，我们都有很多头疼的地方。引入了敏捷，公司的管理层，尤其是高层，肯定希望，能带来改变。但是，我们的原生环境到底带来了哪些束缚，听了分享后，多少有了些头绪。

 

我们所在的大组织的需求，大部分不是直接来自市场，也就是说，我们输出的模块，或者服务，最终在更高的层面上，被集成了。这很容易导致我们只见树木，不见森林。

我们的“客户”，或者说需求方，有自己的利益宿求，首先，他们有自己的开发任务，对于他们来说，第一要务是完成自己的工作，他们抛出的需求，有时候，自己也拿不准，这个时候，他们自己的策略，肯定是延迟决策了。

 

这也是在听的过程中，特别感受到的。可是就算搞清楚了小环境，也没什么用啊。得解决问题啊。还是3个大方面，“需求”（到底做啥），“沟通”（不只是上下沟通，还有左右沟通，有互相依赖咋办），“质量”（做出来的东西，客户不认可，就是白做了。）

 

先说下印象深的，就是听IBM的spootify的时候，她们提到（隐约是一个金融类的项目），人数，大概要上千人左右。她们，分了不同的层次，小分队－》。。。－》部落。不同的层次，由不同的影响力的人来协调。这么横向比下来，我们组，也就算是个最低层次的小分队。

 

但是不同的是，我们这样的结构里，每个小分队，貌似一个小麻雀，还5脏具全。这就带来一个问题，每个人之间的工作，经常有依赖，有人快，有人慢，模块大小也不可能切的很均匀，这该怎么办？

她们的一个技巧是dark  release，做好了就发布，但是，相关的还没做好，就设置个开关，对外先不可见。

我问了一个问题，这种依赖，最后谁来协调。演讲人提到，集成测试的时候，会发现很多问题，反向牵引相关的人改进，谁做的模块谁负责，最后由集成测试人员，来负责最终质量。

豁然开朗！

 

王明兰老师，曾经辅导过我们，这次，她带来了一些方法论上的新思想。促使我回顾下，我们这种Complex类型的工作（也就是不知道做下去之后，带来什么后果的），还是很适合kanban方法的。