《敏捷与业务分析：IT专业人员实践指南》：融合视角提升组织效率

需积分: 9 190 浏览量更新于2024-07-19 收藏 19.85MB PDF 举报

《敏捷与业务分析：面向IT专业人士的实用指导》（2017）是一本由作者基于对业界同仁和客户的深入讨论而编写的书籍。它关注的是在组织采用敏捷方法时，如何确保业务分析视角不被忽视，以及如何将敏捷原则应用到业务分析领域。书中强调了在企业、项目乃至整个信息系统工作中的敏捷支持，旨在填补现有出版物中关于业务分析在敏捷方法中的探索不足，以及明确敏捷与业务分析相结合的最佳实践。书的核心内容围绕以下几个方面展开： 1. **敏捷哲学与实践**：首先，作者深入剖析了敏捷方法论的起源、核心理念和各种实践框架，如Scrum和Kanban，以帮助读者理解其背后的原理和工作方式。 2. **业务分析视角**：作者强调了在敏捷环境中理解业务分析的重要性，包括需求收集、优先级设定、影响分析等关键活动。他们主张，敏捷项目不应简单套用预设的方法，而应根据组织的特定环境和问题范围进行定制。 3. **结合两者的实践指南**：书中提供了丰富的实例和技巧，展示了如何在实际操作中整合敏捷方法和业务分析，以便于业务分析师和其他信息技术专业人员构建工具箱，有意识地应用这些方法来提升组织效率和效果。 4. **全面覆盖**：作者从敏捷的起源出发，探讨了信息系统工作的不同层次和维度，并探讨了敏捷在组织层面的采纳过程，确保了对业务分析领域全面的探讨同时也涵盖了敏捷世界的不同方面。 5. **社会进步与专业发展**：作为英国特许信息技术学会（BCS, The Chartered Institute for IT）的作品，本书还体现了该学会在全球范围内推动信息技术、科学和实践发展，通过知识共享、新思维激发和政策影响，促进社会经济进步。《敏捷与业务分析》这本书为IT专业人士提供了一套实用且全面的指南，帮助他们在采用敏捷的同时，保持对业务核心价值的敏感度，确保信息技术活动能够更好地服务于组织的战略目标。

FOREWORD

I thought I would begin with an agile foreword:

1. Buy this book.

2. Read it.

3. Follow the advice in it.

4. Recommend it to your colleagues.

5. Repeat steps 2 through 4 as appropriate.

6. If it’s a print copy, store it on your shelf to show to everyone how smart you

must be.

And now for a more traditional foreword .

Analysis is so important for agile teams that we do it every single day. Every. Single.

Day. The implication is that we need one or more people on the team who has analysis

skills; the more people the better in my opinion. Agile analysis skills are critical in the

agile world.

But do agile teams need people who are just analysts? Sometimes yes, but very often

no. In most situations, agile teams need people who are generalising specialists, people

with strengths in one or more specialities (such as agile analysis); a broad understand-

ing of the software process and the domain they’re working in; and the willingness to

learn new skills and share their own with others. This is a different staffing strategy

from that which is typical of organisations still taking a traditional approach to IT.

This begs the question of when do we need people who are specialised in agile analysis?

The answer is ‘at scale’. When a team faces a complex domain, it is common to see one

or more people who focus on exploring, understanding and then communicating the

inherent complexities to the rest of the team. In other words, an agile analyst. Similarly,

when a team has geographically distributed stakeholders, then having analysts at the

various locations makes a lot of sense. When a large agile team, or agile programme,

is organised into a collection of smaller subteams it is common to put analysts on

the team who work closely with the programme’s product owner to communicate the

requirements to their subteams. These analysts working on geographically distributed

and/or large teams are referred to as ‘junior product owners’ in some organisations

or business analysts in others. The point, contrary to what you may have heard, is that

some teams need agile analysts.

xiv

FOREWORD

I’m the guy behind the agile modeling (AM) method (see AgileModeling.com), which

was the first serious look at how modelling and documentation activities fit in on agile

teams. I led a group of people, several hundred from around the world, to develop the

initial version of AM in the 2001/2002 time frame. It’s evolved since then of course,

capturing collaborative lightweight strategies for analysis, architecture, design and even

documentation activities for agile teams. Needless to say I’m excited that this book has

been written.

What should you hope to gain from reading this book? Here are my suggestions for what

you want to learn:

1. Discover the agile mindset: whenever you think, ‘that won’t work for me

because I’m in a different situation’, the best thing to do is to assume that

you’re completely and utterly wrong about that (you very likely will be) and

therefore need to work things through. Being agile, having the mindset to

collaboratively work in an agile manner, can take a long time to truly learn.

2. Keep analysis light yet sufficient: when it comes to ‘doing agile’ the biggest

change is often the focus on keeping your work and the artefacts that you

create as light as possible. In agile modelling, we promote strategies such

as working with the audience of an artefact to learn what they really need,

preferring direct communication with others as opposed to documentation

hand-offs, and capturing requirements in the form of executable tests.

3. Focus on working collaboratively with others: modelling is something you

should do with others, ideally using inclusive tools such as whiteboards and

sticky notes. Many heads are better than one.

4. Embrace an evolutionary approach to analysis: as I said earlier, analysis is

so important that we do it every single day on an agile team. This is because

of the agile philosophy of embracing change – we accept the fact that our

stakeholders' requirements will evolve over time, necessitating an ongoing

and evolutionary approach to analysis (and architecture, and design and all

other aspects of solution delivery).

5. Seek active stakeholder participation: one of the more radical ideas in agile

modelling, one that we adopted from usage-centred design, is that the people

who are best suited to perform requirements-oriented modelling are your

stakeholders. If we can find ways to get our stakeholders actively involved

in our modelling efforts, something that inclusive tools (whiteboards, paper)

and inclusive techniques (such as the simple model types described in this

book) enable, then we are much more likely to find out what our stakeholders

actually need.

6. Continuously improve: part of the agile mindset is to regularly reflect on what

is working well, and what isn’t working so well, so that we can potentially

learn from and address the challenges we face. Similarly, the Lean mindset

tells us to experiment with potential improvements, study their effectiveness,

and then adopt new ways of working accordingly. We can always get better.

7. Constantly expand your intellectual toolkit: there are some great modelling

techniques described in this book, including many common ones such as

user stories, epics and personas. These techniques are of course the tip

of the iceberg – there are hundreds of strategies out there that you should

PREFACE

Our idea for a book that looked at business analysis from an agile perspective, and agile

from a business analysis perspective, arose following many discussions with colleagues

and customers. We were concerned that the development of business analysis, and the

inroads made in appreciating the benefits it can offer, were in danger of being eroded

if agile was adopted by organisations and projects without consideration of the busi-

ness analysis world view. A review of available publications highlighted that business

analysis was not widely explored within agile and the application of agile principles to

business analysis (and, conversely, the application of business analysis to agile projects)

were not clearly defined anywhere.

Therefore, the topics in this book aim to address this gap and provide comprehensive

and practical guidance, enabling business analysts to understand how and when they

can support agility at an enterprise, programme and project level. To do this, we needed

to provide sufficient details of the agile philosophy, methods and practices plus the

relevant business analysis approaches and techniques. The more we considered how

these two disciplines would work in combination, the more we felt it was a ‘marriage

made in heaven’ that had significant potential to improve information systems activity

and outcomes and, consequently, the efficiency and effectiveness of organisations.

In order to provide the coverage we felt necessary, the book forges a path from the

origins of agile, through the different levels and aspects of information systems work

and, ultimately, looks at how agile might be adopted by an organisation. We felt it was

important that all these dimensions were explored if the landscape of business analysis

was to be represented thoroughly. Similarly, it was important to encompass the agile

world across this landscape.

One of the key aspects we think important, is the need to tailor the approach adopted

to information systems work in the light of the organisational context and the scope of

the problem to be addressed. Given that agile originated as a software development

approach, adapting it to business improvement projects requires careful consideration.

Comments made to us about ‘following the Scrum method’ do not align with our world

view, which is to always consider the most appropriate way of achieving the desired

outcomes that will benefit the enterprise. This is reflected throughout the book as

we have described various approaches and techniques in order to support business

analysts, and any other IS professionals interested in this topic, in building a toolkit and

applying it in an informed way.

xvii

AGILE AND BUSINESS ANALYSIS

The extensive coverage of this book was an ambitious undertaking. As a result, we

needed help and support from a number of people. In particular we would like to thank

the following two people.

Simon Girvan: Simon is a Fellow of the BCS and a Chartered Engineer, who has over

10 years’ experience working in agile teams in the UK and Australia. He is currently in

a technical director role within UK Government, leading several agile teams working on

complex bespoke software projects.

Simon’s experience implementing agile principles with non-software projects, and

within traditional governance contexts, gives him a perspective on agile development

that aligns well with business analysis.

Simon wrote the book sections on estimation, iterations, methods and the history of

agile. He was also a reviewer of many chapters and created most of the diagrams used

in the book.

Alan Paul: Alan has over 30 years of experience of change programmes and software

projects, and has worked in a range of roles including analyst, project manager and

technical strategy director.

Alan has worked on projects that have applied various methods and techniques, includ-

ing structured and agile approaches; this has given him unique insights into the issues

that can arise during information system development.

Alan reviewed every chapter in the book and contributed to the sections on analysing

the enterprise and estimating.

We were also very fortunate to have colleagues and friends who supported us by

reviewing several chapters and suggesting changes to the narrative: Martin Pearson,

AssistKD Marketing Director, conducted a thorough and detailed review of several chap-

ters as the book neared completion. James Cadle, AssistKD Director, and Terri Lydiard,

Teal Business Solutions Ltd., reviewed the narrative for particular chapters in order to

ensure clarity and correctness. Julian Holmes, ThoughtWorks Ltd, worked with us over

several meetings to define the initial structure for the book. Carol Christmas undertook

a full and thorough review of an early draft of the book.

The BCS publishing team provided ongoing support and encouragement and we would

particularly like to thank Ian Borthwick, Becky Youe and Florence Leroy.

This book was a labour of love because we felt it was such an important topic. It required

many conversations, coffees and cakes before we felt it offered a valuable contribution

to the business analysis and agile domains. We hope all readers will gain insights and

useful guidance that will support them in their professional work.

Lynda Girvan

Debra Paul

February 2017

xviii

剩余294页未读，继续阅读

WindStand

粉丝: 35
资源: 367

《敏捷与业务分析：IT专业人员实践指南》：融合视角提升组织效率

Python库jira_agile_toolbox-0.0.9.tar.gz详解

"CSM认证考试题借鉴.pdf：精华汇总

jira_agile_toolbox-0.0.7：Python开发者的敏捷工具箱

agile_web_development_with_rails_3rd_edition.9994652073.pdf

Bonfiglioli_manual_agile_gb_vec691r1 Modbus.pdf

VDA_Band_Agile Collaboration_en.pdf

agile_web_application_development_with_yii1.1_and_php5_code.zip

Distributed_agile_development_at_microsoft_patterns_and_practices.pdf

Agile_Methods_-_The_Bottom_Line.pdf

PMP vs. Agile_ which certification is best- Entangled.pdf

最新资源