1 / 28

Pragmatic Projects

Pragmatic Projects. Prepared by Doug Glidden. Pragmatic Projects. Pragmatic Teams Ubiquitous Automation Ruthless Testing It’s All Writing Great Expectations Pride and Prejudice. Pragmatic Teams. No Broken Windows Quality is the responsibility of the whole team

erno
Download Presentation

Pragmatic Projects

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. Pragmatic Projects Prepared by Doug Glidden

  2. Pragmatic Projects • Pragmatic Teams • Ubiquitous Automation • Ruthless Testing • It’s All Writing • Great Expectations • Pride and Prejudice

  3. Pragmatic Teams • No Broken Windows • Quality is the responsibility of the whole team • No “team quality officers”

  4. Pragmatic Teams • No Broken Windows • Boiled Frogs • Don’t assume someone else is handling it • Don’t assume changes have been okayed by leadership • Appoint a “chief water tester” to constantly keep track of scope changes

  5. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Communicate within the team, of course • Don’t forget the outside world! • Generate a brand • Crazy team name • Funny team logo

  6. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Communicate • Appoint a “team librarian” • Coordinates documentation and repositories • Knows who knows • Can spot duplication • Appoint “focal point” persons, each with a complete understanding of one component or aspect

  7. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Project activities can’t happen in isolation • Organize around functionality, not job functions. • Organize teams like code: use contracts, decoupling, and orthogonality • Select technical and administrative heads over all teams on a project

  8. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Automation • Code formatting • Test runs • Appoint “tool builders” to create automation tools

  9. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Automation • Know When to Stop Adding Paint • Allow individual innovation • Provide supportive, but not overpowering, structure

  10. Ubiquitous Automation • All on Automatic • Don’t use manual procedures. • Use scripts or batches • Schedule nightly unattended tasks

  11. Ubiquitous Automation • All on Automatic • Compiling the Project • Use makefiles • Generate code • Use regression tests • Automate builds • Run full build process nightly to ensure all steps continue to operate correctly • Run all tests after each build is complete to identify problems as soon as possible • Automate final build • Automate parameter changes • Rerun all tests

  12. Ubiquitous Automation • All on Automatic • Compiling the Project • Automatic Administrivia • Use content-driven automation for administrative tasks • Automate web site generation by pulling information from the repository nightly • Automate approval procedure notifications using markers within the source

  13. Ubiquitous Automation • All on Automatic • Compiling the Project • Automatic Administrivia • The Cobbler’s Children • Use the tools available to you!

  14. Ruthless Testing • Test early. Test often. Test automatically. • Coding ain’t done ’til all the tests run.

  15. Ruthless Testing • What to Test • Unit testing • Integration testing • Validation and verification • Resource exhaustion, errors, and recovery • Check normal things like memory and disk space • Check unusual things like video modes and bandwidth restrictions • Ensure graceful failures • Performance testing • Usability testing

  16. Ruthless Testing • What to Test • How to Test • Regression testing compares test output with previous tests • Types of test data • Real-world data • Synthetic data • Large quantities of data • Boundary conditions • Statistical properties • Exercising GUI systems often requires specialized tools • Testing tests • Cause bugs to ensure they are caught • Use “saboteurs” to test your testing. • Testing thoroughly • Use coverage analysis tools, but don’t expect 100% coverage • Test state coverage, not code coverage.

  17. Ruthless Testing • What to Test • How to Test • When to Test • Test as soon as any production code exists • Test automatically • Running tests • Interpreting results • If a test cannot be run automatically, test regularly on a specified schedule

  18. Ruthless Testing • What to Test • How to Test • When to Test • Tightening the Net • Find bugs once.

  19. It’s All Writing • Treat English as just another programming language. • Build documentation in, don’t bolt it on.

  20. It’s All Writing • Comments in Code • Comments should explain why something is done, not how • Use meaningful variable names • Don’t include unnecessary information • Lists of functions exported • Revision history • Lists of other files used • Filename

  21. It’s All Writing • Comments in Code • Executable Documents • Develop a single authoritative document for specifications that require multiple implementations • Automatically extract data from the controlling document when it is needed

  22. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Follow pragmatic principles even if someone else is writing the documentation

  23. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Print It or Weave It • Web-based documentation that can be kept up-to-date is preferable to printed documentation • Automatically generate different versions needed from a base document

  24. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Print It or Weave It • Markup Languages • Rich markup languages make production of different documentation forms simple

  25. Great Expectations • Gently exceed your users’ expectations.

  26. Great Expectations • Communicating Expectations • Don’t ignore unreasonable expectations • Ensure users understand necessary changes • Impossible expectations • Unnecessarily conservative expectations

  27. Great Expectations • Communicating Expectations • The Extra Mile • Surprise users with extra features, such as tool tips and keyboard shortcuts

  28. Pride and Prejudice • Sign your work.

More Related