内部了解不可省略
项目进行中对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关系有限。