Content deleted Content added
m →Mob programming: Experience Reports link |
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
| (One intermediate revision by one other user not shown) | |||
Line 13:
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|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 [[class (computer science)|class]]es for the functional elements, and [[Modular programming|packages]] for constellations of interlinked classes that carry out a particular function); the two most well-known of these are [[C++]] and [[Java (programming language)|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===
Line 21:
{{Blockquote
|text=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).
<ref>{{cite web|last1=Hammarberg|first1=Marcus|title=Mob programming – Full Team, Full Throttle|url=http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/|website=CodeBetter|publisher=CodeBetter|access-date=9 September 2014|archive-date=15 November 2014|archive-url=https://web.archive.org/web/20141115035554/http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/|url-status=dead}}</ref>
|author=Marcus Hammarberg
|title=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''.<ref>{{cite book |author1=Moses Hohman |author2=Andrew Slocum |chapter=Chapter 28. Mob Programming and the Transition to XP |title=Extreme Programming Perspectives |date=2002 |publisher=Addison-Wesley}}</ref>
| |||