DOCSLIB.ORG

The Great Methodologies Debate: Part 1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Great Methodologies Debate: Part 1 ACCESS TO THE EXPERTS The Journal of Information Technology Management December 2001 Vol. 14, No. 12 The Great Methodologies Debate: Part 1 Resolved “Today, a new debate rages: agile software Traditional methodologists development versus rigorous software are a bunch of process- development.” dependent stick-in-the-muds who’d rather produce flawless Jim Highsmith, Guest Editor documentation than a working system that meets business needs. Opening Statement Jim Highsmith 2 Rebuttal Lightweight, er, “agile” Agile Can Scale: Inventing and Reinventing methodologists are a bunch of SCRUM in Five Companies glorified hackers who are going to be in for a heck of a surprise Jeff Sutherland 5 when they try to scale up their “toys” into enterprise-level software. Agile Versus Traditional: Make Love, Not War! Robert L. Glass 12 Business Intelligence Methodologies: Agile with Rigor? Larissa T. Moss 19 Agility with the RUP Philippe Kruchten 27 Extreme Requirements Engineering Larry Wagner 34 Exclusion, Assumptions, and Misinterpretation: Foes of Collaboration Lou Russell 39 Opening Statement by Jim Highsmith In the early 1980s, I participated in rigorous software development. others be able to understand the one round of methodology debate. Agile approaches (Extreme similarities and differences and be Structured analysis and design Programming, Crystal Methods, able to apply the right mix to their champions such as Tom DeMarco, Lean Development, Feature-Driven own organization. Both the SEI and Ed Yourdon, and Tim Lister were Development, Adaptive Software Rational have made wonderful on one side of the debate, while Development, SCRUM, and contributions to software develop- data-driven design aficionados like Dynamic Systems Development ment, but it is important to Ken Orr, Jean-Dominique Warnier, Methodology) populate one camp. understand the similarities and Michael Jackson (not the singer), The Software Engineering Institute, differences between them and the and myself were on the other. It with its Capability Maturity Model self-professed agile approaches. was debate, but a collegial one. (not considered a methodology Only by purposeful debate will Although we argued, we did so out per se by the SEI, but so consid- organizations be prepared to the debate rages of mutual respect and the desire to ered by many others), and Rational decide which approach, or mix of further the cause of software Software, with its Rational Unified approaches, matches their partic- development. Tom, Ed, Tim, Ken, Process (RUP), populate the other. ular culture and problem domains. and I now serve together on the But even these lines are obscure. Debates become heated at times, Cutter Business Technology In the next few months, I am but thats an important part of a Council still debating. participating on two panel good debate. If people arent debates, one ostensibly on passionate about what they There have been a variety of agile versus RUP and another believe, why bother? similar debates over the last 25 ostensibly on agile/RUP versus the years data-driven versus CMM. There are articles about light One of the great services that process-driven approaches, infor- or agile RUP. It seems that no Extreme Programming proponents mation engineering versus struc- one is willing to concede agility are performing for software devel- tured development, relational to the other side. opment is their determination to database design versus object push extreme positions for database design, object everything Proponents of XP, SCRUM, and example, no documentation, no versus non-object everything. Each other agile approaches have up-front design, limiting work of these debates was useful in argued endlessly for their values weeks to 40 hours, and communal advancing the cause of better soft- and practices often stridently, as code and really radical positions ware development. Whatever have proponents of the CMM and such as frequent testing of ones ones position, having to listen and the RUP. The point is that spirited own code. By taking these posi- respond to thoughtful discourse debate and even some in-your- tions and clearly defining the from the other side helped each face jabs are good for software extremes, XPers have launched side clarify its position. development. Healthy, collegial this healthy debate within the soft- debate helps everyone think ware development community. If Today, a new debate rages: agile through the issues more clearly. Kent Beck and others had advo- software development versus Only by defining and debating will cated moderate positions, 2 December 2001 ©2001 Cutter Information Corp. everyone could just say, Well, Make Love, Not War. Glass, who Cutter IT Journal® we really do just about the same has a long history of addressing Cutter Business Technology Council: thing. If Extreme Programming the yin and yang of issues in his Rob Austin, James Bach, Tom had been named Moderate work, analyzes each of the Agile DeMarco, Jim Highsmith, Tim Lister, Ken Orr, Dick Nolan, Ed Yourdon Programming, it would not have Manifesto values and principles. generated such debate. His analysis indicates the pros and Editorial Board: Larry L. Constantine, Bill Curtis, cons of each of them, and he then Tom DeMarco, Peter Hruschka, Jeff Sutherland brings up one of indicates which side he thinks is Tomoo Matsubara, Navyug Mohnot, these key extreme points around more correct. The final tally? Roger Pressman, Howard Rubin, Paul A. Strassmann, Rob Thomsett which debate should ensue. In his Agile: 8, Traditional: 5, Tie: 3. article, Sutherland challenges the Editor Emeritus: Ed Yourdon Larissa Moss article describes the assumption that software devel- Publisher: Karen Fine Coburn balancing act that most people and Managing Editor: Karen Pasley opment is a predictable, repeat- Production Editor: Linda Mallon their organizations go through. able process. I think this is one Client Services: Christine Doucette Moss says, The debate about rigor position that helps distinguish agile Cutter IT Journal® (ISSN 1522-7383) versus agility should not be about development from traditional is published 12 times a year the choice between them, but development. It challenges one of by Cutter Information Corp., rather about creating methods and 37 Broadway, Suite 1, Arlington, the most fundamental assump- MA 02474-5552 (Tel: +1 781 648 8700, guidelines for merging just tions upon which many project or, within North America, enough of both. Moss article is +1 800 964 5118; Fax: +1 781 management and software devel- about synthesizing rather than 648 1950 or, within North America, opment methodologies are built. +1 800 888 1816; Web site: compromising and she illus- It attacks the premise that plans, www.cutter.com/consortium/). trates this synthesis through two designs, architectures, and require- Cutter IT Journal® covers the wonderful phases the thrills of ments are predictable and can software scene, with particular chaos and the dregs of struc- emphasis on those events that will therefore be stabilized. It attacks ture. Moss reports that a dot-com impact the careers of information the premise that processes are technology professionals around group she worked with did not repeatable the very foundation the world. reject structure per se, only the upon which traditional, rigorous ©2001 by Cutter Information Corp. rigor that accompanied it and only methodologies are constructed. All rights reserved. Cutter IT Journal® when imposed by other people, is a trademark of Cutter Information It is a fertile area for debate and such as their management. She Corp. No material in this publication discussion. may be reproduced, eaten, or comments, The most valuable distributed without written permission When the arguments are all about lesson learned from my dot-com from the publisher. Unauthorized experience is that agility and rigor reproduction in any form, including mushy, moderate, middle-of-the- photocopying, faxing, and image road positions, then others have not only can complement each scanning, is against the law. other they should. little information from which to Subscription rates are US $485 a year analyze and draw their own in North America, US $585 elsewhere, conclusions. Spice and diversity In his article on the Rational payable to Cutter Information Corp. Unified Process (RUP), Philippe Reprints, bulk purchases, past issues, are vital to useful debate. But so and multiple subscription and site are thoughts from those who Kruchten discusses the idea of license rates are available on request. moderate the debate, who empha- tailoring, arguing that through size the similarities between posi- customization, the RUP can adapt tions, who say, Well, they may not to a wide range of projects. He be as far apart as we first thought. asks which is easier: Starting from In his wonderfully conciliatory a blank slate, with a few key prin- article, Bob Glass suggests that we ciples, and then building the Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 14, No. 12 3 process from the bottom up? Or to discuss when he thinks the XP are much easier to talk about starting from a rich knowledge practice of user stories is appro- than do. base and choosing, shrinking, priate and when he believes that modifying, and evolving existing other techniques would be more Debate can be an energizing and recipes to fit the problem at hand? suitable. Addressing the current positive force in software develop- Kruchten describes the concepts debate, he emphasizes what ment and project management. behind the RUP and characterizes you can leverage from the This debate over agile versus it as an open framework with a controversy. rigorous or traditional method- rigorous underlying process model. ologies is healthy, particularly Some of its detractors call RUP Finally, Lou Russells article when approached from a perspec- a heavyweight process and depict reminds us of the need, whatever tive of collegiality and respect. We it as a behemoth that forces you the debate, to include and should value the ideas of those to do zillions of useless and unnat- embrace diversity whether in who advocate both ends of this ural things, he says.
Load more

Recommended publications
  • Xp Project Management
    University of Montana ScholarWorks at University of Montana Graduate Student Theses, Dissertations, & Professional Papers Graduate School 2007 XP PROJECT MANAGEMENT Craig William Macholz The University of Montana Follow this and additional works at: https://scholarworks.umt.edu/etd Let us know how access to this document benefits ou.y Recommended Citation Macholz, Craig William, "XP PROJECT MANAGEMENT" (2007). Graduate Student Theses, Dissertations, & Professional Papers. 1201. https://scholarworks.umt.edu/etd/1201 This Thesis is brought to you for free and open access by the Graduate School at ScholarWorks at University of Montana. It has been accepted for inclusion in Graduate Student Theses, Dissertations, & Professional Papers by an authorized administrator of ScholarWorks at University of Montana. For more information, please contact [email protected]. XP PROJECT MANAGEMENT By Craig William Macholz BS in Business Administration, The University of Montana, Missoula, MT, 1997 Thesis presented in partial fulfillment of the requirements for the degree of Master of Science in Computer Science The University of Montana Missoula, MT Autumn 2007 Approved by: Dr. David A. Strobel, Dean Graduate School Dr. Joel Henry Computer Science Dr. Yolanda Reimer Computer Science Dr. Shawn Clouse Business Administration i Macholz, Craig, M.S., December 2007 Computer Science Extreme Programming Project Management Chairperson: Dr. Joel Henry Extreme programming project management examines software development theory, the extreme programming process, and the essentials of standard project management as applied to software projects. The goal of this thesis is to integrate standard software project management practices, where possible, into the extreme programming process. Thus creating a management framework for extreme programming project management that gives the extreme programming managers the management activities and tools to utilize the extreme programming process within a wider range of commercial computing organizations, relationships, and development projects.
    [Show full text]
  • Structured Analysis
    240 Structured Analysis Tom DeMarco Principal of the Atlantic Systems Guild New York M.S., Columbia, Diplome, University of Paris Bell Labs: ESS-1 project Manager of real-time projects, distributed online banking systems J.D. Warnier Prize, Stevens Prize Fellow of IEEE Major contributions: Structured Analysis, Peopleware Current interests: project management, change facilitation, litigation of software-intensive contracts sd&m Conference 2001, Software Pioneers Eds.: M. Broy, E. Denert, Springer 2002 241 Tom DeMarco Structured Analysis: Beginnings of a New Discipline How it happened When I arrived at Bell Telephone Laboratories in the fall of 1963, I was immediately assigned to the ESS-1 project. This was a hardware/software endeavor to develop the world’s first commercial stored program telephone switch (now installed in telephone offices all over the world). At the time, the project was made up of some 600 persons, divided about half-and-half between hardware and software. There was also a small simulation group (a dozen people?) working to create an early prediction of system perfor- mance and robustness. I was at first assigned to the hardware group. My assignment was to de- velop certain circuits that enabled Emergency Action, the reconfiguration of processors when one was judged to have failed. This was an intriguing assignment since each of the two processors would diagnose the other and then try to decide together and agree on which one was incapable of furt- her processing – but somehow still capable to judge its own sanity. 242 Tom DeMarco To all of our surprise, the software for the project turned out to require a lot more effort than the hardware.
    [Show full text]
  • Software Architecture: the Next Step for Object Technology (PANEL)
    Software Architecture: The Next Step for Object Technology (PANEL) Bruce Anderson, University of ESSPX (moderator) Mary Shaw, Carnegie-Mellon University Larry Best, American Management Systems Kent Beck, First Class Software What is the next step for you? Progress comes Abstract from taking aware steps, but what steps are those? Architectures are the structuring paradigms, styles They could be in attempting to discover and and patterns that make up our software systems. catalogue architectures; creating awareness of this They are important in many ways: they allow us to level of product envisioning; doing design more talk usefully about systems without talking about consciously; finding ways of describing systems; their detail; a knowledge of them gives us design consolidating legacy code; abandoning legacy code; choices; attention to this level can make systems and making new software lifecycles. families of systems have the non-functional What is the next step for the community? Are there properties we want, especially changeability. ways to work that go beyond projects and Each panelist will address the following issues: companies? Will there be focus on the community, l What is architecture? which suggests cooperation, learning, divergence l What is the value you have had so far from and empowerment; or on the marketplace, which this concept? suggests competition, confidentiality, convergence l What is the next step for you? and dependence? l What is the next step for the community? 2 Mary Shaw 1 Background Software architecture is concerned with the What is architecture? We all have experience of organization of software systems: the selection of systems of great conceptual clarity and integrity.
    [Show full text]
  • Examining Capabilities As Architecture
    September 2013 BPTrends ▪ Examining Capabilities as Architecture Examining Capabilities as Architecture Ralph Whittle Introduction This Article is a direct response to one written by Mike Rosen titled, “Are Capabilities Architecture?” [1] published in February 2013 by BPTrends It offers a different and contrasting point of view on accepting capability modeling and mapping as “architecture.” Business Architecture (BA) approaches and methods, while still evolving, have at least reached a point of maturity where the enterprise can fairly assess how it will develop and advance this initiative. As with any emerging field, a variety of approaches and methods will develop and enjoy success. From an historical perspective, consider the number of Business Process Management (BPM), Enterprise Architecture (EA) and Service-Oriented Architecture (SOA) approaches that have matured over the years. And no doubt, the same will eventually occur with the Business Architecture over the next few years. However, just as with the BPM, EA and SOA some different and contrasting points of view will find their way into the various Business Architecture approaches, techniques and methods. Today, at least two different and contrasting organizing principles are considered for Business Architecture. One is “capability centric” and the other is “process centric.” This article advocates and supports the “process centric” organizing principle, specifically using a value stream which is an end-to-end collection of activities that creates a result for a “customer,” who may be the ultimate customer or an internal “end user” of the value stream. The value stream has a clear goal: to satisfy (or, better, to delight) the customer.[2] This is a well known term, familiar in Six Sigma, Lean Manufacturing and BPM approaches.
    [Show full text]
  • Multi-Factor Analysis of Pair Programming Based on PSP
    I S S N 2 2 7 7 - 3 0 6 1 V o l u m e 1 5 N u m b e r 0 4 INTERNATIONAL JOURNAL OF COMPUTERS & TECHNOLOGY Multi-factor analysis of pair programming based on PSP methodology Nabiollah Bayatmoghadam1 (M.S), Ashkan Sami (Ph.D.)2 1Department of Computer Science, Engineering, Shiraz University Email: [email protected] 2Department of Computer Science, Engineering, Shiraz University ABSTRACT In regard with designing software, users play key role. In order to design software, it is necessary to observe standard principles of designation, using templates and using modern methods. Over the decades, using development methods, XP and one of the XP methodologies of paired programming used to design software. These methods have been designed for purpose of enhancing quality of product and rapidresponse to need of market and customer and overcoming weaknesses of traditional methods based on long-term programming and waterfall method. Therefore, every programmer and developer can pass a series of processes for constructing computer software. The processes can be changed daily and efficient processes maynot be effective and useful; although they can be considered as process. The main objective of the present study is multi-factor analysis of pair programming based on PSP methodology. Practical and analytical methodand two PSP methods have been applied for investigations. Key words: software engineering, XP, pair programming, PSP methodology, multi-factor analysis INTRODUCTION In designing software, users play key role. In order to design software, it is necessary to observe standard principles of designation and using templates and using modern technologies.
    [Show full text]
  • Extreme Programming from Wikipedia, the Free Encyclopedia
    Create account Log in Article Talk Read Edit View history Search Extreme programming From Wikipedia, the free encyclopedia Main page Extreme programming (XP) is a software development methodology which is Contents intended to improve software quality and responsiveness to changing customer Featured content requirements. As a type of agile software development,[1][2][3] it advocates frequent Current events "releases" in short development cycles, which is intended to improve productivity Random article and introduce checkpoints at which new customer requirements can be adopted. Donate to Wikipedia Wikipedia store Other elements of extreme programming include: programming in pairs or doing Interaction extensive code review, unit testing of all code, avoiding programming of features Help until they are actually needed, a flat management structure, simplicity and clarity in About Wikipedia code, expecting changes in the customer's requirements as time passes and the Community portal problem is better understood, and frequent communication with the customer and Recent changes among programmers.[2][3][4] The methodology takes its name from the idea that the Contact page Planning and feedback loops in beneficial elements of traditional software engineering practices are taken to extreme programming. Tools "extreme" levels. As an example, code reviews are considered a beneficial What links here practice; taken to the extreme, code can be reviewed continuously, i.e. the practice Related changes Software development of pair programming. Upload file process Special pages Critics have noted several potential drawbacks,[5] including problems with Core activities Permanent link unstable requirements, no documented compromises of user conflicts, and a Requirements · Design · Construction · Testing · Debugging · Deployment · Page information lack of an overall design specification or document.
    [Show full text]
  • Download Slides
    Agile Development within the Corporation Jutta Eckstein 1 ©2009-2012 by IT-communication.com Agenda Processes in the enterprise Integrating organizational processes Trust and transparency Supporting individual development 2 ©2009-2012 by IT-communication.com 1 Processes in the Enterprise 3 ©2009-2012 by IT-communication.com Organization Structure Large companies are often departmental structured – Structure assumes linear development – Tend to control rather than support Therefore: – Integrate them early-on – They are service-providers 4 ©2009-2012 by IT-communication.com 2 Misunderstanding the Agile Manifesto „Processes and tools over individuals, interactions, projects and needs“ – Assured by “Methodology Police” [Ed Yourdan] and the like – Requesting tools, frameworks, etc. although they don’t fit Yet, also an enterprise-wide Scrum process – Might prevent agility 5 ©2009-2012 by IT-communication.com Projects, Teams, and Processes differ Processes will differ Architecture, frameworks, platforms as services 6 ©2009-2012 by IT-communication.com 3 Integrating Organizational Processes 7 ©2009-2012 by IT-communication.com Use Budget instead of Estimates Decision for development requires an estimate Estimates should reflect investment – It’s a budget not an estimate – The budget can later on influence development 8 ©2009-2012 by IT-communication.com 4 Legal Department enables Flexibility Accept the interdependence of time, scope, resources, and quality – Optional scope contract – Requirements can change content- or priority-wise – Description of values and approach are part of the contract • Including the obligations of the customer 9 ©2009-2012 by IT-communication.com Marketing and Sales “You can rant and rave all you want about software quality (or lack there of), but the marketing guys run the world and they want market share now..
    [Show full text]
  • Risk Managment on an Agile Project
    BIO PRESENTATION W3 6/28/2006 11:30 AM RISK MANAGMENT ON AN AGILE PROJECT Michele Sliger Rally Software Development Better Software Conference June 26 – 29, 2006 Las Vegas, NV USA Michele Sliger Michele Sliger has worked in software development for almost 20 years. Michele has extensive experience in agile methodologies, having employed agile practices as a founding member of the engineering teams at biotech start-ups UroCor and Genomica. At Genomica, Michele honed her Scrum and XP skills while working under Mike Cohn, a recognized founder of the Agile movement. She carried that experience forward into Qwest, where she served as an XP Coach on a team tasked with developing high-profile financial applications. She has an undergraduate degree in MIS and an MBA. She is a certified Project Management Professional (PMP), a Certified Scrum Master (CSM) and an active member of the board of the Agile Denver chapter. Currently, Sliger works as an agile consultant at Rally Software Development, where she trains software development teams in agile methodologies. In addition to her work for Rally, Sliger is also an adjunct faculty member of the University of Colorado where she teaches Software Project Management to graduate engineering students. Throughout her career, she has performed the gamut of software development roles, including programmer, database administrator, quality assurance manager, process manager and project manager. Risk Management on an Agile Project Presented by Michele Sliger Agile Coach and PMP Better Software Conference & Expo
    [Show full text]
  • Peopleware, 2Nd Ed
    36 Peopleware, 2nd ed. Partial Contents “This is my all-time favorite software engineering PART I: MANAGING THE HUMAN book. Peopleware accurately recognizes that software RESOURCE engineering is about people, not technology. • Somewhere Today, a Project Is “. it’s not just for managers, I strongly recom- Failing mend this book to everyone, from the most junior • Quality—If Time Permits engineer to the CEO.” PART II: THE OFFICE ENVIRONMENT Mark A. Herschberg — , Javaranch.com • The Furniture Police “. one of the most influential books I’ve ever read. • “You Never Get Anything Done The best way to describe it would be as an Anti-Dilbert Around Here Between 9 and 5” Manifesto. Ever wonder why everybody at Microsoft • Bring Back the Door Peopleware gets their own office, with walls and a door that shuts? PART III: THE RIGHT PEOPLE It’s in there. Why do managers give so much leeway to • Hiring a Juggler Productive Projects and Teams, 2nd ed. their teams to get things done? That’s in there too. • Happy to Be Here Why are there so many jelled SWAT teams at Microsoft PART IV: GROWING PRODUCTIVE by Tom DeMarco and Timothy Lister that are remarkably productive? Mainly because Bill TEAMS ISBN: 978-0-932633-43-9 Gates has built a company full of managers who read • Teamicide Peopleware. I can’t recommend this book highly ©1999 264 pages softcover • Chemistry for Team Formation $39.95 (includes $6 UPS in US) enough. It is the one thing every software manager PART V: IT'S SUPPOSED TO BE FUN needs to read .
    [Show full text]
  • Programming Design Patterns
    Programming Design Patterns Patterns for High Performance Computing Marc Snir/Tim Mattson Feb 2006 Dagstuhl Marc Snir Design Pattern High quality solution to frequently recurring problem in some domain Each pattern has a name, providing a vocabulary for discussing the solutions Written in prescribed format to allow the reader to quickly understand the solution and its context 2 Dagstuhl Feb 2006 Marc Snir History ‘60s and ‘70s Berkeley architecture professor Christopher Alexander 253 patterns for city planning, landscaping, and architecture Attempted to capture principles for “living” design. Published in 1977 3 Dagstuhl Feb 2006 Marc Snir Patterns in Object-oriented Programming OOPSLA’87 Kent Beck and Ward Cunningham Design Patterns: Elements of Reusable Object-Oriented Software By the “Gang of Four (GOF)”: Gamma, Helm, Johnson, Vlissides Catalog of patterns Creation, structural, behavioral Published in 1995 4 Dagstuhl Feb 2006 Marc Snir Impact of GOF book Good solutions to frequently recurring problems Pattern catalog Significant influence on object-oriented programming! Created a new vocabulary for software designers. 5 Dagstuhl Feb 2006 Marc Snir The Task Parallelism Pattern Problem: How do you exploit concurrency expressed in terms of a set of distinct tasks? Forces Size of task – small size to balance load vs. large size to reduce scheduling overhead Managing dependencies without destroying efficiency. Solution Schedule tasks for execution with balanced load – use master worker, loop parallelism, or SPMD patterns. Manage dependencies by: removing them (replicating data), transforming induction variables, exposing reductions explicitly protecting (shared data pattern). Intrusion of shared memory model… 6 Dagstuhl Feb 2006 Marc Snir Pattern Languages: A new approach to design Not just a collection of patterns, but a pattern language: Patterns lead to other patterns creating a design as a network of patterns.
    [Show full text]
  • Two Reengineering Patterns
    Type-Check Elimination: Two Reengineering Patterns Stephane´ Ducasse, Robb Nebbe, Tamar Richner Software Composition Group, Universitat¨ Bern g fducasse,nebbe,richner @iam.unibe.ch http://www.iam.unibe.ch/scg/ Abstract A reengineering pattern describes how to go from an existing legacy solution to a new refactored solution. In this paper we discuss the role of reengineering patterns and contrast them with design patterns and antipatterns. We then highlight the structure of a reengineering pattern and present two simple, related patterns for type-check elimination. 1 Reengineering Patterns When important legacy software can no longer gracefully evolve to meet changing requirements it is often reengineered. Reengineering patterns codify and record knowledge about modifying legacy software: they help in diagnosing problems and identifying weaknesses which hinder further development of the system and aid in finding solutions which are more appropriate to the new requirements. Reengineering patterns differ from Design Patterns [GHJV95] in their emphasis on the pro- cess of moving from an existing legacy solution to a new refactored solution. Whereas a design pattern presents a solution for a recurring design problem, a reengineering pattern presents a refactored solution for a recurring legacy solution which is no longer appropriate, and describes how to move from the legacy solution to the refactored solution. The mark of a good reengineer- ing pattern is (a) the clarity with which it exposes the advantages, the cost and the consequences of the target solution with respect to the existing solution, and not how elegant the target solution is, (b) the description of the change process: how to get from one state of the system to another.
    [Show full text]
  • Enhancing Learnability of Pair Programming Practice When Introducing Novices
    MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Enhancing Learnability of Pair Programming Practice when Introducing Novices DIPLOMOVÁ PRÁCE Pavel Januš Brno, jaro 2014 Declaration I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Bruno Rossi, PhD. i Acknowledgement I would like to express my gratitude to my supervisor Bruno Rossi for leading me through the creation of my diploma thesis. I am grateful to him for stimulating discus- sions about the content of the thesis and supporting developing of my own ideas. I also want to appreciate his provided time, knowledge, valuable information and his patience and willingness. I express special thanks to my parents for their understanding, and my girlfriend for her support. ii Abstract The current thesis focuses on understanding the mechanisms that lead novice develop- ers to better learn the Pair Programming (PP) practice, one of the pillars of Agile Metho- dologies. The main aim is to provide theoretical-grounded suggestions that could help to improve the process by which novices are introduced to PP and start mastering it. To contextualize PP, we review the emergence of Agile development methodology com- pared to more heavy-weight methodologies and we evaluate the importance of PP as one of the key practices of Extreme Programing (XP). We then delve into empirical stu- dies that investigate the efficacy of PP in software development and into the identifica- tion of the state of the art in terms of the introduction of PP to novices.
    [Show full text]