学习软件开发都需要看什么书?
学习软件开发都需要看《c和指针》、《c缺陷和陷阱》、《c专家编程》,这三本书是一个初级C程序员必看的三本书,同时也是应届新员工必须好好学习的教材,非常适合刚毕业的大学生学习 。
另外还有:C++语言提升:《Effective C++:改善程序与设计的55个具体做法》《More Effective C++:35个改善编程与设计的有效方法(中文版)》《C++沉思录》《C++Templates中文版》《深度探索 C++ 对象模型》《泛型编程与STL》一个由C转向C++的程序员,从来没有系统的学习过C++的语法,往往是用到的什么学习什么。
如果要系统入门,《C++ primer》倒是不错。
设计类《代码大全》:《重构-改善既有代码的设计》《代码整洁之道》《实现模式》《程序员应该知道的97件事》这几本书一般讲的是函数以及更低层次的设计。
《代码大全》完完整整的读完过,而且做了很多的笔记,获益良多。
《重构》就不必说了,其他几本书前面大致看了一下,也非常不错,计划有时间要好好学习一下。
架构:《软件体系结构的艺术》《领域驱动设计:软件核心复杂性应对之道》《软件架构师应该知道的97件事》《企业应用架构模式》《面向模式的软件体系结构卷1:模式系统》《软件架构设计》《架构师需要知道的97件事》敏捷开发:《测试驱动开发》《敏捷软件开发——原则、模式与实践》《Scrum敏捷项目管理》《硝烟中的Scrum和XP——我们如何实施Scrum》《敏捷软件开发》
敏捷开发方式有哪些
敏捷开发包括一系列的方法,主流的有如下七种:XPXP(极限编程)的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。
XP注重的核心是沟通、简明、反馈和勇气。
因为知道计划永远赶不上变化,XP无需开发人员在软件开始初期做 出很多的文档。
XP提倡测试先行,为了将以后出现bug的几率降到最低。
SCRUMSCRUM是一种迭代的增量化过程,用于产品开发或工作管理。
它是一种可以集合各种开发实践的经验化过程框架。
SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出,旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进。
Crystal MethodsCrystal Methods(水晶方法族)由Alistair Cockburn在20实际90年代末提出。
之所以是个系列,是因为他相信不同类型的项目需要不同的方法。
虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。
FDDFDD (Feature-Driven Development,特性驱动开发)由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发,是一套针对中小型软件开发项目的开发模式。
此外,FDD是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、 易于被开发团队接受,适用于需求经常变动的项目。
ASDASD(Adaptive Software Development,自适应软件开发)由Jim Highsmith在1999年正式提出。
ASD强调开发方法的适应性(Adaptive),这一思想来源于复杂系统的混沌理论。
ASD不象其他方法那样 有很多具体的实践做法,它更侧重为ASD的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDMDSDM(动态系统开发方法)是众多敏捷开发方法中的一种,它倡导以业务为核心,快速而有效地进行系统开发。
实践证明DSDM是成功的敏捷开发方法之一。
在英国,由于其在各种规模的软件组织中的成功,它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理,而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUPRUP其实是个过程的框架,它可以包容许多不同类型的过程, Craig Larman 极力主张以敏捷型方式来使用RUP。
他的观点是:目前如此众多的努力以推进敏捷型方法,只不过是在接受能被视为RUP 的主流OO开发方法而已。
敏捷开发方式有哪些
敏捷开发包括一系列的方法,主流的有如下七种:XPXP(极限编程)的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。
XP注重的核心是沟通、简明、反馈和勇气。
因为知道计划永远赶不上变化,XP无需开发人员在软件开始初期做 出很多的文档。
XP提倡测试先行,为了将以后出现bug的几率降到最低。
SCRUMSCRUM是一种迭代的增量化过程,用于产品开发或工作管理。
它是一种可以集合各种开发实践的经验化过程框架。
SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出,旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进。
Crystal MethodsCrystal Methods(水晶方法族)由Alistair Cockburn在20实际90年代末提出。
之所以是个系列,是因为他相信不同类型的项目需要不同的方法。
虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。
FDDFDD (Feature-Driven Development,特性驱动开发)由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发,是一套针对中小型软件开发项目的开发模式。
此外,FDD是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、 易于被开发团队接受,适用于需求经常变动的项目。
ASDASD(Adaptive Software Development,自适应软件开发)由Jim Highsmith在1999年正式提出。
ASD强调开发方法的适应性(Adaptive),这一思想来源于复杂系统的混沌理论。
ASD不象其他方法那样 有很多具体的实践做法,它更侧重为ASD的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDMDSDM(动态系统开发方法)是众多敏捷开发方法中的一种,它倡导以业务为核心,快速而有效地进行系统开发。
实践证明DSDM是成功的敏捷开发方法之一。
在英国,由于其在各种规模的软件组织中的成功,它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理,而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUPRUP其实是个过程的框架,它可以包容许多不同类型的过程, Craig Larman 极力主张以敏捷型方式来使用RUP。
他的观点是:目前如此众多的努力以推进敏捷型方法,只不过是在接受能被视为RUP 的主流OO开发方法而已。
敏捷开发的项目管理软件有哪些
Worktile 团队对于开发和Scrum的一些理解,希望有所帮助: 关于开发,我们已经有了太多的方法论和工具,这之间其实很难说哪个方法论是正确的,哪个工具是最好用的;其实开发是“任性的”,它没有定律,如人饮水冷暖自知,其过程是否高效,除了团队的内功实力这个决定性因素之外,还取决于整个流程是否是清晰的。
高效总是伴随着清晰而来,清晰的目标,清晰的计划,清晰的职责……而这也是Worktile采用看板的原因,直观可视的结构将原本错综复杂的流程变得清晰;而高度模块化的特性,又可以让一个个项目不再僵化,变成可以流动拼接的系统。
我们下面就以Worktile本身的开发作为例要介绍一下怎样apply Worktile in development 。
流动的系统我们的开发流程是利用六个项目构成的一套开发系统,这六个项目分别是:路线图Roadmap,灵感Ideas,计划Planning,缺陷Bugs,设计Design,开发Development。
这六个项目中,以开发项目为核心,其他的项目中的任务通过筛选汇总,最重构成可执行的开发计划。
这个系统的构造为:而让该系统得以运转起来的,就是其中各个项目的任务卡。
每个任务卡代表了一个单一的功能、优化点乃至bug。
以任务为驱动的Worktile,赋予了任务诸多的特性和功能,这可以让一个任务所携带的信息变得十分的精确,并且表现力丰富:标题可以简要概括某个功能点;描述可以作为详细的解释;子任务可以分拆一个比较大的功能,或者用于标记开发中的注意事项;负责人让任务责任到人,功能由哪个工程师负责开发一目了然;参与人可以让PM或者team leader跟进开发进度;开始/结束时间可以敦促工程师应该在什么时间完成;标签/自定义字段将开发的优先级和问题醒目的标示出来;附件可以用于添加辅助资料或者图片;如果需要沟通,使用任务评论会非常便捷。
而通过任务(或者整个任务列表)的跨项目复制或者移动,这些任务就可以犹如血液一般在这个系统内流动起来,让整个系统焕发出活力。
管中窥豹【开发Development】是开发过程中最主要的项目,也是落实计划的最前端。
通过重点介绍这个代表性的项目,也可以一窥整个开发系统的运作模式。
该项目由技术负责人负责,新的任务来源于系统其它五个项目的汇总,其中的任务分为以下几个列表:要做:每周的例会上确定新一周的开发计划,然后将【计划Planning】【缺陷Bugs】【设计Design】中的相应任务添加到该列表中,并对新添加的任务按照优先级排序,但在这个阶段并不进行任务的分配;进行中:一个功能进行设计或开发的时候,将其从要做当中拖拽到当前列表,然后分配给相应的工程师进行开发,并指定任务截止日期;待测试:开发完成的任务会进行到待测试列表,由测试人员负责质量保证;如果测试有问题,则退回到进行中,由工程师去处理;没有问题的话,就可以推进到下一阶段;待发布:测试人员检查没有问题的任务会移动到当前列,等待部署发布;已发布:对于已经发布的特性会进入到当前列,一般会把已发布任务在当前项目保留1个月左右,确保没有问题后,归档已发布的任务。
需要注意的是,如果产品是对应多平台的,可以将开发分为多个项目,这样可以让开发更为清晰,比如【Web端开发】、【iOS端开发】和【Android端开发】。
一些经验这套系统内的项目要尽量采用统一的优先级标准,换言之,就是这六个项目要用一套【任务标签定义】。
只有这样,不同项目内的任务在几个项目间流动的时候才会非常顺畅,不会因为标准不一造成什么问题。
每周在开发的【要做】中,仅添加一次任务,不要让工程师们觉得工作总是一望无际的,让他们看到一个个可以完成有限目标,最终,这自然会汇集成为一个Big Dream!完成的任务别急着归档。
对于已经完成的开发内容,都不要急着在路线图、计划或者开发中去归档,可以保留一段时间,比如一周或者一个月,这样可以便于我们回溯过去一段时间的工作成果。
无论你想把这套开发系统弄的多么的精简(比如一个项目)或者多么复杂(三层以上的项目),首先要明确的一点是——这套系统是不是让你的开发变得更加清晰了?为了确定这一点,你要检视一下,在这套系统之下,你的团队目标是不是清晰了,让你的开发计划是不是清晰了,并且让你的团队职责是不是清晰了。
如果没有,你就需要作出调整。
转载请注明出处51数据库 » 软件开发模式 scrum