Agile Software Development

274 views

Published on

Agile Software Development with Python

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
274
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Software Development

  1. 1. CS 361 Software Week 1
  2. 2. Attendance Rules • If you attend less than 80% of classes, you automatically fail this class. • If you arrive late (any later than 12:00:00 pm), don’t try to interrupt the class.Wait outside till the break. You are allowed in during the break. • Be here, ask questions to make the most out of this class.
  3. 3. Administrative •Course Instructor • Ahmet Bulut (ahmetbulut@sehir.edu.tr) •Course TAs • Jeton Pllana (Masters Student). • Oguzhan Sagoglu (Undergraduate Student with inner drive).
  4. 4. Coursebook •Core Material • Foundations of Agile Python Development • The Definitive Guide to Django:Web Development Done Right! •Instrumentation/Enrichment Books • Interactive DataVisualization for the Web • Mining the Social Web
  5. 5. What’s Agile Development? • Focus on short development cycles, on the scale of weeks rather than months. • Each development cycle, referred to as an iteration or sprint, produces a working product.
  6. 6. What’s Agile Development? Pair programming
  7. 7. What’s Agile Development? Pair programming User stories
  8. 8. What’s Agile Development? Pair programming User stories The system metaphor
  9. 9. What’s Agile Development? Pair programming User stories The system metaphor On-site customers
  10. 10. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests
  11. 11. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development
  12. 12. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring
  13. 13. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design
  14. 14. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations
  15. 15. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations Collective code ownership
  16. 16. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations Collective code ownership Continuous reflection
  17. 17. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations Collective code ownership Continuous reflection Continuous Integration
  18. 18. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations Collective code ownership Continuous reflection Continuous Integration Documentation
  19. 19. State of Affairs • Some projects succeed and some projects fail. • No matter what development methods are used. • Development is about much more than simply the techniques that are used. • Good development depends upon a strong grounding in reality; not everything can be known before a project starts, and this must be taken into account when planning.
  20. 20. Waterfall
  21. 21. Waterfall methodology • It assumes that all change can be predicted and described up front. • Exploratory tasks that should be part of development are pushed into the design phase. • The waterfall methodology also assumes that documentation can be sufficient to describe a system. • A software specification detailed enough to unambiguously describe the system is specific enough to be translated automatically to software.
  22. 22. Manifesto for Agile Software Development • Produced in February, 2001. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  23. 23. Enabling... • Agile methods reflect an underlying change in technology. • In the early ‘80s, computing power was expensive and people’s time was comparatively cheap. • The ability to run hundreds or thousands of tests in a few seconds was fantasy. • The idea of setting up and tearing down a SQL database in memory was absurd.
  24. 24. What is Agile? • Planning is critical to any project: the development team needs to know the broad scope and the intended form of the finished product. • Defer coding until you have a basic grasp of what you are trying to build. • Agile methods aren’t a license to go flying off in any direction. • Agile development methods are excellent tools for producing locally optimal designs, but on their own they are insufficient to produce globally optimal designs.
  25. 25. What’s Agile Development? Pair programming User stories The system metaphor On-site customers Unit tests Test-driven development Refactoring Simple Design Short Iterations Collective code ownership Continuous reflection Continuous Integration Documentation
  26. 26. Agile Methods • Feature development and feature maintenance are one and the same. • Your software should always be functional. It may not have the full functionality of the finished application, but it should always be runnable and installable. • Source code is not a product. It is a blueprint for a product. • Writing software is not producing new features, but instead designing them. Similarly, rewriting existing software is really redesigning old features.
  27. 27. Pair Programming
  28. 28. Pair Programming • Most programmers aren’t that productive. • Programming is lonely, and we’re social creatures. • Programmers end up wasting half their day. They spend time reading e-mail, whether personal or company. They surf the Web. They fall into conversations with coworkers. • To some extent, they are just trying to engage with other human beings.
  29. 29. Code space • Working alone with a computer has a strange effect on the human mind.The computer gives rewards and feedback, but it doesn’t engage our limbic system • It’s a place isolated from the rest of the human race. It takes time to come back from code space, often hours, and those are the hours that we have to spend with our families and friends.
  30. 30. Social Programmers • Put two programmers together and their work becomes a social activity. • They work together. • They don’t get stuck, they keep each other from being distracted, they don’t go into code space, and they’re happier at the end of the day. • At worst, you haven’t lost any productivity, and you’ve increased employee morale.
  31. 31. Pair programming • ... improves code quality. • ... is a form of constant code review. • Code reviews are a process in which programmers review and make suggestions about another developer’s code. • Note: Code reviews have been found to consistently decrease the number of bugs per thousand lines of code, and they have been found to be more effective at doing this than any other single measure.
  32. 32. Pair programming • ... transfers knowledge between team members. • There is no obstacle between you and the next person. If you need help from someone who knows a given section of code, you can turn around and ask them. • We’re very good at carrying on conversations with other people and ignoring our larger environment. It takes much more to interrupt our flow of thoughts. • Think of all the wonderful conversations that people have in restaurants and cafes.
  33. 33. Pair Programming • Pairs are fluid. Programmers pair with different programmers every few days to spread the knowledge around. Knowledge spreads like a virus. • 1 person knows something in the beginning. She pairs with someone. Now 2 people know.They move on to different pairs, and now 4 people now know. • The more pairings you have, the more it spreads. • This protects the development group from the loss of any one programmer.
  34. 34. User Stories 1. User stories are the distillation of what the customer wants and what can be produced by the programmers. 2. It is important for programmers and management to be involved in their creation, as they provide a technical check on customers’ wild dreams. 3. It is important that the dreams be those of the customer, though, as the programmers probably don’t have as firm a grasp on the business problems as they’d like to believe.
  35. 35. System Metaphor • There is just one way that the code, the developers, the managers, and the customers talk about the design. When everyone speaks the same vocabulary, meetings and discussions flow smoothly. • The system metaphor allows you to talk about your design in a consistent and unambiguous way.
  36. 36. On-site customers • Having a customer available saves the programmer from having to make guesses about the domain. Making guesses is expensive. • The customer also serves as broad functional QA. She gets to see things along the way. She can catch situations where the developers and customer didn’t communicate quite well enough. • Having the customer on site speeds up this process of interaction.The programmers don’t have to wait for the customer to get back to them.
  37. 37. Thank you! • See you on Thursday at 12pm.

×