Agile Principles and PracticesAnd how they work together

Vipin Jose

* First Developer usually gets the opportunity to set some of the foundational design and standards

Java Developer since 2006

5 greenfield projects where each > 1 year

First developer* in 4

2 high stakes (most recent)

1 truly agile (current)

Expectations

Flexible enough to accommodate any change Quick turn around time

The source is of high quality if the software development process can achieve these.

Main attributes the business expects from its software development process

Without the right processes in place. Software development is like stacking the bricks without using mortar.

Find SMEs in stacking bricks,

keep them happy

Buy specialized tools to stack bricks

Hold regular meetings to find

the best way to stack bricksIntroduce standard operating

procedures to stack bricksThe bricks are stacked, now don’t touch

it!

It is possible…

… but fundamentally flawed

Just use mortar!!

The Right Mix for Mortar SOLID Design Principles Automated Test Cases First Continuous Integration / Continuous Deployment Design Only for Requirement Short Sprints, Short stories Pair Programming Constant Code Refactoring Constant Culture Building

All are required to make the right mix.

SOLID Design Principles Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle

Single Responsibility Might sound too subjective.

E.g.

DAO

Good ways to determine:- Test Cases- Cyclomatic Complexity

Responsible for CRUD operations

Responsible for Creating and Reading and Updating and Deleting

Too much responsibility?

Test Cases Can you write all possible test cases before implementing the class?

Can you identify all the scenarios just by reading the test code? How about 6 months later?

Can you guarantee that a change you introduced in the class has not broken any of its prior responsibilities? Even if you are not the one who created it?

Cyclomatic ComplexityCyclomatic Complexity = Decision Points + 1

Complexity Assessment1-10 not much risk11-20 moderate risk21-50 high risk51+ untestable, very high risk

Cyclomatic ComplexityIf a class is an element and cyclomatic complexity is its atomic number

Be In the Carbon-Nitrogen-Oxygen range

Carbon | Nitrogen | Oxygen Boron Fluoride

Hmmm… OK

Less Stable, Less

Testable

Cyclomatic Complexity Too many classes?

Use sub-modules and apply SOLID to them (OSGI specification) E.g: Netbeans RCP, Java Jigsaw

Time to break the project into smaller ones

Automated Test Cases Types

Unit Test Cases System Test Cases Integration Test Cases Performance Test Cases

Automated Test Cases Result

Functional Requirements of the System and Responsibilities of the Class are documented and the developer does not need to remember every minute detail.

Fearless coding: “Looks like this code is useless and debt causing. Let me remove it … … Oh! 5 valid test cases failed. Let me refactor this.

Advantage Project will pass the Lottery (Bus) Test Developer can focus on technical tasks and finding the right solution to each micro

requirement Knowledge Transfer time decreases and lesser risk of information getting lost in

translation

Unit Test Cases Write the test cases first

In most cases, a class can be one of the following two types: Manager:

Orchestrates the flow and delegates responsibility to other classes Test by mocking the classes and verifying they are called the right number of times (and

with correct parameters) in different scenarios. Worker:

Holds the data manipulating logic – Calculation, Transformation etc. Test by using real data that represents the input and the expected output for each

scenario.

Mixing the two usually complicates the test class

System Test Cases Behavioral Test Cases

Black box testing: test code should not share resources with main code. Can be run from developer environment Gherkin Scenarios And Cucumber: Given/When/Then Mock the external services: WireMock Embed the database. CassandraUnit.

Gherkin Scenarios or Unit Test Cases or Both?

Project is really big and many classes are involved in a single flow Have both levels of testing

Ease in maintenance, Quick Turn Around Time

Integration & Performance Test Cases

Similar to system test cases but with real endpoints

Probable steps in automation:Spawn the environment

Install latest production version of dependent services Run tests on subject service

Destroy the environment

Continuous Integration and Deployment

Git Virtual Machines running the automated test cases on every merge to

develop/master

Design Only for the Requirement

“No, but we’ll need it, in future” is not enough justification: No guarantee that future requirement will directly fit into your design. Your previous effort, of

introducing the design, may be useless. Hard to cover it in behavioral testing as there is not requirement right now Risk. Automated test cases allow a design change any time. Even major refactoring.

Q: “Is there a requirement for this design?”

No design document: Needless overheardCode Fluid Change Constant

Inline Documentation and self code walkthrough

Short Sprint, Short Stories Story Grooming:

No story commitments per sprint. Does not compromise quality in fear of deadline.

Feature / Change Request

Use Case 1

Story 11 Gherkin Scenario

Use Case 2

Story 21 Gherkin Scenario

Use Case 3

Story 31 Gherkin Scenario

Pair Programming Keeps you alert and focused Immediate code review minimizes errors Immediate design brainstorming minimizes technical debt

Constant Rotation of Pairs and Stories

Feature 1 Feature 2 Interrupt Pair Story Grooming

Monday Story 1Dev1 Dev2

Story 1

Dev3 Dev4 Dev5 Dev6 Dev7 Dev8

TuesdayDev1 Dev8 Dev6 Dev4 Dev7 Dev5 Dev3 Dev2

WednesdayStory 2 Dev1 Dev5 Dev7 Dev4 Dev3 Dev2 Dev6 Dev8

Thursday Story 3Dev8 Dev5

Story 2Dev6 Dev4 Dev1 Dev7 Dev2 Dev3

FridayDev1 Dev5 Dev6 Dev2 Dev3 Dev8 Dev7 Dev4

Make it Work. Then, Make it Right. Functional Correctness is the only Acceptance Criteria, not design.

Detailed Gherkin Test Case created in story grooming.

Test case passed = ready for merge.

Lead only needs to review correctness of behavioral test code during merge

Design may not be the best but that’s OK.

Design eventually gets corrected as opinions are consolidated. When different developers work on other scenarios involving the same code.

Proactive reviews by the whole team

Best design achieved faster Lesser effort in

refactoring

Constant Code Refactoring

Remove Technical Debt Remove Spaghetti Code Review and Correct the Design in Every Scenario Sonar in CI/CD

Constant Culture Building Daily standup meetings

The story will be complete by tomorrow. The code will have maximum test coverage.

We should avoid refactoring the code. We should write test case for the missed scenario.

Decide upon the rules of engagement before start. Rules return the desired results, guidelines do not

Make this presentation at the beginning of the project.

Production Support: motivator for code ownership