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”
© 1993 - 2013 Scrum.org, All Rights Reserved
Scrum explained: Roles
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
© 1993 - 2013 Scrum.org, All Rights Reserved
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/
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/
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
Management by walking around
● Round 1 evaluation– How many steps did you take?
– How did you feel? Managers? Workers?
Management by walking around
● Round 2– No more pairs
– Goal: Take 60 steps
– Each person counts his own steps
– You get again 60 seconds
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
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
DBATestingDevelopmentAnalysisOperations
DBATestingDevelopmentAnalysisOperations
DBATestingDevelopmentAnalysisOperations
DBATestingDevelopmentAnalysisOperations
DBA
Testing
DevelopmentTesting
Analysis
Operations
TEAM 1 TEAM 2
Testing
DevelopmentTesting
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: 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 …So that ….
As a …I want to …So that ….
3
1
0
8
13
●
●
●
Scrum explained: Cone of Uncertainty
www.construx.comInitial EstimateProduct Backlog
Item Estimate
Sprint BacklogItem Estimate
Scrum explained: Waterfall vs. Scrum
Req
uire
men
ts
BD
UF
Dev
elop
men
t
Test
ing
Don
e
Req
uire
men
ts
BD
UF
Dev
elop
men
t
Test
ing
Don
e
Req
uire
men
ts
BD
UF
Dev
elop
men
t
Test
ing
Don
e
Req
uire
men
ts
BD
UF
Dev
elop
men
t
Test
ing
Don
e
Req
uire
men
ts
BD
UF
Dev
elop
men
t
Scrum explained: Waterfall vs. Scrum
DONE
DONE
DONE
DONE
DONE
● Done is Live
● Collaboration
● Communication
● Requirements, Design, Development, Testing
– All done in parallel, during Sprint
Scrum explained: Waterfall vs. Scrum
Visibility Ability to Change
Business Value Risk
Waterfall Scrum
© 1993 - 2013 Scrum.org, All Rights Reserved
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 assessmentshttp://www.scrum.org/Assessments/Open-Assessments
● Practice, practice, practice
● And practice
● Follow the rules, no exception.
© 1993 - 2013 Scrum.org, All Rights Reserved
Scrum.org courses
Professional Scrum
Product Owner
Professional Scrum Foundations
Professional Scrum Master
Professional Scrum
Developer.NET | Java
Product OwnersExecutives Scrum Masters
ArchitectsBusiness Analysts
DB SpecialistsDesigners
DevelopersTesters
Everyone
© 1993 - 2013 Scrum.org, All Rights Reserved
Scrum.org coursesCourses 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
– ...
Time for ….
Agile Testing
● Quadrants
Acceptance TestingFunctional TestsIntegration Tests
Exploratory TestingScenario TestingUsability Testing
Test by End User (UAT)
Unit TestModule Tests
Component Tests
Performance & Load TestingSecurity Testing
*ility Testing
Technology Facing
Business Facing
Automated
Automated Manual
Manual?
© 1993 - 2013 Scrum.org, All Rights Reserved
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
ServiceUnit
Unit
UI
Service
Unit
UI
Service
Unit
UI
Service
Unit
How do your curre
nt tests lo
ok like? Explain.
TDD (Test Driven Development)
● TDD Cycle
Write Test Watch Test Fail
Write simplestcode
Run all tests
Refactor
Run all tests
Idea?
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
TDD (Test Driven Development)
● F.I.R.S.T.– Fast
Tests should be fast.
– IndependentTests should not depend on each other.
– RepeatableTests should be repeatable in any environment.
– Self-ValidatingTests should have a boolean output (pass or fail).
– TimelyTests should be written before the production code.
Robert C. Martin
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/
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/
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/
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: “1\n2,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/
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/
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/
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/
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/
Kata String Calculator (10 min.)
Part 4: Review● Who wants to show the result?
http://osherove.com/tdd-kata-1/
Agile Testing: Code Coverage
What does this mean?
Agile Testing: Tools
Time for ….
Time for ….
Pair Programming
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
Time for ….
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 knifehttp://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.)
● Who wants to show the result?
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.)
● Who wants to show the result?
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!
Clean Code: Technical debt
Broken window Phenomena
Clean Code: Technical debt
● Technical debt = Defects, complexity, coupled code, lack of testing, duplication, …
● Do NOT let it grow!
Value
Technicaldebt
Clean Code: SOLIDSRP (Single Responsibility Principle)
DB
Customer
PersistenceSystem
DB
Customer
Enterprise Java Beans 1/2 Java Persistence API
Clean Code: SOLIDOCP (Open Close Principle)
http://lostechies.com
● Open for Extension● Closed for
Modification
Clean Code: SOLIDLSP (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: SOLIDISP (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: SOLIDDIP (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”
Time for ….
Continuous Delivery
Row 1 Row 2 Row 3 Row 40
2
4
6
8
10
12
Column 1Column 2Column 3
Source Control
Automated build
Continuous integration
Automated Testing
Automated Deployments
Continuous Delivery
Automated Provisioning
Continuous Delivery
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 DeliveryTime to Market
Continuous DeliveryCost Reduction
Continuous DeliveryBuilding Blocks
Videos: www.cleancoders.com
Videos: Dan PinkThe surprising truth about what motivates us
Videos: Pentagon wars
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
Books
Books
Books
Books
Top Related