良好的开发习惯在于节奏感

新手一个普遍问题是任务繁重，头绪混乱，每天忙得像狗似的，事情还做不完，还做不好。老大骂你如骂儿子一般恨铁不成钢，自己感到委屈啊，呜呜呜~~~先到墙角蹲着哭一会儿。

怎么办？996吧！

可惜996不是灵丹妙药啊！这个是修来的福报，普通人享受不了！

我仔细观察了这半年团队新人的状况，终于在一天开站会我开始骂人的时候，突然有了顿悟！ 我们的新人开发工作累还没成就感，事情多心里像乱麻，根本的症结在哪里呢？——在于没有节奏感！

据说，做那个事儿不还讲究一个“九浅一深”的节奏吗？开发工作没有节奏， 怎么行！

想想敏捷为啥号召迭代开发？把开发周期平均切割成更小的时间段，然后这就迭代了吗？敏捷了吗？——放屁！

迭代开发除了希望缩短反馈周期之外，还希望培养开发团队的节奏感啊！Scrum提倡“四会”，什么时候开计划会议、评审会议、回顾会议和站立会议，都有一个固定的时间安排。一旦养成了习惯，并能融入团队成员的血液里，做事情就变得有规律可循了！

迭代开发是团队的节奏，那么个人呢？

我那天开站立会议之所以开启骂人模式，起因在于我要求的任务估点没人照着做！为啥要求估点？我是你们老大呢，怎么能不照着我的要求做！？

原因在于他们不理解我为什么要求他们做估算。其实我也认为估算是最不靠谱的事儿，我也不提倡通过估点来评估开发人员的工作量——那为何我还要求团队成员 必须估点？

这又回到开发节奏的话题了！

逻辑就是：没有估点，你就不会去仔细思考这个任务到底要做什么！不思考这个任务到底做什么，你就会在一知半解的时候就开始编写代码！写代码时，不知道先写哪个，后做哪个，于是写的代码也变成了一团乱麻。

必须培养团队成员的开发节奏，这个节奏的体位，哦，步骤是这样的：

• 首先在Jira上领取属于自己的任务卡

• 理解任务卡的目标与业务含义，思考解决方案

• 对任务卡的需求分解任务编写业务场景以及解决方案，并编写验收标准

• 若有必要，和需求分析人员或技术负责人讨论方案和验收标准

• 评估任务卡的天数

• 如果评估的天数太多（超过8天），需要拆分任务卡

• 把任务卡移到In Dev中

• 通过拆分的任务识别测试用例，开始测试驱动开发

看到了吗？ 评估成了任务解决方案撰写的一个“验收动作”。 这里所谓的“评估”，其实是我的醉翁之意不在酒啊！因此，我没有遵循敏捷的做法，要大家来一个计划游戏，又或者需要遵循什么T-Shirt Size。估算天数就可以了，不准确也没有关系，但是 你必须得估算 ！估算之前该干什么？——分解任务！

分解任务有什么好处？叩问一下你的灵魂：倘若你对这个任务一毛都不懂，你还能分解任务吗？倘若你把任务都拆分得干干净净的，你脑子里还会打马赛克吗？

最关键的，你终于可以TDD了！

作为一名程序员，你都不会测试驱动开发，你好意思去谈恋爱吗？