<<

Software development

• Several users work on a same project – Remote or collocated users – Each one works on its own computer

Groupware and Collaborative Interaction (asynchronous) Collaborative Software Development • Work on different tasks • Work at different times ! • Collaboration is hard to organize M2R Interaction - Université Paris-Sud - Année 2013-2014 Cédric Fleury ([email protected]) – Versioning, synchronization between users – Tasks distribution, social aspects

Collaborative Software Development - M2R Interaction - Cédric Fleury !2

Outline Outline

• Collaborative software development • Collaborative software development ! ! – – Version control ! ! – Continuous integration – Continuous integration ! ! – Agile methods – Agile methods

Collaborative Software Development - M2R Interaction - Cédric Fleury !3 Collaborative Software Development - M2R Interaction - Cédric Fleury !4

Version control Version control • Problematic • Problematic – We want to avoid this: – We want to avoid: • Manually share the files (USB key, email, Dropbox) • Delete or overwrite the files of other users • Broke all the project by making a mistake ! – We want to able to: • Edit the project at the same time • Keep an history of the modification • Keep the older version of the files + hierarchy [“Piled Higher and Deeper” by Jorge Cham: www.phdcomics.com]

Collaborative Software Development - M2R Interaction - Cédric Fleury !5 Collaborative Software Development - M2R Interaction - Cédric Fleury !6 Version control Version control

• Version control software • 2 kinds of architecture – Save & restore different versions of the files – Centralized – Synchronize users’ versions • CVS, SVN, … – Keep track of modifications and their authors – Decentralized (peer-to-peer): – Manage Branching and merging • GNU Arch, Mercurial, Bazaar, ,… ! ! • Not only for software development – Decentralized can be used as a Hybrid – Report, images, data from experiments Architecture • One peer can be a central server

Collaborative Software Development - M2R Interaction - Cédric Fleury !7 Collaborative Software Development - M2R Interaction - Cédric Fleury !8

Version control Version control • Centralized • Decentralized architecture architecture

Collaborative Software Development - M2R Interaction - Cédric Fleury !9 Collaborative Software Development - M2R Interaction - Cédric Fleury !10

Version control Version control

• Hybrid • Vocabulary (SVN) Centralized Architecture architecture – Architecture • Repository • Working copy – Actions • Checkout • Update • • Revert • , log, status

Collaborative Software Development - M2R Interaction - Cédric Fleury !11 Collaborative Software Development - M2R Interaction - Cédric Fleury !12 Version control Version control

• Vocabulary (Git) Hybrid Architecture • Drawbacks of the centralized architecture – Architecture • Remote and local repository – Just one access point to the data • Working copy – Just one communication point between users – Actions – Just one historic of the files • Clone – Versioning and sharing are the same operation • Pull, Push • Need to have a stable state before "committing" • Commit • Reset • Diff, log, status

Collaborative Software Development - M2R Interaction - Cédric Fleury !13 Collaborative Software Development - M2R Interaction - Cédric Fleury !14

Version control Version control

• Good practices • Users can modify the same file – But at different part/section of the files – Work on the local copy ! – Send the modification • If they modify the same part of a file • Check if the code compiles locally – A conflict appends • Check for updates from the other users • Usually, it cannot be resolve automatically – Manage conflicts if there are some • Users have to fix the conflit • Check if the code compiles with the updates – By telling to the system, which version is correct • Commit the code on the shared version (server) – By merging the modifications of the users

Collaborative Software Development - M2R Interaction - Cédric Fleury !15 Collaborative Software Development - M2R Interaction - Cédric Fleury !16

Version control Version control

• Conflicts management • Conflicts management

08/10/2010 11:44 AM 94 test.txt :\workspace\test>svn up 08/10/2010 11:44 AM 26 test.txt.mine Conflict discovered in 'test.txt'. 08/10/2010 11:44 AM 27 test.txt.r2 Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved, 08/10/2010 11:44 AM 31 test.txt.r3 (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p C test.txt test.txt Updated to revision 3. Summary of conflicts: <<<<<<< .mine Text conflicts: 1 test User2 making conflict ======User1 am making a conflict test >>>>>>> .r3

Collaborative Software Development - M2R Interaction - Cédric Fleury !17 Collaborative Software Development - M2R Interaction - Cédric Fleury !18 Version control Version control • Tools for conflict management (TortoiseMerge) • Tools for conflict management (TortoiseMerge)

Collaborative Software Development - M2R Interaction - Cédric Fleury !19 Collaborative Software Development - M2R Interaction - Cédric Fleury !20

Version control Version control • Tools for conflict management (SmartGit) • Tools for conflict management (SmartGit)

Collaborative Software Development - M2R Interaction - Cédric Fleury !21 Collaborative Software Development - M2R Interaction - Cédric Fleury !22

Version control Version control

• Conflicts management • Collaboration scenario : centralized (SVN) – To avoid conflict: ! • Users are able to "lock" a file – Only the user who locks the file can modify it – If another user try to lock a file while it is locked by another user, he receives an error message ! • Users have to manually unlock the file when they have finished to work on it.

Collaborative Software Development - M2R Interaction - Cédric Fleury !23 Collaborative Software Development - M2R Interaction - Cédric Fleury !24 Version control Version control

• Collaboration scenario : decentralized (Git) • Collaboration scenario : decentralized (Git) – Integrator mode • A repository is in charge of the test

Inter-personal communications

Collaborative Software Development - M2R Interaction - Cédric Fleury !25 Collaborative Software Development - M2R Interaction - Cédric Fleury !26

Version control Version control

• Collaboration scenario : decentralized (Git) • Collaboration scenario : decentralized (Git) – Dictator mode – Multi-location team • Open-source • Each team can work independently projects • Regular integration of the work of each team • "Lieutenants" can be done make a first check before sending to the "dictator"

Collaborative Software Development - M2R Interaction - Cédric Fleury !27 Collaborative Software Development - M2R Interaction - Cédric Fleury !28

Version control Version control

• Historic management • Historic management – Computation of the historic is linear – SVN assigns a revision according to the « commit" order number to all the project ! – Git assigns a revision number peer file ! – This difference has a strong impact on collaboration • Using branch for collaboration is easier with Git

Collaborative Software Development - M2R Interaction - Cédric Fleury !29 Collaborative Software Development - M2R Interaction - Cédric Fleury !30 Version Control Version Control

• Branch management • Branch management ! – Merging branch (very complex to achieve with SVN) ! ! ! ! – SVN make a copy of the all repository – Git make a link to a particular state of the files

Collaborative Software Development - M2R Interaction - Cédric Fleury !31 Collaborative Software Development - M2R Interaction - Cédric Fleury !32

Version Control Version Control • Branch management • Branch management – Each user can work on particular branches – Classical organisation – Branches can be synchronized between users of a project into branches ! http://nvie.com/posts/a- successful-git-branching-model/

Collaborative Software Development - M2R Interaction - Cédric Fleury !33 Collaborative Software Development - M2R Interaction - Cédric Fleury !34

Outline Continuous integration

• Collaborative software development • Integration ! – Merging the work of several developers – Version control • Goals ! – Test modifications form the beginning – Continuous integration – Detect integration problems at an early stage ! – Avoid fastidious integration phases – Agile methods – Always have the system running • Tests, demos, discussion with the customers

http://martinfowler.com/articles/continuousIntegration.html

Collaborative Software Development - M2R Interaction - Cédric Fleury !35 Collaborative Software Development - M2R Interaction - Cédric Fleury !36 Continuous integration Continuous Integration

• Principles • Feedbacks for collaboration – Version control on a repository – Token on the desk of the person who builds – Automatic and fast build – Auto-testing – Make a sound when a build is valid – "Commit" every day – Web page of the integration server – Deployment on an – Bubble light integration computer – Wallboard after each "commit" – Automatic deployment – Executable always available – Every body know the build state

Collaborative Software Development - M2R Interaction - Cédric Fleury !37 Collaborative Software Development - M2R Interaction - Cédric Fleury !38

Outline Software development

• Collaborative software development • Methods for software development ! – No methods: "Code and fix" – Version control • Efficient for small project • Difficult to add new features or to find bugs ! ! – Continuous integration – Engineering / plan-driven methodologies ! • Come from civil or mechanical engineering – Drawing / construction plan / task distribution / construction – Agile methods ! – Agile methodologies • Adaptive rather than predictive • People-oriented rather than process-oriented

Collaborative Software Development - M2R Interaction - Cédric Fleury !39 Collaborative Software Development - M2R Interaction - Cédric Fleury !40

Software development Software development

• Engineering methodologies • Engineering methodologies – Separation of design and construction – Example: Waterfall • Design – Unpredictable – Require creative people • Construction – Predictable – Require people with lower skill ! – Example: civil engineering • construction is bigger in cost and time than design

Collaborative Software Development - M2R Interaction - Cédric Fleury !41 Collaborative Software Development - M2R Interaction - Cédric Fleury !42 Software development Software development

• Design and Construction for software? • Is software development predictable? – UML = Design, coding = Construction? – Yes in some cases… • NASA programs – Source code = Design, compilation = Construction • Construction is quick and cheap – Usually, requirements are unpredictable • Source code requires creative and talented people (especially for software involving interactions with users) • Creative processes are unpredictable • Customers don’t precisely know what they want • Are the engineering methodologies well adapted ? • Hard to evaluate the cost of different options • Hard to estimate which features are useful ! [Jack Reeves, C++ Journal, 1992] http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm ⇒ Requirements should be flexible in these cases Collaborative Software Development - M2R Interaction - Cédric Fleury !43 Collaborative Software Development - M2R Interaction - Cédric Fleury !44

Software development Agile methods

• Is software development predictable? • Deal with unpredictable requirements – Iterative development • Involve the customers at each iteration • Improve the team organization (self-adaptive process) ! – Effective team of developers (people first) • Do not consider developers are replaceable parts – Analysts, coders, testers, managers • Developers are responsible professionals – Make the technical decisions – Evaluate the time required to perform the tasks

Collaborative Software Development - M2R Interaction - Cédric Fleury !45 Collaborative Software Development - M2R Interaction - Cédric Fleury !46

Agile methods Agile methods

• Manifesto for Agile Software Development ! – Individuals and interactions over processes and tools ! – Working software over comprehensive documentation ! – Customer collaboration over contract negotiation ! – Responding to change over following plan

http://agilemanifesto.org

Collaborative Software Development - M2R Interaction - Cédric Fleury !47 Collaborative Software Development - M2R Interaction - Cédric Fleury !48 Agile methods Pair programming • Examples • Two programmers – XP (Extreme Programming) • Test driven development, pair programming • One computer – Scrum • Roles – Crystal • Safety, efficiency, habitability (less discipline than XP) – One "drives": operating mouse and keyboard • Code: syntax, semantics, algorithm – Open source process ! • Distributed contributors, parallelized debugging – One "navigates": watchs, learns, asks, talks, – Lean development (Lean @ Toyota) makes suggestions • Just in time, Jidoka ("automation with a human touch") • Higher level of abstraction – RUP (Rational Unified Process) ? – • Use case driven, iterative, architecture centric Test, technical task, time since the last commit, – Quality of the overall design Collaborative Software Development - M2R Interaction - Cédric Fleury !49 Collaborative Software Development - M2R Interaction - Cédric Fleury !50

Pair programming Pair programming • Advantages • Productivity – Code quality (it depends on how you measure productivity : lines of code VS running and tested features) • Better designs – Short-term productivity might decrease • Fewer bugs ! slightly (about 15%) – Spreading Knowledge – Long-term productivity goes up • Pairs have to switch off regularly • Because the code is better • Technical and conceptual knowledge • Even better if you consider staff turnover ! – Truck number in XP – Social aspects » Close as possible to the team size • No loneliness, conviviality, better motivation

Collaborative Software Development - M2R Interaction - Cédric Fleury !51 Collaborative Software Development - M2R Interaction - Cédric Fleury !52

Pair programming Scrum

• Pairing strategies • Iterations called Sprint (about 1 month) – In XP, all production code is written by pairs – In non-XP agile teams, usually pairing is not used at all – A trade-off can be found • For some particular tasks – Mentoring new hires – Extremely high-risk tasks – Start of a new project when the design is new – When adopting a new technology • On a rotating monthly or weekly basis • Developers who prefers to pair

Collaborative Software Development - M2R Interaction - Cédric Fleury !53 Collaborative Software Development - M2R Interaction - Cédric Fleury !54 Scrum Scrum • Roles – Product Owner • Product Backlog • Single person • Responsible for products vision • Constantly re-prioritizes the Product Backlog • Accepts or rejects product increment – Development team • Self-organized • Negotiate commitments with the Product Owner • Has autonomy regarding how to reach commitments • Intensely collaborative – Master • Facilitates the Scrum process • Helps resolve issues • Shields the team from external inferences and distractions • Has no management authority

Collaborative Software Development - M2R Interaction - Cédric Fleury !55 Collaborative Software Development - M2R Interaction - Cédric Fleury !56

Scrum Scrum • Sprint – Planning Meeting • Negotiate which Product Backlog items will be processed • Break items into a list of sprint tasks

Collaborative Software Development - M2R Interaction - Cédric Fleury !57 Collaborative Software Development - M2R Interaction - Cédric Fleury !58

Scrum Scrum • Sprint • Sprint Backlog – Planning Meeting – Daily Meeting • Same time and place • 15 minutes, standing up • Summarize work of previous day, work of today, issues • Maintain tasks list (not started, in progress, done), issues list and burn-down chart. • Product Owner may attend

Collaborative Software Development - M2R Interaction - Cédric Fleury !59 Collaborative Software Development - M2R Interaction - Cédric Fleury !60 Scrum Scrum • Sprint • Sprint – Planning Meeting – Planning Meeting – Daily Meeting – Daily Meeting – Review Meeting – Review Meeting • Demonstrate the working – Retrospective Meeting product increment to the • Team reviews its own process Product Owner • Team takes to adapt it for • Product Owner declares futur Sprints which items are done • Master have to manage the • Unfinished items return to psychological safety of the the Product Backlog meetings • Master proposes new items for the Product Backlog

Collaborative Software Development - M2R Interaction - Cédric Fleury !61 Collaborative Software Development - M2R Interaction - Cédric Fleury !62

Scrum Scrum • Sprint • Feedbacks to the team: wallboard – Planning Meeting – Daily Meeting – Review Meeting – Retrospective Meeting – Backlog Refinement Meeting • Items are usually too large or poorly understood • Refine these items into smaller one • Master can help

Collaborative Software Development - M2R Interaction - Cédric Fleury !63 Collaborative Software Development - M2R Interaction - Cédric Fleury !64

Scrum Scrum • Feedbacks to the team: wallboard • Feedbacks to the team: wallboard

Collaborative Software Development - M2R Interaction - Cédric Fleury !65 Collaborative Software Development - M2R Interaction - Cédric Fleury !66 Scrum Scrum • Feedbacks to the team: wallboard • Software to manage Scrum projects

http://youtu.be/KdyV9okLRlc

Collaborative Software Development - M2R Interaction - Cédric Fleury !67 Collaborative Software Development - M2R Interaction - Cédric Fleury !68

Conclusion References • Version control • Collaboration in software development – http://nvie.com/posts/a-successful-git-branching-model/ – Is necessary for big projects – http://www-igm.univ-mlv.fr/~dr/XPOSE2010/ – Is not obvious gestiondeversiondecentralisee/dvcs-svn.html • Technical, organizational and social aspects – http://www.infres.enst.fr/~bellot/java/poly/git.pdf ! – http://fr.openclassrooms.com/informatique/cours/gerez-vos-codes- • Version control source-avec-git/qu-est-ce-qu-un-logiciel-de-gestion-de-versions – Synchronization, versioning • Continuous Integration – Branching: split work between users – http://martinfowler.com/articles/continuousIntegration.html ! • Agile Models • Continuous integration – http://agilemanifesto.org – Improve safety and efficiency – http://martinfowler.com/articles/newMethodology.html ! • Pair Programming • Agile method – http://www.versionone.com/Agile101/Pair_Programming.asp – Organize the team • Scrum – Propose an adaptative process to unpredictable requirements – http://scrumreferencecard.com

Collaborative Software Development - M2R Interaction - Cédric Fleury !69 Collaborative Software Development - M2R Interaction - Cédric Fleury !70