OMOOC.py week10 QA 梗+演示

记要

~大妈的演示梗

每一次QA之后都要求大家对自己的演示进行反思分析改进.
之前可能大家把所有的精气神集中在怎么样把东西作出来,而不是演示一个半成品.
要求每个组要求有周报,组内有站立会议. 演示是完备的汇报,每天团队里的所有人是不是清楚现在项目的状态. 实际上只有通过正式的,整个产品,完整的演示,才能最有效的,逼迫大家所有人都明白所有功能,现在的项目状态. 这种完备的整体的认知,是对编程思想,网络能力,文学创作的三方面的能力,综合性使用. 举例:frank在周中评审需求的重要性的时候,冷静分析项目的结构. 对作品的边界非常清楚,才能做科学的判定.

这种演示,宣传,炫耀,是一种输出,输出是最好的输入. 对自己的作品的结果,及其理解之后,才能确定文案,演示方法等. 个性需求,是否真实解决了日常需求. 定义好,传达好,大家才明白.

一个工程该包含哪些文档,之前的wiki模板.
准备完备的私人教程,面对半年前的你自己,吻合自己的体系.
淌过很多弯路之后的科学的合理的学习路径.
整理各种私人指南.

没有时间写教程是给伪命题. 每一次主题输出,快速输出,都是对过去编程实践的一次编程实践的自我整理. 这种停顿是对呼吸节奏的调节. 阶段性的反思,才能明白自己学会了哪些技能. 哪怕是每天例会前后的整理;给自己挖坑,列出章节,标题,就是对头脑中的已知数据的清理.

niubility:

演示提纲
简介
- 豆列: 灯塔隐喻; 高信噪比信息集
- 引出需求和作品
需求和作品
- 需求: 如何利用我们认为相对优质的资源?
- 需求列表 1,2,3...
- 引出我们的作品需要完成的功能集
作品演示
- 本次围绕功能演示
- 功能输入-输出
- 另外简述本周开发进展
演示小结与迭代计划
简介部分: 文档可再优化表述方式
需求:
- 需求表述还不够清晰, 表现出我们团队对需求的思考还不够系统; 另外, 这些"需求"是不是真实存在?
- 需求表述要增加一些实例, 便于对项目陌生的人尽快理解. 并且愿意因为自己有相似需求, 使用我们的作品
产品:
- 缺乏具体的操作流程演示
- 操作过程演示实际上也是基于实例的产品介绍, 如果操作方便功能强大, 潜在用户更可能愿意使用我们的产品;同时操作流程也是展示项目开发情况/开发能力的一个重要方式(工程师的show time?)
如有时间, 还可增加项目开发方面的一些展示
除了作品产出, 我们还在进行多人协作开发
这部分的思考也是团队共同作用下产生的, 值得和大家讨论

Author:

/mail / gittip / github