软件开发管理
lxguru2
这个作者很懒,什么都没留下…
展开
-
软件开发管理:源码版本管理
引入软件开发管理应该循序渐进。不要试图一蹴而就;要给团队一个熟悉,学习,适应,提高的过程。尝试软件开发管理的第一步是引入源代码版本管理系统。如果你开始一个新项目,版本管理工具当然应该选Git 。Git 是一个开源的分布式版本管理系统,无需后台数据库或中央服务器,非常易于使用。当然,对一个开发项目,我们应该设立一个特殊的Git 节点为項目的正式签入代码目标(也可称为主节点)。这个签入节点本质原创 2016-01-27 04:44:45 · 1046 阅读 · 0 评论 -
软件开发管理: 团队建设
新陈代谢开发团队有一个成长成熟的过程。新陈代谢有两个含义:一个是吐故纳新,吸收新成员,淘汰某些旧成员;另一个含义是团队成员自身的成长和提高。末位淘汰,分级评估: 团队管理人员从日常的项目开发活动如scrum ,和一对一会议,观察团队成员的能力和水平,作出比较客观的评估。可以从3个方面评价团队成员:对项目开发的实际贡献;对帮助其它成员的贡献;成长前景和空间。依据综合得分,给成员排位,原创 2016-02-06 09:52:45 · 1760 阅读 · 1 评论 -
软件开发管理: 迭代小结会(review meeting)
时间:在项目开发过程的一个迭代刚结束时。会议一般约为二个小时。人员:项目开发团队成员;相关人员(产品经理等);高层管理人员(非必须)目的:找到有待改进之处;若能找到改进之办法更好内容:再接再厉之处;可改进之处;急需改进之处;相互表彰最重要是改进之处;表扬和肯定也必须有,有利于提升士气。要点:鼓励每个团队成员对项目管理方式提出意见和反馈,对子任务的完成进度提出意见原创 2016-02-05 09:53:45 · 1135 阅读 · 0 评论 -
软件开发管理: 每日晨会(scrum)
每日晨会是敏捷开发过程中最为重要的一个环节。核心团队成员每天早上开一个非常短的碰头会,每人平均2到3分钟,介绍昨天做了什么,今天要做什么,有什么困难没有。主要目的是便于项目管理人员了解任务开发状态,发现潜在的隐患,督促团队成员勤勉工作,帮助解决困难。一般采用站立式非正规会议,集中在一个小会议室或者是在稍微偏僻一点的走廊。当项目管理人员发现某个团队成员工作不力或者是遇到困难的时候,除在会议上原创 2016-02-04 11:19:45 · 2962 阅读 · 0 评论 -
软件开发管理: 技术午餐会(brown bag)
技术午餐会是一度流行与于某些软件公司的一种团队技术共享形式。Brown bag来源于每个参加者自带从公司食堂拿来的外卖午餐(装在棕色纸袋内) 而得名。由某个团队成员利用午餐信息时间,在一个小时时限内,不正式地向团队介绍相关领域的新技术动态。目的是使团队层面跟踪业界技术发展,知晓其它团队或公司的动态。简而言之,(粗略)知彼。个人认为,如果能找到相关的网上技术视屏,网上视频的效果远好于团队技术午餐原创 2016-02-03 06:29:47 · 598 阅读 · 0 评论 -
软件开发管理:林总六大原则之对照
林总的六大战术原则(一点两面,三三制,三猛,三种情况三种打法,四快一慢,四组一队),是东北野战军华丽变身为百战百胜的无敌之师的练兵法宝。经调教后的东野,对手为之闻风丧胆,一声“戴狗皮帽子的部队来了”,对手了无斗志,土崩瓦解。林总打造东野的练兵秘诀,成就了中国军事上的一段传奇。六大原则,操作性强,不同的岗位采用不同的原则:决策级指挥员适用的是四快一慢,三种情况三种打法。战场指挥员适用的是原创 2016-02-02 07:24:07 · 1436 阅读 · 0 评论 -
软件开发管理: 场景为基础的项目任务分解
确定项目立项(即获得资源预算),如同规划三大战役,是统帅部也就是公司决策层的宏观战略。一个项目立项后,项目责任人(一般是开发经理或产品经理)将项目分解为多个场景(scenario),然后依场景的优先级规划多个迭代。每个迭代一般对应一两个场景,并将场景分解为多个子任务,分配给团队的各个成员。子任务的设计,是详细设计,集中关注有限范围內的组件及相互作用。在实现子任务时,程序员若发现有遗漏的子任务,应为原创 2016-01-31 11:05:45 · 1715 阅读 · 0 评论 -
软件开发管理:系统设计和技术原型
一个软件项目开发前,当然应该先有系统设计。系统设计不同于详细设计,系统设计不是详细设计。系统设计就象一个简略战役构想; 详细设计,就象依据具体地形和进展态势指挥一场战斗,才是软件子功能具体编程实现的有效指导。依靠战役构想(系统设计)指挥具体战斗(软件实现),是不可能的。 对于系统设计,我们可以采用非常正规化的设计规范,采集尽量完整的用户需求,制作尽可能完整的设计。推荐的轻量级设计,是以关键的设原创 2016-01-30 20:29:19 · 2043 阅读 · 1 评论 -
代码开发管理: 内部wiki 系统
软件开发团队不是仅负责软件(详细)设计和实现,而是整个软件产品的方方面面,比如用户支持内部文档。团队成员间也有设置,开发,测试的知识需要共同分享。内部wiki 系统即专为团队协作式文档工具。wiki 系统是共享式文档服务,内置版本支持功能。成功使用wiki 系统的关键,是每个团队成员有意识的,积极的参与;每个成员,不仅是文档的读者,也是文档的共同作者。应该鼓励团队成员经常地使用WIKI系统,随原创 2016-01-29 12:42:27 · 563 阅读 · 0 评论 -
软件开发管理:敏捷开发之玉女心经
(改编于高效程序员的45个习惯)迭代开发,价值优先分解任务,真实进度站立会议,交流畅通用户参与,调整方向互审互查,代码质量测试驱动,安全可靠持续集成,尽早反馈自动部署,一键安装定期回顾,持续改进不断学习,提高能力。现在是2015的除夕之夜;软件开发团队管理系列就告一段落了。正月初一即将开始新的系列--软件开原创 2016-02-08 11:40:11 · 331 阅读 · 0 评论 -
软件开发管理: 创新
软件公司不是研究机构,它的主要任务是开发成品软件。但是,创新力是软件公司的一个重要指标;创新发展是软件公司生存成长壮大的重要动力。技术竞赛技术竞赛是公司范围或者部门范围内鼓励员工积极参与新技术的学习和应用。一般每年定期举办一次,采用展板和原型演示形式,由竞赛技术委员会评定名次,前几名给予表彰。专利专利是公司技术储备的量化。公司应有专人(专利秘书)负责专利申请的程序性原创 2016-02-07 09:22:24 · 850 阅读 · 0 评论 -
代码开发管理: 持续集成
持续集成(continuous integration)意味着有一个自动化系统,持续不断的从代码版本主节点获得最新代码,编译构建,运行广泛的测试用例,如果需要甚至安装部署到中试环境(staging),和生产环境(production) 。这些测试用例,包含所有的签入测试,以及所有的集成测试,系统测试,性能测试。由持续集成系统运行的广泛测试,测试当前系统设计的各个方面,是保护系统实现质量自动化流原创 2016-01-28 08:37:15 · 345 阅读 · 0 评论 -
软件开发管理: 签入测试
签入测试(Check-In Test, 也称提交测试),是保证提交代码的质量的另一个重要工具(还记得代码互审吗?)。软件开发中最常见的代码错误,是新代码改变了某些语法(调用接口)或语义(行为),使得依赖于那些语法语义的其它代码不能正常如前工作。其次是以前修复的错误又死灰复燃。这两种错误,都应该有单元测试和集成测试来检查。签入测试由所有的单元测试和部分重原创 2016-01-27 10:46:31 · 414 阅读 · 0 评论 -
软件开发管理:代码互审(code peer review)
代码互审互查,是非常有效,第一重要的代码质量管理方法。另一个重要方法是代码自动测试。代码互审来得比自动测试更为重要,这是因为自动测试不一定适用于所有的项目;代码互审可发现设计缺陷和后门代码,而且让团队成员相互学习相互磨砥。在专业软件公司如微软,代码互审是非常严格的。一般地代码要经过几个互审回合(也称为迭代),最后经其它成员审核通过,加上签入测试(CIT )也通过,代码才能签入到主节点。原创 2016-01-27 04:46:47 · 1526 阅读 · 0 评论 -
软件开发管理: 编码规范(coding style)
编码规范(coding style)是与语言有关的,适合本部门情况的,详细代码书写格式说明,包括代码范例。编码规范,听起来是个鸡毛蒜皮的小事,实际上,它向所有写代码的团队成员表明了团队对于代码质量和代码可读性,是非常严肃的。每个团队都应该有一个不断维护着的编码规范,确保所有团队成员都熟悉规范的条例。原创 2016-03-23 12:14:52 · 781 阅读 · 0 评论