Agile engineering practices – a short overview

Agile engineering practices – a short overview

• 1.
  Agile Engineering Practices– a Short Overview Dr. Serhiy Yevtushenko, 08 May 2014
• 2.
  Introduction • Goal –short overview about existing engineering practices • Agile Methods – Scrum, XP, Kanban, FDD, DSDM, … • Practice – software development practices applied within methods – Some methods (not all) have recommended set of practices • One Slide per practice
• 3.
  History – XP& FDD Extreme Programming Feature Driven Development Project size 3-12 2 – 250 Units of planning User Story Feature Code Ownership Collective Individual Domain Modeling Shared Metaphor Color Modeling Collaborative Construction Pair Programming Formal Inspection (on many levels) Development Testing Unit Testing/Test driven Development Unit testing Integration Testing Automated Acceptance Testing Manual Testing Builds Continuous Integration Daily Builds
• 4.
  Practices/Level of Feedback PracticeFeedback Time Pair Programming/Code Review/Formal Inspection From seconds to 1-2 days Unit Testing From minutes to tens of minutes Builds/Continuous Integration 10 minutes – daily Integration Test/Acceptance Tests Hour(s) – Days Frequent Releases/Continuous Delivery Tens per day – 1 per quartal
• 5.
  Collaborative construction Pair Programming •Joint problem solving & checking • Requires coordination of developers schedule • Exhaustive • May not function with certain pairs Formal Inspection • Most formal Code Review style – with checklists & metrics tracking • Most effective & most heavyweight • Lightweight code reviews with systems – viable alternative Rotation • Forced postponed code review • Saves times for code review meetings • Requires unit testing in place for functioning Code Review • Less coordination required • Could synchronous and asynchronous • Good systems for distributed code reviews currently available
• 6.
  Unit Testing • Twomajor styles – Stated Based Testing – Interaction Based Testing • Property-based testing (a-la QuickChecks) is currently being explored • Difficulty varies – Class without dependencies (easy) – … – GUI code – Legacy code – Asynchronous Code
• 7.
  Test Driven Development THINK! What is the best way to complete the code? TEST! Add a small failing test IMPLEMENT! Add production code, so all tests will pass REFACTOR! Maximally simplify the code
• 8.
  Behaviour Driven Development •Based on Test Driven Development • Different language is used for expressing tests – Behaviour instead of Test – Should instead of Assert • Suits good for workflow tests – Given – When – Then • Tests: – (a little bit) better documented – more higher level compared to TDD
• 9.
  Acceptance Testing/Specification by Example •Requirements specification intermixed with examples (in tabular form) • Focus on doing right things, instead of doing things right • Most problematic practice in implementation – Tests are easy to create – Hard to debug & maintain, long to run – Number of framework exists • They do not always pull their weight – Business Users involvement is the hardest problem • Should be supported on architecture level for success
• 10.
  Exploratory Testing • Skillfulmanual testing • Test design and test execution at the same time • Sophisticated, thoughtful approach to “ad- hoc” testing
• 11.
  Polyglot Programming &Domain Specific Languages • New Generation of software development languages – Groovy, Clojure, Scale, … • Well-suited for Domain-Specific Languages (DSL) • Suitable for builds and environment scripting • Usage of several languages on the same project could be more productive & beneficial – Unit Tests Code is more compact in scripting languages
• 12.
  Continuous Integration
• 13.
  Continuous Testing • Let’srun tests on every save • „Continuous Integration“ for individual developer
• 14.
  Static Code Checkingand Monitoring
• 15.
  Agile Databases • DBSandbox – DB instance per Developer • In Memory DB for testing • Automatic propagation of DB Schema Changes • Refactoring Databases • Unit Testing DB Code • Test Driven Development for Databases • No SQL – “schemaless” DB
• 16.
  Lightweight Domain Modeling
• 17.
  Continuous Delivery
• 18.
  Q & A Dr.Serhiy Yevtushenko codecentric AG An der Welle 3 60322 Frankfut serhiy.yevtushenko@codecentric.de http://asffm.blogspot.de