kiwi_coder

今天晚上听公司的技术讲座，讲公司是怎么做软件的。到了Q&A环节时，一位同学说到制定项目计划的问题。  当时，我的两个同学都在很好奇的发短信问我提问的奖品是什么。说实话，我也没搞清楚，公司每次的小奖品，你不琢磨一下，你真不知道是干什么的。以前有过像黑板檫的鼠标，这次感觉像是一个带指南针的小刀，好奇怪的组合啊。同学问了问题后，公司一位前辈坐在我前边，转过来问了我对这个提问的想法。我就说这个计划可能

这段时间换了新的pair，在和pair做story的过程中。我们提出了“Story Review”这样一个事情。我们两个人都从中收获颇多，就简单写篇博客记录一下，以后说不定还会有更新。所谓的Story Review其实就是在做完一个Story以后，对做Story的收获和不足的梳理总结，应该包括但也不限于如下：1. 完成Story的过程是否能够改进？解决有

前段时间看到微博上看到一则冷笑话，讲的是如何画马：我看到前半截的时候，我还真的在纸上用笔一点点的画，但是当我看到最后一步的时候，What the Fuck！！！

我们都知道Story卡是对业务价值的描述，是一个业务价值单元。写Story卡的人和读Story卡的人都不会首先去考虑如何实现这个Story，而是思考的是这个Story想要传递什么样的业务价值。这个时候Dev一般都会思考怎么样用最合适的方式去实现。但是对于Task卡，我们就没有去过冬的思考怎么样实现这个Task里提到的东西了。因为它是一个Task，而不具备完整的业务价值。

在软件开发的过程中，我们

何为DEBUG？DEBUG，就是搜索BUG，让后把它DE了。