دانلود کتاب فرآیندهای چابک (Agile) – تیم‌های چابک، ویرایش دوم

For more than a decade now, agile approaches have represented a very popular alternative to the so-called “heavyweight process models.” The burdensome nature attributed to the older methodologies such as SADT, SSADM, SA/SD, V-Modell 97, and even the newer models like RUP with UML and V-Modell XT, is justified by developers and users with the high learning effort required, which is presented in the form of several hundred pages of model documentation. Additionally, the strong adherence to a phase sequence or, as in the case of V-Modell XT, to a series of decision points, is criticized as an overly rigid structuring of time. Even though the process can be adapted, and even though backtracking and incremental division are permitted, at the very least a well-founded configuration must be managed. Furthermore, there are extensively defined project products, project activities, and phase states that must be achieved at largely predetermined points in the project lifecycle, which is also perceived as a restriction of flexibility. The configurability of V-Modell XT for a project execution strategy of “Agile Projects” has not changed this perception. Configuration, documentation, phase regulation, product templates, and method prescriptions put the willingness to learn to a severe test, raise legitimate questions about implementability, and therefore face acceptance problems at all organizational levels. This also affects the entire range of involved roles, such as system analysts, developers, line management, project management, and especially the users. In this context, the immediate readiness for use offered by agile methods is a welcome solution for many. The agile shift became visible with Kent Beck’s still hotly debated, extremely condensed approach variant, Extreme Programming, which, as Eckhart Hanser reports, is based on a simple set of principles and practices. The condensation of the approach consists both in the “liberation” from prescribed processes, the omission of method based specification, and the minimization of the use of methods, templates, and patterns. Extreme therefore also refers to the extremely sparse documentation of Extreme Programming. The more agile the methodology, the more questions arose about examples, patterns, and guidance, and thus the lightweight nature was somewhat methodically enriched again in further agile models. The group of agile methods has become more differentiated, has grown, and as a result has lost some convenience and also some clarity. The current literature market primarily offers monographs on individual agile models, and unfortunately, these works are written in the confident tone of successful projects, and therefore do little to remedy the lack of clarity. The book by Eckhart Hanser makes an important, objective contribution to orientation here. The proponents of agile methodologies commendably place strong emphasis on people, their efforts toward collaboration, their communication behavior, and the ethical values that guide their actions. This is reflected in some of the principles and in the Agile Manifesto. Nevertheless, it is worth questioning whether premises such as daily morning meetings, pair programming, or equally sized task packages truly correspond to human inclinations and foster more humane collaboration, or whether they remain more of an ideal. It is noticeable that the “agile authors” always rave about their personal positive project experiences, but not about scientifically proven findings. It was high time that these social, agile recommendations were at least examined with the same rigor that even agile developers grant their programs—namely, through testing. For the much more complex act of collaboration, one would expect a social prototype, an organizational form under controlled environmental conditions, in which it can be demonstrated, using social-scientific methods, that the given social premises x and the form of collaboration y are best suited for the task z. Eckhart Hanser has dedicated his work to this gap and has observed the sociological aspects of software development in his “Software Engineering Laboratory.” He thus deserves credit as one of the few IT researchers to have incorporated a sociological perspective into software development with his Meta Agile Process Model (MAP), and to have done so using social-scientific methods such as field experiments, participant observation, and group dynamic experiments. The insights gained in the “organizational laboratory”—here I am conceptually inspired by the work of the Tavistock Institute—are incorporated into suggestions for improving agile approaches. This enables the project manager to replace “agile enthusiasm” with well-founded criteria. And this helps to assess whether a task should be approached in an agile or heavyweight manner. As always, the truth will likely lie somewhere in between: for some types of projects, agile models are more suitable, while for others, comprehensive process models are indispensable. With his book, Eckhart Hanser opens our eyes to an objective assessment of the suitability of agile models for a given project type. I am pleased that once again an active member of the “Process Models” working group of the “Business Informatics” division of the “German Informatics Society” has succeeded in publishing an interesting book, and I wish the book a positive reception. The fact that the book also coincides with a thematic focus, “Social, cultural, and location- specific aspects,” initiated four years ago with Professor Gerhard Chroust by the working group, is especially gratifying for all of us. At this point, I would also like to thank Mr. Heine from Springer Verlag for always having “an ear” for the working group. It is to be hoped that the path of social experimentation started by Eckhart Hanser will be pursued much further, that even more societal measures, social criteria, and their indicators will be observed, and that more computer scientists will incorporate sociology.