Presentation is loading. Please wait.

Presentation is loading. Please wait.

8 December 2010. Logistics  Sitterson 014 at 8 am Tuesday, Dec 14  Inviting all clients  Schedule will depend on client constraints (email once booked)

Similar presentations


Presentation on theme: "8 December 2010. Logistics  Sitterson 014 at 8 am Tuesday, Dec 14  Inviting all clients  Schedule will depend on client constraints (email once booked)"— Presentation transcript:

1 8 December 2010

2

3 Logistics  Sitterson 014 at 8 am Tuesday, Dec 14  Inviting all clients  Schedule will depend on client constraints (email once booked)  15 minute presentations  Breakfast will be served  Attendance is mandatory  [101 exam will be testing web sites]

4 What is Expected  Overview of your project Review what you did and why Briefly explain how you did it ○ Architecture ○ Technologies  Lessons learned Development Process Technologies  Demo

5 The Basics  Speak loudly and clearly  Stand up  No chewing gum when speaking  Speak, don’t read: you ARE the experts  Set up and test demos on Monday Last minute “fixes” are often disasters  Script your demos

6 Presentations Hints  Cover all topics, but they don’t need equal time!  Focus on what’s special about your project  Don’t try to cover too much  Keep it light  Give the audience something to look at

7 Death by PowerPoint  Google it and you can waste many hours  One that I like… http://www.slideshare.net/thecroaker/death-by-powerpoint  PowerPoint is Evil (Edward Tufte) PowerPoint is Evil

8

9 When to Use XP  Types of projects High risk Poorly understood requirements  Team Small size: 2 to 12 Needs to include customer  Automated testing Timing issue

10 What Makes a Project XP  Paradigm see change as the norm, not the exception optimize for change  Values communication, simplicity, feedback, and courage honor in actions  Power sharing business makes business decisions development makes technical decisions  Distributed responsibility and authority people make commitments for which they are accountable  Optimizing process aware of process and whether it is working experiment to fix acculturate new team members Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck

11

12 Egoless Programming  Weinberg 1971, The Psychology of Computer Programming During the “cowboy” era  Observed that programmers needed to be team players Accept inspections and reviews Open to corrections and critiques  Ten Commandments Ten Commandments  But pride of ownership is critical to quality

13 Software Craftsmanship  Emphasizes coding skills of the developers  Recognition of importance of the individual  Manifesto Manifesto  Fundamentals Apprenticeship Pride in your work  Basis Pragmatic Programmer (Hunt and Thomas) Pragmatic Programmer Software Craftsmanship (McBreen) Software Craftsmanship

14 Can Craftsmanship Help the Software Crisis?  Craftsmen sign their work basis for reputation hiring on portfolio Forget licensing  Exploit productivity differences between individuals not managing hordes of 'average' programmers small teams of good developers pay differentials  Expose the fallacy of good enough software  Software development is a social, intellectual activity not mechanical : engineering wrong metaphor mythical man month problem still exists  Apprenticeship more effective than training software development as a craft not the same as being taught how to program.

15

16 Software Generations (Rational View) Proprietary Not Integrated 100% Custom Ad-hoc Mix of Proprietary and Commercial Not Integrated 30% Reused Assets 70% Custom Repeatable Commercial Integrated Processes-Tools Managed and Measured Tools Complexity Process 1960s-1980s1990s-2000s2005+ Project Performance PredictableUnpredictablePredictable 70% Reused Assets 30% Custom over budget, over schedule Infrequently on budget, on schedule Frequently on budget, on schedule Collocated On the Job Training Collocated Software Skills Distributed Systems/Software Professionals Team

17 Four Patterns of Success  Scope management  Asset based development Solutions need to evolve from user specifications AND user specifications need to evolve from candidate solutions. ○ As opposed to getting all the requirements right up front.  Process management  Rightsize the process Process and instrumentation rigor evolves from light to heavy. ○ As opposed to the entire project’s lifecycle process should be light or heavy depending on the character of the project.  Progress management  Honest assessments Healthy projects display a sequence of progressions and digressions. ○ As opposed to healthy projects progress through a monotonically increasing and predictable plan.  Quality management  Incremental demonstrable results Testing needs to be a first class, full lifecycle activity. ○ As opposed to a subordinate, later lifecycle activity.

18

19 MOST IMPORTANT  You do well what you enjoy doing  You want to smile on your way to work  Is it a job or a career?

20 When considering a job…  A large company may have a “culture” BUT your experience will depend on your manager  To learn what it is like, talk to peers -- not bosses  Look around environment, behavior, parking lot  Do they cherish learning?

21 The Need for Life-Long Learning Did You Know Original Did You Know 4.0


Download ppt "8 December 2010. Logistics  Sitterson 014 at 8 am Tuesday, Dec 14  Inviting all clients  Schedule will depend on client constraints (email once booked)"

Similar presentations


Ads by Google