[软工顶级理解组] Beta阶段事后分析

目录

设想和目标

  • 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    我们软件要解决的问题有非常清楚的定义，就是要做一款北航学生能够方便使用的教务助手，来解决北航学生每次查询课表、空教室、成绩或是课程中心作业等业务时，都需要经历繁琐的过程，如打开微信，搜索北航小程序，继而进行操作，抑或是小程序没有相关信息的课程中心作业，更是需要登录北航vpn，选择课程中心后进行查询的问题。在Alpha阶段我们已经实现了课表查询、空教室查询、成绩查询、课程中心DDL查询等功能，Beta阶段我们选择在此基础上进一步实现用户呼声较高的功能，校历查询以及用户反馈，并实现我们软件的特色功能————课程评价功能，并解决用户反映的运行速度慢的问题，同时美化程序界面尽可能给用户带来更好的使用体验。

    对典型用户和典型场景也有清晰的描述，在Alpha阶段的基础上，我们对我们的新功能设想了新的典型用户及场景，典型用户仍然为北航学生，典型场景有在校外想要查询自己成绩时，或是上课前查找教室、或是在校外需要查看自己的课程中心的作业时刻表，或是在选课前想要了解以往的学生对该课程的评价，或是想要查看校历已经节假日信息等。

  • 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？)

    • 功能：Beta阶段计划新增功能三个（用户反馈，校历查询，课程评价），已全部实现，并美化了展示界面。
    • 交付时间：按照计划在6月3日完成交付上线。
    • 用户数量：原先计划用户数量400，实际峰值达到379人，未达到目标，原因是Alpha阶段用户已经饱和，并且烤漆宣传难度变大，加上一些用户期望的考表查询功能未能实现等原因，Beta阶段尽管大力宣传仍然和目标有20余人的差距，但我们也比较满意了。

  • 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    • 代码规范：后端为了改进我们Alpha阶段堪称混乱的代码风格，我们在Beta阶段伊始引入pylint，将一条条报错suppress，工程几近重构。但是最后做出来的成果是值得的，如今的代码非常整齐清爽，格式整齐。而且代码风格检查在GitHub平台上使用Action功能进行了自动化部署，每个commit都需要通过代码风格检查。前端人员也认识到代码规范的重要性，虽然没有找到合适的工具，但也利用AS自带的reformat功能来增强代码的可读性。
    • 爆出bug情况：Alpha阶段在测试阶段爆出大量BUG的现象不复存在，用户反馈良好。
    • 继续开发指导性：Beta阶段增加了完备的运行指导、接口规格说明、错误处理说明、更新日志等详细文档，对于未来可能接手的团队可以说非常友好。
    • 运行速度：在Beta阶段，我们针对用户反馈的运行速度慢的问题，重构了爬虫部分，从4台服务器降到2台服务器，大大降低了资源的占用，并且提升了运行速度。

  • 用户量， 用户对重要功能的接受程度和我们事先的预想一致么？ 我们离目标更近了么？

    • 用户量方面，Beta阶段的宣传虽然没有Alpha阶段那么顺利，但也引起了非常多同学的关注，新增的功能使我们的产品更加完善，更加具备用户的吸引力，发布一周，经过我们的极力宣传，用户量净增加近170人，查询次数10000余次，说明其中的大多数用户不是仅仅使用了一次软件，这点很让我们欣慰，从用户的使用次数上看，课表查询、成绩查询以及新增的校历和课程评价功能较受欢迎，不少用户也通过反馈接口为我们提出了宝贵的建议。经过两个阶段的打磨，我们这个软件已经有了教务和小程序不具备的优势，快捷且方便，实现了我们最初的目标。

  • 有什么经验教训？ 如果历史重来一遍，我们会做什么改进？

    • 我们在设想时希望我们的产品能够在iOS的应用商店上市，然而我们在开发时却发现iOS开发者账号一年需要688元才可使用，这就导致了相当可观的iOS用户的流失。
    • 如果历史从来一遍，我们会提早分析目标的可行性，从而使我们的目标更加合理。

计划

  • 是否有充足的时间来做计划？

    • 在Alpha阶段的发布阶段我们就已经开始进行Beta阶段所需工作的讨论，再加上Beta阶段的开始一周，我们有接近两周的时间来做计划。与Alpha阶段类似，我们在Beta阶段的设计阶段基本上确定了每个人的任务，在设计阶段的最后我们在GitHub上创建Issue，规划所需时间，以及完成时间。在开发过程中我们在组会上相互沟通，大家在PM的统一协调下对自己的计划进行微调。

  • 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    • 在组会上PM展示目前讨论得出的Todo list，并针对每一项内容进行介绍，此后大家有针对性的提出自己的建议，并进行讨论，达成一致后PM对计划进行修改。

  • 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？

    • 我们在计划阶段规划的工作基本完成，但是iOS版本的开发没能完成，这是因为iOS的开发者账号一年要688元，团队无法负担。

  • 有没有发现你做了一些事后看来没必要或没多大价值的事？

    • 我们所做的工作全部投入使用，没有被舍弃不用的功能代码。

  • 是否每一项任务都有清楚定义和衡量的交付件？

    • 是的。我们每一项任务都有明确的交付标准，对于开发者来说，主要是代码、文档和apk文件。对于PM来说，主要是博客、Issue管理等。

  • 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

    • 由于前端更换人员、任务较重且其他课程也有DDL的情况，前端的开发进度远远落后于后端，使得前后端的沟通不够及时。
    • 课程评价功能需要将课程与课程代码一一对应，由于教务系统数据格式杂乱，导致出现过多的异常数据。
    • 前一个问题在设计阶段没有估计到，这是因为临近考期其他课程也会有DDL以及前端任务较重的情况没有考虑到。后一个问题已经被估计到了，但是没有估计到教务系统的格式杂乱过于严重。

  • 在计划中有没有留下缓冲区，缓冲区有作用么？

    • 存在缓冲区。与Alpha阶段类似，我们仍将最后的一周作为测试阶段，它同时也发挥了缓冲区的作用。我们在最后一周进行了一些针对开发阶段暴露出的组内沟通不足所造成的问题的修改以及前端部分未完善功能的继续开发。

  • 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    • 如果还有下次的话，将来的计划依然会留出足够时间的缓冲区，用于测试和弥补开发阶段的失误。
    • 同时会进行准确的每日任务分配，尽可能不要出现某几天疯狂加班补进度的情况。

  • 我们学到了什么？如果历史重来一遍，我们会做什么改进？

    • 计划对于团队项目开发来说，是非常重要的事情。本次Beta阶段的所有成果得益于我们先前做好的计划。
    • 如果历史重来，我们需要制定更全面完善的计划，尽量不要出现因为开发者账号等原因舍弃掉部分计划单情况。

资源

  • 我们有足够的资源来完成各项任务么？

    这次有了新成员的加入，也有以前队友的退出，但是新来队友还是很快着手开发项目了。所以人力上我们是充足的。而在服务器这些资源上，我们也尽量的修改代码减少爬虫对于资源的依赖，从原来4个服务器，减少到现在只要2个服务器就可以了。

  • 各项任务所需的时间和其他资源是如何估计的，精度如何？

    首先，大体的人员分布由第一次例会讨论得出。然后在每日例会中，每个人说出自己昨日完成的任务，然后再自己估计明日完成的任务，总体来说精度十分准确。

  • 测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？

    我们拿了一周的时间来进行单元测试和用户内测，总体来说测试时间和人力等资源是足够的。而对于不需要编程的资源，由于有了阿尔法阶段的基础，我们在这次很重视美工设计，留出了充足的时间来做该任务。

  • 你有没有感到你做的事情可以让别人来做（更有效率）？

    没有，我认为我们小组每个人都在自己的职位上充分发挥了自己的用处，可以说每个人都对自己的任务尽心尽力，注入了自己的心血。

  • 有什么经验教训？如果历史重来一遍，我们会做什么改进？

    在Beta阶段时，我们的代码风格问题也解决了，对于爬虫占用资源过多我们也通过更换包降低了爬虫所占用的资源。

变更管理

  • 每个相关的员工都及时知道了变更的消息？

    • 我们的项目变更大概分为部门内变更和跨部门变更。我们的团队有前端、后端、爬虫、服务器部署与管理四个部门。部门内的变更一般会部门内在微信群进行日常沟通，每个相关员工可以及时知道变更的消息。如果需要部门间协作进行变更，我们往往会在每日例会中全组共同讨论，规范变更内容，以减少额外的沟通成本；对于一些紧急变更，我们会在团队微信群进行沟通与通知。
    • 通过上述沟通机制，每个相关员工基本能够知道及时变更的消息。在Beta阶段的开发中，我们并没有遇到什么因为变更通知不及时导致的问题。

  • 我们采用了什么办法决定“推迟”和“必须实现”的功能？

    • 必须实现市场缺少而用户迫切需要的功能。
    • 经过前期调研，我们发现学校缺少可以畅所欲言的课程评价的平台，这导致很多同学信息闭塞，很容易在选课时踩坑，课程评价功能是用户迫切需要的。所以我们以课程评价作为必须实现的核心功能。
    • DDL推送对线上学习的用户来说需求迫切；意见反馈可以使我们及时收到用户反馈，实现与用户的沟通，因此属于必须实现的功能。
    • 校历功能与其他产品重合度较高，虽然从产品完整性来讲我们将其列入了必须实现的功能，但是对其具体功能进行了阉割，只保留了普通的查看校历、课程中心DDL导入校历这两项，其他的如自主添加DDL等功能被推迟。
    • 还有一些功能由于客观原因只能推迟实现。如在规划中，我们最初将”iOS版本开发”列入了待开发功能，但经过调查，我们发现iOS开发者需要付费且费用过高，因此我们只好推迟（放弃）了iOS版本的开发。而考表查询和博雅查询功能由于缺少原始数据，也只能推迟开发。

  • 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

    • 兼容性：对于几乎所有Android机型和主流版本都能够实现兼容。
    • 易用性：按钮功能明确，功能入口醒目，弹窗提示易懂。
    • 稳定性：所有功能都能正常运行，进行常规操作时几乎不出现运行时Bug。
    • 及时性：后端能及时更新学生的信息变化，并反馈给前端。

  • 对于可能的变更是否能制定应急计划？

    能。在每日例会或者微信群中，一些员工会提出一些意见和建议，当经过例会讨论被采纳后，我们会制定应急计划，将任务分配到人并约定好完成变更的DDL。

  • 员工是否能够有效地处理意料之外的工作请求？

    能够有效的处理，我们在开发过程中也出现了许多意料之外的请求。对于意料之外的请求，我们的团队成员都比较积极主动，空闲的员工会主动接下请求并有效的处理好，在大家都没空时，也会积极沟通协作处理好请求。

  • 我们学到了什么？ 如果历史重来一遍， 我们会做什么改进？

    • 变更可能是团队开发中必上的一课。开发过程中，很难保证一切工作都能如计划一般如期进行，且开发过程中也会发现当初计划的不足。
    • 历史重来一遍，我们会更加审视计划，尽量减少变更。如果有所变更，团队成员需要更及时地提出困难，更早的分配任务和DDL，尽量保证其对正常开发任务的最小影响。

设计/实现

  • 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

    设计工作是在Alpha阶段结束到Beta阶段开始前一直在进行的，是我们组员根据Alpha阶段反馈以及Alpha来不及做的功能来设计的。是由PM来主持会议，组员一起讨论完成的。

  • 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

    其实开始设计的时候模凌两可的情况挺多的，比如前端的课程评价页面到底设计成什么样的结构，数据交互怎么做才更方便。这种问题由于还没开始开发，如果把格式定死的话，碰到新的问题不好处理。这种问题我们一般是通过开发过程中前端和后端和爬虫一起讨论来明确。

  • 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML， 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

    我们使用Github的pull-request进行代码管理，使用Issue进行进度管理、使用墨刀进行原型设计，后端使用了单元测试，以TDD的方式进行开发。我们在代码管理方面比较有特色的是使用Github的action来进行代码风格检查，每提交一次都会自动进行检查。我们没有使用UML文档。

  • 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？

    根据测试阶段的Issue数量来看，课程评价功能的bug是最多的，这个功能应该是我们App中最复杂的功能，共有3个嵌套页面，每个页面还有很多小块，产生bug很正常，我们在测试阶段针对课程评价也做了充分的测试，目前的发布版本应该是没有明显bug的。

  • 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

    我们的分工是PM进行后端和爬虫的Code Review，单彦博同学进行前端的Code Review。在每个人更新代码后，都会向总仓库发起一个pull-request，Code Reviewer在检查PR中的代码后，将其合并到总仓库。

    代码风格方面，后端和爬虫使用Python，我们使用pylint和pylint-django第三方包对代码进行静态检查，并配置了适合于我们项目的.pylintrc配置文件。代码风格检查在GitHub平台上使用Action功能进行了自动化部署，每个commit都需要通过代码风格检查。

    前端遵循Dart语言的一般代码规范。由于Android Studio没有合适的适配Dart语言的Checkstyle配置文件，所以我们主要靠AS自带的Reformat功能对缩进换行等进行限制，而变量名、程序结构等其他风格由组员自行维护。

  • 我们学到了什么？ 如果历史重来一遍， 我们会做什么改进？

    我们学到了团队协作时怎么进行代码管理，学到了怎么写代码方便他人阅读，学到了接口说明文档的重要性。如果历史重来一遍，我们可能没有什么遗憾，但是如果Beta阶段多给我们一周时间，我们也许会把考表查询功能完成，因为Beta阶段结束的时候考表才发出来，所以在这之前，爬虫无法获取数据，就没有做这个功能。

测试/发布

  • 团队是否有一个测试计划？为什么没有？

    我们团队有较为完善的测试计划，并且Beta阶段的实践也证明了这一点：

    • 在开发阶段，后端每完成一个模块就编写单元测试来验证模块各个功能的正确性；同时，在开发基本完成以后，由前端、后端、爬虫各自构造小规模数据来验证功能的正确性。
    • 在测试阶段，前端、后端、爬虫三者共同运行，用开发人员的统一认证账户获取数据，详细测试各个功能是否正确运行；同时，小范围地分发测试版本的apk，测试不同机型对apk的适配性。
    • 在验收阶段，进行小规模的压力测试，保证对于用户量较多的情况下能及时响应请求。

  • 是否进行了正式的验收测试？

    如上一个问题所答，我们进行了正式的验收测试，包括功能、压力测试。

  • 团队是否有测试工具来帮助测试？

    有，例如：Postman、PyCharm、Coverage等。

  • 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

    根据用户的请求响应速度与功能的正确性来测量。测试的目的不是为了发现bug，而是为了提高软件的质量，降低软件出现缺陷的可能性；我们的测试工作一方面间接提高了软件质量，另一方面也检验了我们软件开发过程存在的问题（如错误处理是否完善，架构设计是否好等）。

    不足之处就是在编写代码的过程中应该更加注重回归测试，防止发现问题难以定位。

  • 在发布的过程中发现了哪些意外问题？

    在Beta阶段的发布过程中我们没有遇到什么问题，Alpha阶段中教务格式的不统一问题已经基本解决，前端出现的问题也只是交互逻辑上的优化，这也证明了我们的测试是足够充分、完善的。

  • 我们学到了什么？ 如果重来一遍， 我们会做什么改进？

    在Beta阶段，我们深刻认识到了回归测试的重要性。如果重来一遍，我们会在做增量式开发的过程中尽可能多地做回归测试，防止在开发后期遇到问题时难以定位bug所在。

团队的角色，管理，合作

  • 团队的每个角色是如何确定的，是不是人尽其才？

    • 首先，确定好团队的大致分工，将开发工作分为三类：前端、后端、爬虫，另外还有一名PM。
    • 经过讨论、商议、自愿分配，最终确定了这四类工作的人数和人员。
    • 每位同学都进行自己自愿选择的工作，可以说人尽其才。

  • 团队成员之间有互相帮助么？

    团队成员的互相帮助是必不可少的。无论是同部门之间的相互扶持，还是跨部门的会议讨论，商议工作，都是团队成员互相帮助的体现。下面的感谢内容也体现了团队之间的帮助。

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

    目前来说，我们团队没有遇到这方面的障碍。不过，在出现相关问题的苗头时，我们会及时在Scrum Meeting中提出，共同商议，是否需要更换岗位，重新分配工作，或者重新计划相关任务。

每个成员明确公开地表示对成员帮助的感谢 。

成员 感谢内容
孙旭东 我感谢郭骏对我的帮助，因为在我转会进入之后给我细心的指导，并在我遇到问题时耐心解答。
我感谢单彦博对我的帮助，因为在我配置环境时给予指导，解答我的问题，并分担我的开发工作。
我感谢张艺璇对我的帮助，因为解答我在前端开发中遇到的问题，与我一同开发。
我感谢李嘉铖对我的帮助，因为与我协商课程评价相关接口。
张艺璇 感谢孙旭东、李嘉铖同学承担课程评价开发任务，完成核心功能开发！
感谢单彦博同学美化UI，让UI变得比之前漂亮了超多！
感谢胡彬彬同学手动录入校历数据！
感谢杜博玮同学重构爬虫，提高信息获取速度，改善用户使用体验！
感谢郭骏同学的push！一个优秀的leader，能够调动大家积极性，能拍板拿主意，还能给大家提供建议！
单彦博 感谢我前端的两位队友孙旭东和张艺璇，他们每个人都承担了一整个功能页面的设计，非常辛苦。
同时也感谢后端的两位同学胡彬彬和李嘉铖，一直在和我们对接并修改接口。
团队的每一个人在这学期都做的非常好，大家都辛苦了～
李嘉铖 我感谢胡彬彬对我的帮助，尤其是在数据库设计时，我们讨论出的数据库架构比较合理，在开发新功能时只需要做增量式开发，大大降低了开发难度。
我感谢郭骏对我的帮助，在开发过程中经常给我提项目架构层面上的建议与批评，我从中学到了很多。
我感谢前端、爬虫对我的帮助，大家齐心协力才有我们今天的成果。
胡彬彬 我感谢李嘉铖对我的帮助， 因为在整个开发过程中，我们都互相讨论，例如最开始的数据库设计，我们都互相进行验证，一起讨论是否有不足之处。
我感谢郭骏对我的帮助， 因为在对校历的代码复审中，提出了有效的建议，让代码逻辑更简单，更易开发。
杜博玮 我感谢郭骏对我的帮助，花费大量时间帮助我处理相当棘手的教务格式错误。
我感谢整个团队的所有人，在临近考期最繁忙的时候不离不弃，用大量的汗水敲出了这么漂亮的程序。
郭骏 我感谢孙旭东对我的帮助，几乎承担了课程评价界面的所有功能。
我感谢李嘉铖对我的帮助，承担起了一些项目展示方面的协助工作。
我感谢顶级理解团队的所有人，对项目一心一意、不离不弃、和谐共处、共同开发，披荆斩棘，造就了Beta阶段的成功。

总结

  • 你觉得团队目前的状态属于CMM/CMMI中的哪个档次？

    我们团队应当属于CMMI的第三级，即明确级。在上一阶段的基础上，我们可以根据自己的特殊情况，将这套管理体系与流程制度化，现在即使让我们团队开发其他的软件，我们依然有大概率成功。

  • 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？

    我们团队应当已经进入创造阶段。我们互相信任，有共同的远景，有自己的看法，有充分的授权，不去关心或者争执方法论，也减少了对上级的依赖，经常能有自己的想法并付诸实践，让我们的软件变得更好。

  • 你觉得团队在这个里程碑相比前一个里程碑有什么改进？

    相对于之前的阶段，我们已经共同经历了两个月的开发过程，配合比上一阶段更加默契了，许多事情不需要交流就能够理解对方的意思，并且也形成了许多不成文的做法。

  • 你觉得目前最需要改进的一个方面是什么？

    最需要改进的可能是计划方面的问题。在Beta阶段，因为一些奇怪的原因，比如iOS开发者账号需要收费，推送功能需要收费等原因，导致有些功能没能和预想中一样实现。我们在计划上应当早点察觉到，并且需要有应急预案来针对工作量不足的情况。

  • 对照敏捷开发的原则， 你觉得你们小组做得最好的是哪几个原则？ 请列出具体的事例。

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

      我们的软件从两周的开发任务结束之后产出第一版1.0.0版本的app开始，就一直在更新，目前已经更新到1.1.2版本。两个月内，我们发布了8个可用的软件版本，其中实现了不少额外的功能，修复了不少的Bug，且有及时的更新推送机制。这些功能为我们的软件提供了良好的保障。

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

      打地基的开发阶段，PM每日需要审核大家的代码，进行Code Review，体现了共同开发。而测试阶段，大家发动起身边的同学一起进行测试，遇到bug实时反馈到微信群中沟通，由PM进行bug定位后，将错误信息交付给相关同学，进行debug。业务人员（PM）保证了每天的工作和开发人员一起进行。

    • 保持简明——尽可能简化工作量的技艺——极为重要。

      虽然在设计之初，我们有很多很多想要实现的功能，但是在敏捷开发的时间面前，我们为了能够交付更可靠的可用软件，尽可能的简化了工作量。我们围绕目前的核心功能进行了开发和测试，保证了工作量的明确和简化。虽然任务不算很多，但是在一个月的时间里进行不断的打磨，使得软件较为完善。

质量提高

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

  • 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

    我们将继续使用GitHub作为我们的代码托管工具，善用GitHub的Issue和Pull Request功能，并且尝试使用Release功能，让代码管理更加清晰。

    代码规范后端已经足够好，前端可能需要通过进一步寻找工具来管理代码质量。

  • 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

    目前程序的架构方面，还没有感受到有很大的问题，可能需要项目外的人来进行评估。质量的提高可以通过进行Code Review时的主观感受来进行，也可请其他与项目无关的人来阅读代码，从而感受代码质量。

  • 其它软件工具的应用，应该如何提高？

    使用postman进行测试时，会对相应的请求进行保存，从而记录测试内容。GitHub的action，我们可以使用其中更加广泛的功能

  • 项目管理有哪些具体的提高？

    Issue需要更详细，PR需要与Issue进行绑定，PR需要一些review记录。

  • 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

    目前我们通过在收到请求时，将数据库内相应字段+1来跟踪用户的活跃数据。我们计划更加准确记录用户数据，例如请求的成功次数和失败次数等。

  • 项目文档的质量如何提高？

    首先文档要全面。然后，为了保证质量，我们可以请项目之外的人来阅读参考我们的文档，如果能够看懂，或者成功配置好环境运行，就可以认为文档的质量较高。

  • 对于人的领导和管理， 有什么具体可以改进的地方？

    需要开发之前使用更加客观的指标来衡量工作量，且需要多元化的评价指标。评价不应当过于主观，由PM一个人来进行所有领导和管理也略显不妥。

  • 对于软件工程的理论，规律有什么心得体会或不同意见？

    如果一款软件的开发需要做到“敏捷”，在开发时间长度固定的情况下，必然会缩短计划时间和测试时间。但是实践表明，计划和测试的缺少会导致开发阶段出现许多不必要的麻烦，从而带来“欲速则不达”的情况。所以，敏捷开发任务中，如何在计划时间、测试时间、开发时间三者之间做好取舍，是敏捷开发的艺术。

会议截图

会议使用腾讯会议进行，在6月9日19:00举行。杜博玮同学因为有事未能到场。

posted @ 2020-06-14 01:45  软工顶级理解组  阅读(248)  评论(4)  编辑  收藏  举报