Agile Engineering Practices 

Introduction • Mob \ Pair Programming • Code Review • MVP • Collective Code Ownership • Continous Integration\Deployment\Delivery • Poker Planning \ No Estimations • TimeBoxing \ Velocity \ BurnDown Charts • Branching Strategies • Technical Debt Management • Coding Standards • Emergent Architecture \ Design 

Agile • Agile isn't just a set of ceremonies. • It's a cultural and technical philosophy. 

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 

Agile Techniques 

Pair Programming 

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 

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 

Mob Programming 

Mob Programming 

Mob Programming 

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 

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 

No content

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 

Minimum Viable Product (MVP) 

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" 

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) 

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 

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 

Continuous Delivery & Deployment 

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 

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 

No Estimation • Slice the user stories thinly • Time-box and prioritize • Update the forecast frequently 

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 

Velocity • indication of the average amount of Product Backlog turned into an Increment of product during a Sprint 

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 

Branching Strategies • The version control system creates a copy of the code base at that point in time • Master/Trunk/Main • Release Branch • Development • Feature Branch • Develop/test/review feature without any interrupt • Merge issues • Small check-in • Code Freeze not needed 

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. 

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 

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 

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 

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 

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 

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. 

ATDD with SpecFlow 

Behaviour Driven Development (BDD) • BDD requires guidance from developers, testers, and users to ensure answers to the “whys” behind a user story. • BDD is usually done in very English-like language English-like language helps the Domain experts to understand the implementation rather than exposing the code level tests. Its defined in a GWT format, GIVEN WHEN & THEN. • Often with further tools to make it easy for non-techies to understand, like Fitness for example. • This allows much easier collaboration with non-techie stakeholders, than TDD. • BDD focuses on the behavioral aspect of the system rather than the implementation aspect of the system that TDD focuses on. • BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer. 

Test Driven Development (TDD aka uTDD) • No UI automation, No Feature Test, No Regression/Integration, • Not direct linked to Requirement • Focuses specifically on “unit tests.” • The developer takes a requirement and then converts it into a specific test case • Then the developer writes the code to pass those particular test cases only. • TDD focuses on the low level, ATDD on high level. • The BDD is where the step of making it more customer-focused comes in 

What is difference between TDD, ATDD and BDD ? • TDD (uTDD):“Is the code correct?” • focuses on the “inside-out” perspective • create tests from a developer’s perspective. • takes a requirement and then converts it into a specific test case. • BDD : “Is this what we should be testing?” • focuses on the “outside-in” perspective • test behaviors which are related to business outcomes • tests are written in an English-like language ATDD: “Is the code doing what it is supposed to do?” • is written from the users perspective and function as a requirement for how the software should function. • focuses on capturing requirements in acceptance tests and uses them to drive the development 

ATDD with TDD 

What is difference between TDD, ATDD and BDD ? 

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 • https://gaboesquivel.com/blog/2014/differences-between-tdd-atdd-and-bdd/ • https://www.ca.com/en/blog-agile-requirements-designer/guide-to-test-driven-development-tdd- vs-bdd-vs-atdd.html • http://toolsqa.com/blogs/test-approach-and-comparisons-between-atdd-tdd-and-bdd/ 

Contact M. Mustafa Savaşcı Exp. R&D Engineer / Scrum Master E-mail: m.mustafasavasci [at] gmail.com