今天是7月20号，21号也就是明天即项目内测时间，团队的小伙伴们正在紧锣密鼓敲代码。
在项目开发过程几点体会
昨天CEO同学过来问进度，然而我并不能清晰的知道现在的进度，只能每个人都说一下自己的进度。
我们团队是一个全栈化的团队，但是目前还是每个人开发一块，造成单点延迟。全栈化团队一个重要目标就是解决单点性能瓶颈。
在开发的安排上，首先过于乐观的估算了后台编辑页面的开发量，其次小程序和PC编辑端开发开始的迟了些。
在开发过程中，前端对后端的接口设计其实没有仔细了解。对于RESTful不太熟悉；
总结问题
开发工作量估算偏差太大；
开发进度不透明；
单点开发瓶颈；
团队默契度太低，无效沟通太多；
没有一条明确的路是通往成功的，我们能做的是绕过所有已知或者预知的坑，绕不过去就填平。
我的个人经验：
首先我经历的每一个团队都有很多问题，反正是不可能有一个完美的团队，成功可能也不需要完美吧。但是我可以明确的感觉到曾经做的好的团队和不好的团队的差距。我觉得好的团队和做的做的不好的团队一个主要差别在于：认识自己和勇于改变。
然后我们聊一聊敏捷和Scrum,敏捷开发是软件工程学的的一个开发模式，主要思想是以灵活的迭代方式快速实现产品。敏捷开发是一套理论，Scrum是敏捷开发理论下的一套实施方案。包括站立会、燃尽图、任务估算、产品验收等。我之前的团队有严格遵守Scrum的，也有模仿形式的。在早期我是推崇敏捷开发的，后来经历了很多团队，看到了很多问题，也思考了一些，最终觉得敏捷开发和Scrum都不是银弹。每个团队都有自己的特点和问题，所以我不赞同团队严格的Scrum化，但是我们需要借鉴Scrum的一些优秀的方式来解决现在的问题。
再聊聊软件开发和团队。如果我们看到一个团队里的成员在工作中都是积极的，都是有主人翁精神的，那么毋庸置疑，这个团队一定是个不错的团队。这代表团队成员不是被动执行，而是主动思考和执行，团度的创造力，执行力和凝聚力自然是高出普通团队一大截。那么这样的团队从何而来？毋庸置疑，这跟团队leader绝对相关。那是什么特质，让一个leader领导如此团队？当我读了《How Google Works》后受到一些启发：赋能+求实。当埃里克主张做KPI考核机制的时候，佩奇问当有了KPI，员工能不能完成的比KPI更出色，埃里克想了一下之后便放弃了KPI机制。求实在于团队勇于面对当前状况，直面真实，做有效的事情。Get到重点之后，leader要以身作则，塑造一个这样的环境或者说文化。千万不要指望团队每个人自带小马达，环境塑造个人。比如埃里克刚刚进入Google时候想要一个独立的、整洁的办公室，但是好不容易搞了一间不大的屋子，第二天便有一个工程师挤进了他的办公室，这打破了埃里克几十年的职业认知，但是这件事最终赢得了他的赞赏。再比如Google的每周五问答会，员工可以直接问高层任何问题，可以很尖锐。所以Google在创造这种积极的工作环境或者文化方便做的很好。这并不是说模仿Google就能走向成功，而是优秀自有优秀的原因，值得借鉴的还是要借鉴的。
说了那么多，以上的问题该怎么办？
关于开发时间估算。公司一般有两种开发时间设定方式，一种是根据产品功能开发量，开发团队给出完成需要时间，第二种是领导根据公司计划给定一个开发完成时间。两种没有合理不合理之分，但是在产品实现和开发时间估算上要采用不同策略。对于开发时间估算Scrum提供了一个很好的方案，团队一起对产品（产品经理也参与）功能进行拆分，变成开发任务，拆分时候倾向与将开发任务拆分足够小，这样在拆分的时候将把一些隐形开发任务也挖掘出来，避免在开发过程中才被发现。在产品功能拆分成开发任务后，进行开发任务复杂度的估算，用最简单的任务做单位1，以斐波那契数列做估算，切记不要把任务跟时间联系起来。在估算复杂度后根据最简单任务时间乘上复杂度就是任务实现时间。在第一种开发团队给出完成时间的情况下，开发团队根据自己情况，安排迭代周期和每个迭代完成的目标，每个迭代目标驱动。在公司给定开发时间的情况下，对产品功能排序，做最重要的功能，根据任务拆分，每个功能开发时间也是大概确定的。 ！！！另外其实在开发过程中有许多不能确定的开发，比如有些框架没有接触过，就像这次的Egg.js和mongoose我就没用过，就不能确保开发时间，在这种必须要却不能确定时间的应该根据经验给出大体复杂度然后在开发过程中根据个人情况随时调整。整体经验丰富的团队要更能准确掌握时间。最后切记时间只作为开发团队开发进度指导，目的让进度透明，每个人心中有数，不作为强制要求。
开发进度不透明，在开发任务拆分后，配上适当的燃尽图和站立会，开发进度将会公司内部透明；
单点开发。全栈化是解决单点瓶颈的有效方式，全栈开发也是互联网技术开发团队的趋势。随着移动互联网过程中技术的快速发展，各种技术方案都已经成型，各种开源代码实现了我们大部分需求，大量的云服务解决了基础问题，可以说今天的开发者是站在巨人的肩膀上写代码，要学会拿来用，学会甄别优劣，不要自己创造轮子。如果开发卡在了一个点上，那么我们就要思考，是不是有办法让团队里的人也参与进来，比如CI化已经卡在运维一周了，是不是可以让运维开放账号，我们自己来做。
关于团队合作。用简单的规则消除不必要的沟通，如使用RESTful接口规则消除大量接口定义的歧义，相信经过1.0的开发，在1.1及以后团队对与接口的理解将会更畅通。原则就是多沟通好过不沟通，不用沟通好过多沟通。
最后思考，如何让团队对产品负责，而不是一个人对产品负责。。
七月特困，睡不醒，希望八月来碗鸡血。
