agile principles and practices
Post on 19-Mar-2017
133 Views
Preview:
TRANSCRIPT
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
top related