2015-SH项目总结

2015年，加入现在的公司（外包公司，名字就不说了），做SH项目（化名），在这个月（2016.01）结束了。

虽然公司也有做项目总结，不过我还是自己也总结一次。

项目概况：

　　这是个为一间私人会所提供全面服务的一整套系统，有移动（Andriod+iOS）端、内部web（面向会所的员工）、外部web（面向会所的客人）。

　　我们的客户也是软件公司，我们是项目外包，我们负责web的前端，和全部端的后端开发。还有web端的测试。 数据库和界面设计都由客户的人员负责。

　　我在其中负责前端开发，也是一个开发小组的team lead。

　　以下是技术上的概况：　　

　　开发模式： Scrum（敏捷开发），一般两周为一个sprint（迭代、一个sprint提交一次交付，并进行一次demo）

　　团队构成： 4个Scrum team（开发）， 一个QA team（测试）， 1个BA（需求）， 一个PM， 总人数大概30+。我所在的小组加我共4个人。2前端2后端。

　　数据库： mysql

　　后端： java（后端技术不太清楚）

　　前端： angularjs、sass、css3、grunt、gulp、nodejs、shell

　　部署、版本管理：jenkins、 nginx、git、gitlab

　　管理工具： jira、kb

　　

项目问题：

　　这里我只总结两个问题。

　　第一个，刚加入这个项目的时候，感觉团队比较混乱，很稚嫩， 很多东西都要从头的摸索。

　　　　 我很纳闷， 作为一个外包公司， 应该有很大量的项目经验。一个新项目成立后，应该可以借助这些经验快速构建团队、开发模式、开发流程。

　　　　但是实际情况却是，这个项目没继承到来自公司的项目经验，只能在项目进行中摸索学习。

　　　　虽然， 项目中的同事进步都很快，但是，我们本应可以更快。公司缺少对项目的积累和总结。

　　原因猜想： 成也外包、败也外包。 在这个项目，从PM到开发人员，大部分缺少产品意识和主人公意识，应付式的工作。

　　　　这个项目，代码交付后就认为完事了，没考虑更多事情，反正也和自己个人利益无关，没有义务和责任。

　　　　另外，公司也没有相应制度和规范，所以也就事不关己高高挂起了。

　　解决方案： 我认为，项目在交付代码后，还是有事情可以做的，如总结项目经验。

　　　　总结包括但不限于这些问题：技术选型、具体技术点、组织架构、管理、开发流程、编码规范等等。

　　　　总结可以记录项目中发现的问题， 采取的解决方案，以及产生的结果。

　　　　

　　　　这些经验停留在脑子里时，就只是经验， 如果写下来，经过整理，可以形成规范，如果再进行系统整合，可以形成方法论。

　　　　最主要的是，外包公司在这方面有很明显的优势，即项目数量优势。

　　　　现在大多数项目（或公司），都是依靠产品经理的个人经验进行管理和构建，大部分是脑海中的经验。 能做后面几步的很少。

　　　　有了这些大量的整理过的经验，我们可以快速构建团队、开发流程、开发模式，甚至不需要亲自去做， 这能极大提高团队构建和成长的效率， 而且构建出来的团队很快就能有战斗力。

　　第二个，一个sprint为一次开发迭代周期，一般一个sprint为其两周。

　　　　在第一个周一时，BA把需求告诉团队，第二个周五时给客户demo。

　　　　我们每个sprint是开发、team lead（下简称TL）、QA同时开始。

　　　　我们的敏捷有个特点， 就是每个sprint，一般只被告知这个sprint要完成的内容的业务需求。

　　　　由于每个sprint的任务没有预告，开发人员要开工，必须要等到BA告诉TL，然后一起理清需求，分析好设计好，才能开工。

　　　　sprint后期，为了要demo，必须保证开发完成、功能正确且稳定，这导致至少最后一天（最好是2天）开发人员不需要修改代码。

　　　　sprint的头几天QA又会相对清闲的。

　　　　这种流程安排的直接结果，就是每个sprint里，开发人员至少有2天，多的时候3-4天是空闲的。 这导致了团队的低效。

　　　　最讽刺的是我们是在用敏捷开发，效率却如此低下。

　　　　这是开发流程的问题。

　　解决方案：原因猜不到了。直接说解决方案。

　　　　我想到的解决方案其实很简单，就是错开开发人员和其他人的sprint周期。

　　　　TL、QA的sprint早于开发人员的sprint，例如提前2天。 如果开发人员是周一开始新sprint，那么TL、QA应该上周四就要开始。

　　　　他们需要了解、整理需求。因为敏捷的缘故，需求拿到手的时候，一般是不够清晰或者不够严谨的， TL、QA、BA需要整理清楚，至少解决大部分明显的问题，让需求变得可执行，再交付给开发人员进行设计和开发。

　　　　由于开发人员每个sprint开始时就可以开始工作，那么完成时间也就会有所提前，之前在sprint初期被浪费的等待时间被节省下来，可以在demo之前完成功能开发。

　　　　这样的结果是，第二周的周三，开发sprint就结束了，可以开始下一个开发sprint，也可以作为缓冲用来改bug，或留作他用。

　　　　如果开发要提前开始新sprint，相应的TL、QA等，也要提前开始他们的下一个sprint，这能保证开发人员的工作不会被迫中断。

　　　　如果TL、QA的sprint提前2天，理想情况下的好处有：

　　　　　　1. 提高效率：缩短了sprint的周期，从10个工作日（两周），变成8个工作日， 但是产出是差不多的，因为开发人员工作时间没变。那么团队效率就提高了1/5。

　　　　　　2. 降低风险：每个sprint开发人员开始时间提前，就有更多的时间写出更稳定的功能和改bug，demo的风险会降低。遗留到下个sprint的问题会更少。这会是一个良性循环。

　　　　　　3. 减少团队内耗： 不知道有没人有类似感受。当bug多，项目质量差，会导致很多问题。 其中一个是团队内耗， 一般体现是互相推诿。 质量差，就有bug要改，但新的开发任务还照常要完成，时间压力骤升。大家为了自己能完成任务，会把不明显与自己相关的事情推给别人。当然对方也不会乐意接受，于是我们花很多时间用于推掉东西，对团队来说，这些时间都是白白损失。然后恶性循环。 这个方案，有希望减少这种内耗的恶性循环。

　　　　实际情况没那么理想，但应该还是有好的影响，上述几点应该能有不同程度的提高。

项目收获：

　　这个项目中，个人收获还是很大的：

　　　　· 认识到一群很好的同事，年轻、有活力、有想法、技术好。

　　　　· 学到或接触到不少技术： angularjs、sass、grunt、shell、nginx等

　　　　· 自我管理能力提高

　　　　· 小团队管理能力提高

　　　　· 执行力提高

　　　　· 更能坚持做完一件事情

　　　　· 更有自信

完。

-------- 2016.01.29 --------

//

 

//

谢谢观看