JuJu Beta Postmortem

 

JuJu

---

demo
demo

项目github地址
JuJu

 

设想和目标

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

完成基于Julia语言的NER model，并在CoNLL2003 数据集上取得>=70% 的chunk accuracy。

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

我们完成了基本要求，按照原计划交付时间交付了。

 

计划

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

有，吸收了alpha阶段的经验教训，我们对julia语言更加熟悉了，所以规划也更加合理一些。比如对于接口，很明确要什么类型的接口。

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

先进行讨论，如果经过讨论后大家能够明确认定一种想法好于另外一种想法，那么就按照最优解法来。如果不能互相说服对方，那么就各自实现自己的想法。

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

我们原定是想完成后面的CRF，后来这段时间恰逢大家要开始做毕业论文设计，所以这个计划也就不了了之。

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

基本上没有

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

是，我们分为训练，文档撰写， 界面设计三块。

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

不是，对工作量估计得不恰当； test和dev数据集没有分开，这主要是因为我们对这个NLP任务不是很了解。

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

有作用

 

资源

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

有充足的人力资源（6人）以及足够的计算资源。

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

按照alpha阶段的经验估计的。

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

我们的分工已经尽可能细了，充分考虑到每个人的优势以及时间安排。

 

变更管理

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

是的，每日例会都会交流

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

大家给出自己的时间安排，例会上大家根据时间情况确定。

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

计划的工作具有弹性，比较抽象，遇到问题可以灵活解决。

 

设计实现

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

使用了unit test，事实上证明测试是非常有必要的。

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

数据处理部分bug是最多，因为大家对NLP数据处理的内容不是很了解；另外一个出错较多的地方是准确率的评价函数，chunk acc的计算，这个不同于CV里面acc的计算，而且有一些不同的版本。

 

测试/发布

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

有

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

写unit test

 

团队的角色、管理、合作

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

是，充分考虑了大家的兴趣与项目的需要；是人尽其才。

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

有，经常互相帮助

 

总结

作为事后诸葛亮，我觉得我们项目最重要的一个失误在于 忽视了算法流程本身的复杂性，过于看重julia和Flux的复杂性。
诚然，一开始的时候，我们看到julia语言的时候，她的用法以及数据类型的定义和python差别还是很大的，而且我们这个项目的名字叫JuJu，亮点在于Julia，所以我们的重心就自然而然地放到了Julia上，潜意识里认为这个NLP任务很简单。事实上，这个NLP任务是很简单，用pytorch做起来真的很简单。但这主要是因为，pytorch的数据处理部分都已经写好了，还有一些什么其他的坑前面无数人已经踩过了。就是现在如果用python让你从头开始写完这个project，我觉得也不会那么容易，但是至少比Julia简单，因为踩坑的人多。
我们这个项目最大的问题就是，当我们认为一个部分实现出了问题的时候，我们不知道是算法内容本身理解的有问题，比如评价函数，比如word-embedding，还是julia语言我们用错了。
所以，如果让我从头再来一次，我会安排两个人先去用pytorch来把整个过程跑一遍。这样绝对能够省去很多精力，一旦pytorch的结果是对的，再次碰到问题的时候，我们就知道是julia语言的问题。
另外，一个比较有感触的地方在于，我们一开始把dev和test混在一起了，这不是一种规范的做法。因为dev一般是要用来调整超参的。虽然我们是纯粹看着别人的paper写，不用自己去探索网络结构，但是调整超参是一个必须的流程，就想unit test一样，对于整个流程是非常有必要的！
我一直在想，我们这个project的意义是什么？达到state of art的水平，甚至超过他们？不太可能，而且我觉得也不会有人去刷这么老的task。我感觉我们这个project的真正意义在于，推广julia在DL中的应用，让更多的人知道julia。既然是推广，那么一定要做的规范，所以希望大家批评指正~

 

贡献分

陈灿 16.70
恩升 16.00
婷婷 16.63
金华 16.14
胡凯 15.95
宇飞 18.57