Catálogo de publicaciones - libros

Lets start of with a basic question “Why should you read this book?” The answer, as I hope you will see, is because it brings together a range of the most popular and presents them back to back allowing you, the reader, to gain an insight into what it means to be agile, what agile methods are (and are not), what AgileModelling is and what XP (Extreme Programming) is.However, it goes further than this and considers how some of the approaches can be used together, how you can plan larger agile project (using a feature-driven approach) and how you can introduce agile methods into your organisation. All of this is done in a practical, no-nonsense manner that cuts through the hype and tells it to you straight!

In this chapter, you will be introduced to the concept, motivations, goals and principles behind the Agile Movement. You will also learn what the common features of all agile methods are. Following this, a brief review of a number of the core agile methods currently available will be presented, before a brief summary concludes the chapter.

In this chapter, we will first consider some common misconceptions relating to models and model-based design. Once we have dispelled these misconceptions, we shall delve deeper into agile modelling. We will consider the attributes of agile models as well as what agile models look like and when they should be updated.

This chapter seeks to consider how you can make yourself an Agile Modeller or how a team of designers can promote Agile Modelling. We will do this by expanding upon the Agile Modelling practises discussed back in Chapters 2 and 3. We will then consider in more detail the supplementary Agile Modelling practises which, while not a necessary part of Agile Modelling, are useful in helping you achieve an Agile Modelling approach. We will follow this by discussing how you can maximise the modelling process (and by doing so become more responsive and adaptive and hence more agile). We will conclude by discussing how an Agile Modelling session might be run.

In the last couple of chapters, we have looked at Agile Modelling, which applies agile philosophies to the modelling activities that take place within software development projects. In this chapter and the next, we will start to look at how these philosophies have also been applied to the act of programming. In our case, we will look at Extreme Programming (more commonly known as XP). XP is part of the agile movement that focuses on the writing of the software that will implement the required system. This may involve writing Java code, Smalltalk, C++, C#, database tables, XML files, etc.

We have already said that XP is not a design method. Indeed, all it actually is in any formal sense is a set of four values that have motivated twelve practises. Some of these practises are more clearly oriented towards a process than others. For example, the planning game practise, as we will see, has a lot to say about itself. Other practises, such as the 40-hour week are rathermore like guidelines, than a process. That is, you either over work your developers doing 60–80 hours a week or you don't. There is not a lot to say about how you limit the number of hours worked to 40 (exception management buy in and developer acceptance).

Over the last four chapters, we have considered in detail both Agile Modelling (AM) and eXtreme Programming (XP). Both are from the agile movement and both are motivated by the desire to produce better software faster. But how do they relate (if at all)? What is the relationship between Agile Modelling and XP? Are they complementary or contradictory? In this Chapter, we will consider exactly this issue and look at how Agile Modelling can actually enhance an XP project.

In this chapter, we will consider what experiences teams developing with XP and Agile Modelling methods have had. It considers what issues have been found and how they have been overcome. It does reach some contentious conclusions about some aspects of XP and also considers what happens when XP is applied to larger software projects.

Planning, managing and monitoring projects that are agile, adaptive and incremental can be very difficult. As was illustrated in the last chapter, although many of the ideas behind methods such as XP can, and indeed have been very successfully applied, it does not mean that it is easy or that they are particularly scalable (particularly for those new to XP).

In this chapter, we will look at how a project was planned using the ideas presented in the last chapter on Feature-Driven Development. As you will remember, an FDD project is based on the identification of features, their implementation as tasks (possibly grouped into packages of work) implemented within a fixed time box for each iteration.