Let’s Scrum!
为期五天的流程培训结束了。把它说做是流程培训确实有些不准备，准确来说，它的全称叫做“卓越软件工程培训”（Engineering Excellence Training），整个过程除了一些“讲授”的过程，更多的是让我们自己实践——在实践中碰壁，在实践中成长。这个培训的本质目的是为了让新员工熟悉微软的工作流程、各种工具和各种角色的职责，其中我们最常说的就是：Let’s Scrum!
Scrum是一种敏捷开发方法，具体的细节我就不说了，网上随便都可以搜索到。Scrum的本意是“橄榄球中的并列争球”，引申到这个开发方法之中就是：思维碰撞与迅速交流。
Scrum中最有特色的是“净室”（Clear Room）理论，提倡在有限的资源之中获取可用的结果。举一个很形象的例子，假如计划在一段时间内榨取一定量的橙汁，那么Scrum就会要求在这一段时间内一定要得到橙汁，无论是多是少都无所谓，但一定要得到的是橙汁而不是榨到一半的橙子。这也就是说，在Scrum里面，延期交付是不应该有的，加班也是不应该发生的，如果实在快要完不成任务了，应该去删减不必要的需求，而不是拖延交付时间。通过这样的开发模式，整个软件都能在一个可观测的进度中进行，每过一段时间都可以拿到一个功能并没有完全实现、但主要功能已达成并且经过完整测试的版本。
Scrum中还有名为Scrum会议的一种每日例会形式。这种会议其实对我来说并不陌生，因为我曾经就在团队中宣传过每日会议，每日会议的五个问题（本来只有三个，我根据《敏捷迭代开发——管理者指南》这本书的建议，又加上了两个问题）早就在Dian团队的各个实验室贴满（除了东一以外），而且现在应该还找得到。微软的Scrum会议是原始的三个问题版本，包括“之前完成的任务”、“将要进行的任务”和“有没有阻碍目标的事宜”，这是最经典的问题模式。关于每日会议，可以看看我原来写的文章做一个回顾软件开发中的理想与现实（五）——知己知彼，百战不殆。
Scrum是一种典型的“个体软件工程”。在“个体软件工程”之中，开发者是以个体存在，并没有一个项目经理统管全局。不过确实有一个和开发者平级的Program Manager，他负责收集需求和驱动开发人员进行开发。所谓的“驱动”而不是“管理”，这意味着他并不干涉开发者的工作，也并不决定开发者的工作表，而是拿着自己手中的需求“求着”开发者来为自己干活，如果项目进度紧张，他还要主动地砍掉低优先级的需求以满足时间点要求，这样，他就必须用一种非常亲和的姿态与开发者进行沟通。同样，在测试那边，Program Manager的角色也是类似，也是一种驱动的方式进行管理。这种方式充分的保证开发、测试和Program Manager都能充分发挥自己的能力，让个体个性充分体现。同时，通过Scrum会议和其他各种方式（还有很多，Scrum还有很多东西我无法说出来），让项目还能按照既定的方向顺利进展。
当然，所有的敏捷软件开发都会要求用测试先行的方式开发，任何的形式上的模仿可能都会造成很大的副作用。个体软件工程本身往往并没有什么问题，但是对个体的素质要求却限制了它在低水平开发中应用，真是可惜呢。
希望大家都能练好编码和测试的基本功，然后大声疾呼：Let’s Scrum!
有话想说？请留下评论吧~~如果喜欢我的blog，欢迎订阅~~
评论
还没有任何评论。
留下评论