More Related Content
What's hot (20)
Viewers also liked (14)
Similar to Agile principles and practices (20)
Recently uploaded (20)
Agile principles and practices
- 1. Agile Principles and Practices And how they work together Vipin Jose
- 2. * 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)
- 3. 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
- 4. Without the right processes in place. Software development is like stacking the bricks without using mortar. The bricks are stacked, now don’t touch it! It is possible… … but fundamentally flawed Just use mortar!!
- 5. 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.
- 6. SOLID Design Principles Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
- 7. 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?
- 8. 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?
- 9. Cyclomatic Complexity Cyclomatic Complexity = Decision Points + 1 Complexity Assessment 1-10 not much risk 11-20 moderate risk 21-50 high risk 51+ untestable, very high risk
- 10. Cyclomatic Complexity If a class is an element and cyclomatic complexity is its atomic number Be In the Carbon-Nitrogen-Oxygen range Carbon | Nitrogen | OxygenBoron Fluoride Hmmm… OK Less Stable, Less Testable
- 11. 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
- 12. Automated Test Cases Types Unit Test Cases System Test Cases Integration Test Cases Performance Test Cases
- 13. 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
- 14. 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
- 15. 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.
- 16. 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
- 17. 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
- 18. Continuous Integration and Deployment Git Virtual Machines running the automated test cases on every merge to develop/master
- 19. 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 overheard Code Fluid Change Constant Inline Documentation and self code walkthrough
- 20. 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 1 1 Gherkin Scenario Use Case 2 Story 2 1 Gherkin Scenario Use Case 3 Story 3 1 Gherkin Scenario
- 21. Pair Programming Keeps you alert and focused Immediate code review minimizes errors Immediate design brainstorming minimizes technical debt
- 22. Constant Rotation of Pairs and Stories Feature 1 Feature 2 Interrupt Pair Story Grooming Monday Story 1 Dev1 Dev2 Story 1 Dev3 Dev4 Dev5 Dev6 Dev7 Dev8 Tuesday Dev1 Dev8 Dev6 Dev4 Dev7 Dev5 Dev3 Dev2 Wednesday Story 2 Dev1 Dev5 Dev7 Dev4 Dev3 Dev2 Dev6 Dev8 Thursday Story 3 Dev8 Dev5 Story 2 Dev6 Dev4 Dev1 Dev7 Dev2 Dev3 Friday Dev1 Dev5 Dev6 Dev2 Dev3 Dev8 Dev7 Dev4
- 23. 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
- 24. Constant Code Refactoring Remove Technical Debt Remove Spaghetti Code Review and Correct the Design in Every Scenario Sonar in CI/CD
- 25. 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