Catálogo de publicaciones - libros

Colocation has come to be seen as a necessary precondition for obtaining the majority of the benefits of XP. Without colocation teams expect to struggle, to compromise and to trade off the benefits of XP the benefits of distributed development. We have found that you can stay true to the principles and not compromise the practices of XP in a distributed environment. Thus, business can realize both the benefits of distributed and of truly agile development.

Naked Objects and agile software development have been suggested to complement each other. Very few empirical studies to date exist where a product has been developed using the Naked Objects technologies in an agile development environment. This study reports results of a case study where a mobile application was developed using the Naked Objects Framework. Qualitative and quantitative data was collected systematically throughout the project. The empirical results offer support for the argument that the Naked Objects approach is suitable for agile software development. The results also reveal weaknesses in the current Naked Object Framework, namely, that it is not yet mature enough for applications that require intense database operations. The results also show that the development team was able to create an operational user-interface just in five hours, which demonstrates the applicability of the Naked Object Framework in practical settings.

From the perspective of a ‘sympathetic sceptic’, this talk will discuss the issues around the development of critical systems – systems where the costs of failure are very high – and whether or not extreme programming practices can be adapted and used in critical systems engineering. I will start by discussing the characteristics of critical systems development, such as the need to justify claims about the system dependability, and the differences in development culture between XP and critical systems development. I will then go on to discuss how different XP practices reduce or increase the risks of software failure, especially when the reality of implementing XP is considered. I will identify weaknesses in the XP process, such as the use of user stories for requirements definition, that have to be addressed before XP practices will be considered by the critical systems community. I will then suggest how the cultural barriers between the communities might be broken down and will propose how it might be possible to adapt XP practice to the development of some types of critical system by introducing ‘dependability spikes’ into the XP process.

Amid the enthusiasm generated by the success of agile approaches to software development in recent years, we have begun to extrapolate the principles of agile methodologies to propose innovative new ways of managing entire businesses, such as “self-reflective fractal organizations.” However, it is important to resist the tendency toward an attitude that managers have more to learn from us than we do from them. Such an attitude is based on the assumption of a direct and automatic link between agile development and business value creation that is often more imaginary than real, and certainly harder for them to recognize than us. Even a perfectly organized, successful agile project may fail to deliver any business value at all; even more often, we are unable even to judge whether any business value has been created. The potential of agile approaches to contribute to value creation is large, but only if we recognize that we must reach beyond them to study and learn from the best managers. This starts with an appreciation of how difficult (and rare) it is to create a sustainable competitive advantage with IT investment. Some lessons from top management can help us understand the sources of competitive advantage and how we can help our customers in their search for that elusive business value. In so doing, we enable ourselves to create better business cases for managers to invest in software development and we sharpen our own focus on what software development will create the most value for the business.

XP exists for almost ten years now. The latest Standish Report characterizes agile development as a top success factor. The new certified, standardized, and official process model of the German government, V-Modell XT, includes an agile project strategy. These are all clear signs that the agile approach is coming of age.

Being a grown-up doesn’t mean being fully developed – in contrary the need still exists to continuously seek for opportunities for improvement. Thus, instead of being dogmatic about practices, we have to use the agile value system as our guidance for improvement and for creating and customizing practices that help the teams to succeed.

How do we take XP to the next level? How do we get respect and freedom to work as we’d like? How do we get them to listen to us? XP has successfully raised expectations for what is technically possible with software development. The next challenge is realizing that potential. Doing so requires not more technical skills, but better relationships within the organization, a shift in attitude and perspective.

It’s natural to want to have impact in the world. How can we best have impact on organizations? Counterintuitively, the way we gain influence is to listen. The way to gain freedom is to be accountable. The way to get respect is to give it. The way to get them to listen to us is to eliminate the dichotomy between us. We are all on the same side working towards a more effective software development process for the good of our company. What we need is a change in perspective. XPers should first demonstrate that others have impact on them, by listening and acting on what others say. We need to offer accountability. With a record of careful listening and trustworthiness, we will be well-positioned to be heard when the organization has a problem and we have an idea.

A common barrier to organizational impact for programmers is our sense of “being special”. The days of the prima donna programmer are over. What would happen if we treated everyone we talked to as if their ideas, needs, and perspectives had equal value with our own? That would be extreme. It would require a shift in our beliefs about organizations and our contributions to them.

XP has improved programmers work. Influence at the next level uses the same principles apply that have guided XP thus far. Respect, mutual benefit, improvement in baby steps from where we are today; these are principles that can guide the maturation of an XP team to be a full partner in business. These are the principles that, if applied with humility and awareness, will help us take XP up another notch in impact and influence.

XP has introduced best practices into software development. However we need to adopt and monitor those practices continuously to maximise its benefits. Our previous research has focussed on software process improvement model for SMEs (Small-to-Medium Enterprises). This paper introduces a process improvement framework for assessing and improving XP best practices. We have also developed a web based tool support to assess, improve, and suitability of introducing XP into SMEs.

This work focuses on standardization and improvement of processes and practices using a combination of methodologies including Agile Methodologies (AM). It was implemented at a Mexican steel manufacturing company using FDD, XP and RUP. The main goal was to improve the software systems production, maintenance and support.

At XP2004, two of the authors presented an “agile record/ replay” approach[1] to GUI Acceptance Testing based on recording high level use-cases. In the past year we have run a project to attempt to write tests using this approach for three different Carmen Systems products.[2]

During this project we have met new challenges presented by multi-threaded GUIs and web GUIs, and in the process we have produced JUseCase[5] – a Java Swing equivalent of PyUseCase[5], presented last year, and for web application testing we produced WebUseCase[6] – a browser-like use-case recorder based on JUseCase. Via these use-case recorders, we have found that we can fit both these challenges comfortably into our existing approach.

Traditionally, finite state machines and their extensions, such as stream X-machines, have been used for modelling and testing of graphical user interfaces (GUI) and for acceptance testing. This paper shows how these testing techniques can be successfully extended to unit test generation for object-oriented systems and integrated into Extreme Programming in a simple and designer-friendly way. The approach has been used by MSc students in Computer Science at the Pitesti University to write JUnit tests for XP projects and the effectiveness of these tests has been compared with that of tests produced using ad-hoc and traditional functional methods. The conclusions show that over 90 % of the faults found by other methods have also been found by the stream X-machine based approach, whereas less than 75 % (in many instances less than half) of the faults uncovered by the stream X-machine based testing have been found by other methods. As the finite state machine based test generation has been automated, the time spent using the two testing strategies was roughly equal.