新闻动态

建设工具和基础设施作为开发人员自然希望能够将工件组

2019-03-09 19:47:11 作者:小麦

作为开发人员自然希望能够将工件组织得更好,使一些Scrum流程自动化,这样就可以把精力集中在软件开发本身上。一些团队尤其希望能够添加基础设施使以下软件生命周期中的活动和工件更便捷。

待办列表管理:随着系统复杂度的增加,团队希望有更好的方法来获取和管理功能列表、功能性和非功能性的需求、用户用例、用户故事以及这些项目的优先级、估算、状态和负责人。随着Scrum应用到更大型的项目,这些工件的数目会增长到数千个,因此—一个能够按照系统或者子系统组织、支持和管理这些工件的方法变得至关重要。

项目报表: Scrum避免了使用传统的类瀑布式的项目计划,但是策略性的日常项目管理的本质是坚定不移的。因此,团队需要一个简单的方法来让每个人都能够很容易地输入对任务的估算、任务的状态和剩余的工作量。这样就能够自动生成持续有效的燃尽图。此外,在待办列表项生命周期的更换中,还需要向团队发出相应信号。高级员工需要观察每个团队各自的迭代和发布计划才能从全局上评估整个项目所处的状态。

及时的需求分析:很多小型的Scum项目通过非正式的需求管理机制获得了成功,例如团队和产品负责人直接讨论需求。然而,随着项目的复杂度和重要性的增加,可能需要更深层次和更多方式的需求讨论以及需求版本管理。例如,将对多个团队有影响的接口记录在文档中是非常重要的。更改跨团队的接口或新特性都有可能对整个项目造成重大影响。这些需求都应该在需要时,也就是说只在实现这些新功能的 Sprint,开始之前进行详细设计。要解决这个问题,软件开发团队可能需要一种集中的支持,能够更丰富地展现需求,整理待评审的文档,并自动进行变更通知。

先行的测试:因为每个Sprint都会交付潜在可交付的代码作为下个 Sprint的基线,先行的测试用例开发和自动化测试使团队能够跟上Scum快速迭代的步伐。如果能使用工具将需求或者用户故事卡片直接生成测试用例,就可以提高开发的速度并提供验收功能所需的内在可追溯性。需要注意的是,对成百上千持续增长的回归测试的持续管理很可能是决定 Sprint的速度和成功与否的关键因素。

发布计划: Scrum是“追求近期可能性的艺术”,而不是详细预测未来612 Sprint内应该交付什么的黑色艺术。这种哲学是团队思想上的突破,因为它可以让团队专注在当前30天的事情上,从而更可靠地开发出可工作的软件。但是随着团队的扩大和增多,为未来更远的 Sprint做额外的严谨分析有助于避免日后对架构做过多重构虽然敏捷中髙度推荐重构,但是随着程序的规模和部署的数量増多过多的重构就变得不现实了。为了更好地看清楚系统架构未来可能的演变道路,进行额外的发布计划也是适合的。因此, Sprint划会议中可以“向后看”几个 Sprint,也可以进行一些假设性的计划,这样能够帮助团队更好地权衡产品待办列表,并向发起者传达—个更合理的愿景和产品路线图。

另外,软件开发团队通常希望将这些设施和工具都集中到一个中央仓库中,使全球每个角落的每个团队成员都可以全天候地访问。还可以显示即时的工程和项目状态,并且当项目发生重要变更时能够自动发送变更通知。

Sprint中改善基础设施

Scrum,这种级别的基础设施建设是不可能由一个设施团队提前并一次准备好的。相反,Scwm团队自己应该从过去的 Sprint中吸取经验,找出解决问题所需购买或者建造的设施。还需要说明的是设施的建设应该是在Sprint中进行的,因此团队需要为建设设施在产品待办列表中添加相应的列表项。当然,和客户直接相关的功能优先级应该更高。但是有经验的团队能够认识到在产品的范围和团队数量增加时,他们必须持续地安排设施构建的工作以保持工作速率和生产效率。

总结

Scrum是一项被证明确实可行的软件开发实践,可以迅速地提高软件开发团队的生产效率、交付速度和工作质量。

有什么开发组织会否定成功的Scm实施带来的这些好处吗?

减少的开发周期次数

对终端用户输出更高的价值

更好的质量

更低的开发风险

更高的用户满意度

更高的员工士气

实施Scrum虽然看似简单,实际上却通常需要重大的组织性变革来消除阻碍有效开发和交付的障碍。作为变革代理领袖的CXO或者其他高管应该肩负起消除障碍的重任。他们是否能够称职是实施成败的关键。当然,这并不是一件容易的事。而许诺用Scum改善软件产出的CXO应该作为先行者迈出第一步,保证企业在之后的道路上能更好地交付软件和更快地获得商业利益。

此外, Scrum在大规模的企业软件开发中也是相当有效的。它能够使几百位开发人员同时开发一个应用程序。 Scrum的扩张预示着在建立设施和工具上将遇到新的挑战这些问题都需要由团队自己解决,然而只要战胜这些挑战,组织就可能在市场竞争中获得巨大的优势。