OPEN DEVELOPMENT, AGILE, XP AND SCRUM © University of LiverpoolCOMP 319slide 1.
-
Upload
baldwin-snow -
Category
Documents
-
view
216 -
download
0
Transcript of OPEN DEVELOPMENT, AGILE, XP AND SCRUM © University of LiverpoolCOMP 319slide 1.
OPEN DEVELOPMENT,AGILE, XP AND SCRUM
© University of LiverpoolCOMP 319 slide 1
Linux a brief history
• GNU project- Richard Stallman- C compiler released in 1987
• Minux- Andrew S. Tanenbaum- 12,000 lines of C and 8086 assembler
• Linux- Linus Torvald 1991
• Linux distribution today- Linux kernel (3%) + GNU software (28%)
+ others
© University of LiverpoolCOMP319 slide 2
Cathedral and the Bazaar
• Eric Raymond in 1997 published The Cathedral and the Bazaar
• He conjectured that there were essentially two ways to engineer software
• 1. In the cathedral, and• 2. In the bazaar
© University of LiverpoolCOMP319 slide 3
Cathedral approach (e.g. IBM, MS)• Leads to large complex programs
such as operating systems• These projects were worked on by
teams of “high-priests/cathedral builders”
• The product was essentially completed when released for sale
• Were the province of large organisations
© University of LiverpoolCOMP319 slide 4
The Bazaar Approach
• A large network of communicating developers all interested in the solution
• “Release early. Release often. And listen to your customers” - Linus’ principle
• “Given enough eyeballs, all bugs are shallow'' - Linus' law coined by Raymond
• Source freely available and everyone encourage to take part as equals
© University of LiverpoolCOMP319 slide 5
Open source development
• All code open to peer review• Large tester base (need to early
and frequent code releases, early Linux was released daily)
• Open source code/testing debugging- testing frameworks- Run the code using source code debugger
© University of LiverpoolCOMP319 slide 6
Case study (fetchmail)
• Raymond set out to discover why the bazaar approach worked
• About increasing personal productivity
• About open source, open management, open goals
• “egoless programming” Weinberg
© University of LiverpoolCOMP319 slide 7
fetchmail Lessons 1-6
• Personal commitment to the software
• Use what is available• One will get thrown away• The individual (interest) is central• Interest is not necessarily
sustained• Users like helping; become
developers
© University of LiverpoolCOMP319 slide 8
fetchmail Lessons 7-11
• Release early & often. Listen to your customers
• Many eyes make debugging light• Get data structures right, code
follows• Testers are your most valuable
resource• Recognise good ideas from others
© University of LiverpoolCOMP319 slide 9
fetchmail Lessons 7-11
• Release early & often. Listen to your customers
• Many eyes make debugging light• Get data structures right, code
follows• Testers are your most valuable
resource• Recognise good ideas from others
© University of LiverpoolCOMP319 slide 10
fetchmail Lessons 12-17• Recognise your poor ideas• Design perfection comes from
pruning• Good software is used in
unexpected ways• Don’t throw information away• Beware of pseudo-secrets
© University of LiverpoolCOMP319 slide 11
Syntactic sugar is your friendpublic int X{ // C# get { return x; } set { x = value; }}•Generics (always use if relevant!)•For each JavaArrayList <Person> list=new ArrayList <Person>();for (Person person : list) { }Make’s code tighter
© University of LiverpoolCOMP319 slide 12
Surgical Teams
• Observations on team working – Brooks
• Roles: surgeon, co-pilot, administrator, editor, 2 secretaries, program clerk, toolsmith, tester, language lawyer.
• 10 roles; around two surgeons one taking the lead and dedicated to the project
• Teams of 10 do the surgery© University of LiverpoolCOMP319 slide 13
1970s Perspective
© University of LiverpoolCOMP319 slide 14
• PDP 11-Max 128K RAM- Cost about £12,000 then, equivalent of around £124,000
• Applications at the time- Therac-25 radio therapy- Air traffic control
The Surgeon role
• Involved in overall system architecture
• Defines functional and performance specification
• Writes documentation• Uses HLL and CASE tools• Experienced and well paid
© University of LiverpoolCOMP319 slide 15
Co-Pilot Role
• Can do whatever the surgeon can• Shares in the design as a thinker,
discussant, and evaluator• Represents the team and acts as
interface• May write code but is not
responsible for it• Less experienced, younger
© University of LiverpoolCOMP319 slide 16
Administrator, editor, support
• Administrator deals with staff, money, space. Liaises with the rest of the organisation. Usually serves two teams.
• Editor generates final documentation, nurses it through to publication
• Clerical and secretarial support is vital for the administrator and editor
© University of LiverpoolCOMP319 slide 17
Program Clerk, Toolsmith
• Clerk maintains all technical records as a librarian and as a secretary is responsible for machine, and paper files
• Toolsmith is an expert who evaluates, upgrades, customises, builds tools as required by the surgeon and team
© University of LiverpoolCOMP319 slide 18
Tester, Language Lawyer
• Tester generates test cases and writes the test environment. S/he confirms that the functional requirements are met
• Language Lawyer is the HLL expert who thinks up neat, efficient ways to do difficult and obscure things. Will be constantly researching good technique. One lawyer serves several teams
© University of LiverpoolCOMP319 slide 19
Surgical team structure C21st
• Software team leader and junior programmer
• Tester• Project manager/administrator• Everything else done by- IDE and debugging, re-factoring tools-OO patterns- Source control systems
© University of LiverpoolCOMP319 slide 20