敏捷开发

结对项目——网页版四则运算项目报告 前言 这次我们做的是网页版的四则运算，一人负责前端（我），一人负责后端（马福孝）。这次的结对项目对于我来说是一个很好的复习css,js的机会，很好地练习了ajax技术，对前后端分离也有了很好的理解。学到了这么多也算是对我这一周不眠不休码代码的最好回报了。 一、代码仓库地址 代码仓库地址（马福孝）： https://git.coding.net/mafx8859/ArithWeb.git （以马福孝版为准） 吴建瑜： https://git.coding.net/wujy123/twoperson_calculate.git 远程服务器测试路径（直接点击测试）： http://47.93.197.5:8080/ArithmeticWeb1.0/ 本地未编译后测试路径： http://localhost/ArithmeticWeb/WebRoot/calcalute.html 本地编译后测试路径： http://localhost/ArithmeticWeb1.0/ 二、psp展示（计划完成与实际完成） PSP2.1 任务内容 计划共完成需要的时间(min) Planning 计划 30 · Estimate · 估计这个任务需要多少时间，并规划大致工作步骤 30 Development 开发 48*60 · Analysis · 需求分析

案例背景 为什么银行要像灰狗一样快？ 荷兰国际集团（ING） ，成立于1991年，主营业务银行与保险业务，在全球45个国家和地区拥有分支机构，总资产887亿欧元（2018），全球53,000多名员工，拥有3840万个体客户。世界500强排名171（2018），世界品牌500强排名120。 ING的敏捷转型始于2010年，当时还只是涉及IT部门的基础员工。2014年，首席执行官Nick Jue和高级领导团队在制定银行“Think Forward”战略的时候，他们意识周围的世界正在迅速变化。银行不是只与传统机构竞争，对于新技术和新竞争对手，ING必须非常迅速地改变。 紧紧抓住过去不会让我们拥有未来。 转型不只是将组织从A移动到B，因为一旦你击中B，你需要转到C，当你到达C时，你可能不得不开始考虑D。 Nick Jue, ING CEO 当ING引入敏捷工作方式时，公司表现良好，利率仍处于不错的水平，没有特别的财务要求。然而，客户行为随着新的数字分销渠道的变化而迅速变化，客户的期望也受到其他行业数字化领导者的影响，ING需要停止传统上关于产品营销的思考，并开始了解这个新的全渠道环境中的客户旅程。必须提供无缝且始终如一的高质量服务，以便客户可以通过一个渠道开始他们的旅程，并通过另一个渠道继续。灵活的工作方式是实现该战略的必要手段。 创新解决方案 四个关键支柱实现集团总部的全面敏捷转型

史诗, 故事, 版本与冲刺 这四辆马车能够优雅地管理敏捷过程的范围和时间表。并构建您的工作。 一旦软件团队熟悉瀑布或其他传统项目管理风格，他们常常感到“如何构建我的工作”的痛苦。 幸运的是，敏捷开发使用四个明确的交付工具，将结构带入任何敏捷项目：史诗，用户故事，版本和冲刺： · Epic 史诗 大量的工作，包含故事 · Story 故事 最小的工作单位，也被称为任务 · Version 版本 向客户发布的软件 · Sprint 冲刺 团队事务处理的迭代 通过使用这四大工具，软件团队能够组织工作并将其分解成可以实现的部件，因此可以优先考虑客户的反馈意见，并从项目的原始计划中进行改变，而不会觉得像被各种墙围绕一样而感到奔溃。 根据当前见解改变和适应未来计划的能力是敏捷性的标志。 在这篇文章中，我们将定义这四种交付工具，并展示它们如何组合在一起构建您的工作。 但首先，我们来讨论每个工具之间的区别。 史诗 v.s. 故事 史诗是更大的工作，涉及到很多的故事。 史诗可以跨越多个冲刺和版本。 版本与史诗不同，因为它们是软件发布给客户的时间点。 版本可能包含多个史诗。 史诗帮助团队创建层次结构和架构。 故事帮助团队跟踪手头任务的具体细节，并将其细分为子任务。 上图中显示的工作可以选择为，在一个或多个冲刺期间完成的版本。 举措(Initiative)发生在组合层。 重要的是将问题在该层面指出

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 作为一名 1x 开发人员，我在亚马逊五年的工作中总结了 20 条经验法则，希望能够在有限的自由时间内自我提升为 1.1X 开发人员。这些经验法则涉及生产力和学习、编程语言、技术、测试、DevOps、安全、设计和项目管理等领域。希望对大家有所启发。 序 言 我不是一个10x 开发人员。自从有了拨号上网以后，我就没有再建过网站。我在大学毕业几年之后才开始学习编程，因为我在政府和政治领域的职业生涯已经走到了瓶颈。 我写了五年代码了，这段时间都在亚马逊。在这期间，我还在养育三个孩子，我刚开始工作时，他们分别是 0 岁、0 岁和 2 岁。 所以我不是那种在晚上和周末还在努力加班的人。我很顾家。 大约一年前，我做了自己的第一个开源项目。这是我的第一个副业项目，它是一个会议网站。 我从来没有系统地从头到尾读过一本关于软件工程的书。 总之，我是一个 1x 开发人员。我为了体面的生活付出了足够的努力。我没有太多有普遍价值的东西要说，也没有太多时间去提升。 作为一个 1x 开发人员，我使用的是大量的传统智慧。 关于软件工程，我没有太多有趣或新鲜的东西可说。 总的来说，我还没有找到方法去从工作中抽出大量时间，或者去做一些更大的副业项目，或者去大量地阅读，又或者是去取得巨大的成就。我只是能抽点小空

#PureMan6博客目录 一、Scrum Meeting 1、Alpha 【Alpha】Scrum meeting 1 【Alpha】Scrum meeting 2 【Alpha】Scrum meeting 3 【Alpha】Scrum meeting 4 【Alpha】Scrum meeting 5 【Alpha】Scrum meeting 6 【Alpha】Scrum meeting 7 【Alpha】Scrum meeting 8 【Alpha】Scrum meeting 9 【Alpha】Scrum meeting 10 【Alpha】Scrum meeting 11 2、Beta 【Beta】Scrum meeting 1 【Beta】Scrum meeting 2 【Beta】Scrum meeting 3 【Beta】Scrum meeting 4 【Beta】Scrum meeting 5 【Beta】Scrum meeting 6 【Beta】Scrum meeting 7 【Beta】Scrum meeting 8 【Beta】Scrum meeting 9 【Beta】Scrum meeting 10 3、Gamma 【Gamma】Scrum meeting 1 【Gamma】Scrum meeting 2 【Gamma】Scrum meeting 3

项目地址 （点击即可） 队名 江山代有才人秃 团队成员 学号 姓名 岗位 3116008806 张鸿(组长) PM 3116004702 夏浚杰 开发 3116004703 萧英杰 测试 3116004704 谢嘉帆 开发 3116004706 杨辉鹏 开发 3116004713 陈嘉曼 测试 项目描述 我们团队要做的项目一款躲避障碍的小游戏，通过控制两个小球旋转进行障碍躲避 团队合照 团队特色 We are programmers who fix a problem that we don't know we have, in a way we don't understand. 计划安排 第 6 周 1.团队组队、团队博客(✔) 2.团队介绍、成员展示、角色分配、选题确定(✔) 3.制定团队计划安排，团队贡献分的规定(✔) 第7周 1.需求规格说明书 2.原型设计，队员估计任务难度并学习必要的技术 3.编码规范完成、平台环境搭建完成、初步架构搭建 第8周 1.原型改进（给目标用户展现原型，并进一步理解需求） 2.架构设计，WBS, 团队成员估计各自任务所需时间 3.测试计划 第9周 1. 团队项目Alpha任务分配计划 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 第10周 1.用户反馈+测试计划改进 2. 团队Alpha阶段个人总结

时下软件界，架构界吹起了微服务之风，软件从传统的CS到BS，从单体到多服务器，再到现在的微服务；很多伙伴们也跟着技术潮流越来越多的在关注和学些或使用微服务解决项目中遇到的很多问题。本人也在软件行业20来年了，所谓活到老学到老，从软件开发，到软件设计，到软件架构，种种心路历历在目。不过现在我要说的并不是我自己的从业经历，而是我最近在架构方面的学习和领悟所感分享给大家。 架构定义： 软件架构是一个用于指导系统实现的草图，草图包括架构图和设计文档，草图越详细对系统实现的指导意义就越重要，且贯穿于软件的整个生命周期。 软件生命周期中架构设计的体现： 设计期：架构设计是重中之重。需求导向，架构先行。具体工作包括：系统拆分，技术选型，技术验证，接口规范，集成方式，技术规范，部署方案，运维方案等等。 实现期：确保各项技术规范和技术指标的执行落地，保障高质量的代码；指导研发任意和解决各类技术问题，提高研发团队效率；制定测试的技术性方案，包括自动化、性能、安全等方面；配合准备部署环境，运维实施方案落地。 运行期：发布上线相关基础工作，包括是否使用持续集成，自动化发布等技术；运维基础性工作，自动化运维、监控等相关技术。 架构的目标和方法： 目标：可控性与拆分；复用性与抽象；非功能性需求九维目标：高性能，可靠性，稳定性，可用性，安全性，灵活性，易用性，可扩展性，可维护性。 方法：4+1视图模型

结对学习过程 结对原因：我们两个人结对的原因是平时关系就很好，在学习交流过程中会更加方便。我们的学习生活习惯相近，很多时候时间也是结对学习面临的一个比较重要的问题，如果两个人的时间冲突较大，也很难有较长的有效学习时长。 在分成学习小组及结对之初我们并不太理解这种方式的意义，后来通过学习邹老师的《 结对编程和两人合作 》一文，对“结对”有了新的认识。 邹老师首先就“结对编程”的概念进行了解释： 在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。 结对编程不是程序开发者独到的发明，在现实生活中，也存在着类似的搭档关系（Partnership）： 越野赛车（驾驶，领航员） 驾驶飞机（驾驶，副驾驶） 战斗机的编组（长机，僚机） 提示：这些任务都有共同点：在高速度中完成任务，任务有较高的技术要求，任务失败的代价很高。 结对编程中的角色 结对编程中有两个角色： （a）驾驶员（Driver）是控制键盘输入的人。 （b）领航员（Navigator）起到领航、提醒的作用。 这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编辑程序等），另一人负责导航、检查、掩护等。 同时

如何定义自由职业 自由职业 = 自由 + 职业 自由职业是一个组合词，很多人会第一眼看重的是自由，这里我要强调的是职业。 职业就是你（作为个人）的产品，也就是你生存下去的根本。 比如有人是程序员，那么你的产品（产出）是代码；有人是写手，你的产品（产出）是文章。 而自由职业并不是每个人都适合。要看每个人的追求是什么。 有的人追求稳定，有的人喜欢探索；《穷爸爸富爸爸》中有一幅图可以很好的解释职业（如下）： 我们每个人的职业可以分在EBSI四个象限： E(mployee) 职员，这里适合追求稳定的人 B(usiness) 创业，这里非常刺激 S(elf-emplyed) 自由职业，这里也很刺激，介于E和B之间 I(nvest) 投资，这里每个人都应该要做 德雷福斯模型 而每种职业的晋级（发展）基本遵循德雷福斯（Dreyfus）模型。 新手 高级新手 胜任者 精通者 专家 1. 新手 新手最大的特点是，需要指令清单。告诉我怎么做，最好是一步一步的指令。 2. 高级新手 高级新手不想要全局思维。他们会局限于某个部分，而无法看到全局。 3. 胜任者 胜任者能够解决问题。胜任者通常是非常主动，且足智多谋；善于解决问题。 4. 精通者 精通者可以自我纠正。处于这个阶段的人会有很强的独立思考能力，可以自我发现（或通过朋友同事的反馈发现）不足，并及时纠正。 5. 专家 专家凭直觉工作。 --

确定选题 团队选题：“背背佳”---英语单词学习微信小程序 对于这次的团队作业，我们组想了很久最终决定了做一个英语单词学习的微信小程序。大家都知道现在微信小程序炙手可热，各类微信小程序层出不穷，但我们发现周围很多人都有下载关于单词学习的APP，也有去查找类似这次选题的小程序，发现对于英语单词的小程序还没有很完善，因此更确定了我们的选题。 系统详细描述： 应该很多人都用过类似“百词斩”、“扇贝背单词”等英语APP，那我们选题的目标也很明确：帮助用户学习并复习英语单词。那么一款优秀的背单词程序应该这样四个基础功能：单词、发音、音标、释义。我们认为还有必要的是：好友打卡（打卡功能在微信小程序中常见并使用率极高）、例句（可以的话还想提供朗读例句功能）、单词本（添加生词功能，方便巩固复习）、自定义笔记（考虑到用户个体性）等学习功能，复习功能应有选择题、拼写练习、英语联想等，而统计功能应该也有遗忘曲线、背单词数据统计、单词掌握情况统计。这样一看，这个系统应是一个较完整的、以用户角度出发的单词学习小程序。 对于单词学习程序市场上已产出不少，而我们自己通常会去挑选功能目的明确、操作界面简单的APP。功能多固然会方便，但有时候画龙点睛反而会变成画蛇添足；繁杂的界面会把主要功能给掩盖，也会让人减少打开APP的次数。而我们也会通过这两点去完善我们的小程序。 预期用户数量：