Overview presentation showing 4 parts: 1- Agile methodology 2- Test Driven Development 3- Agile different implementations 4- Agile Project Planning and Architecture

1. PART I
AGILE OVERVIEW
Bahaa Farouk

2. CONTENTS
The Story of Software Development
Lean Thinking
Agile Values and Principles
Summary/Review

3. THE STORY OF SOFTWARE
DEVELOPMENT
– We started off with Software Engineering
– IEEE defines Software Engineering as:
“Software Engineering is the application of a
systematic, disciplined, quantifiable approach to
development, operation and maintenance of software: that is, the
application of engineering to software.”
IEEE Standard Computer Dictionary,

4. WHO DOES SOFTWARE ENGINEERING?
– NASA
For the space shuttle’s operating system

5. NASA’S DEFECT DENSITY
– The last 11 versions of the space shuttle’s 420,000 line systems had a
total of 17 defects.

6. MISSILE DEFENSE SYSTEM
– 1969-1975, 5407 person years
– Hardware designed at the same time as software specs being written
– Late changes in requirements not an option
Code &
– Did it Succeed? Unit Test
18%
Design
20%
Integration
Testing
42%
Requireme
nts
20%

7. MISSILE DEFENSE SYSTEM
– Revised Project Statistics
– The project was delivered according to specifications
– Cost: $25 Billion (not adjusted)
– 1969-1975, 5407 person years
Operational for 133 days - Project terminated in 1978
“By the time the 6-year anti-missile system project was completed, the
new missiles were faster than the antimissile missiles”

8. WHERE DID THINGS GO WRONG?
– Software Engineering is a heavy weight methodology and such heavy
weight methodologies characteristically are most successful when:
– Requirements are stable
– Technology is well known and mature
– Everything happens as one would expect
– We are not taking on anything new or unknown
– We have done this many times before

9. CONTENTS
The Story of Software Development
Lean Thinking
Agile Values and Principles
Summary/Review

10. LEAN THINKING
– Based on the best practices of lean production:
– The Toyota Production System, 1988 (1978), Taichii Ohno
• Pull Scheduling - Just-in-Time Flow
• Expose Problems - Stop-the-Line Culture
– Study Of ‘Toyota’ Production System, 1981, Shigeo Shingo
• Non-Stock Production - Single Minute Setup
• Zero Inspection – Automatic Error Detection at Every Step

11. LOWER COST OF CHANGE
THROUGH HIGHER QUALITY
SOFTWARE

12. LEAN SOFTWARE DEVELOPMENT
– Eliminate Waste
• Any development work unrelated to customer value has to be avoided
• administration and project management
• 20% of your features will give 80% of a product’s value
– Focus on Learning
• encourage prototyping as a source for feedback and improvements
• prototype is a good way to challenge and improve currently existing standards.
– Build Quality In
• test driven development creates proper working code from the beginning
• Code is integrated and verified continuously by the developer who is implementing the
use case
• Quality implies that the customers’ expectations are met.

13. LEAN SOFTWARE DEVELOPMENT
– Defer Commitment
• the development needs to be approached in many small increments, rather than a full
specification
• The overall system architecture should support the addition of any feature at any time
• Making the system change-tolerant is the key challenge that software architects are
facing now
– Deliver Fast
• The “Queuing Theory” applies to development teams as well, not just to mainframes
• Progress in small iterations will allow making enhancements available to customers
very quickly, instead of waiting for a final shipment
– Respect People
• effective leadership, which encourages pride, commitment, respect, and trust. Within
such a climate, existing talent can unfold its creativity, intelligence and decisiveness
• Encouraging self-responsibility and autonomy of teams is one key reason for the
remarkable efficiency of lean enterprises

14. LEAN SOFTWARE DEVELOPMENT
– Optimize the Whole
• looking at the entire value stream: What is necessary to deliver a successful and
profitable product?
• both the product itself as well as the process for developing the product, needs to be
reviewed continuously

15. TRADITIONAL PROCESS
Time
50% Done?

16. APPLYING LEAN PRINCIPLES TO SWD
End-to-End small
20 % done = 100 % usable
slices of work

17. APPLYING LEAN PRINCIPLES TO SWD

18. CONTENTS
The Story of Software Development
Lean Thinking
Agile Values and Principles
Summary/Review

19. NEW METHODOLOGIES
XP • Extreme Programming
FDD • Feature Driven Development
Scrum • Agile Methodology
DSDM • Dynamic System Development Method
RUP • Rational Unified Process
AUP • Agile Unified Process
AMDD • Agile Model Driven Development

20. AGILE MANIFESTO
– “We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
• Individuals and interactions OVER processes and tools.
• Working software OVER comprehensive documentation.
• Customer collaboration OVER contract negotiation.
• Responding to change OVER following a plan.
– That is, while there is value in the items on the right, we value the
items on the left more.”
© 2001 Agile Alliance. http://www.agilemanifesto.org

21. PRINCIPLES BEHIND THE MANIFESTO
– Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
– Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
– Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
– Business people and developers must work together daily
throughout the project.

22. PRINCIPLES BEHIND THE MANIFESTO
– Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
– The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
– Working software is the primary measure of progress.
– Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.

23. CONTENTS
The Story of Software Development
Lean Thinking
Agile Values and Principles
Summary/Review

24. USE OF AGILE METHODS
– Helps handle changing requirements & priorities
– Lowers cost of change
– Provides better visibility into project progress
– Reduces risk
– Maximizes return on investment (business value prioritized)
– Encourages higher quality, simpler code
– Delivers business value early & often

25. WITH RESPECT … TO
– Courage!!
– Constant Business involvement
– A need for more Discipline
– Greater emphasis on Testing
– Whole Organization Involvement
– Last but not the least, with an OPEN MIND

26. PART II
TEST DRIVEN
DEVELOPMENT
Bahaa Farouk

27. CONTENTS
What is unit testing?
Why do I want it?
What’s NUnit?
Why test first?

28. WHAT’S UNIT TESTING
A UNIT TEST IS A TEST
OF A SMALL FUNCTIONAL PIECE OF CODE
Public bool IsLoginOK(string user, string password)
{
//…………………………
}

29. DEVELOPER LIVES EASIER
– Easier to find bugs
– Easier to maintain
– Easier to understand
– Easier to Develop

30. ALREADY DONE UNIT TESTING
– Not structured
– Not Repeatable
– Not on all your code
– Not easy to do as it should be
– A framework is missing

31. THE XUNIT FRAMEWORKS
– Original was for SmallTalk
− Kent Beck and Erich Gamma
– Ported to Various languages and platforms
− JUnit, CppUnit, DUnit, VBUnit, RUnit, PyUnit, Sunit, HtmlUnit, …
− Good list at www.xprogramming.com
– Standard test architeture
– Introducing NUnit

32. HOW WE USE NUNIT
– Write Tests
• Make it easy to create and organize tests
• Reference an assembly, spread some attributes, you’re done
– Run Tests
• Allow running all of our tests, a group or just one.
• From command line or GUI
– Review Results
• Immediate Pass/Fail feedback
• Details on each failure
• Able to generate XML reports

33. PART III
DIFFERENT
METHODOLOGIES
Bahaa Farouk

34. CONTENTS
XP
RUP
SCRUM

35. XP
– Pair programming, Refactoring, Simplicity, Planning game, Small
releases
– Continuous integration, Continuous testing,
– Collective code ownership, Sustainable pace, Coding standards, On-
site customer
– Story cards, Prototype UI and UI navigation, Stand-up meeting
– Iteration completeness

36. RUP

37. SCRUM

38. PART IV
PROJECT
PLANNING &
ARCHITECTURE
Bahaa Farouk

39. AGILE PLANNING

40. FEATURES VS. TIME

41. PLAN ITERATIONS

42. ARCHITECTURE
– Keep it simple
• A complex system should be split
into smaller subsystems
– Keep it flexible
• a versatile product needs to
be highly customizable to fit into many different environments
– Keep it small
• can be described and implemented
within a single iteration
– Keep it transparent
• design needs to be discussed with the
people who need to understand it
– Keep it vital
• architecture is something that must be
complete before any development takes place

43. REFERENCES
– http://www.slideshare.net/Siddhi/intro-to-agile
– Agile Software Development, Best Practices for Large Software
Development Projects
– 2003 - Rueping - Agile Documentation A Pattern Guide to Producing
Lightweight Documents for Software Projects
– HP What is Agile
– Coaching.Agile.Teams

44. THANKS