（1）团队有一致的集体目标，团队要一起完成这个目标。

（2）团队成员有各自的分工，互相依赖合作，共同完成任务。

3.1.写了再改模式（Code-and-Fix）：不一定存在需求文档，直接编写代码，出现问题或需求变化时直接进行改动

3.2.瀑布模型（Waterfall Model）

• 局限性：

（1）各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来。

（2）回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯。

（3）最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。

• 适用范围：

（1）如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证。

（2）产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证。

（3）使用的技术非常成熟，团队成员都很熟悉这些技术。

（4）负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。

• 瀑布模型的各种变形：

（1）生鱼片模型：各相邻模块像生鱼片那样部分重叠。缺点：无法确定上一阶段是否结束、什么时候结束。

（2）大瀑布带着小瀑布：为了解决不同子系统之间进度不一，技术要求迥异，需要区别对待问题。缺点：难度较大。

重计划，重事先设计，重文档表达的各类模型（如：瀑布模型等）的集大成者。RUP将软件开发各个阶段整合统一在一个统一的框架内。

• RUP的规程（工作流）：

（1）业务建模：UML等语言

（2）需求

（3）分析和设计

（4）实现

（5）测试

（6）部署

（7）配置和变更管理

（8）项目管理

（9）环境

• RUP软件开发阶段：

（1）初始阶段

（2）细化阶段

（3）构造阶段

（4）交付阶段

    渐进交付的流程：开发->发布->听取反馈->根据反馈做改进

    MVP即最小可行产品，又称最小功能集。具体做法是把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。可以适用于新创立的企业在市场不确定的情况下来检验产品是否可行。

    MVP的指导思想与渐进交付类似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值（产品最区别于竞争产品的地方），为了突出核心功能，别的辅助功能可以不考虑或者用别的平台提供的服务来代替。

    MBP即最强最美产品，对用户需求了然于心，或者产品团队比用户更了解用户的需求，把产品最全、最美的形态展现出来，一举征服用户。一般应用于时间比较充裕，客户要求标准比较严格，开发团队在此之前做了大规模的市场调研摸清用户需求。

（1）使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。

（2）团队的各个成员对团队的目标、角色、产品都有统一的理解。

（3）尽量使用成熟的技术和做法。

（4）尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。

（5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。

（6）增加团队的自我管理能力。

（7）专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

（2）敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势。

（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。

（4）业务人员和开发人员在项目开发过程中应该每天共同工作。

（5）以有进取心的人为项目核心，充分支持信任他们。

（6）无论团队内外，面对面的交流始终是最有效的沟通方式。

（7）可用的软件是衡量项目进展的主要指标。

（8）敏捷流程应 能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去。

（9）只有不断关注技术和设计，才能越来越敏捷。

（10）保持简明一尽可能简化工作量的技艺 一 极为重要。

（11）只有能自我管理的团队才能创造优秀的架构、需求和设计。

（12）时时总结如何提高团队效率，并付诸行动。

第一步：找出完成产品需要做的事情——Product Backlog

第二步：决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog

第三步：冲刺。期间团队通过每日例会（Scrum Meeting）进行面对面交流，所有人向同伴报告进度。Scrum Master根据项目情况，用简明的图表展现整个项目的进度（燃尽图Burn Down Chart、看板图Kanban）

第四步：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

（1）自主管理：自己挑选任务、每次冲刺结束后总结经验并改进

（2）自我组织：每个人联合起来对项目负责

（3）多功能型：项目的测试、说明书等由每个人负责

（1）敏捷宣言表明的是一些优先级， 不必当作圣旨或者教条来争论。

（2）Serum Master 不是一个官， 而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。

（3）一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

（4）在复杂的项目里，要让一线团队成员做决定。

（5）创业公司的团队其实经常是运行在某种快节奏的敏捷的模式中(只不过大家太忙，没工夫论证自己到底有多么敏捷)。

（6）在Scrum 计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。

（7）不要和管理层谈“流程”，他们只关心“结果”。

（8）在大型团队、跨地区的团队，或者复杂项目中，Scrum 并没有非常完美的答案，Scrum的创始人也承认这一点。

1. 2016级计算机科学与工程学院软件工程 (西北师范大学)

2. 2019秋福大软件工程实践Z班 (福州大学)

3. 2019春季计算机学院软件工程 (北京航空航天大学)

1. 由于我们平常与学校内的人员接触较多，因此想选择外校学院的团队项目进行学习；

2. 由于在外校的团队项目中，移动应用程序开发较多，而我们对移动应用开发不够熟悉，因此选择了其他的团队项目；

3. 经过大致浏览，所有的团队项目中，这一个团队的项目我们较为感兴趣，比较贴近我们的校园生活。

 答：角色是当初在进队伍后大家自己选择的。人尽其才的话，由于我们组组长是比较有代码能力的，在后端工作上很大依赖于他，要是当时把任务多分派下去，感觉人力资源能得到更大的利用。  

（2）团队成员之间有互相帮助么？

 答：有，主要是在前端彼此和后端彼此，然后组长给了我们很多帮助。  

（3）当出现项目管理、合作方面的问题时，团队成员如何解决问题？

 答：项目管理方面的问题主要通过开会讨论解决，合作方面一般是由合作双方自行商讨。

（2）分工明确，团队成员的自我管理能力强。

（3）团队各个成员在每次学习中都会总结学习成果以及第二天的学习计划。

（4）团队成员掌握技术水平不一致，人尽其才，项目中的技术是使用成熟的技术；

• 该团队的Github页面如下图所示，并没有包含代码规范文档

• 该团队在Github中提供数据不完整，在做了相应的完善后，运行结果如下：

• 数据库设计图
  

• 数据库详细设计
  

• 测试运行结果

• 项目主页界面如下图：
  

• 用户登录界面如下图：
  

• 发现的Bug如下：

• 在用户的注册流程中，将基本信息填写完成的情况下点击注册将生产错误图1，身份证号码一栏的数据没有传输至后台，在检查了项目代码之后发现在网页中发生错误图2。

用户注册界面如下：

错误图1

错误图2

• 在正常登录用户后，用户的个人页面如下面两张图，可见用户的信息没有同步显示在前端网页中。
  

![](https://img2020.cnblogs.com/blog/1946992/202004/1946992-20200410211418147-1422612861.jpg）

除了上述出现的问题外，还存在其他的Bug和可优化内容。