赞
踩
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
这个作业的要求在哪里 | 团队项目-Alpha阶段事后分析 |
我们在这个课程的目标是 | 熟悉敏捷开发的方法论,并通过实际开发产品进行实践。 |
这个作业在哪个具体方面帮助我实现目标 | 熟悉敏捷开发的方法论:按照给定的模板了解产品总结所应涉及并反思的各个方面。 通过实际开发产品进行实践:对照产品 ALPHA 阶段的实际开发,分析实践带给我们的宝贵经验。 |
Author: 无际软工队
Date: 2022.05.19
依然按照本团队的优良传统,例会讨论后共同完成文档的撰写,再由协调员 PM 进行总结。
以下各部分会注明各部分的初稿编写成员。
本项目将开发一款聚焦校内科研实习和内推信息聚合的中和求职平台,主要解决问题有以下几点:
我们的需求定义明确清晰(选题和需求分析),进行了充分的调研,对使用者的需求有较好的把握。
我们对典型用户和典型场景有清晰的描述(功能规格说明书),我们的典型用户主要有四类,与前文需求中的四个角度相对应,分别是寻找校内实习的本科生、寻找企业实习的学生、招收实习生的教师、有发布内推需求的往届生。典型使用场景著有为校内实习生招收和企业内推两部分,思路清晰,定义明确。
在原计划中,我们设计了个人控制台、主页功能、通知与消息三大基本功能模块。在 Alpha 阶段,我们完成了面向求职者的各项功能和面向招聘者的部分功能。
求职者用户可以通过个人控制台管理个人简历信息,实现了包括个人基础信息、教育经历、科研经历、获奖经历等简历信息的管理功能。求职者也可以体验主页功能,浏览各项招聘信息,查阅招聘详情和对应的实验室、招聘人员的公开信息,并投递个人简历,与招聘人员取得联系。在投递简历后,求职者可以收到来自招聘人员的消息,或在个人控制台中查看相关进展。
招聘者的管理功能尚在完善,后续我们将在 web 平台和小程序中完善招聘者视角的信息管理功能,让招聘者更方便快捷地操作。
团队的工程质量有所提高,主要体现在以下几个方面:
预想的基本一致,用户对于主要的功能很有期待。在联络老师或往届学生提前入驻平台时,很多人都说“这是好事”、“这很不错”等等。在 Alpha 版本发布时,很快积累了百余位学生用户。可见,不论是求职者还是招聘者,都对我们的平台的初期基本功能较为满意。然而,我们在设计过程中仍有不足,一些细节设计尚未完善,比如少数重要的按钮容易误触,以及招聘者平台的不完善等等。
我们积极反思,发现我们的问题主要集中在以下几个方面:
综合上述问题,我们深入思考,总结经验,在以下几个做出改进:
By Selia & TakiVotoid.
在本阶段,我们拥有足够的时间来做计划。在项目进行初期,我们对整个项目的调研、开发、测试等相关工作做了详细的长期计划。在各项阶段进行的过程中,我们坚持周例会、Scrum Meeting 制度,规划短期任务。
无际软工队由七名成员组成,大家性格各异、技能及对产品的理解亦各不相同。
——在项目开发的每一个阶段,都希望能发挥每个人的技能和才智。
基于这个朴素的愿望,项目开始时团队成员一致同意:我们更进一步,在产品成型的各个流程都打破传统意义上的层级关系,扁平化组织结构,在重视每一个人参与和思考的前提下,完成不只限于开发,更包括调研策划、文档完成、宣发推广等在内的各项任务。
在团队决策上,由于上述原则和特点,团队避免采用 PM 拍板方式,也不采用简单的多数决方式来完成开发过程中涉及的各项决策。每次团队讨论依照:提出方案——寻找问题——解决问题——确立共识的方式来进行。
当遇到意见分歧时,我们会先请具有不同观点的团队成员简明扼要、重点突出地阐述理由。然后其他同学加入,进行一段时间的自由讨论。对于每一个策划提案,大家需要从各个角度提出潜在问题和疑虑。我们从疑虑少的方案入手,一项项讨论解决方案,直到取舍和平衡被所有人接受为止。
还真都做完了,哈哈!
——虽然很想这么说,本团队在实际开发过程中,受合作方需求变更和微信小程序审核时效的影响,进行了计划的二次调整:具体而言,将双端并进的任务规划调整成先完成求职者的完成可用小程序平台,再进行后台管理封装——用户后台开发的两步走工作量设计。
二次调整后的工作量,则基本按照计划进行,完成了 ALPHA 阶段预期的全部内容。
在后端开发时,我们几经修改接口的实现形式。最初,我们没有注意到 DJango 和 Restful 框架为我们提供的一些相关简化使用方法,在完成 API 的设计时,代码繁琐,安全性和健壮性差。后来经过组员的沟通和协作,我们引入相关组件,重构了相关代码。在这一事项中,先前的探索看似无用而又浪费时间,但是这样的探索也能作为后续开发的经验和教训供我们反思。
是的,在项目的开发过程中,我们以前端为主要导向,前端每一项需要后端提供的 API 都在 Notion 中以文档的形式明确给出相关需求,后端完成相关 API ,将调用方法以及需要注意的细节填写到相关文档中。这些 API 即是一个个独立的交付件。
项目开发过程中,有两项意外事件:
在计划中,我们预留了缓冲区,用来应对意外,例如:
第三、四点我们真切地遇到了,第五点在实现的细微之处体现。
——产品最终顺利发布,留下的缓冲区帮了我们大忙。
综上所述,团队应当继续坚持留足提前量、做好 PLAN B 准备的做法。
团队对审核等政策风险估计不足,应当继续学习相关知识,积累经验。
By TakiVotoid.
团队共有七人,工作量分配合理。在物质资源上,由于有合作方和大学生创业支持,不存在经济上的问题。在宣发资源上,团队采取针对性投放、争取合作方展示资源等方式,实现了较好的宣发效果,可以说资源足够。
每周例会,我们都回顾了上一阶段的工作、进行下一阶段的工作量评估,团队始终处在磨合、再认识的动态调整过程中,因而对时间和资源分配具有较合理的把握。任务的粒度管理上,我们压缩到两日内完成的粒度,加以基于 Scrum Meeting 的周期性动态管理的方式,没有出现太大的、可避免的问题。
从测试报告来看,团队的系统即使在 ALPHA 阶段也达成了较高的完成度和测试覆盖率,没有出现严重的 BUG。
美工设计工作交由团队的原型设计来完成,后文会提到代码实现上出现的问题,但非编程因素并没有造成问题的产生。
后文介绍了团队分工的具体方式和实践,总体来说团队的任务分配是合理的。
在前端的最后成型阶段,有进行线下的密集小组集体开发,团队成员各司其职成功完成了任务,可以认为虽然进度管理在不可抗力因素的打击下出现了一定问题,但团队的成员管理和任务分工是经受住了挑战的。
团队应当进一步细化分工,确保每个人的工作粒度更细、团队岗位分工更具针对性。
By TakiVotoid.
团队采用 Notion 进行项目文档管理,并通过任务看板、Github Issues 方式来展示任务;团队组织了有效的会议,并实行会议纪要轮值制,确保每一位成员对项目进度的把控和了解。在变更管理上没有产生明显的问题。
团队优先考虑合作方的需求,决定首先冲击上线的平台。
对于用户的两种角色,团队优先处理只能采用 to C 模式解决的部分:求职者;对招聘者则优先采用 to B 模式,以团队沟通、定制化对接工作来减少开发工作量,缓解开发压力。
对于功能组,我们优先完成基本功能,其次完成惊喜功能,最后进行体验的打磨。
有。项目的出口条件可见 ALPHA 阶段测试报告。
前文已经指出了团队所预见的风险和预案。团队遇到的两项意外及对这些意外的成功应对和处理,体现了团队在应急计划制定上所做的努力。
从由于微信审核不可抗力因素导致的,前端最终的线下小组开发冲击上线的过程来看,团队具备完成意料之外工作请求的能力。
团队管理和分工建构的鲁棒性,决定了团队面对挑战和变更的能力。团队应当进一步健全管理机制,保证各尽其能,宏观调控每个人的工作量和投入,帮助团队更好地面对挑战。
By roife & TakiVotoid.
设计工作在编码之前进行,由团队共同讨论完成。
从 Alpha 阶段开发结果来看,目前顺利完成了 Alpha 阶段预期的功能。
在设计中存在一些模棱两可的分歧,主要在架构设计与 UI 设计等方面上。
当发生这种情况时,有不同想法的成员首先会在私下交流解决。如果交流后仍然有不同意见,则会在 Scrum Meeting 上进行讨论。目前在开发过程中遇到的设计上的分歧都能够在当次 Scrum Meeting 上解决,保证了开发的推进。
团队在开发过程中充分利用了 Unit Test,并且后端单元测试覆盖率达到了 93%。同时,每次将功能分支和 BUG 修复分支合并到开发主分支时,会自动触发设置的 CI,从而进行回归测试等。
单元测试很好地保证了代码的健壮性,大大减少了开发过程中因为不谨慎以及多人协作冲突导致的 BUG。
同时,前后端仍然使用了 Notion 作为开发交流的渠道。Notion 可以记录文档的修改者以及修改历史记录,同时可以给团队成员分配任务,大大提高了开发效率,减少了沟通成本。
本项目在建立之初就充分考虑了安全性等问题,因此在发布后没有发现严重的 BUG,大部分 BUG 来自于前端的显示和交互等。
目前大部分 BUG 来自于微信小程序的开发框架导致的前端交互 BUG。由于一些不明原因,微信小程序的真机测试版与发布版存在使用上的区别,导致一些原定的交互操作不能很好触发。但是这并没有影响到主要功能的使用,且用户较难发现。
我们认为这是因为我们对于微信小程序端开发的经验尚不充足,没有想到微信小程序框架存在的一些坑,导致 BUG 在送审前因为无法被触发而未被发现。
代码规范分为两部分。
首先是代码风格相关的规范,这一点由我们的 CI 以及相应的 Lint 工具保证。
其次是代码实现的规范。在项目初期,由一名同学负责审查成员的代码,并对不规范的写法进行纠正,且这一过程持续了数天。
当团队成员已经能够写出符合规范的代码后,这名同学就减少了审查方面的工作,并将精力投入到开发工作中。
当然,在后续的开发中,我们仍然会在 Scrum Meeting 上进行部分代码复审工作,以保证大家严格执行了代码规范。
磨刀不误砍柴功,明确的、引入自动化的代码规范及质量管理机制,为团队带来了很大的帮助。Code Review 工作弥合了大家的经验差异,为团队的总体开发质量带来了较大的提升。
By 春日野くさ & TakiVotoid.
有。
团队针对各 API 功能组、用户端模块和操作流程,完成了单元测试、场景测试、压力测试等多维度、全方位的测试。对后端稳定性和预期功能、安全性,前端交互体验、视图逻辑等方面做了尽可能全面的测试。
同时,团队提供了一套 BUG 收集及反馈机制,并通过直接访谈、或用户群的方式触达用户,虽然时间紧迫,但仍收获了不少宝贵意见。
在验收阶段,团队组织全体团队成员进行了功能性测试,从用户的视角出发,补全用户故事的各个方面,以平台提供的功能序列为主干,测试边界问题。
即便如此,还是存在视图逻辑上的瑕疵未能解决,但这主要是由于不可抗力的审核发布时效过长,留给团队修复的时间过紧所致。
团队基于 DevOps 的最佳实践,实现并完善了 CI/CD 自动化单元测试。对于压力测试,也同样引入了自动化工具。
详见 ALPHA 阶段测试报告。
为了测试软件的性能,在使用 nginx + uwsgi 部署好服务器之后,我们使用 JMeter 进行了压力测试。测试过程均采用高并发利用全部服务器资源。
在进行压力测试时,我们对典型 API 进行了测试,覆盖网络连接、数据库性能、服务器端算力开销、内存占用等多个方面,详见 ALPHA 阶段测试报告。
基于压力测试,成员进一步进行了特定接口的调优、服务器资源管理和监控。
从实绩上来看,平台稳定运行一周有余,初始宣发的大流量也远没有达到给平台造成负担的程度。可以认为平台 ALPHA 阶段的测试设计和实践是卓有成效的。
发布的过程中,我们遇到的问题主要集中于前端:
这两项问题指出了团队产品验收、稳定和发布流程中两个可以进展的方面:
除了上述提到的数点,我们还意识到,尽早地引入内测用户,对产品的打磨非常重要。内测用户能够跳脱出开发团队的预想情景、思维定势,展现最真实的用户使用情况。
By BUAA_Wander & neumy & TakiVotoid.
本团队成员共七人,三名前端开发人员,三名后端开发人员,一名机动开发队员。PM 由前端开发人员担任,团队整体以前端需求为驱动,前端与后端的交流与沟通贯穿了整个并行开发流程。
团队成员的角色主要由成员们各自所掌握的技能和工作经验决定。
PM 具有充足的前端开发设计经验,有一套稳定成熟的UI设计风格,且对产品交互设计有独到见解。
机动开发人员具有丰富的全栈开发经验,作为PM的补充,在技术问题上辅助PM进行决策,并在实际开发过程中辅助观察督促前后端进度。
后端开发人员均能够熟练使用Django框架,且在接口安全性设计、后端服务架构与性能调优方面也有丰富经验。
前端开发人员能够熟练使用Vue(及其衍生的Nuxt和uni-app)框架,在用户界面设计与提高交互体验方面表现出色。
团队开发过程中尽量坚持线下会议,并保持着极高的全员到会率,在会上我们就前后端的技术问题进行深入探讨,并在核心问题上进行全组讨论。
“授人以鱼不如授人以渔“,凭借着良好的分工方案,团队成员之间的帮助方式主要包括:
以后端为例,在项目开始前期,后端技术总监同学带领整个后端速览 Rest framework 的使用规范;每次开会的时候,后端会对最近的工作遇到的技术问题进行讨论与解答;后期后端将数据库换为 PostgreSQL ,这时组员们互相帮助重新配置开发环境,保证大家都能继续正常进行开发。
通过上面的过程,组员间相互学习借鉴,都能够学习到他人的技术长处,并且没有出现“拖油瓶”情况。
团队开发过程中,组员间学习氛围浓厚。团队成员在定期组会机制和有效的项目管理下,对项目进度保持良好的敬畏,使得项目推进顺利。
前后端合作过程中借助良好的接口文档规范和交流沟通机制,API接口对接较为顺利,虽然出现了部分开发不同步的情况,但是并未耽误正常项目进度。
项目开发期间为了应对突发的微信小程序审核事件,前端组需要紧急进行一次高强度开发。团队及时调配了机动开发人员来辅助工作,并在开发后的组会上对参与该次紧急开发的成员们给予了额外奖励分。
团队成员都很腼腆,但他们 给出的奖励分 是真实的。
如果需要的话,请课程组来现场听听大家的心声(课堂总结环节)。
By TakiVotoid.
团队完成了本阶段的所有功能需求,进入完善阶段;同时,团队正在进一步丰富产品功能。处于 CMM 的已管理级(Managed)阶段和 CMMl 三级,明确级。
团队的产品开发已步入正轨,各方面已形成完善的工作流,正处于创造阶段。
团队应当改进风险管理能力,并在需求挖掘上进一步投入精力。
示例已经在以上的各个分项、项目展示中提到过了,以下针对各条给出一个自评。
原则 | 完成质量 |
---|---|
尽早和持续地交付有价值的软件来满足客户 | ⭐⭐⭐⭐ |
欢迎对需求提出变更 | ⭐⭐ |
要不断交付可用的软件 | ⭐⭐⭐ |
项目过程中,业务人员与开发人员必须在一起 | ⭐⭐⭐⭐⭐ |
要善于激励项目人员 | ⭐⭐⭐⭐ |
最有效的沟通方法是面对面的交谈 | ⭐⭐⭐⭐ |
可用的软件是衡量进度的主要指标 | ⭐⭐⭐ |
提倡可持续的开发 | ⭐⭐⭐⭐ |
对技术的精益求精以及对设计的不断完善将提升敏捷性 | ⭐⭐⭐⭐ |
要做到简洁,尽可能减少不必要的工作 | ⭐⭐⭐ |
最佳的架构,需求和设计出自于自组织的团队 | ⭐⭐⭐⭐⭐ |
团队要定期反省如何能够做到更有效,并相应调整团队的行为 | ⭐⭐⭐⭐ |
应当完善代码注释。代码规范团队做得已经较为完善,应当进一步扩大 Code Review 的范围和团队交流的代码质量层次和方面。
前端要重新规范层次化、模块化的 VM 架构,利用好集中式、树形展开的状态管理模式。后端要完善 API 版本机制、设计和实现迭代更新的具体步骤和流程,保证平台接口的鲁棒性,提高平台对新需求的适应能力。
尝试引入 Slack 等团队沟通工具,现有基于 QQ 的团队线上通讯手段存在局限性。
对于活跃用户分析,在后端运行了团队编写的数据统计与分析模块,但收集的数据仍不够全面。下一阶段可以考虑引入第三方数据记录与分析平台,分析用户热点。
代码层面以外,团队还应进行更密切、长期化的用户调研和跟踪,了解用户的反馈意见。
除了已有的 API 文档等项目文档,对于特定复杂模块、关键模块的具体实现机制,应要求开发成员做补充。
PM 要承担起宏观调控层面的更多责任,不只依靠各位优秀成员的主观能动性完成各方面工作。
虽然很可惜现在在封校,但项目进行过程中和项目完成后 PM 很难不请大家吃饭。
课堂学习时体会不深,实际实践下来的体验让我们意识到:软件工程的方法论是软件开发的生命之源。
By TakiVotoid.
由于团队(尤其是后端)在自动化工具上采用了高标准和最优实践,BUG 的出现大大减少,代码统一且高质量,为平台的稳定性提供了充分保障。
项目的冲刺阶段,从燃尽图即可看出,进度出现了巨大的落后,最后不得不以通宵加班的方式完成开发。导致这一现象的原因一是微信审核等不确定性的叠加,从根本上来看更是项目分工的估计不足、容错率不高。项目前端的视图层开发与想象中相比花费了两倍以上的时间——这一迟延主要来源于对小程序端开发工具和机制的不熟悉。Beta 阶段,团队的开发重点将转移到更为熟悉的 Web 平台上来,但 ALPHA 阶段这一惨痛的教训仍应铭记在心,应进一步细致化前端的进度管理。
对于前端,团队基于 MVVM 思想进行开发,两位成员处理 VM、进行简单的原型开发,一位成员负责视图绘制和组装。
理想很美好,现实则不尽如人意。采用这种开发模式是我们做的最好同时也是最坏的决定。一方面,完全解耦的开发分工,不仅(在简陋的微信小程序开发环境下)消除了代码合并的问题,更大大利于调试和协作,为后期并行快速开发提供了条件;另一方面,没有层次化的 VM,搭配上高度层次化的视图层,导致了行为逻辑和数据的龃龉,视图层的组装困难程度大大加深,代码可读性下降——各调各的没问题,视图层和 VM 层之间几乎无法互相 Debug。
团队得到的启示是:除了自以为是的解耦措施之外,前端开发时在层次化、模块化方面也应当预先制定规范,统一架构再行开发。
与职协的合作磋商和最终达成,是本团队开发之外所做最大的努力。
强有力的合作者,为平台引入了更坚固的背书、更明确的目标,以及在路上的更大声量。
但另一方面,也为平台带来了更多的要求、制限和“不可控”——尤其是在另一侧是无法松动的课程要求、既定安排的情况下。
作为产品的直接负责人——项目的开发者们,在需求和需求缠斗的正中间,面对滚动着压过来的名为工期的巨大落石,需要足够的智慧、足够谨慎的安排、留下足够的余量才能够勉强逃生,去攀登更高的山峰,去成就更为平衡、更为完善的产品。
——又或许,我们只是需要更多的实践,更多的经验,需要练就更好的与合作方沟通、探知和了解其需求的能力。
合作为我们带来了正向的促进和负向的压力。在 Beta 阶段,我们会继续挑战它——一块滚滚如雷的巨石,一方巍巍耀眼的峰顶。
Bravo。
——太棒了,大家!整个 ALPHA 开发过程中,团队的所有人共进退,共同面对挑战、克服困难、消解疑虑、各尽所能。我们会在初夏的阳光下兴奋地讨论产品,也曾在深夜的新主楼 G 座里一人一台电脑啃着麦当当奋战到天明。
十分庆幸,团队的七个人能走到一起,不只是完成一门课,更是完成一款雄心勃勃的产品,留下一段虽有缺憾但仍足以笑出来的回忆。
冒险仍在继续,我们将继续前行。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。