Scrum，幸福来得挺突然

突然想到对于scrum中的一个重要角色：产品负责人，我们团队里还没有！！我们现在要做的软件又是根据老系统的经验和教训，开发新的框架，并做新的设计！这些设计和框架主要依据就是老系统的问题的解决！
多次查看楼主的回复，觉得风险越来越大！（我们公司的软件管理可以说是比较松散，没有章法的！没有多少经验积累！）
有形的无形的风险都不知道该怎么控制了！

楼主的意思，我大体理解！我的主要意思是，我的同事们对敏捷啊，模式啊，软件工程方面的知识的掌握都很参差不齐的！这是我很头疼的，我最近一两个月就是看敏捷和偶然看到你说的scrum的模式，而且我也经历过cmmi3的认证过程，对软件过程也略知一二！但是我的同事们在这方面还是有点欠缺！
我一直在考虑是否该使用敏捷（+scrum）开发方式，以及比较高一点的领域设计，我自己的经验不是很多，他们也要在这个过程里面学习，现在的问题就是：您是如何让你的团队了解这样一种理念（开发方式），如何共同提高专业技能，共同分享的学习成果？
因为我比较担心我们的新项目的实施过程变成了一次理论研究过程，这样出来的项目首先会影响项目进度，项目质量也会根据不同人的情况出现一些反差！
曾经看到书说一个研究型的团队（我不是说不要学，而是整个团队不要都专注于研究！）最好不要实施直接的开发！所以，现在我一直感到自己的压力比较大，在这个过程里，我要跟他们分享的东西太多，要教授的东西过多使得我想变成孙悟空了！！
望楼主不吝赐教，小弟不胜感激啊！！！

在考虑打算使用敏捷之前，你是否考虑好打算用敏捷来做哪些事情？做这些事情的目的有是什么？

我想一个项目的实施按照cmmi的流程来的话，主要就是需求、设计、编码、测试、验收，而我们现在最薄弱的环节都不明显，也就是说对于这样一个流程，我们都没有多少标准，尽管过了cmmi！

鉴于最近一段时间的学习，我想采用敏捷的方式重点突破需求管理（能主动跟客户进行沟通，不总是依赖瀑布式的理想方式），设计（大家共同参与，互相交流，不仅可以共享经验也可以共同提高，尤其是现在我们的设计处于很初级的阶段），编码和测试的话，我主要考虑了敏捷中的合作开发方式，尤其是对于我们现在系统极不稳定，bug层出不穷的情况，采用分阶段的配对编程、主动编写单元测试、代码严肃审查等方式进行！

这么多想法，这么多的域，真的有些力不从心，而且在这个过程中，还要对兄弟们进行培训，实在是想跟有经验的各位请教一下，尤其是看到了scrum这个东西，我至少可以规避一些项目实施的风险！
还是请各位多给小弟一点意见，在此借楼主这篇文章，我也在这里多多讨教一下！！

to taochenpfj:
    这两天正忙着一个项目，所以回复的有点迟，见谅。对你所处的团队的情况，我只能从你的帖子中了解一二，要提出针锋相对的建议不太现实，所以我还是陈述一点自己对软件开发管理方面的看法，希望能旁敲侧击地对你有所帮助。
    虽然做了挺长时间的项目/团队管理，我个人更感兴趣的还是纯技术的工作（我现在又回到了架构师的岗位）。我认为，决定一个软件项目的成功与否的因素大的方面就是两个：适合团队的工程方法和适合需求的架构设计。
    先说工程方法。我在那份PPT中提到过，拨开各类复杂问题和工程方法的迷雾，你要实现的目标无非就是“在尽可能短的时间内完成高质量的软件开发”，这里只有两个要求，开发进度和软件质量。软件管理者要管理的核心内容，PMP提到的九大管理内容，说到底也就是这两个而已。既然问题简化了，你就可以看为了保证和跟踪开发进度，你需要引入哪些实践，为了保证软件质量降低项目风险，你要引入哪些实践----这里保守的态度是应该鼓励的，不要一下子尝试太多新东西，如果你是用Scrum，在基本的3+3+3的基础上，每个sprint引入1-2个新实践就很多了，严格遵循plan-do-check-action的方法来引入实践。再强调一下这一段我想表达的意思，如果你找不到头绪，就分析一下你的基本目标，越基本越简单越好，然后选择一个基础的起点起步，让适合团队的工程方法随着团队一起成长。
    再说一下团队。如果给我一个团队来做项目，我对这个团队的成员的要求是：他们可以没有优秀的技术能力，可以不熟悉各种软件开发工程方法，只要他们具备后面列的这些素质就可以--开放，进取，包容，责任心。当然，这个团队中还必须有一位比较资深的分析设计人员（可以是管理者自己）。技术能力可以培养，工程方法只是药方，这些都可以学的。要学习，就要求团队成员必须开放，乐于沟通会沟通（跟闷葫芦合作是一件让人抓狂的事情）；成员要有点小理想，知道自己要什么，有追求有进取心，才有工作的动力；团队合作要能够容纳不同观点，能够接受别人的工作生活习惯（比如可以忍受坐在你对面那个家伙的臭脚）；团队成员需要信守承诺，交给的任务需要负起责任（说一百做五十的家伙要不得）。要让团队成员在某种尝试上达成一致，只需要把握住一个基本问题：大家放弃了在家睡大觉逛街陪家人的机会出来工作，为了什么？我觉得钱的原因是排第一二位的，然后呢，可能是精神层面的因素，比如成就感，跟人交流合作的快乐，而这些都或多或少跟一个因素挂钩----学习的愿望。人（好吧，正常人）天生就有学习的愿望，引入一种新的工程方法本身就是一次学习的机会，不论成功与否每个人都可以从中受益----这一点明确了团队就比较容易达成一致。
    最后说一下架构设计。适合的工程方法装备起来一支高效的团队，但是如果按照一张不合理的设计图纸，一样会盖出一座危楼。这里就是架构设计的重要性，它比工程方法更多地影响到软件质量。架构设计我认为没有什么外部方法可以帮上忙，每个团队拥有一个比较资深点的分析设计人员是必须的，他需要综合把握软件系统的功能和非功能性需求，设计一个健壮的有生命力的系统。这是一个另外的领域，这里不多讲。
   最后说一句，别担心失败，也别让自己还没上路就累垮，困难都是你走向高处的垫脚石，生活就是问题叠着问题，不抛弃不放弃，呵呵。

读君一席言胜读十年书啊！真的非常感谢您的回复！曾经我的一个同事跟我说过：不要觉得你的行业里没有高手，只是你还没到那个层次，就根本看不到高手！呵呵，我不是说自己已经到了“那个层次”了，只是我幸运地碰到了高手！

对于您的建议，我会谨记在心的，尤其是最后一句，之前我也有些内心的表露，就是一种担心，项目的规模和挑战都是我没经历的，尽管我也算是做了一两个项目，但是要实施新的项目管理方法，要设计新的项目架构，心里面总是有太多的不确定性，很担心失败！对于各种项目管理实践，在我们公司又受到管理层的介入，很多实施不能顺利进行，困难不是一般的多！不过如您所说，我不会放弃的，呵呵！毕竟都走了这么长时间，我没有多少放弃的理由，我组内的信任我的同事们也不会认可我放弃的理由的！

对于您的关注重点，我也是非常感兴趣的，也很想专注的研究软件架构，有机会考考研，呵呵，争取与高手为伍！！

再次感谢您百忙之中给我回复！

你好。请问敏捷开发轻文档，那么随着时间的推移项目中的人员必然发生变动，如果没有详细的文档指导，后加入的人员如何快速进入团队开发，如何理解前辈们的设计思想呢？

开发能否成功，在于各个角色是否明白各自应该担当的工作内容，目标要一致，我把项目的角色分为主担、辅担两类，业务开发是项目的主担，对项目负责，管理是辅担，由公司管理部门对项目的过程指标进行检查和提供帮助。两类角色都是非常必要的，只是要有侧重，尽管相互制衡，但是管理角色做的是辅助流程，不是关键路径，就是不要过早的让这些角色由“一票否决”的权力。
开发主担主要是业务分析、设计、开发和测试，实际上抓好两个关键要素就可以，一个是业务设计，一个是任务管理。任务管理的基础也是业务设计充分，不清楚不做，粒度要细，要让开发人员真正明白要做什么。之所以项目做不好，业务理解设计不充分占绝大多数，造成任务的分解做不下去，文档也写不好，一个项目业务的理解其实掌握在少数人手里面，不可能全部都清楚，是个逐步细化和知识转移的过程，这就要求每日的沟通，明白这一点，就知道怎么去做好项目，其它的都是技术手段。
至于管理控制环节，比如SCM、QA，则要尽量的让大家感觉不到他们的存在，他们只是按计划在关键节点时出现，并且随时提供支援。审核的发起由他们来做，结果的判定以业务满足和客户开发过程标准满足为主，在能力不足的情况下，不要让他们有影响项目进度的决策权，项目经理做方案，公司领导来决策。测试也直接纳入到项目经理的管理，对项目经理负责。
敏捷、Scrum等都是提供了一些很好的方法，不过做项目首先要明白做什么，这个问题解决了，方法就有用武之地。

至于团队合作这样的软性指标，更多是一种措辞，项目经理首先要做好定位，搞清楚哪些是自己该做的，哪些是公司该做的，你要做的就是用手上的资源把项目做好。
把业务需求理解清楚，把任务分解调度好，对客户、对上级做好沟通，减少对项目组的干扰，按时把工作做好，最终的目标是按时能拿到奖金。
目标单一，其它的都是手段，方法的引进只是为了解决最关键的问题，一次能做好一个就是成功。

看来看去，团队本身才是最重要的，以前CharlesXP 的XP介绍 我也认为XP团队需要好的人才，未必是技术牛人，善于沟通、进取、发现问题、改进问题的人，由这样一群人组成的团队+一个高瞻远瞩的团队领导，用scrum中那些实践是自然而然的事情。

scrum对于这样的团队或许只是一面大旗，将他们本身有的优点都发挥出来了

现在我们的问题是没有这么一群人，公司wiki简直成了自留地，技术培训也沦为形式，上层也没有这套人员素质要求和过程改进的想法。