新闻动态

为企业级敏捷准备工具和基础设施尽管拥有这种水平的组

2019-03-09 19:37:17 作者:小麦

尽管拥有这种水平的组织结构和协作,大项目和分布式团队中的软件开发成员仍可能觉得缺乏内部和跨团队的协作,以及可靠地交付快速、充分测试的软件迭代所需的项目透明性。虽然 Scrum软件开发的项目管理提供了被证明可行的框架,但是它并没有规定特定的软件工程实践,也没有推荐任何工具来支持 Scrum的流程。Scrum在这方面的哲学是:保持简单,让团队做决定。当众多组织还在为现代工程实践困扰时, Scrum已经引入了Scrum开发者( Scrum Developer)项目和现代应用程序生命周期管理(ALM)工具的培训。

实际上,对于理想的少于十人并且在同一地点工作的团队来说用于计划 Sprint和追踪特性、任务状态和团队进度的最佳工具通常是份经过定制的表格, Scrum Maste负责定制和维护。而一些和需求测试用例和缺陷相关的工程工件也可以用类似的轻量级解决方法,例如利用索引卡片、白板或者软件开发团队的wiki

人员和沟通

要将Scrum推广到分布式团队和带层次结构的团队会带来特别的沟通挑战。多个团队之间如何协同工作实现共同的需求,跟踪特性状态,找出障碍是其中最主要的问题。这个时候,“需要一种机制来让各个团队经常性地分享进度。同时,还需要更仔细地划分产品和技术架构,才能更清晰地将工作分配到每个团队。”( Schwaber,2004)

扩张 Scrum会为沟通带来特殊的挑战

传统的项目管理工具可能能够显示理想化的任务开始和结束日期,并提供在漫长的瀑布式项目中也许没有意义的关键路径分析。而在短周期的迭代中,整个团队都专注在使少数优先级最高的功能尽快达到验收标准,这些以计划驱动的管理分析就不管用了。在小型项目中,只有一个人负责维护独立的任务数据库。这个数据库却和团队日常用于计划和实施的工件(如用户故事和测试)没有直接联系。而大型的项目则需要实时协作的环境,能够反映各个团队在开发、测试和集成产品待办列表中特性时的实时工作状态。为了尽量和本地团队保持一致,这个敏捷项目管理环境必须能让每个人都能快速地查看和更新某个功能在生命周期中所处的位置,要完成这个功能还需要多少工作量,是否有什么障碍出现。

除了需要新的方法计划和追踪迭代外,大型项目对用于定义、组织、分享系统工件也有新的要求。需求、验收测试和缺陷的所有信息在整个Sprint期间必须是非常容易查阅,而不是淹没在和团队承诺不相干的工件信息里。实际上,在快速的迭代中这些工件之间的关系正是团队最关心的问题。因为软件开发团队在每个 Sprint都会开发出很多可工作并经过测试的代码,所以他们必须非常清楚这些工程工件之间的关系,也必须能够随时查阅它们的状态。