敏捷开发

开篇 在前面的章节中，我们说明了如何使用AgileEAS.NET敏捷开发平台俩开发药店系统，但是我们没有从总体上去说明AgileEAS.NET的一些功能，我们都是在细节上讲述了 一些该平台的相关特性，我们在药店系统的开发过程中，只是包含了该平台的大部分功能，还有一些功能，并没有使用到，可能我们后续会继续讲述这些功能。本文就将之前 开发的药店系统，来进行总结和综述吧，之前放出的文章中的配套文档相对来说，还有一些内容还需要完善，不过大体上已经很详尽了，本来想把概要设计文档也放出的，但 是我本机没有特别好的UML建模工具，所以就搁浅了，对大家说抱歉了。下面我们就来总结药店系统开发过程中的心得和体会。 大纲 1、AgileEAS.NET解决了药店系统开发中的哪些问题。 2、药店系统中用到了AgileEAS.NET平台中的哪些技术。 3、并且分析这些技术在其他领域的应用。 AgileEAS.NET平台解决的开发问题 我们在药店中遇到的问题，前面也有具体的文档有分析过，平台提供的功能也是比较强大，主要的功能图如下： 从上图中我们也可以发现，我们的非功能性方面的需求，例如药店系统，需要支持分布式访问支持等。包括一些部署等方面的要求等等。 1、打印问题： 我们的可选择： 水晶报表：微软提供的报表解决方案，功能强大，我认为使用该报表可以做出来一切报表，唯一缺点，需要客户机安装，否则无法使用。

这个作业属于哪个课程 课程的链接 这个作业要求在哪里 作业要求的链接 团队名称 Onecent 作业的目标 对于自己一学期下来对于软件工程这门课的收获与体会做一次总结 Github地址 一.开篇 犹记得自己对于刚开始接触这门课时的迷惑，对于书中很多的专有名词根本就不理解其中的含义。因此第一次作业就是让我们提出让自己迷惑的问题并试着去解答，还有就是发挥自己的想象去做出对于软件工程课程的设想，设想其到底是一门怎样的课程。因此接下来我就会给出自己第一次所提出的问题和所做的畅想的博客地址。 博客地址：（ https://www.cnblogs.com/sl1999/p/11479447.html ） 二.尝试着对自己提出的问题进行解答 1.什么是断言（assert） 在第一次作业中我提出的第一个问题就是什么是“断言”，由于那是我第一次接触断言，所以我对其的含义及用法并不了解。我想现在我可以尝试着对其作出我的解答了。断言其实是防止程序意外出错的一种宏，如果其参数计算为假，则程序发出警告，且退出。在程序进行单元测试时经常就会用到断言。使用断言是一定要记住，ASSERT只有在Debug版本中才有效，如果编译为Release版本则被忽略。对于这个问题是自己在完成作业是，由于进行单元测试，经常用到断言。因此对于断言就有了自己的理解。 2.敏捷的具体含义 正如我在第一次作业里面提到的

1. 什么是 Scrum 　　Scrum 是一种轻量级的框架，适合于小型的、结合紧密的团队开发复杂的产品。 Scrum 是二十世纪后期一些软件工程师协同努力的脑力劳动的成果，现已成为技术领域最具魅力的方法。但 Scrum 并不因此而复杂难用，相反，它不仅适用于技术领域，你还可以轻易将本文中介绍的工具和实践应用于其他领域。 　　一个 Scrum 团队通常由 7 人± 2 人组成，他们在固定的周期用迭代开发的方式一起协同工作。在每个迭代中，他们有充分的时间来评审和反思。“ 检查和调整 ”是 Scrum 的口头禅之一， Scrum 团队还有一个显著的特点就是非常关注 持续改进 ——既包括他们采用的过程，也包括他们的产品。 2. 角色（ Roles ） 　　Scrum 中有三种角色：产品负责人（ Product Owner ）、 Scrum Master 和团队成员。 2.1. 产品负责人（ Product Owner ） 　　从企业的角度看，一个开发团队代表了一笔重大的投资，包括：人员工资、办公室租金、计算机和软件的采购和维护费用等等。 产品负责人的责任在于帮助企业获得最高的投资回报 （ ROI ）。 　　其中一个最大化 ROI 的方法是引导团队做最有价值的工作，同时远离那些低价值的工作。产品负责人控制团队的待办列表中待办事项的优先级顺序。在 Scrum 中

使用Nutz开发应用。 刚配置好Tomcat。启动项目没问题。然后一访问就报错了。 2012-8-18 19:17:40 org.apache.catalina.core.StandardWrapperValve invoke 严重: Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: 23 in the generated java file The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330) at org.apache.jasper.compiler

误区 之前我没有项目经验，在上一家公司的项目管理上，我只是照葫芦画瓢。 产品发起，整个项目没有项目经理这一说。或者说有，但却真的感受不到，一丁点也感受不到。 产品发起会议，或者开发发起会议。无论谁来发起会议，一般都会针对于某一具体需求或者某一具体实现方式。 没有具体的任务规划，任务拆得不够细致。这个和开发自身有关系。当然那时的公司确实没有一些指导性质的模板和导师。 任务分得不够细致，就会导致工期评估差距比较大。 各种O们的临时紧急需求，很多O没有技术背景和项目管理背景。很多时候提出的需求都是发生在项目开始过程中。 都是很急的需求，不得不重新估算时间和排期。开发为了避免延期风险，就是让产品排优先级，然后我们根据优先级估时。 直到有必要的需求都在这个迭代中计划上。 没人全局把控，产品从产品角度，开发从开发角度，业务从业务角度。始终没有一个最终的协调人。 产品在对各种O的对话中，气场和身份不足，导致需求基本是提出就会安排。即便是请出青岛总负责人出面沟通，最终的结果一般就是接受。 之前我们是青岛为开发，北京为产品、UI、前端、测试。异地沟通。电话会议是常有的事情，私下的临时沟通电话更是家常便饭。 信息同步、开会、理解程度 都会造成沟通上的成本增加。 紧急需求上线后，三个月没人反馈。问了才知道，财务提的需求他们没用过。 开会一般都会临时决定，发起人会准备资料

我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确，那么最终得到的结果也是正确的。瀑布开发有非常成功的案例，比如微软。但从总体来讲，瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结，提出了Agile Dev的概念，中文翻译为敏捷开发。 一．什么是敏捷开发 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。 换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。相对于瀑布开发模式，敏捷开发更加灵活可操作。 二．敏捷开发方式及流程 敏捷开发有很多种方式，如scrum,XP,LSD，FDD等，其中scrum是非常流行的一种。 scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。 scrum的基本流程如图所示： 1.po（product owner指产品负责人）负责整理user story，形成左侧的product backlog

这是敏捷开发一千零一问系列的第十篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？ 方案 之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。 方案1：开发人员全体参与架构设计 敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。 一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保不发生歧义，因此做架构的人和写代码的人在一定程度上融合一下，能大量减少不必要的架构设计，尤其是某些细节。 二方面，文档或设计本身不是工作产品，在上面投入太多的工作量，极有可能是浪费而非保障。 当然问题是：哪些人有能力做架构？ 这个问题如果换成：哪些人可以开一家新的世界500强企业？答案是“大学在校生”（IT界最近的世界500强多数都是在大学里边成立的）。所以同样是这些人，一样能做架构，只是看怎么做了。 方案2：用师徒团队搭建全民架构团队 如果没有专门的架构人员和编码人员，那么最好的结构就是师傅们做架构，同组的徒弟们将其实现为编码。 “这不也是分工吗？”是的

这是敏捷开发一千零一问系列的第九篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 问题 总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？ 这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。 方案 最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。 现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。 方案1：Sprint0 对于长期的项目，常常引入“Sprint0”的概念。 Sprint0就是在开始不断开发功能的众多Sprint迭代前，先做一个准备工作，大约持续一个迭代的周期。 准备工作的内容五花八门，从团队组成，项目范围，到这里说的架构设计。有些团队每过一段，尤其在发布了重要的版本后，都会重新开一个Sprint0，来分析下一个版本的架构设计。 这样就可能出现几种不同的迭代变形，最左边的是最轻量级的（周期短的、架构不重要的），最右边的则相反。 Sprint1 Sprint2 ... SprintN Sprint0 Sprint1 Sprint2 ... SprintN ... Sprint0 Sprint1 Sprint2 ... SprintN

这是敏捷开发一千零一问系列的第四篇。（ 之一 ， 之二 ， 之三 ， 问题总目录 ） 有一次课程上居然来了一个非开发人员，他是个网站的业务人员，提出了这个问题，并被评为课堂最佳问题之一。 问题 一线业务部门应该怎样具体参与到敏捷开发中来？ 答案 方案1： 敏捷开发中有很多活动是需要业务部门参与的，如果没有时间，第一个要参与的事情是“评审会”，就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用，并提出改进意见。 但是要注意改进意见不要急于实现，而是应该询问下一步原来的计划，或许原来的计划更加重要。 如果能在评审会上对产品未来的应用做出一点预测，对之后的迭代会有帮助。 方案2： 如果能选出一个代表，参与到计划会中，对于产品经理难以解答的问题给出补充解答，是一个更好的活动。 各种解答应该具有预见性，因为所谓软件需求，无非是业务需求在软件中的体现。业务需求很少是没有计划就盲目开展的，因此若能提供预见性的解答，对整个产品未来的方向都会有很大的帮助。 方案3： 将业务架构、商业计划转达给开发人员。 技术架构实际上是业务架构的体现，比如360，其业务从最开始就没打算局限于杀毒，所以业务部门就可以提前告诉开发组，当有一天要开发聊天、安全桌面、安全浏览器的时候，开发组并不需要把一个杀毒软件“重构”成一个聊天软件，这是不可能的。 对于产品研发，业务部门若能将市场定位、商业计划

目录 第1篇Scrum冲刺博客 各个成员在 Alpha 阶段认领的任务 各个成员的任务安排 整个项目预期的任务量 敏捷开发前的感想 团队期望 第1篇Scrum冲刺博客 各个成员在 Alpha 阶段认领的任务 成员 Alpha 阶段认领的任务 谭万钏 前、后端开发；项目架构设计；服务部署 刘志豪 后端开发以及数据库设计编写 谭艺 后端开发以及数据库设计编写 唐崇珂 后端开发以及模块测试 刘霍翔 模块测试以及进度报告的编写 石林峰 模块测试以及进度报告的编写 各个成员的任务安排 谭万钏： 前端页面设计（首页、登录页面、教师页面等）、后端功能包括登录功能等。 刘志豪： 后端功能实现包括提问讨论、评论功能以及数据库编写等。 谭艺： 后端功能实现包括作业上传以及数据库编写等。 唐崇珂： 后端功能实现包括设置功能的实现以及测试总结等。 刘霍翔、石林峰： 主要负责测试总结工作等。 整个项目预期的任务量 任务 负责人 开始日期 结束日期 Alpha版本 数据库 8748 2019/11/18 2019/11/22 建立数据表 8748 2019/11/18 2019/11/19 实现基本操作 8744 2019/11/19 2019/11/22 前端页面 8747 2019/11/18 2019/11/25 首页页面 8747 2019/11/18 2019/11/19 登录页面 8747