做技术卡的规范和原则

最近大家都在学习跟项目有关的知识,有跟项目源码学习有关的学习卡,也有跟项目有关的技术学习卡,比如:Jenkins,Jersey,Async等等。
我就仿照林老师写的文章《如何完成一张学习卡》来一波做技术卡的规范和原则

原则(INVEST)

  • Independent(独立的)
    • 学习过程中遇到的问题若不属于技术卡的范畴,不必深究
    • 你学习的内容紧紧围绕技术卡
    • 例如:学习jersey+mybatis+mysql仅仅跟这三个技术有关,当前不必深究gradle
  • Negotiable(可协商的)
    • 验收条件是你和 pair 讨论过后的结果
    • description 和 AC 需要让/QA/BA/老师检查
  • Valuable(有价值的)
    • 理解所学的技术(对自己的价值)
    • share 的时候让大家理解你所学的技术(对他人的价值)
    • 可结合知识上手项目(对项目的价值)
  • Estimable(可估的)
    • 对每张卡的完成时间做个估计,可对此卡估计出学习时间(<=一天)
    • 若不能估出完成时间,说明此卡太大,不可估计,需要拆卡
  • Small(较小的)
    • 对每张卡估点,且点数相对小一点(<=2)
    • 点数 >2 需要拆卡
  • Testable(可测试的)
    • 用与之前写的验收条件检验学习产出

规范

  1. 领卡 + pair

    • 一个人做卡叫 solo
    • 两个人才叫 pair
  2. 给卡估点

    • 1点就是1人天(和你的pair一天完成)。
    • 如果 points 很大(>2)需要拆卡。
  3. 写 description

    • 需要写上预期的学习过程和验收条件,并将 demo 上传到 github 。
    • 将 demo 地址写在 description 最后一行。
    • readme 里面要写清楚环境的配置、运行程序的步骤、程序运行的预期结果写清楚。
      • 例如


        做技术卡的规范和原则_第1张图片
  4. 验收

    • 若验收结果可视化,尽量画图。
    • 比如学习一期源码的逻辑题答题流程
  5. 填写GoogleDrive的工作记录表

    • 开始时间和结束时间
    • 预估时间、实际时间和超时原因
    • pair 对象和总结
  6. 结合项目

    • 思考该技术点在项目中有什么作用,为什么要用它。
  7. 发散类比

    • 回忆自己的知识库有没有类似的知识点。
    • 比较二者之间的相同点和不通点。

优秀技术卡

来自马红和骆承秀的 moco 学习卡:


做技术卡的规范和原则_第2张图片
  • Moco 的 demo:github
  • Moco 的 学习文章:

你可能感兴趣的:(做技术卡的规范和原则)