敏捷开发

敏捷开发是以用户的需求为核心，采用迭代、循序渐进的方法进行软件开发。而Scrum是实现敏捷开发的具体方式之一 Scrum内容 个体和互动高于流程和工具 Scrum是以团队为基础，为企业创造价值。团队成员一起努力实现团队业务目标。 一个团队制定了任务目标，他们就会： 弄清楚如何开展这项工作 需要做的工作 找出阻碍完成工作的因素 有责任解决在其范围内的所有困难 与组织内其他团队共同解决他们无法控制的问题 在Scrum中关注团队责任是至关重要的。 工作的软件高于详尽的文档 Scrum需要把每一步工作中完成的产品增量作为每一个Sprint的主要结果。无论在Sprint期间发生了什么事情，重点都是创建产品增量（这个增量是Sprint中完成所有产品待办项目列表项目的总和，创建的增量可以是还没有包含足够的功能让业务决定交付它，但是团队的工作是确保当前的功能具有可交付的质量）。 客户合作高于合同谈判 Scrum旨在促进协作。团队成员互相协作，以找到构建和交付软件（或其他可交付成果）的最佳方法。一个团队，尤其是产品负责人，与利益相关方合作，检查和调整产品的视觉，使产品尽可能的有价值。 响应变化高于遵循计划 Scrum团队会经常制定计划，首先，他们除了构建当前的sprint计划，还会创建长远计划，如：发布计划和产品路线图。这些计划可以帮助团队作出决策。然而，团队的目标并不是盲目地遵循计划

敏捷，简单的释义，即灵敏、快捷。 「合理的任务规划」 能让团队的工作即饱和而又能够有良好的应变能力（灵敏），团队需要时刻保持着良好的应变能力，因为我所了解的开发团队一直都面对着一个不确定因素——需求变化快。 「专注」 能够有效提升效率（快捷），当人在多件事情之间来回切换的时候，效率就会显得低下而且心情还很容易变得糟糕。 接下来将带给你如何使用敏捷的工具之一 Scrum 帮助你完成「合理的任务规划」和如何「专注」 。 一张图看懂 Scrum Scrum 工具包括：3个角色、3个工件、5个活动和5个价值观。 3个角色 01 Product Owner： 职责： 🔘清楚知道产品的愿景，分为近期和远期。 清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。 🔘获取外界的诉求并进行整理成 User Story。 外界：用户、运营部门、其他业务方 User Story：需要实现的功能，以客户的角度，描述「我需要功能A，来达到我的什么目的」。 🔘对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。 一个功能的实现，有时候牵涉各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通

如果还不知道Scrum敏捷开发的朋友们，同理，还是请出门左转，点击 Scrum 了解下。 以下是原文中提到的9个Scrum不行的理由。除此之外，作者陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。 Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？ Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。 Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。 Reason 4:Scrum只不过是一个流程

软件 能够完成预定功能和性能的可执行的计算程序、支持程序正常的运行、以及描述程序的操作和使用文档。 软件工程 将系统的、严格约束的、可量化的方法应用与软件的开发、运行和维护。 软件开发生命周期 1）确定问题； 2）可行性分析 3）系统分析 4）系统设计 5）编码 6）测试 7）安装、维护 软件开发模式 1）瀑布模式 2）螺旋模式 3）快速原型模式 4）喷泉模式 5）混合模式 6）敏捷开发模式 瀑布模式 1）重视各阶段的顺序性 2）当一个阶段的文档获得认可才进入下一个阶段 问题定义 可行性研究 需求分析 软件设计 编码 测试 维护 螺旋模式 1）设计、执行并测试原型 2）再设计、执行并测试新特征 3）将原型逐步扩展为最终程序 敏捷开发方法 1）以人为核心、迭代、循环渐进 2）针对传统的瀑布模式弊端 3）分为多个相互联系、独立运行的小项目 4）软件一直处于可使用状态 特点 1）更符合软件开发规律 2）自底向上 3）逐步有序 4）遵循软件客观规律 5）迭代增量开发 轻量级软件开发方法 1）Scrum 2）极限编程（XP） 3）精益开发 4）动态系统开发方法 5）特征驱动开发 敏捷开发典型过程 1）对产品形成共识 2）建立和维护产品需求列表、并进行优先级排序 3）筛选高优先级需求进入本轮迭代开发 4）细化本轮迭代需求，一次在本轮迭代完成 5）每日召开站立会议 6）对每轮迭代交付的可工作软件

微服务与敏捷开发（Scrum/Kanban）的核心思想之我见   关于“微服务”和“敏捷开发”的文章网络上有很多，所以这里不再重复叙述这些概念的解释和特点，而是就个人实际工作中对他们的核心思想的理解及运用分享给大家，希望能对大家有所帮助。   当下IT开发领域，“微服务”及“敏捷开发”越来越被各公司及团队重视。但是在交流中发现很多人对“微服务”及“敏捷开发”存在很大的误解，尤其在各公司的招聘岗位介绍中更能看到很多描述错位的地方。   首先，微服务和敏捷开发都是指导思想，是模式和方法，并不是特指某个软件应用、开发语言、开发框架等。并不是使用了某个软件应用或某个框架就算是微服务或敏捷开发了，也不是采用微服务和敏捷开发理论指导开发工作，就必须要使用某些软件或开发框架才能进行，这个是对微服务和敏捷开发的严重误解。   其次，在实际开发工作中，这两个指导思想要紧密的联合起来运用，才能达到更高效的团队运作，才能既快又好的进行产品迭代，将这两种指导思想的优势充分发挥出来。 先说一下微服务   微服务是一个架构理念，是指导架构设计的一种思想模式，延伸了领域驱动设计（DDD）。微服务是为解决逐渐复杂的系统设计、开发问题而提出的。当一个应用系统太过复杂时，设计与开发难度要比简单功能的系统大得多。其主要原因就是系统内有太多的耦合。这对系统迭代可能是致命的。DDD理论则较好的解决了这个问题

阅读与准备工作 格式描述： 这个作业属于哪个课程 课程链接 这个作业的要求在哪里 作业要求 我在这个课程的目标是 课程目标 这个作业在哪些具体方面帮助我实现目标　 具体实现 作业正文 作业正文 参考文献 参考文献 我的课程目标是： 了解软件开发流程，清晰自己的思路，在以后工作中能够少走弯路。 具体实现： 结合书中的知识通过与同学组队共同完成老师和课程布置的作业，在做中学，学中做，真正把书上的东西变成自己的。 作业正文 一、个人的自我介绍 我个人认为自己比较懒，不但不喜欢运动，而且爱好美食，但唯独爱好乒乓球，超级喜欢猫咪。在学习方面学习能力较差，导致我的基础比别人要差很多，这么多大牛曾让我压力山大， 二、阅读与思考 1. 回想一下你初入大学时对你所在专业的畅想 当初你是如何做出选择你所在专业的决定的？ 当初在填写志愿时是真的不知道要填写什么才好。家人特别是我大姐推荐我选择计算机这个行业，其实当初我是拒绝的，我脑子不好使，觉得学起来可能会很吃力，一度想要报考农业大学的。。但在家人的坚持下，我还是报考了软件工程这个专业。 你认为过去一（两）年中接触到的课程是否符合你对你自己所在专业的期待，为什么？ 我对这个专业的最大的期待就是:我能够了解一些软件应用、网站之类，在它们的背后是怎么样形成运行的。学习了两年后，对这些也有了一些了解，在完成老师布置的作业的基础上

敏捷软件开发与传统软件开发的对比 最早了解敏捷开发是通过大二的一次博雅课堂，一位在百度工作的北航学长跟我们分享了他近年来从事敏捷开发的经历。印象最深的一句话是一个延迟3个月交付100%功能的软件和一个按时交付75%核心功能的软件，敏捷软件开发者更愿意选择后者。本学期的软件工程基础课又向我们讲授了传统软件开发，经过课上和课后的学习，对于敏捷软件开发和传统软件开发有了浅显的认识和理解。由于课上学习的重点是传统软件开发，所以课下对敏捷软件开发进行了更多的涉猎，本文以敏捷软件开发为主体，来分析其与传统软件开发的对比。 敏捷软件开发与传统开发方法相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正软件中的错误，提高开发效率，同时为需求的调整提供更多机会，保证软件向正确的方向发展。 传统软件开发如瀑布模型强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。 对敏捷联盟宣言的理解 1.个体和交互胜过过程和工具，强调软件开发必须发挥人的积极性和创造性，更看重人的沟通和团队的力量； 2

运维日常三大工作，发布，变更，故障处理 事实上对正常的发布来说，还有很多步骤 工作当中或者IT典型的公司，在提供产品的工作当中，大体分为两种运维环境 以电商站点为例，开发代码写完以后要想上线应用，以java为例，代码开发以后，第二个步骤肯定不可能直接把代码部署到线上应用环境中去， 所以一般第二步叫做构建，build（类似c代码的编译，编译完以后才能测试，一个庞大的java项目是需要一个构建工具进行构建的，类似编译操作一样，来检查代码间的关系，来完成依赖关系的检查，） 第二步构建，构建好以后 第三步可以做测试了，比如单元测试，功能测试，集成测试等，测试完成，如果没问题，这个时候就可以放在预发布环境里了。 测试是放在测试环境中做的，发布之前还应该放在预发布环境，预发布环境要进行接受性测试（发到准线上，我们检查对应代码运行结果，根据访问界面之类的，是否没有问题） 如果没有问题，就可以上线了 第四步部署 所以大致分几步 （先做开发计划 plan，plan完成以后开始实施开发） 1.写代码的过程（开发） （开发完以后，要做单元测试，因为不同的人对应的开发项目本身有可能只负责这个项目中的很小一部分功能，由于每个功能的开发进度不一定完全一样，所以每个小组开发完功能以后，会将它集成到对应的代码树上，类似于推送的 写完代码要push到远程仓库来合并，合并完以后做单元测试） 2.开发完以后，做构建，

【上次回答了 软件开发者面试百问 中测试部分 ，这次，由于时间关系，简单回答一下软件项目管理部分的问题。这些问题的答案，一般没有正确与否，各个人回答不同，这里仅供大家参考。】 1. 范围、时间、成本，这三项中哪些是可以由客户控制的？ 范围、时间、成本，是项目管理中常说的三角关系。任何一方改变都可能牵扯到其他两方的变动。项目管理的本质，就是在保证质量的前提下，寻求这三者之间的最佳平衡。因为客户是需求方和投资方，客户有权对这三者进行控制，当然客户主要控制范围，即提出他们的需求——项目要实现的功能特性，其次，客户也非常关心能交付的时间和所付出的成本。在满足客户的需求情况下，可以在时间、成本上和客户进行交流、谈判。从项目管理的角度看，最好固定其中一项，其他两项可以根据实际状况来调节保证项目质量。 2. 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？ 项目成功是团队协作的结果。在对项目进行估算的时候，需要由参与项目各个环节的人进行符合实际的估算，最后汇总起来进行综合分析计算，获得项目总的估算结果。 项目的最后期限设置除了客户定死最后交付时间，其他的情况都是根据项目的进度估算结果而进行符合实际的计划得出的。 3. 减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？ 根据项目的类型和项目进行中的实际情况来决定，如果项目是规模比较大，时间长的

用例千万条，质量第一条。 流程不规范，亲人泪两行！ 昨天衬衫哥接到新的上线需求提交到测试，功能很简单。 程序猿童鞋告诉我，不用测了，没问题的。 这个时候，刚工作不久的测试童鞋可能本着相信同事，抹不开情面，选择不测或者少测，直接发给运维童鞋准备部署上线了。 如果是这样的话，测试童鞋准备被上课了：上线后有问题，都是测试的锅了。 测试第一准则就是：不要相信任何人说的话。眼见为实，任何事情都需要验证过，以可交付的文档，原型等文字内容为准。为什么？ 因为要随时防止背锅啊。 上线前，项目经理催你进，产品经理催你，运维催你，销售也催你。 上线后，出问题了，他们第一反应就是，测试怎么没测出来？ 所谓，催进度他们来，背锅测试去。 这个时候，需要需要把之前评审过的测试用例甩出来，漏了大家都有责任，有锅大家一起扛。 与产品的聊天记录，邮件把需求不清晰，上线前还在变更需求的锅甩回产品。 测试计划要把各种风险多描述清楚，特别是测试时间被压缩会导致漏测的风险标注出来。为什么？因为项目开发进度从来都是不够的，测试时间从来都是被压缩的。 没错，这就是it行业里的潜规则之一。 不要信什么敏捷开发，背靠背开发，都是为了减少程序猿们的文字工作。以前的开发模式，特别是需要CMMI3以上的，开发过程中各种文档，写的项目成员是欲仙欲死。 所以现在流行敏捷开发，开发文档少，程序猿童鞋举双手赞成