敏捷开发

经历了几个从商业角度来看或成功或失败的项目，都会发现代码、设计都会慢慢地、在不经意间腐化。而且有一个项目开始的时候，架构是经过精心设计的，也有较为严格的代码规范，并且通过静态代码检查来尽量保证代码的质量，连code review都有一个可供参考的checklist。但半年一年之后，还是会发现，很多代码都已经臃肿走样，到处都是复制粘贴，动辄好几千行代码的模块，能 work、但不 right的代码。 getting it work is easy getting it right is hard 不禁想问问代码和设计是如何一步步腐化的？ 本文地址： https://www.cnblogs.com/xybaby/p/13173047.html 代码如何开始腐烂 其实大家都听说过 clean code，但不一定真正意识到其重要性，且知道并不等同于做到，而时间更是一把杀猪刀，让程序员秃了，让代码烂了。 一个新项目开始的时候，大家都是满怀壮志，期待灵活可复用的架构，期待成功的产品。与此同时，敏捷开发告诉我们不要过度设计，当然，本身也是很难预料到以后需求变化的方向，于是应该等到第一次变化的时候才去考虑如何重构以应对这一类型的变化。但问题很可能就会出现在这里。 也就是说，也许哪一天，当我们需要加一个新功能的时候，会发现原来的设计和代码不是很方便增加这个新功能。当然，我们不应该过多苛责之前的设计

项目 内容 课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/nwnu2020SE 这个作业要求链接 https://www.cnblogs.com/nwnu-daizh/p/12976163.html 团队名称 L.M.W.Y.D队 团队成员分工情况 杨玲(代码撰写)；刘志梅（代码撰写）；王斌龙（数据库）；东文财（界面代码分析和部署）；马凯军（界面代码分析和部署） 团队的课程学习目标 1.掌握软件编码实现的工程要求。 2.学敏捷软件开发过程。 这个作业在哪些方面帮助团队实现学习目标 每天的代码编写 团队博客链接 https://www.cnblogs.com/LMWY/p/13167454.html 团队项目Github仓库地址链接 https://github.com/1171849616/team-project 任务1： 团队软件项目编码准备，要求如下： （1）软件开发环境配置： Eclipse插件技术开发-RCP（Rich Client Platform）：胖客户端应用程序 jdk1.8 数据库mysql （2）项目编码规范说明文档，上传到团队项目Github仓库： 已上传 https://github.com/1171849616/team-project （3）博客中提供团队项目仓库中上传项目编码规范文档后的截图： 任务2：

上篇分享了老板经常加需求改需求的四种情况和应对方法，这篇分享产品经理经常改需求、加需求的情况。 产品经理经常加需求、改需求，主要有四种因素决定： 1）老板的瞎指挥； 2）产品经理本身的能力不足； 3）程序员的能力不足； 4）项目流程不合理和管理方法存在缺陷。 这些因素要分开来分析，不同因素引起的问题要用不同的方法来解决，不能一概而论说产品经理经常改需求、加需求是产品经理的问题。 这部分我们分成两篇文章来分享，这篇分析“人”的能力不足而引起的经常改需求、加需求的情况，下篇分析项目流程和管理方法不合理而引起的改需求和加需求的情况。 1. 产品设计流程 我们要解决产品经理经常加需求改需求的问题，就要从产品设计的过程上来分析，从根源上找到引起问题的原因，才能从根本上解决这些问题。 产品经理做产品设计的流程有三个步骤： 1）设计产品框架 2）用思维导图设计模块、功能及功能间的关系 3）设计产品原型或用户故事 这个是简化的流程，实际流程比这个复杂的多，这篇不是讲产品设计的文章，我们就不用完整的流程。这3个步骤，每个步骤出问题，都会给项目带来不同程度的问题，甚至是灾难。 2. 设计产品框架 这个步骤，主要的工作是做产品的顶层设计，产品针对哪些用户，解决用户的什么问题，商业模式、赢利模式是什么，产品的规划是什么，分多少步骤实现这个规划，每个步骤核心要解决什么问题，以及实现计划是什么等。

本文已收录 GitHub ，更有互联网大厂面试真题，面试攻略，高效学习资料等 我们前面讲的任务分解，主要是在讲开发任务的分解。今天我们换个角度，看看需求的分解。是的，需求也要分解。 有一次，我和一个做开发的同事聊天，他给我讲了他近期的烦恼。 同事：我们现在就是需求太多，开发的人太少，再这么干下去，哪天觉得自己抗不住了，我就拍拍屁股走人。 我：你没尝试着砍砍需求？ 同事：怎么没尝试？产品的人都不同意。这批功能他们都说是关键功能。 我：你有没有尝试把需求拆开了再砍呢？ 同事：还可以这样？ 同事很惊讶，我一点都不意外。我们都是在说需求，但彼此对需求的理解却是大不相同。我先来问个问题，提到需求这个词，你会想到什么呢？ 以我们用了好多次的登录为例，如果我问你这个需求是什么，大多数人的第一直觉还是用户名密码登录。 基本上，闯入你脑海的需求描述是主题（epic），在敏捷开发中，有人称之为主用户故事 （master story）。 如果你对需求的管理粒度就是主题，那好多事情就没法谈了。比如，时间紧迫的时候，我想砍需求，你问产品经理，我不做登录行不行，你就等着被拒绝吧。 但是，如果你说时间比较紧，我能不能把登录验证码放到后面做，或是邮件地址验证的功能放到后面，这种建议产品经理是可以和你谈的。 这其中的差别就在于，后者将需求分解了。 大多数人可以理解需求是要分解的，但是，分解的程度不同

软件测试以后需求量会越来越大，随着互联网的发展，市面上产品会越来越多，产品的质量也越来越重视，测试的投入也是慢慢加重，你还会觉得软件测试行业没有前景和出路吗 ？ 是你自己想太多，我觉得有前景和出路，不是仅停留在手工测试上，你要全面发展，自动化测试和性能测试，你都要会，慢慢积累，这些都是你的财富，到每个公司去都是很吃香的 至于说软件测试都是女生，男生不适合，没有这样的说法，我自己管理的团队，男生比女生多，男生逻辑思维会比女的强，在一些比较重要的测试点，我会交给男的去测试，测试是不分男女，其实是看你个人的能力 刚刚上面也说过，不要只停留在手工测试，虽然后面测试需求会变大，但是要求也会随之变高的，竞争也大，人总是要压力中脱颖而出的，要时时刻刻保持学习的态度，才不会被这个社会所淘汰。 由于历史原因，大部分测试人员，最开始接触都是纯功能界面测试，随着工作年限，会接触到一些常用测试工具，比如抓包，数据库，linux等。 测试行业的现状 现在测试行业的的趋势，你去面试任何级别的测试工程师都会问你是否会自动化测试，所以自动化测试已经是必备技能，而不是加分项。 换句话说，会用开源的测试工具不足以在公司涨薪或者跳槽至一线互联网大厂。因为真正企业自动化测试落地肯定是一个团队在做，当你熟悉使用这些开源框架之后，你会发现有些框架之间是相通的，所以基于这些开源框架，我们打造一个属于自己的测试框架

什么是质量内建 随着时间的推移，我们项目的开发效率会逐渐降低，直到几年之后整个项目可能就无法维护，只能推倒重来。具体的表现首先就是随着时间推移，我们会发现整个需求列表里面能做的需求越来越少，因为每当我们增加一个新特性，需要改动的代码就非常多，所以最后每提出一个新的需求，团队评估出来的改动成本都非常高，导致最后难以增加新的特性。 第二个表现就是缺陷难以修复。我们做出来的系统只要有人用就会有反馈一些线上的故障，一开始代码很简单的时候修复起来是很快的，但是随着代码越来越复杂、代码行数越来越多，我们会发现定位问题太难了。尤其是现在我们的项目采用的是非常复杂的架构，所以当用户线上报错的时候，我们很难去定位到是哪里出了问题。但其实只要定位到了问题，修复起来是很快的。 第三个表现我们称之为“打地鼠现象”，简单来说就是当你“按”下一个缺陷的时候，又会蹦出来几个新的缺陷。这样会导致大家在工作的过程中压力非常大、心情也会比较沉重。 所以对于这些挑战，我们也有想办法去解决，CI、CD 以及 DevOps 的出现都让我们看到了很好的方向。但是我看到很多团队其实只是靠 DevOps 解决了一些基本的问题，并没有解决核心的问题。这是为什么呢？因为核心问题主要是靠开发人员的能力提升来解决的，但由于改变一个人是很难的，所以企业往往会绕开这些问题。所以我今天分享的内容主要会涉及到开发人员如何去写代码等一些实践。

最近在某乎上看见一个比较热的问题：一个小公司如何进行数据化管理？ 作为在数据行业的老人，我觉得有必要从痛点、模式、方法来为各位解答疑惑，同时，我也调研了几十家中小型公司的管理层和CIO，他们也给出了自己的思考，都总结在下面的这些内容里。 小公司的数据管理，相比于大公司，是比较难的，为什么？ 首先，中小企业的创始人未必能够认识到数据的价值。对于一些早期的业务，光依赖人工的作业方式，也能发展得不错。老板看不到明显的痛点，又考虑到投入产出比，自然不会选择这种模式。 第二，就是钱，也就是足够的资金预算，这点我就不说了，自己去体会。 第三，数字化转型不仅是引入系统这么简单，还伴随着组织架构、业务流程、决策权力的调整，这就对业务原有的运作机制提出挑战，甚至极可能动到某些管理者的奶酪，因此推动的时候必然遭受阻力。 第四，另外一个难题就是企业缺乏数据文化，员工不了解数据管理的目的，也没有利用数据辅导业务的意识，IT费尽心血搭建的报表平台，业务也不用。 所以很多企业数据化建设项目干了一大半，但是没有业务部门的支持，最后还是凉凉。 所以，中小企业的数字化转型，不是一件简单的事情。在不同阶段，面临的挑战也不一样。既考验老板意识、也考验资金体量、组织能力、人才素质等等。但毫无疑问，数据管理是中小企业做大做强的必由之路。 在上面这种缺人、缺钱、缺文化、缺基础的情况下，中小企业数据化管理应该从哪开始下手呢？

这个作业属于哪个课程 课程地址 这个作业要求在哪里 作业地址 这个作业的目标 2020-06-03 Beta冲刺第七天 作业正文 作业正文地址 其他参考文献 《构建之法现代软件工程》 明日安排/问题困难/心得体会 学号 明日安排 问题困难 心得体会 221600137 无 无 无 221701117 基本完成，后续测试若发现问题再改进 如何在移动端正常显示遇到困难 七天的辛苦终换成欢天喜地的愉悦感与满足感 221701135 无 服务器数据同步问题 团队合作重在沟通 221701216 暂无 暂无 看到测试发现的bug得到完善很开心 221701239 继续测试,发现问题并改正 暂无 感觉大家合作做出来的网页真的挺好的,基本功能也挺完善的 221701334 无 无 无 221701419 检查代码，一些交互看需不需要加 无 今天的bug修改起来都比较容易，出现的问题都较浅，很容易定位到问题。但是回顾自己完成的界面并不满意，一些细节交互没有体现 021700531 无 无 大佬带的好 221701315 暂无 暂无 时间飞快，好好做好自己的工作 昨日完成的项目内容 学号 项目内容 花费时间 剩余时间 221600137 无 0 0 221701117 完成个人页面文章显示问题，修改各种跳转错误的问题 160 0 221701135

项目 内容 团队名称 三带一队 日期 2020.06.18 地点 10A 216外 1.1. 今日完成任务情况以及遇到的问题 组员 完成的任务 葛佳诚 系统模块的连接与人脸识别模块的测试 张芹 人脸识别模块的编写与实验 李佩杉 人脸识别模块的测试 赵栋 系统模块的连接与系统主页等文字内容的编写 任务的代码提交情况如下图所示。在今天的任务中，我们遇到的主要问题有：人脸识别的准确率问题。 图1.1.1 Github界面 1.2. 成员贡献时间 组员 贡献的时间（h） 葛佳诚 12 张芹 8 李佩杉 6 赵栋 2 1.3. 明天任务安排 组员 明天的任务安排 葛佳诚 撰写冲刺总结博客 张芹 撰写冲刺总结博客 李佩杉 撰写冲刺总结博客 赵栋 撰写冲刺总结博客 1.4. 站立会议照片 站立会议照片如下： 图1.4.1 会议照片 1.5. 项目燃尽图展示 项目的燃尽图如下： 图1.5.1 项目燃尽图 1.6. 项目总体进度 今天是小组开始Alpha阶段冲刺的最后一天，通过小组成员的努力，我们完成了Alpha阶段的冲刺并实现了系统的基本功能，期间遇到了许多问题，我们也在解决这些问题的过程中学习了许多，希望在之后的学习实验中，我们能做得更好。 来源： oschina 链接： https://my.oschina.net/u/4411837/blog/4317418

Beta冲刺(4/7) 这个作业属于哪个课程 班级 这个作业要求在哪里 作业要求 这个作业的目标 记录冲刺当日的SCRUM会议和PM报告 作业正文 刚下飞机——Beta冲刺(4/7) 其他参考文献 ... SCRUM会议 会议记录表 学号 组员 昨天花了多少时间 还剩余多少时间 昨日完成的任务 遇到什么困难 今天的进度 明天的计划 221701317 卓晓鑫 6h 3d 完成敏感词功能、重构Admin部分代码 无 实现举报处理中相关接口、修复bug 实现成就、认证学校管理相关接口，重构Action和Service层代码 221701328 张春翔 5.5h 3d 前端完成编辑问题、回答功能，完成删除问题、回答、评论、回复的功能 无 前端完成查看消息界面和认证界面 前端完成查看成就功能，对需要显示认证信息的地方进行补全 221701319 郭秋中 4h 3d 完成编辑问题的获取问题内容，以及修改Bug 无 消息的生成，以及将未读消息已读 修改Bug，优化后端代码，完成剩余功能。 221701333 池政涛 3h 3d 编辑回答接口，bug修复 暂无 认证接口编写，举报信息处理接口编写，bug修复 修复bug，优化代码，编写相关接口 221701337 朱凯文 6h 3d 实现分页，单个删除，问题举报处理的批量选择，举报处理气泡提醒 无 完成批量删除。评论，回答，举报，回复处理界面