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


● 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

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


● 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

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




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: 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 ….















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


DONE

DONE

DONE

DONE

DONE

● Done is Live

● Collaboration

● Communication

● Requirements, Design, Development, Testing

– All done in parallel, during Sprint


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 assessmentshttp://www.scrum.org/Assessments/Open-Assessments

● Practice, practice, practice

● And practice

● Follow the rules, no exception.


http://www.scrum.org/Assessments/Open-Assessments

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


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?


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?


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

– 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


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: “1\n2,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?

Agile Testing: Tools

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

http://en.wikipedia.org/wiki/Broken_windows_theory

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

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

https://github.com/jdewinne/PSDExamples

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

https://github.com/jdewinne/PSDExamples

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!


Broken window Phenomena


● 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

http://lostechies.com/

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.

http://javiernavarromachuca.blogspot.nl/2011/07/interface-segregation-principle.html

Clean Code: SOLIDDIP (Dependency Inversion Principle)


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

https://www.cleancoders.com/promotions/the_business_case

Videos: Dan PinkThe surprising truth about what motivates us

http://youtu.be/u6XAPnuFjJc

Videos: Pentagon wars

http://youtu.be/aXQ2lO3ieBA

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