Describing Alterantive Courses of Action in Use Cases

Title: Describing Alterantive Courses of Action in Use Cases
Type: Rules
Status: final
Version: 2007-08-28
Gist: explain how to model alternative corses in use cases, which can be represtented in purely textual, tabular and grafical fashion. Use case descriptions should provide both an overview and a detailed view. They should clarify for the reader a certain set of scenarios. The use cases context is a set of constants.
Definition: Scenario: one single complete path through the use case
Source: David Gelperin (Modeling Alternative Courses in Detailed Use Cases, LiveSpecs Software, 2003), Tom DeMarco (Structured Analysis and System Specification, Prentice Hall PTR, Upper Saddle River, NJ, 1979), some minor adjustments from my point of view.

R0: The general size rules for use cases apply.

R1: An alternative course of action is either of four types: {Exeption Handler, Required Selection, Optional Action, User-invoked Interrupt}
Exeption Handler: a scenario with an exeption handler does NOT yield a useful business result; in the sense of the use case.
Required Selection: The actor or the system has to select from a number of options and the chosen option determines the next segment of the scenario. the scenario will yield the useful business result in the sense of the use case unless another alternative course says otherwise. It is possible to state "do nothing" as an option, but only if this is not the most frequent option. If it is, use optional actions instead.
Optional Action: some possible segment is included in the scenario. It does yield a useful business result in the sense of the use case.
User-invoked Interrupt: The actor decides to continue with a scenario of a different use case. This other use case has to be described if part of the system. There is NO useful business result in the sense of the use cases (but maybe of the other use case)

R2: There is exactly one sceanrio that represents the most frequent course of events. ' aka main scenario

R3: Each start of a segment of a scenario is associated with a number between 1 and 99. It represents the probability of this segment to occur. The number is the analyst's best guess. Fill it in square brakets.

R4: The sum of all probabilities of a decision point is 100.

R5: Exeption Handlers[text] should begin with "UNLESS". Exeption handlers[graphics] should be signalled by the term "exeption" near the transition between decision and first action of the handler.

R6: Required selection[text] should use IF-THEN-ELSE-clauses. Required Selections[graphics] include an action preceeding the decision, that provides the selection

R7: Optional Actions[text] should use a short and descriptive name in square brackets, placed at the point(s) of insertion into the main scenario. Optional actions[graphics]: same..

R8: User-invoked Interrupts[text] should include an explicit link to the other use case. User-invoked Interrupts[graphics] should make use of "goto" marks

R9: Each use case is supported by real world numbers of its occurence.

Communicating Plans in Agile Development

Name: Communicating Plans in Agile Development
Type: Rules
Status: final
Version: 2007-08-23
Gist: How to communicate a release or iteration plan to team members and to management
Source: Mike Cohn (Agile Estimation and Planning, 2006), my own tested ideas.

R1) You should communicate often, a plan is there to change. This keeps you updating the plan.
R2) You should communicate honestly, you want trust among your team and your bosses.
Note: Agile Planning is about providing real options. Don't get trapped in your own inappropriately communicated release dates.
R3) Make sure communication is two way. It's much easier to get a commitment from everybody if you involve people.
R4) If you're using Gantt charts, try to get away with a plan of milestones only. There may be lots of small milestones between the bigger ones. You may render the plan more readable if you include activity bars between milestones. They should not be connected to the milestones.
Note: remember, the bars are for readability only.
R5) If you're using Gantt charts, don't show a work breakdown structure; do a feature breakdown structure instead. Don't show individual's tasks.
R6) If you're using Gantt charts, show each feature with the lenght of the iteration.
Note: Some tasks relating to the feature will start at the beginning of the iteratioen. The feature will be finished at the end of the iteration, not earlier.
R7) Talk about a due date with a specific degree of confidence or by using a range or both. You may want to use the 50% and 90% confident numbers.
Note: This correctly reflects the degree of uncertainty that is inherent in future.
R8) For communicating or predicting feature burndown, use three numbers: velocity of the most recent iteration, average velocity of the last 8 iterations (or as many as you have, if less), average velocity of the worst 3 iterations.
R9) In reporting or planning test results, use either the number of passed tests (if all tests passed) or the number of failed tests (if at least one has failed).
Note: It does not make sense to report or plan based on failed tests vs.passed tests. In test-driven or even behavior-driven development, a feature is considered finished if and only if all it's tests pass. There's no 'finished to a degree'. You're aiming at zero defects.

12 Tough Questions for Waterfall Projects

Title: 12 Tough Questions for Waterfall Projects
Type: principles
Status: final
Version: 2008-08-22
Gist: to show waterfall projects what they are missing; to show waterfall projects that say they have always been 'agile', that they really have not.
Source: I stole the idea from Tom Gilb's (generic) 12 Tough Questions.

1) why aren't you able to show some useful piece of product after less than 10% of scheduled project time?
2) how do you know that you will hit the scheduled delivery date, at the start of the project?
3) how productive is your team, in terms of features delivered per month? why don't you know?
4) how do you prevent gold-plating before all the necessary features are done?
5) do you know how many defects you have implemented in the latest version of your product? why did you implement those?
6) what if you want to choose between fixed-date and fixed-scope near the end of your schedule?
7) how long does it take you to know wether a change to the system caused ripple effects?
8) how do you know that every feature you deliver is useful by the date of delivery?
9) why aren't you able to deliver a useful system halfway through the project schedule if management wants you?
10) why isn't your team committing to deliver the feature set planned for the project?
11) if the requirements will change anyway, why do you write them down way in advance?
12) do you pay your contractors cash money, even if they have not provided you with a valuable solution to your problem yet?

Humane Interface Design

Title: Humane Interface Design
Type: Principles
Status: final
Version: 2007-08-22
Gist: guiding you in making decisions when designing a user interface.
Source: An article on Shmula on humane interface design. I stole it completely because I like them so much. Did not add anything.

P1) It's not your fault.
P2) Simple things should stay simple.
P3) Fewer choices mean fewer worries.
P4) Your data is sacred.
P5) Your train of thought is sacred.
P6) Good interfaces create good habits.
P7) Modes cause misery.

Do Job Interviews Efficiently

Title: Do Job Interviews Efficiently
Type: Rules
Status: final
Version: 2008-08-22
Gist: selecting people to join your project team in an efficient and fun manner

R1) invite all candidates at once
R2) talk to the group, let the group talk to itself
R3) wait for the silent people to be asked questions by other people
Note: You will need to explain the project only once. You will feel the people you want to be with in a couple of minutes anyway.
You will save time.