V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
merlinran
V2EX  ›  分享发现

干货!首届 Chongqing Hackup 精华分享

  •  
  •   merlinran · 2015-03-19 11:00:21 +08:00 · 1942 次点击
    这是一个创建于 3540 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前两天发了个召集http://www.v2ex.com/t/176467 ,可能很多人没看到或者还在观望。

    首届活动还是比较成功。下面是我连夜整理的精华内容。欢迎点赞,拍砖更佳。


    今天聚会的各位CEO都如此成功了,还在拼命,小编怎么好意思偷懒?深夜加加班,把这些记录的精华发布出来。

    产品排期和工作量评估

    新晋创业者Yeti,特别苦恼于新产品的进度。业务领域新,采用的技术也新,屡屡挖坑屡屡埋。难道没有更靠谱一点的办法吗?

    两位对交付项目非常有经验的老大总结道:在技术路线和业务领域相对熟悉的项目,按照经验估计的值,再加上30%的余量,就很靠谱了。当然,这是跟那些对IT有一定理解的客户。如果客户比较飘,思维发散多变,加个100%的余量也是可以的。而且,一定要重申需求变化的范围

    如果是做产品,灵活度就比交付项目要高一些。可以确立小阶段内的整体目标,而非制定长期且固定的计划。小编所在的开源项目团队,是固定发布日期,按照紧急和重要程度,把需求/BUG放入其中,算是暗合了Scrum吧。

    打造牛B技术团队

    要排期准确,就需要熟悉业务,也要熟悉技术领域里的坑。二者都需要长期积累。业务需要浸淫,而如何打造一支坚实的技术团队,咱们的阿苏老大颇有心得。

    • 每天的晨会

    按照之前计划,当天要完成的事情,每位程序猿/媛来讲讲,准备如何去实现。如果想得不清楚,很快就会卡壳,团队就知道风险所在。有坑的地方,其他跌过坑的同事也可以指出来。

    另外这也是一种形式的同行评议,评价采用的技术路线,每一次探讨,都是进步的契机。

    • 每周五下午的内训,大家轮流讲topic。主要基于两点考虑:

      • 能做出来不一定懂,能讲出来才是。
      • 工程师都是寂寞的,他们们写出了牛X的代码,也希望被人赞叹,希望登高一呼,群山喝彩。这是尊重了人性的规律

    如何鼓励大家主动分享,又不带来压力呢?

    首先不要把时间定死,一个小组轮下来,就是俩月了。俩月的工作中,总能找到点儿东西分享的吧?

    那些实在懒惰的程序员,给点惩罚咯。每天下午茶时间的零食,你就负责跑腿。

    有负激励,也要有正激励。讲得好的同学,奖励纪念金币,可以兑换现金,放在桌上,那也是一种荣誉,可以显摆的啊!

    一个牛B的技术团队,要鼓励每位程序员,努力成为全栈,或者在通往全栈的路上。

    效率工具

    现在各种专业的工具越来越多,程序员兴奋异常!一款称手的工具,将大大提高生产力。

    团队协作工具,大家在使用的有TowerTeambition,相较于上一代的产品,比如Microsoft Project和Atlassian的JIRA,它们虽然功能不那么多,但更加轻量,更适合小团队的工作方式。

    对几个人窝在民宅里的创业团队,最高效的就是白板了。大面的玻璃墙,写写画画和便利贴。未来的Facebook,未必不会从这里走出呢。

    有一款人肉测试服务,把APK提交上去,两天后给你把关键的点测得清清楚楚。不知道是不是testelf,反正他们是做这个的。

    明玮兄提到一个服务http://libraries.io 。它可以帮你跟踪项目中使用到的开源包,是否有升级更新,是解决了什么问题,就不用一直盯GitHub了。

    程序员的思维模式

    王老大遇到不少应聘的程序员,一门心思就想写原生代码,纠结于每一行代码是不是自己拿手敲出来的(那不是打字员么?)。这种思维在两类人群中比较常见:

    • 做外包出身。之前都是找CMS改改就交给客户,所以特别希望找找从头写代码的感觉。

    • 学院派。比如那些计算机竞赛或者Linux的同学,觉得内核、算法才牛B,越往底层越牛,恨不得拿代码写个CPU出来,看不起应用的人(小编当年狂啃C++时,也是这样想的哦)。

    特别明显的现象是重后端轻前端,觉得JavaScript是啥嘛?玩都不屑于玩的东西,还好意思称自己叫代码?但其实,前端的未来可能更加光明。平行类比制造业,质量多好、多高效,也许在过去的岁月、或者少数基础产业非常重要,但个性化和极具设计感的消费级产品,才是更广大的未来。

    论CEO的三种境界

    • 第一种CEO,身后背着一群团队成员,勉力前行。
    • 第二种CEO,和团队并肩作战,同吃苦共受罪,就差大被同眠。
    • 第三种CEO,团队在前面跑着,自己紧跟在后。前面说,来箱子弹,递上去;前面又说,口渴了,赶紧端茶递水。

    再往上一层,CEO已经不做端茶递水的工作了,他专注于解决团队其他成员不能解决的问题,是什么呢?战略(确定那不是懂事的长?)。

    论业务层的测试驱动

    为什么上测试驱动,实因切肤之痛。小团队很难找到专职测试,即便有,也难有充裕时间完整覆盖。随着代码的增加,问题会越来越明显。

    测试的核心,是让产品经理参与。产品经理规划测试用例,写TODO list,把需求列表转化为可以执行的断言。JAVA自然用Maven,而OC就用XCTest。

    我们知道,测试粒度有粗细,DAO - Service - Controller,每一级都可以引入测试。产品经理只能关注到业务层面,所以至少要覆盖Controller级。工程师在保证进度的前提下,可以自己在更小粒度上测试。

    代码质量除了用技术手段和流程来把控之外,也事关工程师的责任心和荣誉感。在春节加班改完团队的BUG之后,文艺老板迅疾组织讨论,题目就叫《程序员的自我修养》。

    从更高的视角看,按照墨菲定律,没有检查的地方,就一定会出问题。任何行业,关键地方一定要设立检查点

    王老大高屋建瓴:测试驱动蛮好,敏捷开发蛮好,但关键在于,要在合适的时间做合适的事。在某个项目中,老大并未耽于代码,而是在14天内六易设计稿,让客户拍案惊叹:这样的提供商,岂能不用!创业者的勤奋可见一斑。而这做事的思路,与现今流行的精益创业不谋而合。

    行业发展

    做外包的企业,几年之内就能看到未来成败。有机会成的,一定会扩大规模,项目越做越大。但成于大项目,更可能死于大项目。尤其现在的时代,90后员工的想法已经完全变了,庞大的团队,将给管理带来巨大挑战。做产品,是条艰难重重的道路,但也是必然的选择。

    企业和个人的成功,极大地取决于运气。某总曾误打误撞进入国内技术的前沿,差一点就成为腾讯早期员工。与成为亿万富豪的机会失之交臂,可叹。但一朝展露头角,便可以进入圈子,资源共享和整合的机会就多起来,所以二次成功的机率就大大提高。


    本期的干货就为您分享到这里。所以,可有兴趣一起玩?来跟咱们对对眼吧。

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1526 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 17:14 · PVG 01:14 · LAX 09:14 · JFK 12:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.