Agile Talk 30 Jul 1o2


Published on

All that I live and breathe in XP

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Talk 30 Jul 1o2

  1. 1. Agile Software development From a programmers point of view 7/28/2010 1
  2. 2. Agenda 1. Introduction 2. What is Agile Software Development? 3. Review of XP values and Practices 4. XP vs Waterfall 5. What makes/breaks an agile team 6. Are Architecture and Agile two opposing forces? 7. Does agile apply only to J2EE/.net/Ruby projects only ? 8. References 9. Q &A 7/28/2010 2
  3. 3. Introduction • Around 15 yrs of hands on experience in software development • 8 yrs in Agile environments • IBM alumni 1996-2007 • Leading a technology startup as Chief Architect( since 2007. Prefer to be called Chief Programmer. • Keen interest in Architecture, MDD, XP. 7/28/2010 3
  4. 4. Agile Software development • Need a method for developing software – Else can not foresee risks, costs, projections, value, predictability – How/when/what/why. • Till the art of software development matured, we looked at established engineering methods – civil engineering surely contributed one buzz-word: architecture – Design review came from automobiles . – Why did they spent so much energy (time/money/effort) on architecture/design? • Well, Software by very definition is something soft or malleable. So why borrow from approaches which specifically restrict this natural value. – In contrast, can they build a quick and dirty bridge to check if it would work and iteratively improve it? • Whats Agile: (an adjective as per – Characterized by quickness, lightness, and ease of movement; nimble. – Mentally quick or alert: an agile mind. 7/28/2010 4
  5. 5. Change is the only constant • Name one project where users signed off requirements and accepted them as-is. • Users only have an initial understanding of their need, but they can not: – document software requirements. (sign off ??) – validate designs. • However they can give feedback (better soon than later) • Every feedback directly implies change • What would you rather do (or what would they pay for): – Build a software that meets User needs – Build a software which meets documented requirement. • Users know it best: – Why cant you change it, it is software after-all. • Extraneous factors/Bad initial choices/changing context are all examples of change. • Change is a necessary evil though its not necessarily evil: It keeps the users/stake holders happy. • Need a method which reduces the risks of divergence from user needs, makes it easy and safe to introduce change. 7/28/2010 5
  6. 6. Extreme programming (XP) • A method for developing software ( and specifically software only) • Specifically meant for Software development: – Emphasis on “Soft”: and not a generic engineering method – Emphasis on “development”: and not project/program management • An Agile method (scrum/DSDM are other examples) • Light on processes, heavy on discipline. • Recognizes key values which should be held high in all actions at all times. • If you had only one day to finish the project, what would you rather do? Code+Test or create design documents ? 7/28/2010 6
  7. 7. 5 XP values define the team dynamics Five core values which must be held high at all times in all actions • Communication – Amongst programmers, – Between programmers and business users – Open and accessible (same room/same time, virtual room: wiki, skype) • Simplicity – In design – In planning • Feedback – Quick and direct • Courage – To change – To estimate tasks • Respect – Respect the values to gain respect from peers – Respect choices made by your team 7/28/2010 7
  8. 8. 12 XP practices support these values (1/2) 1. Metaphor – How users express an unseen system, E.g. spread sheet, mailbox etc. – Could also be an early protoype or an existing system 2. Simple Design – Do not build mega structures by guessing the future (simplicity) – Let the future unfold naturally and then act in the context. 3. Test-first/TDD – Write (automated) tests before writing the code – Let tests be the only documentation of your code 4. Ruthless Refactoring – Keep improving the design by refactoring code (courage) – Change runtime code and keep tests constant (or better) 5. Continuous integration – Integrate often (n times a day) and make sure all unit tests pass (feedback) – Each integration advances the system from one stable state to next stable state. 6. Pair programming – Program in pairs: tests, design, code (feedback, respect) 7/28/2010 8
  9. 9. 12 XP practices support these values (2/2) 7. Collective ownership – Every pair can change every program: TDD+refactoring+CI (respect, courage) 8. Coding standards – A common way of expressing programmers intentions (respect) 9. Small releases – Keep releasing to business users frequently (feedback) 10. Planning game – Focus on what is of highest value to the customer at all times (simplicity) – Re-assess what is pending and what is now most important (feedback) – Dont change course during a cycle (1-3 week) – Consider priorities, programmers estimates in deciding what should be done 11. On Site customer – Writes functional tests. – Define prioiry and feature scope. – Give constant feedback 12. 40 Hour week – Do not burn out, instead improve estimates – Don’t let your team sign up for whats not possible (respect, feedback) 7/28/2010 9
  10. 10. A day in life of an Extreme Programmer • During planning game: – You get to choose the task(s) that you’d want to own up, rather than Mr Project Mgr deciding who does what. – You get to say, how much ideal time you think a task needs, no one tells you their SWAG. Note: ideal time is different from real time and ratio keeps changing. • On a typical engineering day: – Daily 10 min standup meeting (aka daily scrum) • What did you do yesterday, what do you plan to achieve today, • What do you need to finish up the task, from whom – Discuss the task with your pair. • Review existing unit tests in the area • Simplest design that would meet the task – Write unit tests covering your task • These tests should fail • Most times they would also fail compilation: Which forces you to think of design (design by interface) – Write runtime code which makes these failing tests pass – Make sure all the unit tests (old and new) pass in your workspace – Get into integration queue (manual/automated) – Integrate code and make sure all tests still pass – Have a nice evening, forget the code, really forget it 7/28/2010 10
  11. 11. Let tests be the only documentation • Would you call up someone about the code he/she wrote a month ago to know how it is supposed to work ? Would he/she know/remember ? • Can all code which is under development/change be documented ? • Word/PDF documents don’t breathe, hence there is no way to assert if they are correct. • It takes minutes of a programmers time to diverge from documentation (code comments, they go though the same life: or death) • However unit tests do breathe: they turn red/green. They talk to you in your favorite language (which better not be english) • Unit tests express and assert the original intentions of the author, current feature set and known bugs. • Unit tests act as a scaffolding when you change code. Imagine a design/code document trying to assert that there is no divergence from it in the code • Most times, code comments can be either replaced by a better named/refactored method or a test which shows the pre and post conditions. • Does not replace end-user documentation though ! • If there is time available to write code documentation/comments: better spend it on writing more unit tests. • Reduces the stress of carrying all the knowledge in your head: makes it easy to go on vacation/rotation. 7/28/2010 11
  12. 12. XP vs Waterfall • XP is water fall… practiced in the reverse order.. Here is how – Water fall: Requirements =>Design=>Code=>Test – XP:Test=>Code=>Design (By refactoring)=>Requirements (by Feedback) • However there is an order of magnitude difference in time scale. • There is also a difference between the meaning of “test” in the two approaches: Integration test vs. Unit test • XPs take on requirements: – We may or may not ask right questions to the user, but we do give them working software early in the game to make them produce feedback. Push vs Pull, key differentiator. – Don’t surprize them too late, let them get used to the system and speak for you, for a common good • XP take on Design: – Test First + Pair Programming => simplest design to meet today’s needs – Refactoring +Tests=> continuous improvement in design 7/28/2010 12
  13. 13. What makes/breaks an agile team (1/4) • Unit tests loose value if – they are not run frequently and by every one in dev team(no not by ‘QA’ team) – they take too much time to run hence team fears running them – if they fail randomly and team accepts them as “known to fail” – Whats missing ? A will to fix the tests or may be a coach to define crisp tests • Test first should not be misunderstood as: – I’ll have a few tests by the time I integrate but let me write the runtime code first – After-the-fact unit tests generally check the happy scenarios and only show an invocation pattern • Refactoring is the art of improving design (and various “-bilities) while keeping the feature energy constant. • Refactoring is a big adventure/risk – If there are no tests.. leave refactoring for SuperMan – Don’t start refactoring unless you have reviewed the test coverage – Better add sufficient tests before boarding the refactoring train • Refactoring should – Enforce DRY (Don’t Repeat Yourself): express every thing once and only once: keep normalizing your code – become second nature to programmers – always be preferred over conditional code (iron your cloths before wearing) – Be part of a continuous cycIe: Tests->Code->Refactor-> and back 7/28/2010 13
  14. 14. What makes/breaks an agile team (2/4) • Continuous integration has no/low value if it does not run unit tests – or if the team has a habit of choosing to not run unit tests in crunch (remember value system has to be kept high at all times ) • Dev team asserts a need for refactoring but project management pushes features (respect, courage) • Unlikely to see an unpaired programmer to do a fair/honest job at test first/ simple design • Don’t let team members branch off for days to creating new functionality – Instead define baby steps (small tasks) to reach there – Continuous integration is the key – Stay on a single branch as far as possible (except for release management) • Do not create communication barriers – between programmers – Between programmers and users – Keep all communication open and available (physical: same room, virtual: wikis, commonly owned chat transcripts) • Good IDE is important and so is good command on IDE. static code analysis, automated refactoring are useful features e.g. eclipse. VisualStudio is still catching up. 7/28/2010 14
  15. 15. What makes/breaks an agile team (3/4) • It is wrong to assume that productivity is halved by pairing. In fact: it improves – Peer pressure/ peer recognition – Some people are good at pointing mistakes – Less chances of loosing focus to e-mail/phone/chat/facebook – Good for bonding in team, – Very useful for coaching new team members – Required for collective ownership of code • It is also wrong to assume that productivity reduces because of unit tests – Instead it increases because of drastically reduced “break-point-driven” debugging – It makes the programmer think in terms of class interfaces which leads to robust designs – It continuously builds a regression protection – It makes It easy to replace parts of the system without breaking any functionality • Ability to quickly run all unit tests is a critical success factor – lack of which leads to real productivity losses – Continuously focus on “small-ness” of unit tests – Treat tests as first-class citizens in your codebase: refactor them as needed. 7/28/2010 15
  16. 16. What makes/breaks an agile team (4/4) • Each test is like a main() program: typical test frameworks allow you to run each of them selectively. Compare it with the trouble of maintaining N-different tool executables (or batch files) – It’s a good idea to create all your tools with in the test framework itself: they keep getting exercised during your test runs and stay healthy: – Regular (Test) Exercise Keeps you (and your Project) healthy • Pollination is also very important – Cautious effort should be spent in making sure that pairings rotate – There is a fear of developing islands of excellence: whenever we need to change inventory we look towards tom and harry. They know it best • Self organizing teams reflect on themselves and improve – Hold “Review and Improve” session end of every cycle. • Critical to have a coach/mentor/scrum master in the team • Never forget DRY (Don’t Repeat yourself) – XP does not mean copy/pasting code • Having a production environment clone available for development teams use (test and deploy) since the very beginning is also very important. – Try to deploy to that environment as early as possible (first cycle must do) 7/28/2010 16
  17. 17. Are Architecture and Agile two opposing forces? There is clear contradiction in the literary meanings of the two words.. So is the common perception. Distinguish Architecture from Software Design-Build-Test-Deploy cycles. • Agile methods apply to the design-build-test-deploy cycles much more than they do to define grounds up systems architecture. • When new projects are proposed/started there may/may not be clear guidance/agreement on the development model. Who/when/where the development takes place is not even known sometimes. • An early definition of an architecture is needed to create sketches of what is required/proposed • Stated needs=>system context =>architectural overview=>component definition • Some of these may be software components (others being hardware/networking components). • Build vs Buy decision in software components. • These early architectural decisions lead to a definition of what needs to be custom built, these decisions would also typically drive how these components communicate • Notice nothing has been detailed on the knowledge/information/software content of this project while there is an architecture defined as an early guidance yet • From here on things work different ly for an XP/agile team vs a Waterfall team. UP falls some where between them 7/28/2010 17
  18. 18. …and then we do agile • An agile software development team starts building the software by looking at the userstoris within the architectural sketch ..which only bounds them in choice of platform/language/package etc. • There may also be metaphors, architectural templates, early prototypes etc. to jump start • Instead of an elaborated requirements gathering/documentation/sign offs or "Designing" the whole system, they focus on user needs and turn them into testable software in small cycles. • One strong reason why architecture is important is : The“-bilities” of a system or to mitigate the lack of them: maintain-bility, testa-bility, scalability… • Architecture defines the “-bilities” and tries to solve some of them in system definition, however a majority of it (e.g. response time, memory usage) are a direct output of the build. It is “failry- talish” to solve them by designing . Even if you do, you need to measure(test) them. • In agile environment, refactoring keeps evolving the software design and improves its "-bilities” driven by the current needs of the users and substantiated by tests (performance tests here) • In-flight architectural evolution is possible with agile but impossible with front-heavy design approach. 7/28/2010 18
  19. 19. Agile practices help significantly in Architectural Spikes. They also help in evaluating new platforms/frameworks/thirdparty softwares quickly. e.g. the Unit tests come handy when we want to quickly check if we all our features would work in a different operating environment (windows vs linux, oracle vs db2) Example of in-flight architectural change • We found abc database to be too slow for the current needs of this application and we need to move to xyz". • It is an architectural change, and an agile team reacts to it in the same manner as it would to any change: a) make sure you have unit tests for the impacted area b) refactor the code c) implement the tests for the new feature d) implement the feature. • Here, refactoring the code may mean bringing in a database-adaptation-layer to make sure that the code can sustain the change in database. • However the basic approach remains same: – unit-tests help you survive the refactoring, – refactoring makes way for new features. Summary: Architecture and Agile are two complementary forces pushing projects to success. Agile makes it easy to fix failed initial assumptions. 7/28/2010 19
  20. 20. Does Agile apply to only Java/.net/Ruby projects? (1/2) • Which project would not want – To make end users satisfy – To take a risk mitigation approach since the very beginning – Improve their chances of success • What parts of today’s talk were language/platform specific? • In general it has nothing to do with platform/language etc. – However tools may vary in availability/maturity level • Once you cross the fence, the other side looks too murky no matter what language/platform you work on • I was in the same state when I started working with DSP assembly programming after 12 years of C/C++/Java/Perl/C# and 5 years of agile – Could not wait till the code was deployed on test-boards to know if it is working – Wrote Unit tests directly in assembly langauge and tested all modules in place in visual editor – Refactored assembly code by re-arranging the code into reusable macros – A test board to run all tests and give feedback. • Do not rule out maintenance and repair projects: • create unit tests to reproduce bugs and cautiously invest time in developing regression test suites for buggy/frequently changed areas. 7/28/2010 20
  21. 21. Does Agile apply to only Java/.net/Ruby projects? (2/2) • Do not try to do agile with >20 team size. – It is arguable if a programming team of 40 means a project or a program – Almost certainly it will not be coherent – Better break it at natural fracture boundaries and run smaller close-nit teams with pollination – Could also be a geographical boundary, but not necessary • Distance (onsite-offshore) should not make a communication barrier any more, – ICT solves that (skype, video chat, desktop sharing, many different ways) – however needs focused effort to make geo-separated teams co-operate • Spend initial energy in choosing tools (IDE/test framework/CI Platform) – If there is nothing available, create and use. 7/28/2010 21
  22. 22. References Books (must read) 1. Extreme programming explained, embrace change by Kent beck 2. Test driven development: by example by Kent beck 3. Refactoring: Improving the Design of Existing Code by Martin Fowler More books 1. Refactroing to patterns: by Joshua Kerievsky 2. Agile Software development by Alistair cockburn 3. Extreme Programming installed by Ron Jeferries Web: wiki run by Ward Cunnigham 7/28/2010 22
  23. 23. Q&A 7/28/2010 23