Scrum团队 《构建之法》第6~7章】的更多相关文章

身在大学,却想起了在高中的生活和初中的生活,特别是初中的生活,为什么这么说呢!因为<构建之法>,看了其中的两章的内容,为什么想到了初中和高中的生活呢,因为在高中和初三的时候看的最多的就是课本,虽然有时会看不进去,但是同样会硬着头皮去看,因为要想考一个好的高中所以就认真的学习,看书.但是到了大学,可以说很少去看课本了,都开始看电子版的书了,当然看的电子版的书,就分好坏了,(其实书都分好坏,主要是看你怎么去看待它,在书中看到的是什么,是主人公的坚持不懈的努力,还是一些其他的东西!)而我就看了好几本…
第六章-敏捷流程 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,而敏捷流程的精髓就是在于快速的交付. 敏捷开发的流程如下: 1.找出完成产品需要做的事情 - Product Backlog. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺(Sprint).在冲刺阶段,外部人士不能直接打扰团队成员.期间每日例会,向同伴报告进度,把问题摆在明面上.同时启动每日构建,让大…
第八章 这一章主要讲的是需求分析,主要介绍在客户需求五花八门的情况下,软件团队如何才能准确而全面地找到这些需求. 第九章 问题:我们现在怎样培养才能成为一名合格的PM呢? 第十章 问题:如果典型用户吴小石头的需求和问题太过麻烦或者复杂,我们是应该想办法解决还是换一个典型用户?…
第四章 两人合作   这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点.怎么做.以及一些注意事项. 1.“错误处理 当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20%的时间,给代码加一些错误处理就大功告成了,但是这20%的工作往往需要全部项目80%的时间.” 疑问:“错误处理”是什么概念?它有哪些类型及方法? 思考:我查阅了一下资料,上面解释道“在程序设计过程中,由于某些错误的存在,致使程序无法正常运行,处理这些错误以使程序正确运行就称为错误处理.”根据错…
第一章 看了第一章,第一章主要是概论,主要讲述软件是什么,是由什么组成的,然后接着陈述软件工程是什么,看了第一章之后,得知,软件工程只是实现软件的一个工具,有了工具做事情才容易.还有进行运维和维护软件,并且我们所开发的软件要符合客户的要求,不能盲目开发,浪费精力和体力,根据自己的想法去做满足客户的软件,而且要不断的发现bug并进行修复.    软件工程在社会发展处于什么地位,发展潜力在未来究竟有多大? 第二章 看完第二章之后,我才知道之前我们的想法是多么的幼稚,以为可以运行就可以,才知道软件是需…
第十章:典型用户和场景 问题 :什么是典型用户? 第十一章:软件设计与实现 问题 :开发人员的标准工作流程就是不断的发现BUg,修改bug来完善功能,在此过程中要等待同伴复审,在这阶段中,开发者应该如何缩短处理等待的时间? 第十二章:用户体验 问题:怎样给用户一个很好的第一印象,我们的产品应该怎样定位该产品的目标人群?…
<构建之法>第五章用体育运动等团队例子引出软件开发团队的形式,用更加生活化.形象化的例子让读者更能理解软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.瀑布模式:当软件行业还在年幼的时期,它从别的成熟行业借用了不少经验和模型.在那些“硬”的行业中,产品…
上一次读后感涵盖前五章的内容包括个人技术,结对合作,小组项目等.本周作业的燃尽图以及站立会议是关于<构建之法>第六章的内容,所以关于这一章的读后感涵盖在上两篇博客中. 第七章 MSF 介绍MSF(微软解决方案框架),他有自己的九条思想框架,总结起来就是勤于客户交流,保证个人价值的同时要注意与团队共进退,相信合作的力量,在保持敏捷的同时将作品价值最大化.还有重要的一点就是总结前人经验,并且把自己的经验与他人分享,利用这些经验避免一些错误,这在团队合作中尤为重要. 第九章:项目经理 项目经理分为两…
本周选读<构建之法>第8章——需求分析.由于有团队项目初期调研阶段做调查问卷的经历,这一章节中很多知识点我都比较有体会.对我而言,这一章节最有价值的内容就是厘清了关于需求分析的两个误解和近10个行之有效的调研方法. 第一个误解有关需求的内涵.需求不仅仅来源于用户(软件直接使用者)的需要,还可以是企业为维持生存.追逐利润的商业模式,或者开发者在考虑到代码迁移.架构演化.平台变化时提出的技术上的需求.另一个误解有关需求分析的实现.做需求分析是一个循序渐进.应时而变的过程,不只是简单地将用户所表达的…
本周选读邹欣老师的<构建之法>第16章——IT行业的创新. 邹欣老师将本章话题分成五个部分来阐述:创新的迷思.创新的时机.创新的招数.魔方的创新.创新和作坊,博主认为时机和招数这两个部分在编辑上不是很和合理,时机部分的内容不够切题,招数部分却出现了讲时机的内容,以下会具体说明. 创新的迷思尝试为“外行人”拨开迷雾,打破普遍存在的错误印象.未曾涉身IT工业界之前,我们常常认为对一个优秀产品.乃至一个新的商业生态的诞生,最关键的是灵感,是一个颠覆性的好想法,但现实世界不存在这种一蹴而就的好事.邹欣…