scrum---from a coder's perspective

内部了解不可省略

 

项目进行中对scrum有所使用，从程序员的思维来看，我觉得这个东西如果正确使用的话，尤其是在比较成熟的team里面是会对team有很大帮助的。

但是如果team不成熟，那么会把事情弄糟。

 

scrum比较像一种中间件（3DEngine，或者STL这种），它会把事情变得简单，同时也会隐藏很多细节。

直接带来的好处是显然的，manager们可以更加清楚的看到team的进度和灵活的讨论，就像使用stl的vector，string使得编程变得容易很多。

 

坏处则是manager们从jira上太容易看到进度这些东西了，反而会提供一种温床，让人倾向于无需探求内部情况。

这就像我们刚用stl的时候，可能滥用vector，更不会去reserve来提高效率，我们只是看到接口，但是没有去看内部实现。

 

结果是开发效率还可以，但是运行效率差得不行。

所以觉得合理的做法就是manager或者leader需要对于team的工作情况有详细的了解和理解，然后借助scrum来简化管理。

 

---

局部劣势

 

直接调用dx api画一个矩形，几行代码搞定。

但是在大型3d engine里，画一个矩形，要花费比较大的功夫。尤其是一个陌生的引擎，需要先查很多代码。

但是这显然不能证明我们不应该使用3d engine。

scrum的目的也是一样，是提高整个team的管理水平和生产力，而不是每一件事情的速度。

 

---

team成熟度

 

大型游戏开发过于复杂，这个不是麦当劳卖汉堡，一套流程和定量可以搞定，里面涉及艺术创作，软件开发，QC等等等等。

keep it as simple as possible, but not too simple.

 

团队实力是根本因素, 队员实力，大家配合程度。。。

scrum没法根本性的改变游戏开发的方式，这个只是一个工具而已。

在使用scrum的时候，扬长避短是team需要做的事情。

在之前的经验中看来，scrum倡导的方式的确和实际需求有所出入的时候，大胆改变是应该的。

 

这也是对于team实力的一个不错的考验。

 

友好通畅的沟通：在scrum本身和使用方式上大家有意见友好的讨论，对与错最后有个清晰的结论，最后统一遵守。这和打篮球比较像，教练的战术可能不够好，球员有想法可以在制定战术的时候讨论，但是一旦定下来了，就要好好执行，阳奉阴违，然后球场是自己搞自己的一套是最差的战术。

 

原先一些比较好的东西也可以融合进来，比如我比较喜欢原来的weekly meeting，小组做在一起，就一些问题做一些比较随意的讨论，可以是项目的想法，可以是看到的论文。

而且在一些阶段，stand meeting也可以省掉，大家都知道彼此在干吗，就没有必要走这个形式了。

 

---

最后个人观点，team成熟了，scrum好东西，team不行，用了不如不用。

而且适合的才是好东西。

team实力是关键因素，最后做出好游戏和用不用scrum关系有限。