敏捷开发

这学期的软件工程课，老师一开始就谈到了一个词——敏捷开发。下面来详细谈一下敏捷开发。 就老师课上说讲解的内容，首先说一下敏捷软件开发的核心价值观，它包括承诺（commitment）、专注（focuse）、公开（openness）、敬重（respect）、勇气（courage）。 scrum的框架，它包括三个角色，四个仪式，三个物件。 （一）敏捷开发的起源 敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 （二）敏捷软件开发的原则 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准

转自维基百科 敏捷软件开发 敏捷软件开发 （ 英语： Agile software development），又称 敏捷开发 ，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。 原则 雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。其中包括了以下方针： 个体和互动 ：高于 流程和工具。 工作的软件 ：高于 详尽的文档。 客户合作 ：高于 合同谈判。 响应变化 ：高于 遵循计划。 其中左边的描述是右边原则的重点。 宣言中还包括以下原则： 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

无论作为产品用户还是管理咨询顾问，都非常非常喜欢微信。自认感情比较克制属于“高冷”挂，但从很多方面都太佩服太崇拜张小龙了（新书里微信也会是最喜欢的案例之一，真的不只是一个产品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆发后，微信的响应大概最快速也相对最到位的了，看一看立马有了“疫情专区”（不知道官方名称是什么，以下暂以此代称），对于了解疫情整体数据和最新动态都很有帮助，真是觉得太棒了。 之前了解到微信也是使用敏捷开发，最近也在筹备ASM实战课程和Scrum咨询服务产品，奇葩开个脑洞用Scrum YY一下看一看“疫情专区”开发过程，也通过这种方式简单科普一下敏捷开发基本理念与价值以及Scrum的流程实践吧。 本文包括4部分： 敏捷开发基本理念与价值 敏捷开发实践方法 Scrum的3个角色与5个活动 如何通过Scrum实现微信看一看“疫情专区” 敏捷开发基本理念与价值 敏捷开发根源于适应性项目管理和精益开发，相较于传统基于“预测+规划+控制”的瀑布式开发方式，能够适应需求变化的风险，及时理解与响应客户需求，通过周期迭代交付可工作的增量产品的方式，增强项目管理灵活性与可预测性，并基于团队责任制的工作理念运行，借鉴精益管理理念与优秀实践，流程效能高，能够显著优化开发成本，提升产品质量与竞争力、客户满意度、团队及干系人满意度。 就像微信看一看的“疫情专区”

软件测试最早可以追溯到1958年的美国第一个载人航天计划-水星计划，当时在该计划中首次诞生了软件测试团队。当然，在此之前也肯定是有软件测试存在的，但远没有这次有了自己的江湖地位。但这也仅仅是软件测试的萌芽，远没有到开宗立派的地步。因为你想想这时候软件也只是萌芽阶段，各种软件的理论，标准都还没有诞生，所以更别提软件测试了，因此很长一段时间内，软件测试时间内是没有什么发展的。 时间到了1975年，这一年，软件行业的一个超级豪门诞生了-微软。我不知道微软是不是第一家纯软件开发的公司，但微软确实使软件开发得到了快速的发展。也是从那时候起，美国的软件行业一骑绝尘。随着软件行业的蓬勃发展，软件的规模越来越大，复杂度也越来越高，随着而来的是软件的质量被逐渐的关注起来，软件测试的理论逐渐得到积累。到了1979年，梅尔斯出版了软件测试第一版本著作《软件测试的艺术》这本书，第一次明确的给出了软件测试的定义“The process of executing a program or system with the intent of finding errors”，至此软件测试算是正式的开宗立派， 有了自己的江湖地位。个人认为现代测试的开端应该就由此开始。推荐大家都去读一读这本书，不一定能学到多少新东西，但是就凭它的江湖地位就足以让大家去瞻仰一下了。 自动化测试的历史演进 软件测试的开宗立派

所谓敏捷开发，就是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发的流程： 在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。它遵循的原则是： 1. 快速迭代 相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。 2. 让测试人员和开发者参与需求讨论 需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。 3. 编写可测试的需求文档 开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。 4. 多沟通，尽量减少文档 任何项目中，沟通都是一个常见的问题。好的沟通

在远古时代，文字没有出现之前。知识的传承靠口口相传，不管隔了多少代，其准确性很高。文字出现后，我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们，左右着我们。各位是否也有相同的想法？试想一下，上节课我们讲了什么？每次应允别人的承诺，我们转过头就忘记？比如忘记约会，忘记洗车、忘记写日报？ “要想知道栗子的味道，你得咬一口”这个真理朴实，正确。当用户提出一款软件时，我们不要只想着从技术的角度，认为用户不专业，他的需求是错误的。如果他专业，就没我们啥事了。用户大脑中的需求是离散的，不可控的，这时，就需要我们放下成见，彼此真诚相对，让用户参与进来，通过各种方法，一条条梳理，直至双方的理解是一直的。 其作用：1.我们弄懂了用户为何会这样想。2.用户通过亲身参与，头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程，需要双方彼此做出改变，很难.....，往往难得事情才是最重要的，要不怎么会有“战胜困难”的伟大，痛苦成就了欢乐。 软件的最大价值只有在用户认可，使用才算真的有价值。“再牛逼的算法，再严谨的逻辑”不符合用户实际需求，都是白费力气。“当顾客很饥饿时，他只需要的立马填报肚子的食物，而不是需要几天或者几个月才能做好的满汉全席”。 扯远了，回归正题。因用户对软件领域不专业，脑中对需求没有一个正确的定论。就需要我们专业人士，运用特殊的方法，梳理用户真正的意图。

Sprint（冲刺）是Scrum的核心，持续时间为一个月或更短的时间，在这个时间内构建一个完成、可用的和潜在可发布的产品增量.在整个开发过程期间，其长度应保持一致，前一个Sprint完成后，新的下一个Sprint紧接着就开始，有点像接力棒的游戏。 Sprint计划会议：会议时间不要过长，不要为了会议而会议。通常一个月内的，上限为8小时或更短；依次类推。其主要目的是确定每个参会者都理解会议的目的。敏捷教练要确保会议顺利举行并教导敏捷团队遵守时间盒规则。包含几点：这次做什么？如何完成所选的工作？期间会遇到什么问题？预期可交付的增量？ 每日站会：2W1H，昨天我做了什么？今天准备做什么？是否需要他人协助？注意一点，站会的时间不要太长，其核心的地方，每个人参与，不要开成训导式的，确保每人都可以发言及每人都有机会主持会议； 开发工作：通过看板、代码测试、代码审核、沟通来确保Sprint正常进行； Sprint评审会议：在Sprint尾期进行，用于检视所交付的增量并按需调整ProBackLog列表。参会人员：团队成员、客户、利益相关者；会议时长同样不要太长，根据Sprint的大小决定。在会议中集中讨论几个要点：probacklog哪些“完成”、哪些“未完成”、遇到什么问题及如何解决的、演示“完成”的工作并解答增量交付的问题、讨论当前的probacklog的情况

软件项目管理的两大主流管理模式：传统项目管理（预测型项目管理）、敏捷项目管理； 传统项目管理（预测型项目管理）：瀑布式、部分迭代开发模式，要求在项目一开始，需求足够明确、文档足够规范、迭代过程需求变更越频繁，其对项目造成的灾难往往越大。相信很多IT团队都尝试过，这里不赘述。 敏捷项目管理作为新兴的项目管理模式，简化了传统项目的流程，从繁琐的流程和详尽的文档中解脱出来。但并不代表敏捷不做计划，有很多人的观念“敏捷不做计划”这是错误，否“probacklog、scrum、看板、燃起图、燃尽图、用户故事等等”方法和工作又是为谁提供工作依据？敏捷即迭代、增量交付，其中代表XP、Scrum是用的最多的方法，其核心思想：拥抱变化，通过sprint迭代快速向客户交付可用的软件，并通过反馈来确定产品的方向，使产品利益最大化。 1.管理流程 完整的项目管理流程包含五个过程：启动、规划、执行、监控、收尾； 敏捷的项目管理框架：构想、推测、探索、适应、结束。 构想阶段：确定产品的构想、项目范围、项目团队以及团队共同的工作方式。通常采用用户故事方式进行深挖； 推测阶段：制定功能发布计划、里程碑和迭代计划，确保交付构想的产品（产品路线图-组件团队-项目章程-流程剪切）。通常采用故事作坊模式进行深挖和确定需求； 探索阶段：在短期内提供可经测试的功能，不断的刺探市场\客户的反馈，减少项目的风险和不确定型

在当今极度变化的大环境中，产品团队正面临着一场巨大的变革。为了更好的适应大环境，研发团队都极力做自我调整。 达尔文曾说过“留下来的物种往往不是最强的，确实最先进化的”，从传统的“瀑布式”到“迭代式”，最终再到敏捷型研发团队。无数组织、团队都在进行思考、变革。 研发团队一定要通过无尽的加班，才能交付产品，不能一边享受生活一边交付产品吗？ 产品一定要尽善尽美后再推向市场，是否可以通过小的版本快速推向市场？ 答案是可以的，是时候来场变革了！ 在本系列，我将和你一起探索敏捷项目管理的知识和实践。 最终客户价值在销售时交付，不是在计划时交付。 敏捷商业目标 持续创新力--满足当前客户的需要； 产品适应性--满足未来客户的需要； 缩短交付进度--满足市场，提高投资回报率（ROI）； 可靠的结果--支持业务增长和盈利能力。 持续创新 关起门来造轮子，已经无法适应当今复杂的商业和技术环境。开发产品和新服务都需要新意识。 特别是随着大数据、人工智能、工业互联、5G的发展，编程步入了一个高速发展的时期，从C语言到python，从低级语言到高级语言层出不穷，从成人编程教育到少儿编程的兴起，市场给了我们更大的机遇和挑战。 持续创新能力随着环境的变化显得尤为突出，当大家都在聊4G，5G已经悄然来临，快速占领行业浪尖--这就是持续创新的一种表现，带来的机遇和收益往往是巨大的。 创新思想并不会是模式化的

## 给应用程序添加安全机制 使用Spring Security和单页应用,就像Jhipster生成的代码,你需要Ajax的登录/退出/错误页面.为了更好的使用,我们已经为这些页面配置好了Spring Security,并且已经为你生成好了所有的Javascript和HTML代码. 默认情况下, JHipster 内置了4中不同的用户: "system",只主要为审计日志 "anonymousUser", 匿名用户 "user", 拥有 "ROLE_USER" 权限的普通用户. 密码为 "user" "admin", 拥有 "ROLE_USER" 和 "ROLE_ADMIN" 权限的管理员. 默认密码为 "admin" 处于安全因素,你应该修改这些密码 HTTP Session 认证 这是一个典型的Spring Security认证机制,我们在此基础上做了显著的改善,使用HTTP Session,是一个有状态的机制,如果你计划扩展你的程序,你需要一个粘滞回话的负载均衡器,以便每个用户都在同一个服务器. 改进了 remember-me 机制 我们改进了Spring Security的 remember-me 机制,以便每个用户只有一个独立的Token,它储存在你的数据库 (关系型或非关系型数据库,这取决于你生成项目时候的选择),我们同样也储存了很多信息变准实现