Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Agile

Agile practices

What problems Agile tries to solve?

  • Failed projects
  • Over budget, over time projects
  • We don't know the future and it changes anyway
  • Cost of change increases with time
  • Fear of change in the code
  • Employee satisfaction

What is Agile?

  • The Agile Manifesto?
  • Better (Software) development practice?
  • A buzzword?

Agile is a question

  • Why?
  • Why do we do this?
  • Why do we do this way?
  • Is it beacuse the previous programmer did it this way?
  • Is this working for us?
  • Do we provide good value to our customers?
  • Can we do better?

The 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:

  • 4 values
  • 12 principles

4 values of the Agile Manifesto

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

12 principles of the Agile 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.
  • 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.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile methodologies

  • Scrum
  • XP - Extreme Programming
  • Kanban

Agile practices

  • Estimations (flexible, changeable)
  • Short iterations of development
  • Autonomous (self organizing) teams
  • Retrospective
  • Continuous Improvement
  • Continuous Learning
  • Regular Feedback
  • Communication (between team members, with clients, among teams)
  • Trust - managers trust team members, team members trust each other and the manager
  • Transparncy - visibility of decisions and statuses

Engineering practices

  • Frequent commits to VCS
  • Branching strategy that fits the process
  • Test automation
  • Continuous Integration
  • Continuous Deployment
  • TDD - Test Driven Development (or Test First programming)
  • Pair programming
  • Mob programming
  • Refactoring (reducing technical debt)

Feedback

  • Automated tests, CI (less than 10 min build)
  • From the Product owner (the representative of the client)
  • From the clients
  • Continuous Deployment, deployment circles, feature switches, A/B testing, easy rollback

TDD - Test Driven Development

  • Write tests first that will fail
  • Then imlement code

Benefits

  • Avoid Scope Creep
  • Build trust in team members
  • Reduce coupling of code (avoide spaghetti code)

Scrum

XP - Extreme Programming

Open Questions

  • How to introduce Agile and better engineering practices in an organization?

Resources

Coding tasks

Coding Dojo - Kata

  • Write code away from managers, deadlines, meetings, and production bug.
  • Safe environment to practice and experiment.
  • Simple task that can be done in a short period of time (e.g. 1-2 hours).
  • Can be done multiple times in different ways (e.g. procedural vs OOP vs functional), (TDD or not), (alone, pair, mob).
  • Tasks that can be used to learn a technique.

Pair Programming

  • There is no single right way to do it. Experiment!
  • Driver - Navigator
  • Driver - Navigator - Observer

Driver-Navigator

  • Driver writes code.
  • Navigator thinks and tells the driver what to write. - The highest possible abstraction that matches the knowledge and experience level of the driver.
  • The Observer is strictly observing what the current pair does.
  • Sometimes neither of them know what to do. Then talk. Then suddenly one has an idea. That person becomes the navigator and the other the driver. The navigator then needs to explain the solution and the driver types it in.

Randori

  • There is always a pair
  • Others in the team are watching.
  • Then the coder/driver goes back watching, the navigator becomes the driver and someone from the team becomes the navigator.
  • Basically: Driver-Navigator-Observers

Change of roles: when to switch?

  • Time boxed: fixed time (e.g. every 7 min).
  • Feature boxed: When a small feature is complete.
  • Ping Ping: One person writes the test(s), the other person implements the feature.
  • As you feel right.

Direction of switch?

  • When there are more than 2 people, which direction to switch?
  • Driver out, Navigator to Driver
  • Navigator out and Driver to Navigator.

Change of roles

  • Write tests as well
  • Work in pairs or triples
  • Use git and github
  • Hide your ego. Be considerate. You don't want to be criticized.

Nor do you want your code described as shit. I think we could improve it this way. Or let's look at this other approach it might fit better. Of course we don't have a deadline so you can try both and see the relative advantages and disadvantages.

Test Driven Development - TDD

One Dimensional space-fight

Level 0

  • The computer generates a random whole number between 1 and 200.
  • The computer prompts the user to guess.
  • The user has to guess the number. After the user types in his guess the computer tells if this was bigger or smaller than the number it generated, or it was exactly that number.

Level 1

  • If the user hits 'x', he can leave the game without guessing the number.

Level 2

  • If the user presses 's', show the hidden value (cheat)
  • If the user presses 'd' the game gets into debug mode: the system starts to show the current number to guess every time, just before asking the user for new input. Pressing 'd' again turns off debug mode. (It is a toggle.)

Level 3

  • The 'm' button is another toggle. It is called 'move mode'. When it is 'on', the object move a little bit after every step (+/-2). Pressing 'm' again will turn this feature off.

Level 4

  • Let the user guess several times.
  • Pressing 'n' will skip this game and start a new one (generate new number to guess).

Swapping Pairs

  • Show the code to each other swapping among the pairs.

Retrospectives

Prime Directive

Regardless of what we discover, we under- stand and truly believe that everyone did the Retrospective Fundamentals 11 best job he or she could, given what was known at the time, his or her skills and abili- ties, the resources available, and the situation at hand.

5 stages

  • Set the stage (time, prime directive, goal)
  • Gather Data
  • Generate Insights
  • Decide What to Do
  • Close the Retrospective

What went well?

  • How did you like the pairing part?
  • What other improvements would you make?

TDD and Pair programming

Parts of the session

  • Pair programming a project using TDD.
  • Switching pairs to explain the solution to each other.
  • Retrospective

Why in pairs

  • Why in pairs? Because you already know how to program alone. Let's try something else now.
  • Why stand-alone task? So you can experiment without the fear of breaking your peoduction code.

Tic-tac-toe

Tic-tac-toe - hints

  • Decide on a representation of the board
  • Allow the computer to recognize when someone won.
  • Report invalid boards?
  • Allow two humans to play
  • Make the computer play.
  • Make the system play agains itself
  • Watch War Games

Game of Chomp

  • Chomp
  • Special cases
  • Winning and losing positions