最近这个季度

最近比较忙，算了下自己可以利用的空闲时间，忙时一天可能只有1到3个小时空闲时间，甚至一天没有空余时间。一周大约只有30小时时间是可以利用的，如果算上玩手机时间只会更短，如果再把这些时间再浪费掉，可能最近半年的成长就只有一些项目经验而已了。所幸平常关注的博客和《软技能》这本书里有提及一些关于自我时间管理相关内容，我简单实践了2个月，分享下这方面的心得感悟。

计划和休息

《软技能》中作者是如何做计划的？

• 季度计划 明确宏观目标，以及如何实现
• 月计划 估算当月能完成多少工作量
• 周计划 为每周安排必须完成的强制性任务
• 日计划 排除干扰，按需调整
• 休息 每隔一段时间休息，只做强制性任务

很惭愧，工作刚开始一两年我少有计划，单纯凭借好奇心学习到了不少东西。大约从去年写年度总结开始才刚刚做一些计划。目前我使用微软to-do跟踪自己的计划进度和deadline效果显著，治好了我的拖延症。

简单来说《软技能》中阐述的几个观点我感觉十分受益：

1. 要有计划
2. 完成计划时保持专注
3. 使用番茄工作法可以保证保证一段时间的专注， 同时还可以确定自己的工作效率， 总结不足提高自身效率，从而帮助自己精确且高效的指定计划
4. 只有你完成了计划的工作，接下来的休息时间才能安心

这边年读书情况

这半年看的书比较少，但是刷题和博客总结写的多了些

技术类：
《sql反模式》推荐， 应该叫数据库结构设计的最佳实践
《软技能，代码之外的生存指南》 有很多事比代码更重要的多，推荐

心理类：
《你的灯亮着吗》 解决问题前，先要搞清楚问题的本质。 一般般

本人本身不太喜欢方法论，感觉都是套路，生搬硬套不适合自己，敏捷开发就是其中让我保持谨慎态度的方法论之一。

敏捷开发与Scrum

对于一个项目来说，能够即快又好地完成当然是非常棒的，但是众所周知，受限于项目管理三要素：时间、质量、成本，只能折衷选择。因此「敏捷」作为一种方法论（虽然Agile自称为Culture）被提出，其中Scrum(/skrʌm/，一种球类比赛)是比较知名的实现类之一。

在Scum中，它主要强调将瀑布式开发流程转为多阶段小迭代，可以理解为CPU的多级流水线(Instruction pipeline)设计，流水线设计将CPU的计算逻辑拆分，实现了复用计算模块，进而提高了时钟频率，同时也引入了寄存器/分支预测等管理模块增加了复杂度。

类似于CPU流水线机制，敏捷开发本质是在保持时间、质量不变的情况下，通过投入管理成本降低开发过程的空转成本，进而提高时钟周期的方法。

用白话来说，可以把软件开放比作流水车间，把PM，SE比作流水线工人。

我见过的的假敏捷

然而到了现实，由于各种原因，却很容易成为假敏捷

• 将工位的隔栏拆开变成网吧“敏捷岛”
• 强行将Release计划拆成一个月一版，将Sprint拆成2周就看作快速迭代，照着人月神话反着搞
• 招聘一堆无责任心的开发让你去“敏捷”，永远无法实现“全功能部队”
• 客户难沟通，PO低估工作量，SE设计缺陷，编码质量低等原因，最终导致延期
  上述任何一个问题，都可能导致最终项目一锅粥，导致高层焦虑，中层跑路，底层混日子的结果。

敏捷能够提供强大高效的方法论，但是前提是需要本身基础过硬的团队，敏捷只能帮助存在进步瓶颈的团队。如果项目已经空心化，债务多，这不是敏捷方法论应该解决的问题。

1. 我就喜欢写代码行不行？

如果刚刚投入工作，工作还无法完全胜任，那我的建议是多写写代码，打怪升级完成自己的年度绩效。

如果已经能够胜任当前工作，下一步应该集中在提效上。这一步和之前自己积累的经验和知识密不可分，只有真正了解代码懂代码，才能从同龄人中的“熟练工”脱颖而出，两者的提效虽然结果一样，但是本质却完全不一样。

如果已经摆脱了熟练工的称号，实际上已经完成了自我提效，提前完成自己的本职任务，下一步可以计划推动团队的效率。

如果太过专注技术，专心自己的一亩三分田，相当于给自己设限成毕业两三年的水平。这种人应该被打上不胜任的标签，在寒冬中很容易被优化掉。专注技术还有一个误区，就是容易把“实施细节”和“技术”两者混淆，特别在软件行业“实施细节”很容易随时代改变，基本三年就会大变样，而“技术”类似于“知识”不会过时。看到这里大家可以自己思考下，自己学到的到底是“实施细节”还是真正的“技术”。

2.如何推动团队进步

恭喜你跨过了第一道坎，推动团队进步不是一个人的事，一般推动团队分为两部分：个人影响团队，团队自我驱动。

个人影响团队比较简单，就是把自我提效所积累的经验和知识共享给整个团队，完成的手段可以是博客分享，会议分享，文档分享。

团队自我驱动，实际上我把整个团队拟作了一个人，一个人找出别人的缺点很容易，但是找出一个团队的问题却没那么容易，同时也会受到公司和领导的局限，比如一些项目管理的领导就是二传手，只催你进度的那种，这时候就需要你主动找他讨论。

如何找到团队的缺点？可以通过下面两个大类的套路：管理手段和技术手段。

管理手段可以从知识管理、代码规范、需求分析三处着手：

知识管理： 建立知识库，避免重复的培训，重复的解答问题

代码规范：借助代码缺陷检查工具，具体到负责人提升代码规范

需求分析：避免低效，无效会议，避免各种妥协下产生的需求

技术手段比较简单：

重构升级：弃用老的架构，拥抱新技术，带领团队提升技术

内部造轮子：内部定制工具，帮助团队高效完成任务

找到了团队的缺点接下来可以制定度量，衡量团队的推进程度，可以从两个角度进行度量：

跟自己比较：比如这次做需求提测bug数减少，需求delay少了，满足需求不需要上线只要配置上线，等等

和别的团队比较：这个比较凶残，我也不知道用什么度量比，但是有的大公司就是这样做的。

3.总结与晋升

从发现缺点到最后得到成果完成团队推进目标，是时候写个ppt在领导面前吹一波了，这个就不用我教了。