<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet href='http://feeds.feedsky.com/styles/temp01.xsl' type='text/xsl' ?><!--这是一个由Feedsy提供技术支持的Feed，为了提高读者阅读的体验，以及满足用户美化自己Feed的需要，我们设计了多种精美的Feed模板，提供给大家选择，所有最终呈现出来的样式，皆由用户自愿选择使用，未经许可，任何团体和个人，请不要擅自修改样式或者盗用，这是对于用户选择权的尊重。--><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:fs="http://www.feedsky.com/namespace/feed" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"><channel><atom:link href="http://feeds.feedsky.com/csdn.net/sodme" type="application/rss+xml" rel="self"></atom:link><fs:self_link href="http://feeds.feedsky.com/csdn.net/sodme" type="application/rss+xml"></fs:self_link><lastBuildDate>Wed, 15 Apr 2009 22:50:00 GMT</lastBuildDate><title>大宝(sodme)的专栏</title><description>专注于网游服务器技术研发、团队及过程改进，关注网游产品设计、研发、市场与运营完整流程中的各个环节</description><link>http://blog.csdn.net/sodme/</link><item><title>我心中的敏捷(6)----SCRUM之如何规划每一天</title><link>http://blog.csdn.net/sodme/archive/2009/04/15/4078439.aspx</link><description>上一篇文章中，我谈到了SCRUM方式下对项目的逐层分解概念，而其实，我们的目的并不在于分解本身，我们的目的是在于加强对项目的控制力度，是想让一个比较大的项目，能按一个比较可控的进度进行研发。逐层分解后，落实在实实在在的研发中时，那就要看具体到每一天的工作来如何安排了。其实，有很多其它的开发方式有比SCRUM更好的项目分解方法，但为什么那些方式都很容易陷入进度不可控的泥潭呢？我想，其中一个很重要的原因就是，每一天的具体控制没有作好。OK，那就让我们一起来看看如何在SCRUM的开发方式下，作好每一天的工作。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4078439.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Thu, 16 Apr 2009 06:50:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/04/15/4078439.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>我心中的敏捷(5)----SCRUM之项目分解与控制力</title><link>http://blog.csdn.net/sodme/archive/2009/04/13/4070887.aspx</link><description>作传统软件时，可能你的用户只是一两家企业，你可以整天泡在你的用户那里，把各方面的需求了解得清清楚楚、明明白白、真真切切，但是，互联网的用户动辄千、万计，甚至百万、千万、亿计，你无法靠一个设计者的脑袋去考虑清楚这么多人的需求和喜好，你只能尽快提炼出他们需求中最重合的、“你自以为有用”的需求，而后尽快把想法实现出来，把可测版本推到用户面前，去验证你的设计，然后再尽快推出新的版本来满足你从用户那里得到的新有效需求。从某种意义上来说，这种开发模式下的软件形态，是一种周而复始、不断进化的过程，它甚至已经超越了我们以前所了解的传统的软件生命周期模型。蓦地，这让我想起了佛学里所说的轮回，是的，只要这种开发方式下出来的产品走上良性循环，它的存在形式本身就是一种轮回。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4070887.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Tue, 14 Apr 2009 05:35:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/04/13/4070887.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>我心中的敏捷(4)----多样的形式与不变的本质</title><link>http://blog.csdn.net/sodme/archive/2009/03/24/4021583.aspx</link><description>前面几篇文章中，都在不断重复着＂敏捷＂二字的真正内含，是的，如果要说起这些所谓的内含，应该没有人会反对，但是，如果把这个问题再引申一步：如何理解各种各样的敏捷开发形式与敏捷方法论之间的关系？如何把书本上总结的各种各样的敏捷理论用于我们的开发实践？这些问题，可能就不再是那么容易回答的了．在本篇文章中，将会阐述我对这些问题的理解以及我的实践解决之道．&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4021583.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Wed, 25 Mar 2009 06:14:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/03/24/4021583.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>我心中的敏捷(3)----两种世界观</title><link>http://blog.csdn.net/sodme/archive/2009/03/23/4018331.aspx</link><description>“实践、总结，再实践，再总结”，我的很多研发观念，都是在这样的过程中不断形成和改进的，而我之所以能坚持这样不断作下去，是因为我想把一件事不断的作得更好，一直逼近我自己想要的极致。而事实上，因为每位开发者所在的领域、所掌握的工具、所面对的客户都可能有所不同，采用不同的开发方式本身就是非常自然而然的。其实，我的这个系列文章，有一部分是在说研发，而更重要的一部分是在说我们应该以什么样的思想、什么样的态度，以及什么样的方法来作事，而无论“这件事”是研发，还是销售，是产品，还是公司，我想，很多的东西，都同样适用。经过前面一虚一实的两篇文章后，下面引出的这篇文章仍然偏向于“虚”，仍然偏向于方法论，至于对大家有没有用，要看大家思考的深度和探索的力度。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4018331.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Tue, 24 Mar 2009 04:49:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/03/23/4018331.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>我心中的敏捷(2)----我们的实践</title><link>http://blog.csdn.net/sodme/archive/2009/03/23/4015875.aspx</link><description>第一篇文章，说到了敏捷方法论和世界观的问题，看似有点玄了，其实，任何一个可以坚持下去的人或者任何一件可以坚持作下去的事，它的背后，都一定有一套自己的逻辑体系在支撑，而这个逻辑体系，就可以看作是它作事作人的方法论．敏捷二字, 其含义有两层: 高效率, 高质量. 其目的也绝不仅仅在于&quot;快&quot;研发, 它的终极目的, 是推动整个产品或者公司团队加速面向市场提供好产品的速度和质量. 在这一篇文章中，将会详细谈到我们自己的具体作法，当然，这已经是一年前的文章，很多作法可能已经因应现在的形势进行了改进，但基本的思想已暗含其中。你的作法可能与此不一样，但任何已经学会驾奴开发过程的同仁应该都会明白这些作法背后的含义。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4015875.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Mon, 23 Mar 2009 16:49:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/03/23/4015875.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>我心中的敏捷(1)----首先不应该是噱头</title><link>http://blog.csdn.net/sodme/archive/2009/03/20/4006404.aspx</link><description>这是继“作团队感悟”之后，转载自我网易博客的又一个系列文章，在这个系列文章里，主要记录和描述了我对于敏捷开发、敏捷团队以及敏捷公司的理解。我认为，敏捷和迭代，已经是一种世界观和方法论，而不仅仅是一种技术手段或者工具。融汇贯通敏捷和迭代的深层次思想，不仅仅能帮助我们提高研发水平和研发质量，更重要的，它可以更好的帮助一个团队或者一个公司走向成功。下面，引出第一篇文章内容。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/4006404.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Fri, 20 Mar 2009 17:03:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2009/03/20/4006404.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>作团队感悟(18)----如何引进开发方式</title><link>http://blog.csdn.net/sodme/archive/2008/09/27/2985742.aspx</link><description>这是一篇有关“如何引进开发方式”的作团队感悟，其核心思想是：每个团队，都会在技术水平、团队氛围、心理心态等方面有诸多不同，我们不能武断地以别人对一种开发方式的评价而冒然决定在不在自己的团队中使用。即使是要使用这些新概念，也要根据团队实际情况进行改良和再造，抓住新概念的本质精神，对具体方式进行简化和借鉴，以求更好促进当前的开发。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/2985742.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Sat, 27 Sep 2008 17:11:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2008/09/27/2985742.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>作团队感悟(17)----小结一下我的作团队感悟</title><link>http://blog.csdn.net/sodme/archive/2008/09/26/2980745.aspx</link><description>从第一篇文章到现在，我从多个方面总结了自己的作团队感受，其中很多内容是涉及到诸如心态、目标以及理念之类的东西，也穿插着介绍了如何把这些精神层次的东西注入到我们平时的实践中。我总结这些，有两个目的：一是首先对自己这几年来团队和项目的教训及经验予以梳理，让它变成一种可被记忆、追踪的东西；二是，想给业内诸多，可能与我们当初一样，还处于摸索期和困顿期的同业们以些许的启发，以助大家早日走上良性循环的发展之路。不管是哪种目的，其最终，我就是想让这种作事的方法、态度和理念可以被复制，要么被我们自己复制到其它的团队或项目，要么被其他的人来复制。我不能也不敢说，这些作事的方法和理念是多么多么的正确，多么多么的好，但如果你是从第一篇文章读过来，你应该可以明确感受到这些方法和理念背后所深深铭刻的东西，那就是：从不说套话，务实至上。也就是说，我写这些东西，不是想获取一时半会的文章点击率，而是以对项目和团队的实用价值为上，不实用的，在我自己这里，首先就过不去。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/2980745.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Fri, 26 Sep 2008 15:42:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2008/09/26/2980745.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>作团队感悟(16)----连长+政委，黑脸+红脸</title><link>http://blog.csdn.net/sodme/archive/2008/09/25/2975873.aspx</link><description>这是一篇有关“连长+政委，黑脸+红脸”的作团队感悟，其核心思想是：作为一个完整的团队，既需要关注业务，也需要关注思想；既需要关注业绩，也需要关注团队成长。但是，如果我们把这所有的责任都推到团队领导者一个人的身上，显然不合适，也不现实，因为，团队领导者也是一个普通人，其精力有限，其特长亦有限。所以，团队内部，需要有人在这些团队领导者顾及不到的地方进行有效协助，而这个协助，应该是自发的，不一定非要某个固定职位的人来作。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/2975873.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Thu, 25 Sep 2008 17:08:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2008/09/25/2975873.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item><item><title>作团队感悟(15)----培养危机感</title><link>http://blog.csdn.net/sodme/archive/2008/09/24/2971479.aspx</link><description>这是一篇有关“培养危机感”的作团队感悟，其核心思想是：团队的成长和成熟，很多情况下，依赖于团队成员自我要求的不断提高和改进，而之所以能够这样不断的“自我要求”，“危机感”在其中起了很大的作用。所谓“生于忧患，死于安乐”，只有当每个团队成员，都能明确知道我们与别人的差距，都能明确知道自己应该在哪方面努力，都能知道我们的团队和项目都有哪些危机，团队成员才会更有目标、争分夺秒地主动改进。所以，从这个意义上来说，“培养危机感”，其目的绝不仅仅是灌输一种压力，更深层次的，是想让整个团队不仅有目标，而且有动力。&lt;img src =&quot;http://blog.csdn.net/sodme/aggbug/2971479.aspx&quot; width = &quot;1&quot; height = &quot;1&quot; /&gt;</description><pubDate>Wed, 24 Sep 2008 17:09:00 +0800</pubDate><author>大宝(sodme)</author><guid isPermaLink="false">http://blog.csdn.net/sodme/archive/2008/09/24/2971479.aspx</guid><dc:creator>大宝(sodme)</dc:creator></item></channel></rss>