ThoughtWorks、Teambition、Trello、Slack、DevCloud 主流敏捷软件开发工具平台比较

在大公司做了6年程序员,2年项目经理的小王,正在创业公司迎来他焦虑的而立之年。

但是对于3个月前加入创业公司的决定,他现在有些烦躁和怀疑人生。在他过往的经验看来,公司新接的小项目,在过去的大公司里1个月就该交付了。现在已经3个月了,工作、生活一切好像都乱了套,虽说对创业有心理准备,但是这些在他看来都不应该成为问题——

? CEO低估了项目难度,在客户面前满口答应1个月交付没问题

? 对软件版本缺乏有效的管理

? 各语言代码检查,安装各种工具和插件,不胜其烦

? 半路接手项目,开发环境和架构大换血造成拖延

? 手工集成

? 测试人员介入太晚,开发完才测试

……

1个全栈工程师带3、5个刚毕业的程序员,大部分正规军的系统训练,团队尚在磨合期,却要满足客户不断提出的需求,紧迫的deadline,一个项目失败就可能直接导致创业失败。

面对严酷的小团队、新团队技术创业现实,在开发人员素质参差不齐的情况下,必须依靠工具辅助开发全流程,补齐创业团队短板,提高研发竞争力。对比大企业的自有自研工具,中小企业多靠第三方工具实现,我们比较了ThoughtWorks、Teambition、Trello、Slack、DevCloud主流敏捷软件开发工具。

1、产品功能是否覆盖软件开发全生命周期

Thoughtworks: 是

思特沃克是较早将DevOps理念引入中国的跨国公司,也为国内多家大型软件公司提供过咨询服务。旗下产品:mingle(项目管理)、Snap CI(持续集成-已停止服务)、GoCD(持续交付)、Gauge(自动化测试)。跨国公司的调性就是不为单一市场本地化,所以产品全英文界面,产品基于开源平台开发。

Teambition:否

Teambition是国内团队协作工具的领导者,互联网创业明星企业。主打项目管理沟通与协作,产品不仅包括软件开发,还包括众多传统垂直细分行业。产品支持部分API接入,以方便完成软件开发的全流程。

Trello:否

Trello可以说是国外开发者(国内部分团队)偏爱的产品了,与Teambition一样主打项目管理,但是Power-Up支持了众多场景与API,没有细分具体行业,但简洁的全中文界面,清晰的场景,学习成本极低,很容易上手。如果你的团队纠结于付费和国际化,使用Trello绝对是不二之选。

Slack:否

近日传闻AWS有意收购Slack,Slack作为国外异军突起的SaaS产品,将邮件、聊天、搜索整合在一起自下而上推动增长的模式打破了SaaS产品的固有套路。产品依然不支持中文,特别是某些服务所需网络国内访问并不顺畅,团队使用成本较高。

DevCloud:是

DevCloud是华为自主研发的一站式云端DevOps平台。产品包含项目管理、配置管理、代码检查、编译构建、流水线、测试管理、部署管理、发布管理服务,实现了端到端一站式开发,覆盖软件开发全生命周期,专注软件开发领域。

2、是否有服务团队一对一指导?

一个企业选择一个全新的研发平台,全新的模式,迁移成本巨大,不仅是代码安全,还有人员学习成本。特别是服务场景越多的产品,不是单单的FAQ能解决的。然而大部分互联网企业的产品,是很少提供专项的专家技术支持的。

思特沃克(Thoughtworks)侧重咨询,往往只针对大型企业提供服务,以“三高”著称:高品质、高规格、高价格。不是一般中小企业享受得起的;Teambition、Trello、Slack主打互联网模式,只有消费到一定金额的客户才会有技术支撑,其余全靠自学;DevCloud(华为软件开发云)可以说充分发挥了华为的人海战术,技术支撑团队可以进驻企业,一帮一把项目迁移上云,扶上马再送一程。

3、是否更适合国内企业场景?

如上文所述,外来的和尚不一定会念本地经。况且能请得起外来和尚的也不多。近些年互联网创业风起云涌,3、5个人的创业公司和团队比比皆是,这种苍蝇腿肉跨国公司是看不上的,也不可能全程培育,他们更崇拜全球统一标准、统一模式。这里本土企业的优势就明显了,创业者与创业者有更多共同语言。

以上,工具只是辅助,思想还需实践。所谓敏捷开发的核心,不过是转变生产方式,以市场、客户、用户为导向,重新理顺管理、开发、测试、运维的关系。一个真诚的建议是能面对面交流的,千万不要以邮件代替。转型总是痛苦的,可是“飞轮效应”告诉我们,虽然早期推动困难,但只要轮子转起来,就会越来越快。这还难道不值得我们今天多加一点力吗?

时间: 2024-08-25 23:59:18

ThoughtWorks、Teambition、Trello、Slack、DevCloud 主流敏捷软件开发工具平台比较的相关文章

敏捷软件开发简述

前言:由于我读了邹欣老师的<构建之法:现代软件工程(第二版)>,因此对敏捷软件开发有了比较大的兴趣.于是我在网上找了一些论文,比如Requirements Engineering and Agile Software Development.A decade of agile methodologies: Towards explaining agile software development.在读了这些论文之后,对敏捷软件开发有了大致的了解.这篇博文主要是简单介绍敏捷软件开发,重点集中在主

浅谈敏捷软件开发与传统软件工程的对比与敏捷开发产生的原因

引言 在"计算机程序的蛮荒时代",人们对于程序的设计.编写是随想随写.灵活变化的.正如我们初学各种编程语言时那样,似乎把程序写对也不是什么很难的事情.然而,这种程序设计模式或许适用于几百行至几千行的小程序,而当我们面对更大的软件规模.更多的代码行数以及更复杂的人员架构时,这种随想随写的程序开发模式似乎不再适用,于是使人们遇到了「软件危机」,进而促使了软件工程这样一门学科的产生. 在我上一门程序设计的课程的时候,老师讲过,当我们学习各种语言.算法和数据结构时,我们学习的是怎样进行&quo

敏捷软件开发VS传统软件工程

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,

敏捷软件开发和传统软件工程

一.   传统软件工程 从上个世纪60年代开始,人们开始逐渐认识到了确实存在着"软件危机" 这样一个事实,软件开发人员被诸如下列问题困扰: 软件生产不能满足日益增长的需要 软件开发成本和开发进度估计往往不准确 软件开发人员和用户之间信息交流不充分,用户对完成的软件满意度很低 软件价格昂贵,软件成本在整个计算机系统中所占的比例急剧上升,软件已成为许多计算机系统中花钱最多的项目 软件质量难以保证 软件可维护性差,程序中的错误很难改正,适应性或完善性维护都极其困难 导致危机问题的一个重要原因

敏捷软件开发?什么是敏捷?

敏捷软件开发?什么是敏捷? 敏捷开发(Agile development)是如今软件工程项目中一个大热的词汇,很多大大小小的开发团队都喜欢高举敏捷开发的旗号,搞出一套显得大大不同于传统的运行模式来区分自己的团队博取眼球,他们手头所做的事情,只是套用一套流行的敏捷开发模板,如Scrum,Crystal,XP到自己的开发流程中,就认为自己的整个开发体系会有一个质的飞越.然而他们是否能真正驾驭所谓的敏捷开发?他们是否理解了敏捷开发的核心理念?这都是要划一个大大的问号. 笔者我在刚刚接触这个词的时候,下

软件工程:传统软件工程 vs 敏捷软件开发

前言 软件工程(Software Engineering): 是一种层次化技术. 将系统化的.规范的.可量化的方法应用于软件的开发.运行和维护,即将工程化的方法应用于软件. 研究"建立和使用一套合理的工作原则,以便经济地获得可靠的.可以在实际机器上高效运行的软件"的方法. 敏捷软件开发(Agile software development): 一种应对快速变化的需求的一种软件开发方法.基于迭代和增量开发,通过自组织,跨团队,沟通协作完成开发工作. 一.传统软件工程 (一)产生背景 随着

敏捷软件开发与传统软件工程

敏捷软件开发与传统软件工程 北航计算机学院 14061157 李奕成 引言 软件开发过程是软件工程中相当重要的一环.一个正确.高效的软件过程能够提高软件工程活动的稳定性.可控性和有组织性.但是,并不存在一种软件过程能够完美的适应所有的软件工程情况.因此,在不同情况下选择合适的软件开发过程显得尤为重要.现代软件工程方法必须是"灵活"的,也就是要求软件工程活动.控制以及工作方法适合于项目团队和要开发的产品. 说到软件工程.敏捷开发,就要提到软件过程的发展历史.20世纪60年代,不存在现代意

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何