Introduction Professional Scrum Developer for Java

Introduction PSD
Professional Scrum Developer Java

Who am I? Who are you?
Name From What would I be if I did not end up in IT?

Rules during the course
● Questions?
– Ask!!!!
– Or put them on the board
● Mobile phones
● Laptops
● Breaks

Course content
1. Introduction
2. Scrum explained
3. Scrum courses
4. Agile Testing & TDD
5. Pair Programming
6. Clean Code
7. Continuous Delivery
8. Tools
9. Books

Scrum explained (5 min.)
● Question:
What is Scrum for you?
● Put in one sentence on a post-it what you think
Scrum is.

Scrum explained
● What are the results? Discuss.

Scrum explained
● Definition:
Scrum is a framework for developing and
sustaining complex products.

Scrum explained: Roles
● Product Owner
– Maximize value of the product
– Manages Product Backlog
– 1 person!
– Prioritizes PBI's
● Scrum Master
– Ensures Scrum is understood & enacted
– Servant leader
– Helps Product Owner, Development Team & Organization
– Applies Scrum theory, practices & rules
© 1993 - 2013 Scrum.org, All Rights Reserved

Scrum explained: Roles
● Development Team
– Professionals
– Self organizing
– Everyone is a developer
– Cross functional
– Self Organizing
● Scrum Team
– Consists of “Development Team”, “Product Owner” and
“Scrum Master”

Scrum explained: Events
● Sprint Planning
– Define work to be performed during the upcoming Sprint.
– Timeboxed: 8 hours for 4 week sprint
– Two parts
● What will we do
● How will we do it
– Sprint Goal
● Daily Scrum
– Daily 15 minute time boxed event
– For the Development Team
– No status meeting

● Sprint Review
– Inspect the increment and adapt Product Backlog
– Invite stakeholders
● Sprint Retrospective
– Opportunity to inspect how we are working and to
adapt
– For the Scrum Team
http://davidemanske.com/wp-content/uploads/2013/06/SpeedBoatRetrospective-300x128.png
http://www.flickr.com/photos/92328289@N02/

● 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/

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

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

● Round 1 evaluation
– How many steps did you take?
– How did you feel? Managers? Workers?

● Round 2
– No more pairs
– Goal: Take 60 steps
– Each person counts his own steps
– You get again 60 seconds

● 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

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.

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.

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

Scrum explained: transparency,
inspect & adapt
Cirkel van Deming
PlanPlan
Inspect
Do
Goal
• Constantly improve
• Deliver faster
• Deliver more efficient
• Deliver with higher quality
Act

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

Scrum explained: DoD
“Done”: Means a PBI is
potentially shippable.
Definition of Done (DoD)
● Checklist
● Visible
● Inspected & adapted

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?

Scrum explained: Estimation
Architect
Team
Customer
When?
During BDUF
Sprint Planning
All the time
How?
Hours
Fibonacci
Beers
...

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?

Scrum explained: Poker planning
http://wendysdogwalking.co.uk/wp-content/uploads/2013/04/dog-on-sofa-300x225.jpg

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
●
●
●

Scrum explained: Cone of
Uncertainty
www.construx.comInitial Estimate
Product Backlog
Item Estimate
Sprint Backlog
Item Estimate

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

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

Scrum
Visibility Ability to Change
Business Value Risk
Waterfall Scrum

Scrum explained: Scope,
Resources, Time and Quality
● Project Management Triangle
QUALITY
SCOPE
TIME
RESOURCES

Scrum explained: Where to start?
● Read the Scrum guide!
● Embrace failure.
● Do some assessments
http://www.scrum.org/Assessments/Open-Assessments
● Practice, practice, practice
● And practice
● Follow the rules, no exception.

Scrum.org courses
Professional
Scrum
Product Owner
Professional Scrum Foundations
Professional
Scrum Master
Professional
Scrum
Developer
.NET | Java
Product Owners
Executives Scrum Masters
Architects
Business Analysts
DB Specialists
Designers
Developers
Testers
Everyone

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

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
– ...

Agile Testing
● Quadrants
Acceptance Testing
Functional Tests
Integration Tests
Exploratory Testing
Scenario Testing
Usability Testing
Test by End User (UAT)
Unit Test
Module Tests
Component Tests
Performance & Load Testing
Security Testing
*ility Testing
Technology Facing
Business Facing
Automated
Automated Manual
Manual?
Brian Marick, http://bit.ly/PrsMY1

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

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.

TDD (Test Driven Development)
● TDD Cycle
Write Test Watch Test
Fail
Write simplest
code
Run all tests
Refactor
Run all tests
Idea?

● 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

● 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

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/

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

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?

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)

Part 2: Review
● Who followed TDD Cycle?
● How many tests do you have now?
● Who wrote multiple tests at once?
● What about exceptions?

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

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?

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

Part 4: Review
● Who wants to show the result?

Agile Testing: Code Coverage
What does this mean?

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.

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.

Pair Programming
● Disadvantages
– Are there?

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

Clean Code: Boy Scout Rule
“Leave the campground cleaner
than you found it.”

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
● ...

Clean Code: How to measure?
● The # tests?
● The # bugs?
● The # duplicated code?
● The # unused code?
● ...

Clean Code: How to measure?
http://www.osnews.com/story/19266/WTFs_m

Clean Code: Clean Kitchen
3 Michelin sushi chef Saito is a master with the knife
http://youtu.be/robvvJZkfcU

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”, ….

Clean Code: Names (15min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code: Names.java

Clean Code: Names (10min.)

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

Clean Code: Functions
Any comments?

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)

Clean Code: Comments (20 min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code: Comments.java

Clean Code: Comments (10min.)

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!!!!!!!!!

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()

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

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!

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)

Clean Code: Technical debt
Code Rots
in Presence
of Change!

Broken
window
Phenomena

● Technical debt = Defects, complexity,
coupled code, lack of testing, duplication, …
● Do NOT let it grow!
Value
Technical
debt

Clean Code: SOLID
SRP (Single Responsibility Principle)
DB
Customer
Persistence
System
DB
Customer
Enterprise Java Beans 1/2 Java Persistence API

Clean Code: SOLID
OCP (Open Close Principle)
http://lostechies.com
● Open for Extension
● Closed for
Modification

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/

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.

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”

Continuous Delivery
Row 1 Row 2 Row 3 Row 4
0
2
4
6
8
10
12
Column 1
Column 2
Column 3
Source Control
Automated
build
Continuous
integration
Automated
Testing
Automated
Deployments
Continuous
Delivery
Automated
Provisioning

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

Continuous Delivery
Time to Market

Continuous Delivery
Cost Reduction

Continuous Delivery
Building Blocks

Videos: Dan Pink
The surprising truth about what motivates us

Tools
●
Management: Jira, Trello, Excel
●
Continuous Integration: Jenkins, Bamboo, Hudson
●
Testing: JUnit, FitNesse, Cucumber, DBUnit, TestNG, Greenpepper, Jbehave,
Jacoco, Arquillian, ...
● Automated Deployment: Deployit, Nolio, uDeploy
● Collaboration: Confluence, xWiki
● Automated Provisioning: Puppet, Chef, Vagrant, MCollective
●
Quality: Sonar
●
Build tools: ant, ivy, maven, gradle
●
Source safety: subversion, git
●
Cloud solutions
– Continuous Integration: Cloudbees
– Public PAAS: Heroku, OpenShift
– Issue Management: Atlassian (Jira), Trello
– Don't forget Amazon

Introduction Professional Scrum Developer for Java

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Introduction Professional Scrum Developer for Java

Similaire à Introduction Professional Scrum Developer for Java (20)

Dernier

Dernier (20)

Introduction Professional Scrum Developer for Java