团队作业—bate冲刺+事后诸葛亮

助教_林日臻 助教_林日臻 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区

团队作业—bate冲刺+事后诸葛亮

  • 发布时间:2024.11.16
  • 作业链接:2024.11.26

格式

为了方便其他学校的老师或者助教了解课程实况,请大家在作业开头添加格式描述:

这个作业属于哪个课程<班级的链接>
这个作业要求在哪里<作业要求的链接>
这个作业的目标<写上具体方面>
其他参考文献…

作业要求

以下内容基本是按照时间顺序排列的,请各组合理安排时间,不要将多项任务集中到某段时间里密集地完成。

  • 1篇Beta阶段置顶集合随笔,包含以下所有内容的链接

  • 1篇换组交接博客(在11月18日前发布并添加到集合随笔中)

  • 1篇alpha阶段问题总结随笔(在11月18日前发布并添加到集合随笔中)

    • 关于设计/实现;测试/发布相关的问题
    • 关于变更管理;团队的角色,管理,合作相关的问题
    • 关于设想和目标;计划相关的问题
  • 1篇凡事预则立随笔(在11月18日前发布并添加到集合随笔中)

  • 1份代码规范

  • 7篇冲刺随笔

  • 1份用户使用调查报告

  • 1篇Beta冲刺总结随笔

    • 关于项目预期计划、完成度相关的问题
    • 关于过程体会、组员分工协作相关的问题
    • 关于计划完成情况、项目运行链接及截图展示等相关的问题
  • 项目课堂演示、答辩

  • 制作答辩PPT

  • 自行设计评审表

alpha阶段问题总结随笔具体要求(在11月18日前发布并添加到集合随笔中)

  • Alpha冲刺,很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是,各组对于软件工程的“Learning by doing”的意涵了解的还不深刻,遇到的问题也不少。停一停,开个总结会,来个事后诸葛亮,为了下一步走得更好

  • 请各小组在在进行beta冲刺之前,以小组为单位发布一篇针对问题的总结。总结的提纲内容,请参照邹欣老师的博客:项目管理之事后诸葛亮会议

凡事预则立随笔具体要求(在beta冲刺开始前发布并添加到集合随笔中)

  • 下一阶段需要改进完善和新增的功能。

  • 需要改进的团队分工(针对之前的不足,需要加强和改进团队协作和分工的地方)。

  • 需要改进的工具流程(如版本控制、测试工具等)。

  • 所有博客的计划安排,以及冲刺七天的时间计划安排。

7天冲刺随笔博客的具体要求**

每天的冲刺博客分为scrum和PM报告两部分

  • SCRUM部分:

    • 每个成员描述:从昨天站立式会议到现在的成就(完成了哪个任务,花了多少时间,还剩余多少时间)、存在的问题/遇到的困难,从现在到明天站立式会议的安排。(可以以表格形式列出)
    • 团队成员的工作如果是开发工作必须有代码签入,给出签入记录对应的Issue内容和链接/图片**(如果缺少,当天冲刺日志-2分)**
    • 团队成员的工作如果是测试等其他工作,那要有具体的结果,如截屏、测试报告等 (如果缺少,当天冲刺日志-2分)
    • SCRUM 会议的照片一张,会议照片应该是每天冲刺会议的真实非摆拍照片,可以挡住脸保护隐私。(如果出现照片复用的情况当天冲刺日志不计分)
  • PM 报告:

    • 总结整个项目预期的任务量(所有工作的预期时间或者issue总数)和目前已经完成的工作量(已完成工作花费的时间或者已经完成的issue数目),还剩余的工作量(剩余工作的预期时间或者剩余issue数目)
    • 画出燃尽图,要显示真实的情况
    • 记录任务总量变化,体现在工作中发现了多少以前没有想到的事情;可以画成图表
    • 适当的项目程序/模块的最新运行图片/gif/视频 (如果缺少,当天冲刺日志-2分)

Beta冲刺总结随笔博客的具体要求

  • 回应冲刺开始前设立的任务(要完善、新增的功能)。用表格的形式展示完成情况;对于没有完成的项,描述具体的完成程度

  • 在冲刺开始前的“alpha阶段问题总结随笔”和“凡事预则立随笔”中,你们组设立了一些改进计划,这些计划的完成情况如何?

  • 可运行的项目链接、项目文件、程序二维码等。如果为微信小程序、APP等移动端项目,请注意相应的上线审核机制,所需时间等事项,务必提前了解并做准备。

  • 项目各功能的运行图片、gif或视频

  • 各成员在冲刺阶段的体验、收获、心得

  • 各成员的贡献度分配,可使用以下markdown

    | 学号 | 工作内容 | 贡献度 |
    |-----|---------|-------|
    |     |         |       |
    

评分标准

  1. 答辩得分(与之前计分规则一致)= 助教打分总和/(助教人数)* 0.6 + 老师打分总和/(老师人数) * 0.40

  2. 博客得分总分100分:

  • (60’)【覆盖课程目标4】
    • alpha阶段问题总结(事后诸葛亮)
      (5’) 设计/实现;测试/发布相关的问题
    • (10’) 代码规范
    • (30’) 7篇冲刺随笔
    • (10’) 用户使用调查报告
    • beta冲刺总结
      (5’) 项目预期计划、完成度相关的问题
  • (20’)【覆盖课程目标6】
    • alpha阶段问题总结(事后诸葛亮)
      (5’) 变更管理;团队的角色,管理,合作相关的问题
    • (10’) 换组交接博客
    • beta冲刺总结
      (5’) 过程体会、组员分工协作相关的问题
  • (20’)【覆盖课程目标7】
    • alpha阶段问题总结(事后诸葛亮)
      (5’) 设想和目标;计划相关的问题
    • (5’) 凡事预则立
    • beta冲刺总结
      (10’) 计划完成情况、项目运行链接及截图展示等相关的问题
  1. 这次作业得分 = 答辩得分 * 60% + 博客得分 * 40%

博客规范

1、提交规则

  • 博客以班级作业页面的提交时间为准;需要提交的文件以CodeArt的提交时间为准;

  • 在deadline前交,分数为实际得分 ;

    • 若帖子发布后在审核(帖子显示404),可以在deadline 之前先于作业页面提交链接,再等待审核通过
    • 不接受上传失败、网络原因等补交理由
  • 补交:在deadline 后两天内提交视为补交,分数为实际得分 * 50%;写了但是忘记提交作业和补交扣分一致

  • 缺交:在deadline 之后两天未补交视为博客缺交,分数为0分;

  • 作业抄袭:当助教发现两篇博客文字/图片/代码过于相似时,判定两篇博客都为抄袭,分数都为-100%(注意是倒扣!);

  • 伪造提交:虽然作业博客没有完成,但是先提交到作业占位置,判定为伪造提交,分数得0分;

注:提前提交的作业,如果能积极响应助教和老师的反馈并在deadline前做出相应修改,在后续评分时,这些修改完善也会被纳入考量。提早准备好处多~

2、注意事项

班级群如果发布相关通知也是作业要求一部分,请及时查看群通知; 若需要在群填写相关信息,未能在deadline之前完成填写的,扣实际得分的50%; 如对作业存在疑问,请在deadline之前三天在班级群提出;

若助教对作业要求有修改,会在群内公告,请务必查看并按新的要求完善作业; 请及时回复老师或助教的点评并作出相应修改。即使提交了作业,也应该关注班级群中助教的公告!

3、疑惑解疑

若有对题意不清或者有不理解的地方,可在该博客下方留言,或者在QQ群或微信群中直接提问

...全文
0人已提交
完成率0%
暂无数据

相关推荐

国央企在推动科技创新时,如何利用技术交易系统实现全流程闭环管理?.docx

国央企在推动科技创新时,如何利用技术交易系统实现全流程闭环管理?

BIZKEEN

高校技术转移办公室人员如何提升技术成果的推介效率?.docx

科易网基于AI模型+行业大数据,在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,推出科技创新领域的AI+工具与数智化解决方案,推动科技创新与产业创新智能化发展。

BIZKEEN

机械三维3D设计图-自动引孔锁螺丝设备.zip

机械三维3D设计图-自动引孔锁螺丝设备.zip

ZL4120505

sogou-wubi-5.5f.zip

五笔输入法

一and一>二

智能体上下文工程:预算控制与结构化压缩的Python实现

【内容概要】 本资源是《智能体演化史》系列第四篇的配套代码,用 108 行 Python 实现一个会"收桌子"的上下文管理器。核心是两件事:一是设一个上下文预算,用 token 估算函数实时盯着;二是超预算时执行结构化压缩——把早期轮次压成一段结论式摘要,保留最近若干轮原文,并且对失败尝试和关键事实单独留档,不让它们被摘要吃掉。配套测算脚本给出三组可复算的数据:关键信息密度从第一轮的 100% 衰减到第 80 轮的 13%(腐烂的本质是稀释,不是撑爆,按当前增量要 213 轮才真的撞上 128K 窗口);跑 80 轮,不压缩累积 199 万 token,滚动摘要降到 37.1 万,直接截断只要 42.6 万但关键信息只留下 8%。这组数字说明:只盯着账单会选错策略。 【适用人群】 智能体已能跑通、但长任务开始"变傻"的开发者;负责长会话产品体验的工程师;需要在成本与准确率之间做取舍的架构师。 【使用场景及目标】 1) 给自己的智能体加一层可配置的上下文预算与压缩; 2) 用测算脚本对比三种策略的成本与保留率,做出有依据的选择; 3) 作为团队内部分享材料,解释"提示词工程"为何被上下文工程取代。 目标:让长任务不再越跑越糊涂,同时把 token 花在真正重要的信息上。 【其他说明】 需 pip install openai 并配置 OPENAI_API_KEY;预算值与保留轮数为常量,可按业务调整。测算脚本离线可跑,假设参数在文件内显式标注,便于改成你的真实口径。压缩会损失细节,涉及合规留痕的场景请关闭自动压缩或单独归档原文。

积流成海
评论 1
收藏 已收藏
分享
返回顶部