了解TechExcel更多产品资讯、客户动态以及精彩行业洞见
22年国际成熟产品应用,产品研发项目全生命周期管理,构建企业铁打的营盘
整合项目管理、需求管理与质量管理的混合型敏捷
敏捷已成为当今最被广泛接受,并被广泛实践的开发方法。有趣的是,敏捷方法的流行并不是因为它取代了其他开发方法,相反它与这些方法进行了更好地融合。现实中,众多敏捷项目的成功,也证明了敏捷将走向杂化的未来。 SpecDD是一个以需求为核心的混合敏捷开发方法。它旨在提供一个简单的框架,在一系列原则指导下能同时管理敏捷项目和传统项目。SpecDD中的用
在Scrum中,工作流经常是非常简单的,一个任务可能仅仅包括了几个状态,开始,进行中,工作完成,关闭。但是在SpecDD中,工作流经常没那么简单,因为质量控制和需求管理也是工作流的一部分
在我拿到计算机科学博士学位的时候,我已经从事软件工作一段时间了。从最初的程序员做起,随着经验的积累,开始逐渐管理软件团队和软件项目。后来我成立了自己的软件公司,并领导这个公司成为应用生命周期管理领域的行业领先者。我经常问我自己和我的同事这样一个问题:如果你只能选择一样,你觉得以下哪个方面的改进,是开发出一个好软件的关键因素: 更好的
TechExcel公司CEO兼首席软件架构师,周铁人博士
当团队处于分布式协同工作时,沟通是最大的问题,也是我们需要尽最大努力去改进的区域。 会议开销最小化。团队成员应该能够便捷地加入电话会议或网络会议。共享桌面的网络会议是非常有用的。视频会议中让相互间都能看到工作白板,也是一个非常不错的选择。 免提耳机、网络摄像头、IM客户端、应用程序共享软件和电子邮件等工具,都是用来帮助沟通
敏捷已成为当今使用最广泛的开发方法。值得一提的是,敏捷方法的流行性并不是因为它取代了其他开发方法,相反是与这些开发方法方法进行了更好地融合。现实中众多敏捷项目的成功,也印证了敏捷将走向混合化的未来。
SpecDD是由周铁人博士创立的一种以需求为核心的混合敏捷开发方法。它基于同时支持敏捷开发和非敏捷开发流程而设计。
软件敏捷开发宣言中提出了以下12个原则: 持续、尽早交付有价值的软件以满足客户,是我们优先要做的首要任务。 拥抱需求变更,甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。 频繁交付可执行的软件,从几周到几个月,交付时间越短越好。 在整个项目过程中,业务人员和开发人员必须每天在一起工作。 激发每个团队成员的积极性来
我们已经明确了敏捷的价值,接下来我们应该将它们实际应用到项目管理中。 简单化: “一切都应该尽可能简单,而不是更简单。” [1] 这似乎是显而易见的,但往往很多时候我们发现自己在努力增加更多的产品功能。项目经理必须有勇气去拒绝那些没有在需求中明确提到的任务或交付件。 拥抱变更: 变更总是不可避免的,拥抱变更也是敏捷开发项目
最近几年,科学技术急速发展。软件的复杂性和CPU处理速度也呈指数增长,而不是线性上升。这种增长率的变化导致的连锁反应,增加了市场的波动,这反过来又要求企业能够快速适应消费者的需求。行动缓慢的庞然大物被普遍认为是缺乏竞争力的,在交付新特性方面也存在更大的风险,这已经是“老生常谈”或是过时的问题了。这也为敏捷开发方法的兴起做出
当一个团队采用敏捷开发后,项目负责人和管理层,很自然的希望团队正确交付可执行产品的同时,也能提高交付的效率。但实际项目执行的过程中,往往遇到设计团队和开发团队互相抱怨的情况,产品负责人在开计划会的时候,会向团队讲解备选的需求故事。由于客户的需求可能更多是一个想法,技术如何实现,最后的产品会用何种方式来表达,可能都还是比较模糊的。综
在和某个想采用敏捷研发管理的客户交流过程中,发现客户存有一种认识,即团队的研发管理模式从传统的管理方式迈入新的敏捷研发管理模型时,只是研发模型的变更,团队还是同一个团队。但是角色定义要变化么?很多时候,客户会觉得没有必要,因为还是原来的开发团队,还是继续做开发项目,只不过快速响应需求,然后开daily standup meeting。这里其实存有误区。
在传统的缺陷跟踪管理软件中,bug都是提交成一个issue/task,当一个大型软件开发过程中,新功能很多,对应产生的bug也很多。即使是使用了很好的缺陷修复优先级,比如说block new feature 测试的,都设置成B.C,但是最终还是会导致同一个优先级的bug数量很多的情况,导致开发无从下手。
所有被block的new feature,它们的优先级也是不一样的,开发没办法一目了然的知道哪个bug是优先级最高的,他无法判断优先修哪个bug。
TechExcel的DevSuite产品推出了Q
在当今充满变数和快节奏的大环境下,一个产品的上市时间已经成为产品成功与否的重要因素。如果对于“完成”没有一个清晰的定义,那么很可能会遭遇产品延期,风险,并且增加公司成本。“完成的定义”也被俗称为DoD,它是一个很有用的工具,可以用来为产品的交付定义各种条件和参数。每个组织根据不同的参数为产品勾勒出不同的DoD。产品参
由于敏捷开发正成为越来越多开发团队的标准,敏捷应用生命周期管理持续呈现增长势头。一个已经被证明了的事实,那就是很多工具供应商发现把自己的产品标识成敏捷工具甚至是敏捷ALM工具,是很管用的。 然而,何谓敏捷应用生命周期管理?应用生命周期管理结合了技术因素和功能因素,为常见的项目活动(如开发,配置,部署,发布,测试,质量,集成,和需求管理)提供一个综合方案
敏捷方法指导团队将产品需求置于Product Backlog中管理,并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前,由Product Owner从Product Backlog中挑选迭代周期准备开发的意向表(Willing List)进行总体介绍,然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法,认为首先不需要对需求做分析,因为需求一直在变。所以提出了Story的概念,认为需求就该是对需求的一种类似讲故事的方式来表达的,这样便于让原始客户比较
SpecDD是一种管理软件研发过程的混合型敏捷方法,它基于同时支持敏捷和非敏捷研发过程而设计,使得开发团队能用相同的办法来管理敏捷和非敏捷项目。SpecDD框架中包含了产品负责人、项目经理、测试主管、开发团队和测试团队五个角色。在SpecDD 模型中,一个项目的研发过程通过三个空间来进行表达,即,需求空间、研发空间和QA测试空间,三个空间是相互完全整合的。
在敏捷开发中最重要的原则之一就是使用燃尽图报表。基本上有两种类型的燃尽图报表;基于剩余时间的燃尽图,和基于剩余点数的燃尽图。基于剩余时间的燃尽图是一种比较流行的方式,它描绘了Sprint日常工作进度以及预计剩余工作时间。基于剩余时间的燃尽图具有以下优点: 易于实践和推广;它真实反映了每个开发人员估计的剩余时间。对于一个有经验的团队成
所有组织面临的情况是使用敏捷可以解决问题。然而,并非所有公司都做好了走向敏捷的准备。尤其是一个拥有多年开发经验的大型团队,会有很多其他的制衡。一个常用的办法是首先实施并塑造敏捷框架。然后将更多的敏捷活动逐步增加到项目各个迭代周期的现有流程中。这种办法常被称为“混合型”敏捷开发,并且有其可取之处。敏捷框架并不是万能的
确保团队执行“足够的”测试覆盖面是非常困难的,尤其是对敏捷开发团队来说。对于初学者而言,一个开发Sprint中要完成多少的质量保证工作才够呢?我们知道,敏捷的标准是在开发Sprint结束的时候要完成一个可交付的产品。那么这是什么意思呢?这意味着软件不能有严重的商业缺陷,不会丢失数据,不会奔溃,同时没有功能性缺陷阻碍基本功能的使用。虽然这
IT技术的迅速发展,为企业提供了全新的运作方式,组织的运作也越来越依赖于IT系统。同时,如何在可控制成本下提供高可用性的IT服务,成为摆在企业CIO面前的新课题。
20世纪80年代末发源自英国ITSM(IT Service Management,IT服务管理)是一种比较成熟的IT管理模式,有关ITSM的标准、软件、实施方法、咨询/培训认证等在我国已受到越来越多的关注。近年来,国内
钎具是用在岩石或其它构筑物中钻凿眼孔的钻头。为了要钻凿不同材质的物体,钎具衍生出极其繁多的样式。管理各式各样的产品和客户需求对钎具供应商造成了不小的困扰。近年来我们为钎具公司部署产品需求管理解决方案时,发现了他们的产品管理上的共同的痛处后。我们整理这些要点以及相对应的解决办法,分享给广大的读者,以减少同行的人走弯路。
软件项目的失败率高,产品品质低是众所周知的事。为提高品质和编程效率,许多的研发团队已经试着在采用某一种或多种混合的敏捷操作。敏捷方法强调交付可执行的版本,而不强调中间产物(如文档)及流程的管理。但在实际的经验中人的因素(知识经验不足,或甚至离开团队)对产品品质和软件持续的交付产生一定的影响。如要保证团队协作效率以及产品高质量的交付,选择
近十多年以来,在国家十一五规划和高校"211工程"、"985工程"的推进下,高校的IT基础设施及信息化建设有了迅猛的发展,尤其是随着近年来国内掀起的数字校园建设的热潮,更是使得网络和各种应用系统已成为高校科研、教学、管理、生活服务等各方面业务开展的支撑平台和赖以运行的基础。然而,正是随着这股热潮的逐步开展,和网络基础设备和应用的增多,很多困惑和
员工状态数据,是对事件派发最重要的支持数据。从管理的角度说,其重要性明显高于用户资料、CMDB相关数据、甚至事件申报信息等。
待命管理把传统服务台摊牌工作的模式,转化为待命员工主动要工作的积极模式。ServiceWise IT服务管理软件平台中,我们是这样对IT运维人员待命状态进行有效的管理:一、待命管理原则1、员工状态的自主表达
2、可以表达的状态设
现在很多客户,不管是发包方还是接包方,都会来问我们IT服务外包该怎么管,既要管人,又要管事,往往2个都没管好。先来分析下原因,为什么客户会有这样的困惑。对于发包方来说主要困惑是不知道怎么去管理这些外包服务商,也不知道怎么去量化这些服务,到底什么是好的服务,什么是不好的服务,服务要做到什么程度才算好的等。而对于接包方来说主要困惑是不知道派出去
我们内部IT目前服务目录的建设初具规模了,大家还比较认可,觉得现在提事件比以前简单了许多,也清楚的知道什么事情该什么事件解决了。以前没上系统时,来什么活干什么事,没有明文的服务内容上的说法,后来IT逐渐的认识到了IT服务管理的问题,开始上了系统,让我们所有的人都在系统上提交,不在受理电话的了。可大家觉得太麻烦了,还要填写内容,有些问题总觉得写出来
用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现一直没有定论,只好在这里原创一下。前言:为何需要讨论用户故事的颗粒度其实需求颗粒度的问题由来已久,即使是在传统开发中,也没有提及在需求分析阶段应该把需求做到什么颗粒度才可以开工。所以在下面这些分析之后会发现,其实即使反推到传统开发中,下面提及的方法也
IT项目管理从某个意义上来说,就是风险管理。从理论上讲风险管理可以分为三个部分:风险识别、风险分析和风险解决。 传统的风险管理系统只能帮我们较正规地统计和管理风险,这些系统本身是不能规避或解决任何风险的。在实际操作上,由于可能发生风险的种类很多,处理起来所耗费的人力物力也相当可观。在下列的案例中,我们建议的不是一套昂贵而且全面的风险
在1995年当我在美国从事IT工作时,曾以咨询师的身份加入一个有数千员工的大公司的研发团队,使用Visual C++实现一个汽车修复估价系统。当时我们没有什么项目管理工具。因为没有足够的数据可借鉴,项目经理对一个项目完成所需的时间完全就是拍脑袋得到的。不仅如此,就是完成某个功能(如,汽车修复的估价报表)的时间也是可以偏差到百分之几百。 当时Jeff是我
十五年前,美国硅谷,当时程序员是一项很有前途的职业,很多人都为能在美国硅谷工作而自豪,但是众多程序员都有一个共同的烦恼,就是有编程和自动测试工具,但是没有管理工具(例如Bug管理工具)。周铁人、蔡培堃和几个中国年轻人看准了这个市场有前景,便开发出了专门管理Bug的工具PowerTrack,。有了它,程序员们可以快乐地管理原来令他们头疼的Bug,这也是TechExcel公
相对于ERP(Enterprise Resource Planning)和CRM(Customer Relationship Management)而言,软件应用生命周期(ALM: Application Lifecycle Management)是比较新的概念。过去几
这一类书籍都是由敏捷领域内公认的大师所编写,主要是阐述了什么是敏捷开发,敏捷开发能够带来的好处等等,简而言之,属于洗 脑类书籍。阅读这类书籍的时候,要深入体会书籍中的哲学
敏捷扑克是什么? 其实应该叫“估算扑克”更准确一些,本质上是扑克牌,基于Delphi估算原理,可以快速估算出需要的数字。关于扑克牌上的数字 估算扑克牌上的数字,有
售后服务平台登录