Agile engineering practices – a short overview
0 likes1,189 views
This document provides a short overview of agile engineering practices, including Scrum, XP, Kanban, FDD, and DSDM. It summarizes key practices such as pair programming, test-driven development, behavior driven development, acceptance testing, exploratory testing, polyglot programming, domain specific languages, continuous integration, continuous testing, static code checking, agile databases, lightweight domain modeling, and continuous delivery. Each practice is briefly described in one slide with information on feedback time, styles, and challenges.
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 Practice Feedback 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 • Two major 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 • Skillful manual 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
- 13. Continuous Testing • Let’s run tests on every save • „Continuous Integration“ for individual developer
- 14. Static Code Checking and Monitoring
- 15. Agile Databases • DB Sandbox – 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
- 18. Q & A Dr. Serhiy Yevtushenko codecentric AG An der Welle 3 60322 Frankfut [email protected] http://asffm.blogspot.de