混合建筑-创业型软件企业的研发规划.docVIP

混合建筑-创业型软件企业的研发规划.doc

  1. 1、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
混合建筑-创业型软件企业的研发规划

混合建筑-创业型软件企业的研发规划 1有必要规划研发体系吗? 很显然,大家都认为有必要。因为: 1公司未来良好发展的基础 很显然,一个破破烂烂的4缸4冲程发动机怎么可能让汽车保持在200公里的时速。而缺少润滑油,各个缸点火不同步不仅不会增强动力反倒是会消耗动力。 此外,把发动机放到汽车的哪个位置,周围给不给它留出点空间也是个问题。Benz有8缸发动机,V形排列。也很难想象我们永远开着4缸的车同别人的8缸16缸乃至160缸的车赛跑。很少有人不同意在适当的时候换8缸发动机。但是,怎么换?是不是能把车的机器盖子拆了,前面立上个一米高的发动机? 2. 保证团队稳定的基础 研发体系不完整→工作混乱→人们疲于奔命→厌倦工作→人才流失 3. 无规矩不以成方圆 研发体系建立的过程就是制定规则的过程,有了规则众人才能知道右侧通行才能知道红灯停绿灯行才不会在过独木桥的时候接二连三象下饺子般落水。 2 研发工作的特点 软件公司,以软件开发为主,没有软件开发就等于是无源之水无根之木。但是什么是软件开发? 从微观上看,软件开发就是把思想变成文字的过程,是受主观情绪影响的创造过程。 对于每个个体而言,软件开发不是照本宣科,它的效率不是常数。看下列公式: SDE = F(IQ, EQ, EXP) * EMOTION。 SDE = Software Development Efficiency, 软件开发效率 IQ = Intelligence Quality, 智商 EQ = Emotion Quality, 情商 EXP = EXPerience, 经验 EMOTION = 情绪,完成当前工作的意愿 EQ中包括: 1.持续专注软件开发的能力(注意力专注时间) 2.工作受到打断之后重新恢复的速度 IQ是不变的,这也是为什么人们看重学校名气的原因; EQ受个人阅历、身体状况等影响较大,变化较缓慢; EXP是个人的知识的积累,其变化速度以季度、半年或者年为单位 EMOTION受到环境的影响最大,变化速度也最快。 不良因素对个体情绪的影响有短期和长期之分,偶然的不良因素只会影响一时的EMOTION,但是积累过久,可能会使得人对当前的环境产生厌倦。这也是为什么都市里出现很多“工作恐惧症”的原因,这直接导致效率低下,人心涣散。软件开发工作应约束和激励并举,只有约束没有激励会挫伤员工积极性。 3 指导思想 什么样的规则才是成功的规则? 当规则变成了每个人的习惯,当每个人都通过实践认识到遵守规则所付出的代价远远小于收获时,人们自然愿意会把规则变成习惯,就像人人都知道右侧通行(大陆国家的习惯,而岛屿国家的左侧通行习惯是由航海习惯演变来的)好虽然偶尔有人出格但是绝大多数都遵守这个规则。 规则对于新成员来说应该是一个指南,而对于老成员来说是一种习惯。习惯的力量是巨大的,当一个群体形成习惯之后,新成员会不自觉地融入该习惯中,而无须别人的呵斥苛责。这也是为什么强调“群体习惯”而淡化“规则”的重要原因。 那么怎么会让规则变成研发人员的习惯?这些习惯是怎样形成的呢? 如果一个规则,让你觉得很不方便,恰好又没有人监督你是否遵循这个规则,那你还会去遵守它么?我想,这个回答应该是显然的,大多数人都不会去遵守它。 这里举一个简单例子。 持续集成,每日构建已经成为软件工程里面普遍认同的好办法。那么可以制定规则要求程序员每完成一个小功能就要把他们的程序变更检入库。但是同时规定每次入库之前,程序都要经过测试,而有些时候,程序的彻底测试需要半个小时到一个小时的时间。这时候,程序员会觉得测试很麻烦,花掉了太多时间,他很可能会等完成多个功能后(也许要花一整天或者两天乃至更多),然后再测试并检入。这违背了持续集成的原则,使得冲突和缺陷的检测更加困难,因为在一次引入多个变更时,更加不容易确定是哪个变更导致了错误。 对于这个问题,难道没有解决的办法吗?在后文软件配置管理中描述。 ? 那么是不是说,有了规则,有了监督就一定灵光呢? 完全靠强制手段推行?大家都应该知道,强制手段并不是包治百病的灵药。 软件开发效率取决于EMOTION,所有可能导致开发人员抵触情绪的规则的强制实行,都可能暂时或者长久地降低开发效率。研发制度不是封建制度和奴隶制度,居高临下、懿气指使必定会招致开发人员的反感。强行指令,每时每刻派人盯着并不是好办法,迫不得已,不要使用,更不要说多次使用。 此外,不得不说的一个问题是,虽然资本可以购买技术,但不等于说,有了钞票的报酬,就可以不顾及每个个体的感受和尊严。人们只有在团队中同时获得物质和心理满足,才会为这个团队全力贡献,尤其在软件开发的团队中,很难衡量思想转化成代码的效率,消极转化和积极转化是十分不同的。 有很多软件工程或者软件管理的书籍都提到这样一个统计:好的程序员比差的程序员效

文档评论(0)

zhengshumian + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档