1 / 20

OPEN DEVELOPMENT, Agile, xp AND SCRUM

OPEN DEVELOPMENT, Agile, xp AND SCRUM. 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.

ericgregory
Télécharger la présentation

OPEN DEVELOPMENT, Agile, xp AND SCRUM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OPEN DEVELOPMENT,Agile, xp AND SCRUM COMP 319

  2. 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 COMP319

  3. 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 COMP319

  4. 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 COMP319

  5. 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 COMP319

  6. 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 COMP319

  7. 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 COMP319

  8. 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 COMP319

  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 COMP319

  10. 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 COMP319

  11. 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 COMP319

  12. Syntactic sugar is your friend public int X{ // C# get { return x; } set { x = value; } } • Generics (always use if relevant!) • For each Java ArrayList <Person> list=new ArrayList <Person>(); for (Person person: list) { } Make’s code tighter COMP319

  13. 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 COMP319

  14. 1970s Perspective • 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 COMP319

  15. The Surgeon role • Involved in overall system architecture • Defines functional and performance specification • Writes documentation • Uses HLL and CASE tools • Experienced and well paid COMP319

  16. 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 COMP319

  17. 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 COMP319

  18. 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 COMP319

  19. 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 COMP319

  20. 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 COMP319

More Related