团队之阅读感想

Scrum团队

团队名称:雨中狂飙

团队目标:在走的基础上学会奔跑,队员个人能力提升,学会团队精神

团队口号:在雨中狂飙,在困难中前行,挑战突破自我,逼出最好的自己

团队照:

角色分配:

产品负责人: 王大华

Scrum Master: 冯梓凡

PM项目经理:容杰

用户:梁仕标

团队项目选题(待定)

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

1.梁仕标

第六章说了关于Scrum的敏捷开发流程、开发原则、与及Product Backlog(产品第需要做的事)、Sprint Backlog(冲刺前需要解决的事情)、Sprint(冲刺)。敏捷的团队合作与及敏捷的开发过程,有助于我们更好地完成团队合作,协调各方面出现的困难,每天的例会都能让队员总结,提出问题,这样更好地知道团队项目进展的情况。还有每个冲刺根据实际情况弄一个实际项目的燃尽图,这个图能直观观察团队的困惑、突破、进步,对于团队来说是一个巨大激励图。

第七章讲了关于微软解决方案框架(MSF),微软推荐的软件开放方法。随着MSF的发展,里面加入了更多关于敏捷的流程,其中MSF的思想框架包括

1、推动信息共享与沟通,除了技术机密、安全性等信息要采取必要的保护措施外,所有信息保留和公开

2、为共同的远景而工作。

3、充分授权和信任

4、各司其职,对项目共同负责

5、交付增量的价值

6、保持敏捷,预期和适应变化。预期变化,不是期望变化。

7、投资质量。对投资的重视,引起对质量的投资,引起对人、过程和工具的投资

8、学习所有的经验。定期进行阶段性的回顾和总结

9、与顾客合作

MSF加上敏捷的开发流程,追求高质量,重视与用户的交流。

2.容杰:

     阅读了《构造之法》的6章后,对于敏捷流程有了初步的理解,不过本书比较通俗易懂,看起来也不会太难,Scrum讲的是在软件开发过程中的敏捷过程,它遵循一定到原则和步骤,但这些原则不是教条式的,不是不变的。敏捷要求团队的每个人都负责,不是干完自己手头上的事就万事大吉啦,而是要每日例会,报告自己的进度,还要定期的冲刺,这些都保证了软件的更新速度和质量,以及随时根据用户的需要更改。

    第7章讲了MSF方法,它有9个基本原则,这9个原则涉及了各方面,表明了软件开发的一些流程以及该做些什么,对于软件的质量有了一定的保证,也更容易的满足用户需求。

3.冯梓凡:

什么是scrum

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,但它同样可以用于运行软件维护团队。

项目管理的核心原则:

  1. 不同类型/背景的项目所采用的项目管理方法可能是截然不同的,没有最好,只有更好,要灵活使用,管理方法也是工具而已;
  2. 项目管理,应以成果为导向,而非过程为导向。不要为了管理而管理;
  3. 衡量项目成败与否,着重看得是项目成果的商业价值和投资回报,而不是仅仅看有无超支、延期或严格执行原始计划;
  4. 20/80原则,尽可能的满足与项目利益关系最紧密的人的核心需求;
  5. 尽可能的尽快向与项目利益关系最紧密的人展示项目成果,并获取反馈以做出不断的、必要的调整,并确保提供高商业价值的交付。

基于事实反馈而作必要调整的决策模式,经过实践检验,较前端预测型决策方式,更加有效。

Scrum虽然只是敏捷开发的一种框架,忽略了编码的细节,更多关注过程的实现,同时也体现着上述的5条核心原则。

Scrum关注软件产品的商业价值增量。通过不断的迭代,软件在第一次心跳来到后,不断成长,逐渐成为一个产生预期商业价值的完整体。同时,Scrum更注重交付商业价值中优先级最高,最重要的商业价值(需求、功能)。集思广益,越复杂的系统,越需要下放权力,对于Scrum团队,要成为自身命运的管理者。充分发挥自身的能力和潜力,挑战和创新并存。

 

 4.王大华

1.敏捷流程

1). 敏捷概念:在软件工程的语境里,敏捷流程是一系列价值观和方法论的集合。从2001年开始,一些专家开始倡导敏捷的价值观和流程,强调了敏捷的做法(个人和交流,可用的软件,与客户合作及响应变化)

其实总的来说第六章就是教我们Scrum是什么,为啥要Scrum,Scrum要怎么做。

什么是Scrum? Scrum 是一个用于开发和维持复杂产品的框架,由若干个短的迭代周期Sprint组成(2到4周)。在这个周期内,每个人都有自己的个人规划及团队规划

为啥要Scrum?Scrum对项目的众多需求采取分而治之的方法,能让相关人员集中精神,在一定期限内解决部分问题,明确地指出不同人在项目中的投入和责任的不同 ,激励团队内部交流,并优化团队其他人员的交流方式。

Scrum要怎么做?第一步是Product Backlog,就是先找出需要解决的问题。第二步是SprintBacklog,把东西细化,划分了小部分来完成。第三步:冲刺,每天一个例会总结,报道今天的收获,用简单的图表来展现整个项目的进度。第四步则是得到软件的一个增量版本,然后发布给用户,我们再在这个基础上进一步增加新功能和改进。

第七章讲的是MSF

概念:MSF( 微软解决方案框架结构)是一组建立、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业和技术的目标,降低采用新技术后系统整体的费用,以及成功的应用微软技术整合商业过程的方法。

在这章中只要讲的是MSF的原则,MSF团队模型和开发模式,MSF和CMMI

MSF有九条原则,如下:

1、推动信息共享与沟通,除了技术机密、安全性等信息要采取必要的保护措施外,所有信息保留和公开

2、为共同的远景而工作。

3、充分授权和信任

4、各司其职,对项目共同负责

5、交付增量的价值

6、保持敏捷,预期和适应变化。预期变化,不是期望变化。

7、投资质量。对投资的重视,引起对质量的投资,引起对人、过程和工具的投资

8、学习所有的经验。定期进行阶段性的回顾和总结

9、与顾客合作

然后是这章的思想,MSF是一种框架结构

框架结构重点解决一个基本的问题:它提供解决总体问题和作出有效决策的轮廓。 
框架结构可以增强分析和开发大型项目的能力。MSF 能够确定项目最大的风险在何处,强调制定计划和确定进度,确保成功发布一个产品所必备的条件。

MSF基于一组工作模型,这组模型是由微软公司及其合作伙伴,在与客户成功开发分布式计算和客户服务器应用程序的经验得来的。

框架结构不是一种预先决定工作结构、工作任务和发布产品具体方法的方法论,而是提供了灵活的方式、应用有创造力的方法去解决实际存在问题的思想。

MSF的团队模型

过程模型:

再通过下面的图片我们就可以了解到MSF是如何解决问题的了

最后一点是现在在国内已经有很多MSF应用或MSF思想得到认可的实例。比如,用友公司是内最著名的财务软件公司,以往大多是最终使用客户购买用友软件,而现在有很多系统集商来购买用友财务软件。这些集成商在用友软件的基础上开发出更能满足不同客户的千万别的需求的产品,帮助它们达到自己的商业目的。而用友只需提供财务软件核心,让其它集成商在此基础上进行再开发。这对用友、集成商和客户都是有利的。此外,其它领域的公司也有似情形。MSF将结出越来越多的灿烂的果实。

时间: 2024-12-29 12:44:52

团队之阅读感想的相关文章

大道至简第四章阅读感想

大道至简第四章感想 大道至简第四章标题为流于形式的沟通,主要内容可见说的是关于沟通的问题. 第一节的标题是:客户不会用C,难道就会用UML吗?程序员不能要求客户需要精通C语言,因为在客户(的代表)学会用C语言来向开发人员描述他们的需求之前,可能他就已经被老板开掉了.因此没有客户会笨到愿意用C语言来描述他们的需求.C语言是程序员与计算机交流的语言,而不是他与客户交流的语言.程序员面对的是计算机,但计算机不是客户.因此开发经理有一种优势,可以让开发人员以需求调研的身份出现在客户面前.要深入项目的需求

大道至简第五章阅读感想

第五章失败的过程也是过程 今天王建民老师依旧带领着我们阅读了大道至简第五章,第五章是失败的过程也是过程.通过前面的技术.团队和沟通,这章主要讲了关于做工程的问题. 文章开篇以一句<明皇实录>中的“虚有其表耳”来说明一个很重要的问题就是:不能只求外表,而是要透过表象,力求实质. 第五章的整体思想是让我们注重过程,因为有很多人从来不注重过程,只注重结果.然而过程对于一个编程人员也是非常重要,如果一个好的编程员从来不在乎程序的过程,只是关心最后程序是否能够实现,那么这个编程员一定不是一个好的编程员.

WEEK 7:团队项目的感想

经过了几个星期的团队协作,我们的“爬虫”有了很大的完善,我作为团队中的主DEV,在这个过程中一边工作一边阅读,也有了不少的收获. Brooks的<没有银弹>告诉我们,在软件领域,没有什么绝招可以让我们轻轻松松就能克服困境,提升软件的性能,无论在哪一方面取得突破,软件工程各方面也不会有质的飞跃,因此,想要做好软件工程,必须充分利用软件工程的各种方法来解决问题.软件的设计是一项复杂的工作,其中需要考虑的问题是方方面面的,随着代码行数的提高,问题的复杂程度是呈几何增长的,我们只有灵活运用知识才能解决

《梦断代码》第一阶段阅读感想(包括第0、1、2共三章)

由推荐序一.推荐序二和作者的话中可以先了解到这本书讲的是一个故事,关于一堆人马并肩托起代码大石.欲将其推上山顶,虽历经磨难,但仍奋力创造的故事.与大多数技术书籍不同,把真实的人.事.技术和理论以及产品的发展过程结合在一起,这也使我对这本书产生了极大的阅读兴趣.    第0章 软件时间    与别的书不同,本书从第0 章开始,就已经暴露的作者是个程序员.......    首先介绍了作者早年间玩游戏的经历,这是我不禁想到现在大家普遍玩游戏仅仅是娱乐,根本没有心思去琢磨去改游戏,仅仅只是玩,当然这也

《thinking in java》阅读感想

本来打算第二篇文章分享一下webservice技术的,留在下一篇文章吧,写技术文章比较费时,必须每一步都得实践,否则读者看了没有用,该被骂了,周末有时间的话我一边实践一边记录吧,这篇文章跟大家分享一下<thinking in java>这本书的读后感吧,其实个人感觉分享一些学习想法和经验比分享一个技术,作用更大. <thinking in java>这本书我读了三遍了,可能有的人读的不只三遍了,我就说说我读了三遍之后的一些感想吧,首先绝对推荐这本书,为啥?可能有的人觉得太基础,有的

构建之法1、2、16章阅读感想

这本书可以说是我进入大学以来读过的最容易理解的一本有关于软件工程的书,语言平易近人容易理解,让我对软件工程在原有基础上有了翻新的认识,让我重识认识了软件工程"知行合一"的思想,加深了我对软件工程行业整体的理解.阅读的同时,我也产生了一些疑惑,以下是我在学习过第一.二.十六章后提出的一些问题和我的思考! 第一章:概论 问题:在软件工程发展的短短几十年中,人们整理了许多原则和规律,有些是比喻,例如"大教堂和集市",描述了两种大规模团队构建产品的方法,这种比喻让读者有各种

自我介绍 and 阅读感想

自我介绍 在你一生中身体最健康,精力最旺盛的时候,能在大学全职学习和研究,这是少有的机会.请说明一下,你是怎么选择了这个专业的? 大一入学科大的时候其实学的是物理专业.因为高中曾经自学物理竞赛,并且得到了一等奖,并且拿到了科大的冬令营金奖,而物理又是科大的王牌专业,所以顺理成章的去读了物理.但是高中生对于专业选择的认识和对于今后职场生活的认识都是太狭窄的,只能在当时自己能看到的范围内做出眼前的最优解.所以大学入学后,了解物理专业的发展前景.工作环境.就业方向,以及物理实验室中的科研条件,从简单的

Dynagon代码阅读感想

因为要做动态网络生成,于是去github找代码,看到这个dynagon比较对的上眼,于是clone下来慢慢研究. 链接:https://github.com/lanius/dynagon 于是我发现这个真的是写的好棒好棒,C#写的真是漂亮啊,让我见识到了delegate,lambda表达式,select,order,sort,aggregate,泛型,LIST,还有封装的种种. 看到triangulator那一块的时候遇到了Delaunay三角划分算法,没有补算法的情况下真是看不下去了.但是已经

个人关于带团队的一些感想

大概在3年前,我就开始慢慢的带团队干活了,团队小的时候加自己就两个人,多的时候有5.6个,现在来写这篇总结性的文字,对于带团队这件事情,或多或少有些个人的想法. 我喜欢稳定的工作团队,以至于一直跟其他人说,我不想在项目里面做培训师,训练了一批新人,由于一些原因,大部分走了,又接着训练另外一批,就这样反复的训练下去.对于喜欢找应届毕业生的企业这真可能会是一个事实,新人报道,没有多大生产力,经过一.两年的训练,可以高效生产了,结果走人了.喜欢稳定的团队,效率是我主要考虑的一个因素. 稳定的工作团队,