• 0
  • 0
分享
  • 禅道软件设计六大原则——软件测试圈
  • 曼倩诙谐 2024-10-11 14:33:58 字数 2393 阅读 256 收藏 0

  每一个产品都是为了解决某个问题而产生的,在诞生之初都是有自己的目标和原则的。只不过随着时间发展,产研团队慢慢更换,很多东西就慢慢丢掉了,改变了。所以在设计完善禅道项目管理软件的时候,我一直都比较恐慌,唯恐哪一天禅道也变成了自己不喜欢的样子。也就有了一些自己固执地坚持,不肯妥协的原则,跟大家分享下。

  第一原则,长周期原则。

  想尽一切办法让产品的生命周期大于团队的生命周期。每个产品都有自己的生命周期,每个团队也都有自己的生命周期,这是客观规律。但我总会觉得用户和客户因为信任选择使用禅道,我们就要为用户和客户负责,这是我放不下的责任和义务。一方面我努力地赚钱,让团队持续发展,为我们的用户和客户提供更新和支持服务。另一方面我就一直假设万一有一天我们团队不存在了,用户和客户怎么办?

  我想到的解决方案就是开放源代码。这样用户和客户可以选择私有部署,不会受限于某一个平台本身,可以一直使用。用户和客户还可以根据自己的实际需要对禅道进行修改维护,哪怕禅道团队哪一天不存在了。目前禅道有开源版和收费版两个版本,其中开源版的代码是完全开放的,收费版的代码我们也做了必要的开放。禅道还提供了非常彻底的扩展机制,方便用户和客户进行二次开发。我曾经见过一位客户就是通过修改禅道的语言项,将禅道改造成了工程造价管理系统。

  第二准则:不伸手原则。

  牢记,用户和客户才是数据的唯一主人。未经用户和客户同意,不能拿用户的数据。大家可以查阅一下国家关于某互联网用车平台的审查报告。吐槽的话就不说了,再多的语言也无法表达我作为一个普通用户的愤怒和无奈。所以我从来是不相信任何互联网平台的。我们的所有数据,哪怕是独立的云主机,在大厂的技术人员面前,都是透明的。

  我们增长团队的同事经常问,有没有禅道功能模块使用频率的数据?我说不好意思,我没有埋点,没有这些数据。只能通过用户的反馈来做一些判断。迄今为止禅道就有一个检查更新的功能,会有标准的HTTP REFERER和禅道的版本号等信息传递到我们的检查更新接口,而且这个功能用户也可以关掉。

  我们也提供了云禅道的服务。但我们提供了完整的数据备份导出功能,用户可以随时将数据备份到本地,转为私有部署。最近有某互联网大厂下面的任务管理工具开始割韭菜了,一个账户一年700块大洋,很多客户就咨询如何转到禅道。我们看到有API接口,但骚操作就是API的权限是要额外申请的,一般不给开放。靠这种方式绑架客户,能行得通?

  第三准则:不跟随原则。

  我在前面的文章也提到禅道的设计一直坚持独立自主原则,不会说市面上的某个软件做了啥,我们就要做啥。大家一直诟病中国很难出原创的产品。我觉得不是缺人才、技术和资源,缺的是一份自信。我看完《流浪地球2》的最大感觉就是自信的中国人,可以做出最优秀的产品。

  不跟随,也不是说完全闭门造车。我们还是要保持开放的态度,广泛地吸收信息、学习新的技术产品,但最关键的是遇到问题不要第一时间去找市面上是否有可以参考的案例,而是应该自己进行设计,有了自己的方案后,再来查找资料进行印证和完善。我们一定要自己从0到1进行思考,不停地做这个训练,保持对产品的敏锐洞察和独立判断。

  第四原则:不唯上原则。

  作为一个企业管理工具,在某种意义上我们充当了第三方的角色。这就需要我们抉择,在做产品设计的时候更倾向于哪一方?是更多地考虑公司管理的需求,还是更多考虑执行团队的需求?

  不同的产品对这个问题有不同的选择。比如某互联网大厂的聊天软件,完全的唯上。老板是很爽了,但这样管理的后果是什么呢?表面看一个问题管理者在群里面过问下就很快解决了,但这会引导大家将更多的注意力和资源集中到群里面管理者提出的问题,从长远看,公司正常的协作机制会被破坏掉。

  所以禅道在设计的时候,不会说管理者想要啥我就要做啥,我们要思考这个需求是否合理,是否有更好的解决方案,是否能够提升效率而不是降低效率。所以很多客户反馈的需求我都没有放到通用版本里面,会通过插件或者补丁的方式提供给客户,以满足客户个性化的需求。

  第五准则:不迎合原则。

  与不唯上原则相对应,不迎合原则,就是不迎合只是为了减少一些录入等操作而产生的需求。我举个具体的例子:有很多的用户跟我们反馈说,禅道里面任务的剩余工时应当自动更新计算,理由也很正当,减少用户的计算和录入。从用户的角度来思考,这个需求是完全可以理解的,做起来也非常的简单,但这个需求我们就一直没有做。为什么呢?因为这样操作是错误的。我具体来解释下:

  一个任务最初预计8个小时,第一天开发人员花了6个小时,这个任务还剩余多少个小时呢?还剩俩个小时?很显然不一定。开发人员有可能还需要6个小时,也有可能这个任务还需要1个小时就可以完成。各种情况都会存在。所以用户在更新工时的时候,需要根据实际情况重新做估算。重要的就是这个估算的过程。

  市面上也有很多简单的任务管理工具,为了迎合用户录入的快捷,对流程做了刻意的简化。比如任务就只有标题,没有描述,没有估算工时,没有优先级。爽不爽?用户在录入的时候太爽了,但从团队协作角度来讲,该做的工作一份也不会省,前期少做1份工作,后面就需要用N倍的代价来弥补。正所谓录任务一时爽,项目后期火葬场。

  第六准则:守边界原则。

  一个产品应当搞清楚自己的定位,一个产品团队也要搞清楚自己的价值和定位。做好自己该做的事情,不要做自己不该做的事情。比如不要自作聪明地帮用户作决策,这种小聪明往往会变成惹人厌的地方。再比如不要骚扰用户,让用户安安静静地用你的软件。例子我就不举了,举多了容易得罪人。

  以上是我们禅道项目管理软件团队所一直坚持的原则,您怎么看?欢迎留言讨论。


作者:春哥    

来源:http://www.51testing.com/html/91/n-7795891.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   前言  无论做什么自动化,测试报告一定要有的,它可以清楚的展示出来我们执行用例的情况。便于查看自动化测试结果内容。安静这边了解目前通过python生成的测试报告分别有:HTMLTestRunner、BeautifulReport 、 pytest-html 和Allure,这几种报告内容都是属于不同的模板,本篇文章主要介绍下这如何生成以上四份报告的过程以及对比情况。  HTMLTestRunner  HTMLTestRunner是Python标准库的unittest模块的扩展。它生成易于使用的HTML测试报告。使用时需要下载,然后放到项目目录中  下载地址:http://tungwaiyi...
            12 12 1841
            分享
          • 一、保证Bug的有效性提交的bug必须是有效的,所以我们在提交bug时,需要确定以下几点:交付过程中测试人员需按照设定好的模块,对bug进行归类提交;bug的类型默认为UI问题、功能问题、崩溃问题,提交bug时不可混淆;需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、 bug是否具有唯一性;避免提交操作错误、重复的、已知的Bug。二、Bug标题要简洁明了bug标题要简明扼要的阐述问题本质,让开发能快速了解你所提的bug的大概内容。需要写明在哪个页面执行什么操作出现什么现象。举个例子!正确示例: 在我的设置页面不填写任何内容点击保存后,客户端崩溃。错误示例:设置页面...
            11 11 4162
            分享
          • 前言性能测试是通过性能的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。术语:场景(Scenario):场景即测试场景。在LoadRunner的Controller部件中,可以设计与执行用例的场景,设置场景的步骤主要包括:在Controller中选择虚拟用户脚本、设置虚拟用户数量、配置虚拟用户运行时的行为、选择负载发生器(Lo...
            0 0 2305
            分享
          •   1. 背景  智能座舱是当前汽车行业开发设计和差异化竞争的焦点,当前智能座舱控制器多为整合了传统IPK、HMI、HUD、DMS等若干控制器之后的“一机多屏”的复杂系统。在软件架构上,多操作系统也是其一大特点,如整合安卓和QNX系统是最常见的方案,而在硬件接口上通常是车载以太网、CAN/CAN FD以及LVDS等。  座舱域控制器由于自身特点,其功能测试用例多达几万条甚至十几万条,完全依靠传统手动测试,需要投入大量的人力资源,难以满足越来越短的项目开发周期和软件快速迭代的需求。为了提高测试效率,需采用自动化/半自动化的方式以完成座舱域控制器的功能测试。  2. 测试内容分析  从智能座舱域部...
            0 0 52
            分享
          • 51Testing软件测试圈的小伙伴们,九月开学季开始啦!为了给测试人员更多测试技能的提升,51Testing软件测试圈为大家准备了资深测试专家文章合辑~资深测试专家的精品文章内容包含:1、初级向中级测试工程师进阶2、入门测试行业的必备条件3、自动化框架构建4、测试经验分享5、python服务端小案例6、Python3编写接口自动化框架7、现有测试质量模型优化8、HTML基础9、浏览器兼容性策略本次活动资深测试专家及主题分享:蚂蚁金服开发工程师-任建勇曾供职于多家互联网公司及(比如支付宝)大型外企,多年安全测试以及测试管理工作经验,曾担任开发工程师、自动化测试 工程师、安全测试工程师...
            7 3 11713
            分享
      • 51testing软件测试圈微信