UML Distilled by Martin Fowler et all

Rating: Concise. Worth returning to.

Finally, there is a book about UML written by a practitioner for practitioners. It even has code samples that make sense. Nice.

The only complaint I have at the moment is the amount of forewords and prefaces: 10 pages for a book that has 159 pages of content.

All right, so what did I get out of this book?

1. Use '''UML as sketch''' to help communicate design ideas.
2. Everything in UML is optional, so when reading a diagram do no make assumptions based on something not being present.
3. It is ok to use non-standard notations, if they are better known, or simpler - be pragmatic - the goal is for your audience to understand your design.
4. There are also useful, non-UML diagrams, like the screen flow diagram, and the decision table.
5. It is very difficult to get UML right before coding, therefore using UML as blueprint in forward engineering may not be efficient.

This book should be read twice and should be kept around for reference.

Scrum and XP from the Trenches by Henrik Kniberg

Rating: Very interesting.

I've read this one initially at the end of 2006. Lots of interesting,
real-life observations.

Scrum Concepts:

• velocity (aka actual velocity) - the sum of all initial estimates of story points, for stories completed in one sprint,
• estimated velocity -  the sum of all initial estimates of story points, for all stories planned for one sprint,
• external vs internal quality (visible to the user or not)
• yesterday's weather - look back several sprints and average out the estimates
• taskboard - index cards for stories, and post-it notes for tasks on a wall, grouped into: not checked out (stories and tasks), checked out (tasks), done (stories and tasks), unplanned items, next (stories), aka: sprint goal, burndown chart
• seat the team together for audibility, visibility, isolation:  
• audibility - any team member should be able to talk to any other team member without shouting or leaving his/her desk
• visibility - any team member should be able to see any other team member and the taskboard without leaving his/her desk
• isolation - the team does not disturb anyone else, and nobody disturbs the team
• "knowledge bridge" person - a person attending all retrospectives
• insert a lab day between sprints - page 74
• acceptance thresholds - for release planning and fixed price contracts
• all-hands pulse meeting - weekly, 15 minutes, the teams share information about what they are doing
• the firefighting team - a temporary team that protects scrum teams from interruptions by fixing bugs, or finishing old business

Code Branching Tips:
 * trunk should always build
 * tag each release
 * when in doubt, do not branch
 * synchronize often

XP Concepts:
 * pair programming
 * test-driven development
 * incremental design
 * continuous integration
 * collective code ownership
 * informative workspace
 * coding standard
 * sustainable pace / energized work


Interesting observations:

• for keeping product backlog, the product owners preferred shared Excel file to a bug tracking system, because the Excel file required fewer clicks
• internal quality should not be negotiable
• 3 week sprints worked best
• a meaningful sprint goal is important to keep the team focused
• sprint backlog is initially defined as a list of stories from product backlog, not tasks; later in chapter 6, the associated tasks are shown on the taskboard
• product backlog has the following pieces of information: ID, name, importance, initial estimate, how to demo, and notes - all are printed on cards for the planning meeting
• tasks estimated in story points (ideal days), down to 0.5
• demo of a technical story does not have to be a demo on a computer, it can be a piece of paper showing test results - page 66
• code review is an OK alternative to pair programming
• most teams do not include acceptance testing in the sprint, because it cannot be time-boxed

Quotes:

"TDD is hard, but trying to do TDD on a code base that wasn't built using TDD from start... that's really hard! [...] Lesson learned: If you are stuck with having to do manual regression testing, and want to automate this away, don't (unless it is really easy). Instead, build stuff that makes manual regression testing easier. Then consider automating the actual testing."

Tools/frameworks mentioned in context of TDD:
jUnit, httpUnit, TestNG, Selenium, HSQLDB, Cobertura, Spring

Agile Project Management with Scrum by Ken Schwaber

Rating: Intended for Scrum masters.

 

Quick comments:
A bit academic. Dedicated to Scrum masters, not developers. For Scrum essentials go to Appendix A: Rules.

 

:-) Funny bits:

 

"It is possible to have simple software requirements. A single customer who is the only person who will use the system can spend enough time with the developer that the two can agree exactly what to build. Assuming that this customer '''dies immediately [...]'''"

 

"You notice that the commissioner gets increasingly agitated during your presentation, tapping his feet, '''spitting at the floor''', and uttering muffled expletives. He appears to be very unhappy." - page 78.

 

Concepts:
empirical process control (visibility, inspection, adaptation) vs defined process control, stakeholders, complexity assessment graph, scrum skeleton, product backlog (sprint stories [0.5-n days]), Scrum
roles (product owner, the team, Scrum master), sprint, planning meeting, sprint backlog (sprint tasks [4-16 hours]), daily Scrum, sprint review meeting, sprint retrospective meeting, burn-down chart, adjustment (complexity) factor, the art of the possible, self-organizing team, time-boxing, incremental delivery, sashimi,
sprint goal, changes report, product backlog burndown report, suboptimal measurement, scaled project, daily scrum of scrums, staging.

 

Bottom line for us, the developers:
Scrum is about letting the team estimate the work (stories) initially, divide them into tasks, assign within the team, estimate work left to do every day, and present results every 30 calendar days (sprint). Scrum is about product owners defining, prioritizing, and providing feedback on the work. Scrum allows product owners to see in great detail how the work is progressing daily, and change course if necessary.

 

Quotes:

 

"The process of developing functionality includes: analysis, design, coding, testing and documentation."

 

"During this training, I emphasized that '''Scrum Masters have no authority over the development teams'''; they are present only to ensure that the Scrum process is adhered to and that the teams' needs are met." - page 103.

 

Interesting observations/Criticism:

• testers are not part of the team at MegaBank, QA starts at the end of every sprint - page 72, however, in other cases, they are part of the team
• there is a special, 2 week, release sprint at MegaEnergy - page 91
• the definitions and index do not include velocity which is an important scrum concept