210 likes | 385 Views
8 December 2010. Wrap up. Presentations. 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].
E N D
8 December 2010 Wrap up
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]
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
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
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
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)
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
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
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 • But pride of ownership is critical to quality
Software Craftsmanship • Emphasizes coding skills of the developers • Recognition of importance of the individual • Manifesto • Fundamentals • Apprenticeship • Pride in your work • Basis • Pragmatic Programmer (Hunt and Thomas) • Software Craftsmanship (McBreen)
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.
Software Generations (Rational View) 1960s-1980s 1990s-2000s 2005+ 70% Reused Assets 30% Custom 30% Reused Assets 70% Custom Complexity 100% Custom Managed and Measured Process Ad-hoc Repeatable Distributed Systems/Software Professionals Collocated On the Job Training Collocated Software Skills Team Mix of Proprietary and Commercial Not Integrated Commercial Integrated Processes-Tools Proprietary Not Integrated Tools Predictable Unpredictable Predictable Project Performance over budget, over schedule Infrequently on budget, on schedule Frequently on budget, on schedule
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.
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?
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?
The Need for Life-Long Learning Did You Know Original Did You Know 4.0