Agile engineering practices
- 1. Agile Engineering Practices Mustafa Savasci linkedin.com/mustafasavasci
- 2. Introduction • Mob Pair Programming • Code Review • MVP • Collective Code Ownership • Continous IntegrationDeploymentDelivery • Poker Planning No Estimations • TimeBoxing Velocity BurnDown Charts • Branching Strategies • Technical Debt Management • Coding Standards • Emergent Architecture Design
- 3. Agile • Agile isn't just a set of ceremonies. • It's a cultural and technical philosophy.
- 4. Agile Mindset • Our purpose working high quality software • Continous delivery of valuable software in sustainable pace • Deliver working software frequently • Responding to change • Self Organized Team • Continous attention to design and architecture
- 7. Pair Programming • two programmers work together at one workstation • the driver, writes code • the navigator, reviews each line of code as it is typed in • is Social Skill not suitable for everyone • Cannot force people • Pros & Cons • increase man hour • decrease defects • increase code quality • better diffusion and know-how transfer • reduction in coordination efforts • Define common coding standards • Clash of Egos
- 8. Mob Programming • All team working • at the same time • in the same space • at the same computer • on the same thing • 5 to 15 minutes rotates • Driver : writes the code & not think & listen navigator • Navigator : Tells the driver what to do. • Pair Programming + Code Review + Standup
- 10. Mob Programming
- 11. Mob Programming
- 12. Mob Programming Mob Success • Critical code to create • Production code to fix • Complex problems to analyze/solve • Big refactoring sessions Mob Failures • Repetitive Tasks • Boring Tasks • Long Tests Run
- 13. Code Review Types • Peer Review (online/offline) • Code Inspection • Team Review Advantages • Less defects • Readability • Consistent design • Coding Standarts • Share knowledge • Make for better estimates • Code reviews mentor newer engineers Best Practices • 60 minutes at max • 500 LOC at max • aim to understand every changed line • Don't assume the code works • Commenting matters • Consider how the code will work in production • Check documentation, tests, and build files • Follow up on review comments • Use checklist
- 15. Minimum Viable Product (MVP) • product with just enough features to satisfy early customers, and to provide feedback for future product development • Minimum Releasable Product • MVP ≠ Minimum Releasable Crap
- 16. Minimum Viable Product (MVP)
- 17. Collective Code Ownership • Encourages everyone to contribute new ideas to all segments of the project. • Faster code development, prevent possible bottlenecks • Reduces the risk that the absence (or unavailability) • Is a favorable factor in the diffusion of technical knowledge • Encourages each developer to feel responsible for the quality of the whole • One technical perspective like "Conway's Law"
- 18. Continous Integration • Integrate your code every few hours/days. • Keep your build, tests, automated test and other release infrastructure up to date • Each integration should get as close to a real release as possible. • Compile • Execute unit test • Run automated test • Run static code analysis • Binaries(setups)
- 19. Continous Delivery • is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. • Automated release with one click • Decide to release daily, weekly, fortnightly, or whatever suits your business requirements. • release more often, thus accelerating the feedback loop with your customers
- 20. Continous Deployment • every change that passes all stages of your production pipeline is released to your customers • there's no human intervention, and only a failed test will prevent a new change to be deployed to production. • accelerate the feedback loop with your customers
- 21. Continuous Delivery & Deployment
- 22. Kanban Board Scrum Task Board • Visual Board, All tasks are visible to Team • All Task is transparent to all stakeholders. • Encourage collaboration & conversation • More Interactive and Fun • In Scrum, Dev Team update the board in Daily Scrum meeting • Dev Team can calculate Velocity BurnDown chart and other metrics
- 23. Planning Poker • Estimation for Product Backlog • All Team members estimate the PBI • who gave the high and low estimate justify their reasoning • Planning Poker, Fibonnacci Series, Natural,T-Shirt size
- 24. No Estimation • Slice the user stories thinly • Time-box and prioritize • Update the forecast frequently
- 25. BurnDown Chart • the amount of work that has been completed in iteration, and the total work remaining. • Team use ! • Not a performance report • Trend or indication for Team
- 26. Velocity • indication of the average amount of Product Backlog turned into an Increment of product during a Sprint
- 27. TimeBoxing • allotting a fixed, maximum unit of time for an activity • define and limit the amount of time dedicated to an activity. • Software creative work, don’t have only one solution. • Pros&Cons • Keep focus • Provide prioritization • Increase productivity & efficiency • encourages teams to start getting work done
- 28. Technical Debt Management • Technical debt is the difference between what was promised and what was actually delivered. • Preventing technical debt is what allows development to be agile in the long run.
- 29. Technical Debt • Indicators • The loss of productivity • Increase in testing • Postponed releases • Code duplication • Increase in bugs • Being scared of changing anything • Unreadable code • Decreased velocity • How to Fix • Merciless refactoring • Fast automation • Slow down to go fast • Clean code principles • Clear definition of done • Key engineering practices • Fail Fast (Code Review etc.) • Monitor & Fix constantly • Fix root causes
- 30. Coding Standards are a formalized set of rules and practices that developers can adhere to when writing code which ensures that the code is easily readable, maintainable and extensible and reduces the risk of introducing bugs. 1. Create the minimal set of standards you can live with. 2. Focus on consistency and consensus over perfection. • No big Coding Standard Documentation (Anyone Read/Remember ?) • Automated tools (FxCop,SonarQube,Resharper,Intellij supports) • Strive to continually reduce codes that do not meet the Coding Standards. • Do Code Review • Add important items to Code Review checklist
- 31. Emergent (Agile) Architecture • Simple design no BUDF • the best architectures, requirements, and designs emerge from a self organized team during the development • “You Aren’t Gonna Need It” (YAGNI) • Create Spike solutions • the simplest and smallest software architecture is the best architecture, can be maintained and changed easily by a development team
- 32. Retrospective • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly • Key practice for Inspect & Adapt • Continuos Improvement Kaizen
- 33. Retrospective • How to apply Retrospective more productive ? • Create safe environment for stakeholders • Try out new retrospective templates • Small&SMART actions that can fit to one iteration. • Track action items during the sprint • Stakeholder’s participation must be ensured • Choose different location • Vote and Prioritize retro items for taking measure • Not allow in Retrospective • Don’t play blame game • Don’t let monoton or boring • Futurespective
- 34. Acceptance Test Driven Development • Acceptance Test is an executable specification of system behaviour. • ATDD aims to encourage collaboration among the user, developer, and tester to ensure that acceptance tests exist before writing any code.
- 37. Resources • https://www.versionone.com/agile-101/agile-software-programming-best-practices • https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd • https://www.agilealliance.org/agile101/agile-glossary/ • https://www.atlassian.com/agile • https://www.ca.com/en/blog-agile-requirements-designer/guide-to-test-driven-development-tdd- vs-bdd-vs-atdd.html • https://gaboesquivel.com/blog/2014/differences-between-tdd-atdd-and-bdd/ • https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report • https://speakerdeck.com/lemiorhan
- 38. Contact M. Mustafa Savaşcı Exp. R&D Engineer / Scrum Master