Team programming

Last updated

In software engineering, team programming is a project management strategy for coordinating task distribution in computer software development projects, which involves the assignment of two or more computer programmers to work collaboratively on an individual sub-task within a larger programming project. In general, the manner in which this term is used today refers to methods currently in vogue within the software development industry where multiple individuals work simultaneously on the same activity; in these systems, programmers are often grouped in pairs at the same computer workstation, one observing the other working on the software and alternating roles at time intervals.

Contents

Traditional team management methods

Traditional software development has nearly always involved multiple programmers working on separate parts of a computer system for any project of significant scope and scale—a method of division of labour. Clearly, it is unreasonable to imagine that a single programmer could adequately complete all the required work for a complex system working entirely on their own within a viable timescale; and as development projects become more complex, specialised expertise becomes of paramount importance in aspects such as systems analysis, quality assurance, and technical challenges posed by individual components. Initially this tended to be an informal process, but with the rise of commercial software development as a viable industry, a more industrial and systematic approach became necessary.

Paper-oriented systems methodologies originally designed for undertaking governmental projects, such as the Structured Systems Analysis and Design Method (SSADM), assigned individual people to carry out individual tasks, and specified the role of designers as being clearly separate from that of the programmers in the waterfall software development model. This methodology also clearly separated each of the individual "life-cycle" stages through which a system development project progressed. The resulting "paper trail" for a systems development project could take so long to build that often parts of the analysis documentation—or sometimes its entirety—was out of date by the time of actual development, rendering them worse than useless.

Modern trends: multiple programmers to one sub-task

Difficulties were experienced with these older methods, such as costs spiralling out of control as systems grew, and schedules failing to meet time-to-market targets. These issues gave rise to techniques such as pair programming, mob programming (aka. ensemble programming), along with new systems lifecycle structures such as the Boehm spiral. Specification of these new approaches began in the mid-1980s and continues today. Many of these strategies involve multiple programmers working collaboratively on the same piece of source code as opposed to being individually responsible for individual tasks. For example, in "pair programming", responsibility for the resulting product is equally shared between two programmers who work on their assigned sub-task together. Benefits of this approach include the deficiencies in knowledge of one programmer to be compensated for by the ability in specific areas by the other programmer; in addition, the shared responsibility is thought to increase incentives for meeting project deadlines and quality targets.

This technique is frequently used in newer programming methodologies that are focused around object-oriented programming techniques, such as the Rational Unified Process and Extreme Programming (acronym "XP"), often in combination with design documentation methods such as the Unified Modelling Language (UML). In object-oriented programming languages, software functionality forms modular, discrete units (termed classes for the functional elements, and packages for constellations of interlinked classes that carry out a particular function); the two most well-known of these are C++ and Java. This lends itself well towards the division of programming projects into sub-teams, although issues are still often encountered in integrating the resulting product following completion of each sub-task.

Mob programming

French mob programming session Mob prog.jpg
French mob programming session

Mob programming (sometimes informally called mobbing, ensemble programming or posse programming [1] ) is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time. With mob programming, the collaboration is extended to everyone on the team, while still using a single computer for writing the code and inputting it into the code base. [2]

The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). [3]

— Marcus Hammarberg, Mob programming – Full Team, Full Throttle

It builds on principles of lean manufacturing, extreme programming, and lean software development. Early use of the phrase "mob programming" was made in Extreme Programming Perspectives. [4]

In addition to software coding, a mob programming team can work together to tackle other typical software development tasks. Some examples include: defining user stories or requirements, designing, testing, deploying software, and working with subject matter experts. Almost all work is handled in working meetings or workshops, where all the people involved in creating the software are considered to be team members, including the customer and business experts. [5] Mob programming also works for distributed teams in the same virtual space using screen sharing technology. [6]

See also

Related Research Articles

<span class="mw-page-title-main">Pair programming</span> Collaborative technique for software development

Pair programming is a software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

A software company is an organisation — owned either by the state or private — established for profit whose primary products are various forms of software, software technology, distribution, and software product development. They make up the software industry.

In computer programming, unit testing, a.k.a. component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior.

Software development is the process used to create software. Programming and maintaining the source code is the central step of this process, but it also includes conceiving the project, evaluating its feasibility, analyzing the business requirements, software design, testing, to release. Software engineering, in addition to development, also includes project management, employee management, and other overhead functions. Software development may be sequential, in which each step is complete before the next begins, but iterative development methods where multiple steps can be executed at once and earlier steps can be revisited have also been devised to improve flexibility, efficiency, and scheduling.

The following outline is provided as an overview of and topical guide to software engineering:

<span class="mw-page-title-main">Computer-aided software engineering</span> Domain of software tools

Computer-aided software engineering (CASE) is a domain of software tools used to design and implement applications. CASE tools are similar to and are partly inspired by computer-aided design (CAD) tools used for designing hardware products. CASE tools are intended to help develop high-quality, defect-free, and maintainable software. CASE software was often associated with methods for the development of information systems together with automated tools that could be used in the software development process.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

<span class="mw-page-title-main">History of software engineering</span>

The history of software engineering begins around the 1960s. Writing software has evolved into a profession concerned with how best to maximize the quality of software and of how to create it. Quality can refer to how maintainable software is, to its stability, speed, usability, testability, readability, size, cost, security, and number of flaws or "bugs", as well as to less measurable qualities like elegance, conciseness, and customer satisfaction, among many other attributes. How best to create high quality software is a separate and controversial problem covering software design principles, so-called "best practices" for writing code, as well as broader management issues such as optimal team size, process, how best to deliver software on time and as quickly as possible, work-place "culture", hiring practices, and so forth. All this falls under the broad rubric of software engineering.

In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions.

Skeleton programming is a style of computer programming based on simple high-level program structures and so called dummy code. Program skeletons resemble pseudocode, but allow parsing, compilation and testing of the code. Dummy code is inserted in a program skeleton to simulate processing and avoid compilation error messages. It may involve empty function declarations, or functions that return a correct result only for a simple test case where the expected response of the code is known.

<span class="mw-page-title-main">Edward Yourdon</span> American software engineer and pioneer in the software engineering methodology

Edward Nash Yourdon was an American software engineer, computer consultant, author and lecturer, and software engineering methodology pioneer. He was one of the lead developers of the structured analysis techniques of the 1970s and a co-developer of both the Yourdon/Whitehead method for object-oriented analysis/design in the late 1980s and the Coad/Yourdon methodology for object-oriented analysis/design in the 1990s.

Open-source software development (OSSD) is the process by which open-source software, or similar software whose source code is publicly available, is developed by an open-source software project. These are software products available with its source code under an open-source license to study, change, and improve its design. Examples of some popular open-source software products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media player.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

Extreme programming (XP) is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.

The following outline is provided as an overview of and topical guide to software development:

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

References

  1. ↑ Edward Sykes (Heretsch); Rajpal Singh (2012). "ACCU 2012 Lightening Talks: Posse Programming" (PDF). Accu2012 Lightning Talks.
  2. ↑ Zuill, Woody (2014). "Mob Programming: A Whole Team Approach". Agile2014 Conference Experience Reports: 11.
  3. ↑ Hammarberg, Marcus. "Mob programming – Full Team, Full Throttle". CodeBetter. CodeBetter. Retrieved 9 September 2014.
  4. ↑ Moses Hohman; Andrew Slocum (2002). "Chapter 28. Mob Programming and the Transition to XP". Extreme Programming Perspectives. Addison-Wesley.
  5. ↑ Nigri, Julien. "Le Mob Programming : Présentation". Soat (in French). Soat. Retrieved 9 September 2014.
  6. ↑ Harrer, Simon; Christ, Jochen; Huber, Martin. "Remote Mob Programming" . Retrieved 29 April 2019.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.