20150417作业4 阅读《构建之法》 第5.5 第6 第7章

6.1.1

敏捷開發原則

1.儘早並持續地交付有價值的軟件以滿足顧客需求

2.敏捷流程歡迎需求的變化,並利用這種變化來提高用戶的競爭優勢(這個需求變動聽說是程序員都受不了吧?

3.經常發佈可用的軟件,發佈間隔可以從幾周到幾個月,能短則短

4.業務人員和開發人員在項目開發過程中應該每天共同工作

5.以有進取心的人爲項目核心,充分支持信任他們(其實那些是大牛..

6.無論團隊內外,面對面的交流始終是最有效的溝通方式(地理條件約束呢..?

7.可用的軟件是衡量項目進展的主要指標

8.敏捷流程應能保持可持續的發展.領導、團隊和用戶應該能按照目前的不掉持續合作下去

9.只有不斷關注技術和設計,才能越來越敏捷

10.保持簡明--儘可能簡化工作量的技藝--極爲重要

11.只有能自我管理的團隊才能創造優秀的架構、需求和設計

12.時時總結如何提高團隊效率,並付諸行動

6.1.2

敏捷流程

第一步:找出完成產品需要做的事情--Product Backlog

第二步:決定當前的衝刺(Sprint)需要解決的事情--Sprint Backlog

第三部:衝刺(Sprint)

第四步:得到軟件增量

7.2

MSF基本原則

1.推動信息共享與溝通

2.爲共同的遠景而工作

3.充分授權和信任

4.各司其職,對項目共同負責

5.交付增量的價值

6.保持敏捷,預期和適應變化

7.投資質量

8.學習所有的經驗

9.與顧客合作

时间: 2024-10-19 04:41:24

20150417作业4 阅读《构建之法》 第5.5 第6 第7章的相关文章

阅读<构建之法>第三10、11、12章并提出问题

<构建之法>第10.11.12章 第10章: 问题:对我们了解了用户的需求后,但是我们想法和做出来的软件会和用户的需求有偏差,比如风格.界面的修饰等等,那么我们程序猿怎样才能让自己的想法更加靠近用户的想法呢?是设身处境么? 第11章: 问题:我们现在这个阶段是在做四则运算APP,如果按照这章的步骤走下去,每天都要进行进度更新,和每日会议还有每日构建的,会不会不太符合我们现在的处境?毕竟我们的所有时间不能只为一门课程服务,还要大量的时间花在其他的课程上呢. 第12章: 问题:在实际的项目中,我们

阅读&lt;构建之法&gt;第三10、11、12章

第十章典型用户和场景 1.典型场景和典型用户 对用户的认识,例如用户的价值,如何定义用户,用户与场景的结合,在从场景到任务等,还有用户的模板或者故事. 2.规格说明书 (1)功能说明书 定义相关的概念->规范好假设->避免误解,界定一些便界条件->描述主流的用户/软件交互步骤->一些好的功能和副作用->服务质量 (2)功能说明书模板 (3)技术说明书 (4)功能驱动的设计 构建总体模型->构建功能列表->制定开发计划->功能设计阶段->实现具体功能 对

第一次阅读构建之法

    第一次阅读构建之法,把以前很多门课的知识点联系到了一起.      软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.      从一个简单的程序,扩展到一个满足各种功能的应用软件,再扩展到一个能保证服务质量的软件服务.源程序是建立在数据结构上的一些算法.构建不仅仅是CC和link命令,一个复杂

《构建之法》第8、9、10章 读后感

<构建之法>第8.9.10章 读后感 第八章:需求分析 软件开发团队就是为了用户着想,于是总会在程序项目开发前进行项目的需求分析 本章节讲述软件需求的4个步骤,(1)获取和引导需求(2)分析和定义需求(3)验证需求(4)在软件产品的生命周期中管理需求 .在软件工程中分析软件需求需要考虑相关者的利益关系,例如用户.顾客.市场分析师.监管机构.软件工程师等之间的关系. 讲述了9种用户调研方法:(1)焦点小组(2)深入面谈(3)卡片分类(4)用户调查问卷(5)用户日志研究(6)民族志/人类学调查(7

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

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

第五次作业 关于《构建之法》的心得体会

阅读了邹欣老师的<构建之法>这本书,我感受颇多.上个学期在学习软件工程的课程的时候,并没有很大的学习兴趣.但是读了这本书,我完全有了新的感受.以下是我的学习心得. 阅读这本书使我对下面个人技术和流程.分析了软件工程师的成长.软件团队合作的几种模式和开发流程.敏捷流程.需求分析.项目经理.用户体验.软件测试.质量保障这些概念有了更深刻的理解. 我了解到了创建单元测试的主要步骤以及好的单元测试的标准是什么.还有团队的力量是无穷的,这让我懂得了我们应该增强团队合作意识,这样很多时候会事倍功半.通过阅

阅读构建之法第一章有感

今天阅读了构建之法第一章,感觉到自己其实玩具的阶段都不到,离研究阶段更是差的有段距离.了解到程序其实只是一个藏在你电脑里的数据结构加算法,要想成为软件还得经历软件工程这一阶段,软件工程便是把系统的.有序的,可量化的方法应用到软件开发,运营和维护上的过程中.首先我要进行软件需求分析,一个成功的软件是要有市场需求作为背景的,没有需求你做的软件就是无用的东西,有了需求然后我们对软件进行设计使之安全 可行 基本满足市场的需求.然后我们便对我们的软件进行测试.最后软件在用户手中运行,但是十全十美的软件是不

为什么报计算机还有阅读构建之法的心得

1.为什么选择计算机这个专业; 当初读本科的时候,一志愿填的是电气工程及其自动化,估计是因为分数太低了被调剂到了网络工程专业.之前的我并没有过多的接触计算机,感觉自己对这方面并没有多大的兴趣,本科的时候自己的学习并没有多么的认真.当时自己还想过要转专业,后来也不了了之了.慢慢的感觉这个专业还可以,也就学了三年,后来到了考研的时候,本来打算考金融专业的,但是跨专业考研难度挺大的,而且最近几年计算机这个专业实在是太火了,毕业之后工作找工作各方面都不错然后就限定决心考了计算机技术.庆幸的是考上了,现在

第五次博客作业-读《构建之法》心得

读<构建之法>心得 首先,这是一本全景式图书,会让你更了解这个行业,能让毕业生在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料,这是一本与现实接轨的教材. 其次,这是一本最佳实践式的书,涵盖了科学.健康的软件工程开展中的每个方面,介绍了种种方法论,但不是高高在上.纲领性的方法论,而是方法论的最佳实践,确实可用,拿来就用. 第三,这本书让人有情怀,学生对“古老的”瀑布教材或“舶来的”敏捷书籍,难免会缺乏信心:这东西行吗?适用于现代吗?适用于中国吗?而如果到各大论坛.社区.或者询问“过来人”

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展