Introduction to the official PSD for Java training from scrum.org. It doesn't cover all topics from the official curriculum, and serves as a intro and teaser to actually follow the official training.
12. Scrum explained: Events
● Sprint Review
– Inspect the increment and adapt Product Backlog
– Invite stakeholders
– Timeboxed: 4 hours for 4 week sprint
● Sprint Retrospective
– Opportunity to inspect how we are working and to
adapt
– For the Scrum Team
– Timeboxed: 3 hours for 4 week sprint
http://davidemanske.com/wp-content/uploads/2013/06/SpeedBoatRetrospective-300x128.png
http://www.flickr.com/photos/92328289@N02/
13. Scrum explained: Events
● Sprint
– The heart of Scrum
– Timeboxed: Max one month.
– Delivers a “Done”, useable and potentially
releasable product increment
– Contains all the other events
http://www.flickr.com/photos/gareth_price/
14. Scrum Explained: Artifacts
● Product Backlog
– Ordered list
– Never complete
– Contains PBI's
– Product Owner is responsible
● Sprint Backlog
– Set of Product Backlog Items
– Plan for delivering Product Increment
– Contains Sprint Goal
● Increment
– Sum of all PBI's done during a Sprint
15. Management by walking around
● Round 1
– Pair up: one person will be manager, other the worker
– Simulation: shopping mall traffic, by walking from one
shop to another
– Goal: Take 60 steps
– Instructions:
● Go 1 step forward
● Turn 1 step left
● Turn 1 step right
● Stop
– Manager counts the number of steps
– You get 60 seconds
16. Management by walking around
● Round 1 evaluation
– How many steps did you take?
– How did you feel? Managers? Workers?
17. Management by walking around
● Round 2
– No more pairs
– Goal: Take 60 steps
– Each person counts his own steps
– You get again 60 seconds
18. Management by walking around
● Round 2 evaluation
– How many steps?
– How did you feel?
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Fugle,_%C3%B8rns%C3%B8_073.jpg/250px-Fugle,_%C3%B8rns%C3%B8_073.jpg
19. Scrum explained: self organizing
● No one (not even the Scrum Master) tells the Development
Team how to turn Product Backlog into Increments of
potentially releasable functionality.
● The Development Team self-organizes to undertake the
work in the Sprint Backlog, both during the Sprint Planning
Meeting and as needed throughout the Sprint.
● Self-organizing teams choose how best to accomplish their
work, rather than being directed by others outside the
team.
20. Scrum explained: self organizing
Old style Scrum
Team lead assigns tasks Development figures it out ;-)
No such thing as people working together Pair programming
All communication is done through team
lead
Direct communication between developers
Weekly status meeting, reporting to
manager
Daily Scrum
Team lead is responsible The whole Scrum Team is responsible,
including ALL developers.
21. Scrum explained: transparency,
inspect & adapt
● Pillars of empirical process control
– Transparency: be realistic, no hidden stuff
– Inspection: Look back, measure stuff
– Adaption: Be open for changes!
● You can NOT predict the future
22. Scrum explained: transparency,
inspect & adapt
Cirkel van Deming
PlanPlan
Inspect
Do
Goal
• Constantly improve
• Deliver faster
• Deliver more efficient
• Deliver with higher quality
Act
23. Scrum explained: Cross functional
DBA
Testing
Development
Analysis
Operations
DBA
Testing
Development
Analysis
Operations
DBA
Testing
Development
Analysis
Operations
DBA
Testing
Development
Analysis
Operations
DBA
Testing
Development
Testing
Analysis
Operations
TEAM 1 TEAM 2
Testing
Development
Testing
TEAM 3 TEAM 4
Analysis
Testing
Analysis
24. Scrum explained: DoD
“Done”: Means a PBI is
potentially shippable.
Definition of Done (DoD)
● Checklist
● Visible
● Inspected & adapted
25. Scrum explained: DoD (5min.)
● Answer the following questions:
– What is your Definition of Done?
– Who owns the Definition of Done?
– Who or what influences it and how?
26. Scrum explained: DoD (5min.)
● Answer the following questions:
– What is your Definition of Done?
– Who owns the Definition of Done?
– Who or what influences it and how?
28. Scrum explained: Estimation
● How?
– In group!
– Discussion & Conversation is most important.
– Relative to other things
● Hours???
– Parkinson's law: When an item is finished earlier, the
developer will fill remaining time.
– Ideal or working hours?
Example: Why 16 hours and not 15?
29. Scrum explained: Poker planning
http://wendysdogwalking.co.uk/wp-content/uploads/2013/04/dog-on-sofa-300x225.jpg
30. Scrum explained: Backlog
refinement
● aka Grooming
● Refine PBI's
– Clear and understood
– Estimated
– Broken down in small enough items
– Have acceptance criteria
Product Owner
+
Development Team
During EACH Sprint
Timeboxed
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
So that ….
As a …
I want to …
As a …
I want to …
So that ….
3
1
0
8
13
●
●
●
32. Scrum explained: Waterfall vs.
Scrum
Requirements
BDUF
Development
Testing
Done
Requirements
BDUF
Development
Testing
Done
Requirements
BDUF
Development
Testing
Done
Requirements
BDUF
Development
Testing
Done
Requirements
BDUF
Development
33. Scrum explained: Waterfall vs.
Scrum
D
O
N
E
D
O
N
E
D
O
N
E
D
O
N
E
DO
N
E
● Done is Live
● Collaboration
● Communication
● Requirements, Design, Development, Testing
– All done in parallel, during Sprint
38. Scrum.org courses
Courses Public and private courses are offered worldwide Assessments Certification
Professional Scrum
Foundations
Hands-on training for people
looking to start Scrum or reboot
a struggling implementation.
Professional Scrum
Master
In-depth training for Scrum
Masters and experienced
practitioners needing more
advanced instruction.
Professional Scrum
Product Owner
Teaches people how to
maximize ROI, and optimize the
Total Cost of Ownership of
products and systems.
Professional Scrum
Developer
Students work as part of a
self-organizing team to learn
how to use ALM tools and
Software development best
practices in Scrum.
Certification
only granted
to those that
achieve a
passing score
on the
associated
assessment
39. Scrum.org vs Scrum Alliance
● Scrum.org
– Assessments have more value.
– Each course is the same (doesn't depend on the
trainer)
– Open for feedback and improvements
– Home of Scrum!
● Scrum alliance
– Easier to get certified
– ...
42. Agile Testing
● Test Pyramids Mike Cohn, Succeeding with Agile
UI
Service
Unit
● Not executed frequently
● Take long time to execute
● Executed frequently
● Take short time to execute
43. Agile Testing (5min.)
● What is wrong with the following?
UI
Service
Service
Unit
Unit
UI
Service
Unit
UI
Service
Unit
UI
Service
Unit
How
do your current tests look like? Explain.
44. TDD (Test Driven Development)
● TDD Cycle
Write Test Watch Test
Fail
Write simplest
code
Run all tests
Refactor
Run all tests
Idea?
45. TDD (Test Driven Development)
● Three Laws of TDD
– First: You may not write production code until you have written
a failing unit test.
– Second: You may not write more of a unit test than is sufficient
to fail, and not compiling is failing.
– Third: You may not write more production code than is
sufficient to pass the currently failing test.
● Keep test clean!
● One Assert per Test.
● Single Concept per Test.
Robert C. Martin
46. TDD (Test Driven Development)
● F.I.R.S.T.
– Fast
Tests should be fast.
– Independent
Tests should not depend on each other.
– Repeatable
Tests should be repeatable in any environment.
– Self-Validating
Tests should have a boolean output (pass or fail).
– Timely
Tests should be written before the production code.
Robert C. Martin
47. TDD (Test Driven Development)
Kata String Calculator
● Before you start:
– Try not to read ahead.
– Do one task at a time. The trick is to learn to work
incrementally.
– Make sure you only test for correct inputs. there is
no need to test for invalid inputs for this kata
http://osherove.com/tdd-kata-1/
48. Kata String Calculator (10min.)
Part 1
● Create a simple String calculator with a method
int Add(string numbers)
– The method can take 0, 1 or 2 numbers, and will return their sum
(for an empty string it will return 0) for example “” or “1” or “1,2”
– Start with the simplest test case of an empty string and move to
1 and two numbers
– Remember to solve things as simply as possible so that you
force yourself to write tests you did not think about
– Remember to refactor after each passing test
http://osherove.com/tdd-kata-1/
49. Kata String Calculator (2 min.)
Part 1: Review
● Who has written first a test, before writing the
Calculator class?
● How many tests do you have now?
● How many times did you run the test?
● How many times did you refactor your code?
http://osherove.com/tdd-kata-1/
50. Kata String Calculator (10 min.)
Part 2
● Allow the Add method to handle an unknown
amount of numbers
● Allow the Add method to handle new lines
between numbers (instead of commas).
– the following input is ok: “1n2,3” (will equal 6)
– the following input is NOT ok: “1,n” (not need to
prove it - just clarifying)
http://osherove.com/tdd-kata-1/
51. Kata String Calculator (2 min.)
Part 2: Review
● Who followed TDD Cycle?
● How many tests do you have now?
● Who wrote multiple tests at once?
● What about exceptions?
http://osherove.com/tdd-kata-1/
52. Kata String Calculator (10 min.)
Part 3
● Support different delimiters
– to change a delimiter, the beginning of the string will
contain a separate line that looks like this: “//
[delimiter]n[numbers…]” for example “//;n1;2”
should return three where the default delimiter is ‘;’ .
– the first line is optional. all existing scenarios should
still be supported
http://osherove.com/tdd-kata-1/
53. Kata String Calculator (2 min.)
Part 3: Review
● Who followed TDD Cycle?
● How do the names of your tests look like?
[MethodUnderTest]_[Given]_[Then]?
● How many asserts does one test contain?
http://osherove.com/tdd-kata-1/
54. Kata String Calculator (10 min.)
Part 4:
● Calling Add with a negative number will throw
an exception “negatives not allowed” - and the
negative that was passed. If there are multiple
negatives, show all of them in the exception
message
http://osherove.com/tdd-kata-1/
55. Kata String Calculator (10 min.)
Part 4: Review
● Who wants to show the result?
http://osherove.com/tdd-kata-1/
61. Pair Programming
● Roles
– Driver
– Navigator
● Rules
– Pair on everything you'll need to maintain.
– Allow pairs to form fluidly rather than assigning partners.
– Switch partners when you need a fresh perspective.
– Avoid pairing with the same person for more than a day at a time.
– Sit confortable, side by side.
– Produce code through conversation. Collaborate, don't critique.
– Switch driver and navgator role frequently.
62. Pair Programming
● Advantages
– Higher quality
– Constant knowledge sharing
– Deliver faster
– Faster development
– An extra pair of eyes
– If Bob (the guru) leaves for a round-the-world trip →
He Can!
– If Rob (the junior) joines the company, he gets up to
speed in notime.
64. Clean Code
● Michael Feathers, author of Working Effectively
with Legacy Code
“Clean code always looks like it was written by
someone who cares. There is nothing obvious
that you can do to make it better”
Elegant
Efficient
Straightforward
Simple
Direct
Well written
Meaningfull
Clear
Beautifull
66. Clean Code: Boy Scout Rule
“Leave the campground cleaner
than you found it.”
67. Clean Code: Broken Windows
Theory
The broken windows theory is a criminological theory of the norm-setting and signaling effect of
urban disorder and vandalism on additional crime and anti-social behavior. The theory states
that maintaining and monitoring urban environments in a well-ordered condition may stop further
vandalism and escalation into more serious crime.
http://en.wikipedia.org/wiki/Broken_windows_theory
● Just add another “if”.
● Dirty code invites to add
more smells.
● Growing method length
● Growing class length
● ...
68. Clean Code: How to measure?
● The # tests?
● The # bugs?
● The # duplicated code?
● The # unused code?
● ...
69. Clean Code: How to measure?
http://www.osnews.com/story/19266/WTFs_m
70. Clean Code: Clean Kitchen
3 Michelin sushi chef Saito is a master with the knife
http://youtu.be/robvvJZkfcU
71. Clean Code: Names
● Use meaningful names
● Use intention – revealing names
● Avoid disinformation
● Use pronounceable names
● Avoid encodings
– No Hungarian Notation
– Member prefixes?
● Use solution domain names
● Use problem domain names
● Pick one word per Concept
– No “get”, “retrieve”, “fetch”, ….
72. Clean Code: Names (15min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code: Names.java
74. Clean Code: Functions
● Small!
● Do one thing!
● Reading code from Top to Bottom
The stepdown rule
● Arguments
– No flags
– As less as possible
– Don't use it for returning values
● Have no side effects
– “checkPassword” should not create a session
● Exceptions over Error codes
● DRY
76. Clean Code: Comments
“Don't comment bad code – rewrite it.”
Brian W. Kernighan and P.J. Plaugher
● Explain in code, not in comments
● Redundant comments :-(
● Misleading comments :-(
● Commented out code :-(
● HTML comments :-(
● Too much information (Do not add the whole
specification document)
77. Clean Code: Comments (20 min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code: Comments.java
79. Clean Code: Formatting
● Vertical formatting
– Lines per file.
– Each class should be max 200 lines!
– Vertical openness
● Use some white lines ;-)
– Vertical Density
● Tightly related lines should be close to each other
● Horizontal formatting
– Line length
– Each line should max be 120characters long
– Horizontal Openness and Density
– Indentation
● Team rules!!!!!!!!!
80. Clean Code: Law of Demeter
● A module should not know about the innards of
the objects it manipulates.
customer.getAddress().getBillingAddress().getLine1()
government.getPresident().getJobDescription().setName()
81. Clean Code: Exceptions
● Use exceptions, instead of return codes.
● Use meaningful exceptions
● Don't return null
● Don't pass null
● Write the try / catch / finally first
● Use unchecked exceptions
82. Clean Code: Emergent Architecture
(5min.)
● How does your architecture looks like?
● First design, then implement?
● You think also of the future? And have statements like:
– It must be scalable
– It must be extensible for any feature we can think of
– …
Discuss!
83. Clean Code: Emergent Architecture
● BDUF is waste!
● TDD is design.
● BDD is design.
● Allow your architecture to emerge as you
develop.
● Think in slices (not in layers)
86. Clean Code: Technical debt
● Technical debt = Defects, complexity,
coupled code, lack of testing, duplication, …
● Do NOT let it grow!
Value
Technical
debt
87. Clean Code: SOLID
SRP (Single Responsibility Principle)
DB
Customer
Persistence
System
DB
Customer
Enterprise Java Beans 1/2 Java Persistence API
88. Clean Code: SOLID
OCP (Open Close Principle)
http://lostechies.com
● Open for Extension
● Closed for
Modification
89. Clean Code: SOLID
LSP (Liskov Substitution Principle)
Functions that use pointers
to base classes must be
able to use objects of
derived classes without
knowing it.
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
90. Clean Code: SOLID
ISP (Interface Segregation Principle)
http://javiernavarromachuca.blogspot.nl/2011/07/interface-segregation-principle.html
● One interface per kind of
client.
● No methods in interface that
client does not use.
● No “fat” interfaces.
91. Clean Code: SOLID
DIP (Dependency Inversion Principle)
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
● “High-level modules should
not depend on low-level
modules. Both should
depend on abstractions”
● “Abstractions should not
depend on details. Details
should depend on
abstractions”
95. Continuous Delivery
Deployment Pipeline provides
constant quick feedback
Continuous
Integration
Middleware
Provisioning
Virtualized
Infrastructure
Test ToolingDevelopment
Central
Monitoring &
Logging
Application
Release
Automation
O T A P all identical
On Demand
Environments