构建之法——Team & Scrum & MSF

    第五章(团队和流程)83-99 

这一章主要介绍的是团队精神

那是不是说只要能组合在一起的就是组成了一个团队了?其实不然,软件团队有各种形式,适用于不同的人员和需求。适合自己的团队才能共赢!

一个好的团队流程能把冲突的积极方面(各自尽力把自己的工作做好,说服别人)释放出来,而避免消极方面(因为冲突而产生的消极、抵触情绪等)。我们不能因为说有了团队的队友就放松对自己的要求,因为每一个人的工作质量会直接影响到最终软件的质量,当所有的个人高质量工作加起来才可以达到一个优秀的团队高质量工作项目。

软件团队的模式有好多种:主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队模式、特工团队模式、交响乐团模式、爵士乐模式、功能团队模式和官僚模式。每一个团队不能够冲着利益最高的而自创模式或乱串模式,适合自己团队和项目要求的才是最重要的。那么怎样加强与别人的合作呢?在一个组织之中,很多时候,合作的成员不是我们能够选择得了的,所以很可能出现组内成员各方面能力参差不齐的情况,如果作为一个领导者,此时就需要很好的凝聚能力,能够把大多数组员各方面的特性凝聚起来,同时也要求领导者要有很好地与不同的人相处与沟通的能力。如果领导者在开始时没有以身作则做好各方面的工作,就会产生许多不良的后果。

所以,学会与他人合作,发挥团队精神在具体生活中的运用,可以使我们收到事半功倍的效果,可以使我们的工作更加良好地向前发展。

  • 第六章(敏捷流程)100-119

    “敏捷流程”是一系列价值观和方法论的集合,这个做法并得到了一些软件界的专家的肯定。

6.1.1 中有谈到敏捷的开发原则,其中有一条说“经常发布可用的软件,发布间隔可以从几周到几个月,能短则短”,那么,是不是可以把问题对应到我们平时电脑或手机上的软件更新?相信大家都会遇到这样的一个困惑,我们的电脑和手机时不时就会弹出一个框来提示我们要更新系统软件的版本,可是,版本更新得如此频繁,那些软件需要我们更新的软件,如果我们更新完了,这个软件就真的是焕然一新了吗?就会有更好的体验效果了吗?答案是不一的,因为作为使用者的我们,从实战可以得出,有时候一些软件的更新只是很微小,更新完后几乎发现不了有什么大改动,此时就会让有些用户觉得该公司是在“骗流量或者骗点击量”。这些都因人而异,因为有时有的软件更新真的可以使得用户使用更加方便或有更大的视觉冲击震撼。

敏捷的适用范围是有限的,敏捷对团队的要求很简单:自主管理(Self-managing)、自我管理(Self-organizing)、多功能型(Cross-functional),一般人不能马上做到这一点,它不是“银弹”,不能解决软件开发的所有问题,所以敏捷的方法不是万能的,它能帮助你更早地知道你是否能如期完成任务,如此而已,那到底什么时候才适合选择敏捷?这就要根据不同用户跟不同项目的实际需求而定了,因此我们不能过于依赖敏捷做法。

  • 第七章(MSF)120-140

    什么是MSF?它其实就是微软推荐的做软件的方法——微软解决框架方案(Microsoft Solution Framework,MSF)。

我很欣赏MSF的九条基本原则:推动信息共享与沟通;为共同的远景而工作;充分授权和信任;各司其职,对项目共同负责;交付增量的价值;保持敏捷,预期和适应变化;投资质量;学习所有的经验;与顾客合作。

MSF规划得如此合理,那么是不是就可以随意而安了?答案不言而喻,MSF在世界范围内由微软顾问咨询部及微软认证的培训中心提供培训,它在不断发展,它是一个框架结构,它不是一成不变的。相反,MSF会随我们从微软的客户和合作伙伴那里的学习而不断的发展和完善,新的思想和准则会不断地被引进MSF。这些发展将适应技术的更新、商业需求的变化,并支持构建更好的软件解决方案。

MSF注重团队模型,它展示了如何组织项目队伍,在时间控制和连续不断发展计划的要求下,有效的交付系统的解决方案。它描述了六种基本的角色(产品管理、项目管理、开发、发布管理、测试、用户体验)。在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目。任何一个角色都无法实现其目标,都将危机整个项目。因此,每个角色都被认为是同等的重要,重要的决定都要共同做出。

时间: 2024-10-22 12:56:29

构建之法——Team & Scrum & MSF的相关文章

《构建之法》学习(7)——MSF

<构建之法>学习(7)--MSF 1.MSF简史 微软解决方案框架,也就是微软推荐的软件开发方法 2.MSF基本原则 推动信息共享与沟通 所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到技术机密.安全性等信息要采取必要的把握措施. 使用Alert来提醒何事发生了变化:所有的信息都保留并公开,不能删除工作项. 为共同的远景而工作 这个目标必须是明确的,没有二义性. 这个目标不是当前就能达到,必须是通过努力才能达到的. 这个目标不是空泛的,它应该对项目成员每天

项目管理学习——《构建之法》读书笔记

最近终于有时间来读读书了.买了<构建之法>已经一年多了,这次静下心来读完了,收获很大.现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本,当时由于对于整个行业没有太大的感触,而这本书又全部由专业术语和定义组成,所以当时的课是相当痛苦.而老师通过的这门课程的方式又由各种理论知识考试为准,所以当时学习感觉相当“鸡肋”. 好的地方: 1,情景式.对话式对白,有趣易读.这点非常喜欢,很多实际中碰到的问题在这里可以重现.比如:每日构建,在实际开发中,就会由于各种原因导致不

《构建之法》—第6-7章

一.要求  阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-program.html Scrum实践

构建之法6-7章读后感

阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-program.html Scrum实践:<硝

构建之法现代软件工程(第五次)

构建之法现代软件工程(第五次) 这周我阅读了<构建之法>第六第七章 敏捷开发的原则: (1)尽早并持续地交付有价值的软件以满足顾客的需求: (2)敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势: (3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短: (4)业务人员和开发人员在项目开发过程中应该每天共同工作: (5)以有进取心的人为项目核心,充分支持信任他们: (6)无论团队内外,面对面的交流始终是最有效的沟通方式: (7)可用的软件是衡量项目进展的主要指标: (8)敏捷

构建之法阶段小记五

本周学习了构建之法的第6.7章,在先前两人结对编程和团队开发流程的基础上对于软件项目有了更进一步的了解. 第6章以许多浅显的描述介绍了敏捷流程的一系列理论及其原则,最重要的即 找出完成产品需要做的事情.决定当前的冲刺需要解决的事情.冲刺及每日例会和最终发布版本给用户并在此基础上进一步计划增量的新功能和改进.开发过程中成员与外界的交流及成员自身注意力的集中往往会产生一定矛盾,在开发时团队成员一般不能直接被外部人士打扰,因而产生了"Scrum Master"这样的一个角色来进行成员及外界的

构建之法第七章学习心得

这周我学习了构建之法第七章MSF的介绍.MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户.同样是强调效率,人性,灵活,还有前景. MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职.MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式.都是很人性,灵活,以及对自身有高要求的模式.结合上一章的敏捷流程和这次学习的MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法,个人还是比较喜欢.MSF的最大特性是商业化,并一直体现在项目的实施过程中.

构建之法学习回顾(二)

学习完构建之法五到八章之后,发现这本书更加贴近于当代,一般的软工教材为了追求更广更久的接受度,在内容上会趋于保守,而这本书不同,许多生硬的知识都得到了新的活力. 在第五章的学习中,主要讲了典型的软件团队模式和开发流程.以及我们也将讨论团队模式和开发效率之间的一些关系. 团队有一致的集体目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作.团队成员有各自的分工,互相依赖合作,共同完成任务.只有我们当做一个团队一样进行工作和学习才能取得更大的成就. 第六章的学习中讲了敏捷流程及其原则,Bac

《构建之法》读第六、第七章有感

<构建之法>读第六.第七章有感 第六章: 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,Scrum 采用迭代.增量的方法来优化可预见性并控制风险,并且SCRUM 是一个用于开发和维持复杂产品的框架. 敏捷开发的流程如下: 1.找出完成产品需要做的事情,每一项工作用天为单位计算. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺阶段各个团队相互独立,所有的问题都只能在