Agile Development and UI/UX design

Agile Development (Unit 1)

Shivang R. Patel October 3, 2023

CE/IT Department - GEC Modasa

Gujarat Technological University, Ahmedabad
Outline

Agile Development
Agile Practices
Extreme Programming
Planning
Testing
Refactoring
Agile Development
Agile means

• Relating to or denoting a method of project management, used especially for software

development, that is characterized by the division of tasks into short phases of work
and frequent reassessment and adaptation of plans.
1
1
https://productplacementblog.com/movies/dell-pc-monitor-used-by-keanu-reeves-as-neo-in-the-matrix-
resurrections-2021/ 1
Agile Practices | In early 2001,

A group of industry experts met to outline the values and principles that would allow
software teams to work quickly and respond to change. They called themselves the Agile
Alliance.
Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value...

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

2
1. Individuals and interactions over processes and tools

Figure 1: Team(Developers + Customer) - Individuals and interactions over processes | Tools and Technology

2 3
2
https://www.pixelstalk.net/hd-scooby-doo-wallpapers/
2. Working software over comprehensive documentation.

Figure 2: Good Documentation

3
3
from "Man v/s Bee" tv show.
4
3. Customer collaboration over contract negotiation.

• You cannot write a description of the software you want and then have someone
develop it on a fixed schedule for a fixed price. Time and time again, attempts to treat
software projects in this manner have failed.
• Successful projects involve customer feedback on a regular and frequent basis.
• A contract that specifies the requirements, schedule, and cost of a project is
fundamentally flawed. In most cases, the terms it specifies become meaningless long
before the project is complete. The best contracts are those that govern the way the
development team and the customer will work together.

5
4. Responding to change over following a plan.

Figure 3: Flexible Plan

• When we build plans, we need to make sure that our plans are flexible and ready to
adapt to changes in the business and technology.
4 6
4
from Google Map.
Agile Practices | Principles (1/3)

The above values inspired the following 12 principles, which are the characteristics that
differentiate a set of agile practices from a heavyweight process:

1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter time scale.
4. Business people and developers must work together daily throughout the project.

7
Agile Practices | Principles (2/3)

5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.

8
Agile Practices | Principles (3/3)

12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

9
Extreme Programming

Figure 4: Stone as a interdependent practices and they make strong wall like good software!

Extreme programming is the most famous of the agile methods. It is made up of a set of
simple, yet interdependent practices. These practices work together to form a whole that
is greater than its parts.
5
5 10
https://www.tatatrusts.org/our-stories/article/artificial-glaciers-to-the-rescue-in-leh
• Customer Team Member • Sustainable Pace
• User Stories • Open Workspace
• Short Cycles • The Planning Game
• The Iteration Plan. • Simple Design
• The Release Plan. • Consider the Simplest Thing That
• Acceptance Tests Could Possibly Work.
• Pair Programming • You Aren’t Going to Need It.
• Once and Only Once.
• Test-Driven Development
• Refactoring
• Collective Ownership
• Metaphor
• Continuous Integration

11
Planning

Figure 5: Planning!!!

6
6
Image copy from: https://www.busytourist.com/
12
Planning

1. Initial Exploration[Spiking, Splitting, and Velocity]

2. Release Planning
3. Iteration Planning
4. Task Planning
5. Iterating

13
Initial Exploration - Spiking, Splitting, and Velocity (1/2)

Stories that are too large or too small are hard to estimate. Developers tend to underestimate
large stories and over-estimate small ones. Any story that is too big should be split into pieces
that aren’t too big. Any story that is too small should be merged with other small stories.
Velocity: Relative estimates don’t tell us the absolute size of the stories, so they don’t help
us determine when to split or merge them. In order to know the true size of a story, we
need a factor that we call velocity. If we have an accurate velocity, we can multiply the
estimate of any story by the velocity to get the actual time estimate for that story.
For example, if our velocity is “2 days per story point,” and we have a story with a relative
estimate of four points, then the story should take eight days to implement.

14
Initial Exploration - Spiking, Splitting, and Velocity (2/2)

Spiking: Initially, developers have no idea of their teams velocity. spend a few days
prototyping a story or two to get an idea of the team’s velocity. Such a prototype session is
called a spike.

15
Release Planning

Figure 6: Based on business priority, release softwares in modules or batch[2–4 months in the future].
16
Iteration Planning

Figure 7: typically two weeks long

8
8
https://www.zstream.io
17
Task Planning

Figure 8: typically 4–16 hours long

9
9
https://toggl.com
18
Iterating

• Every two weeks, the current iteration ends and the next begins. At the end of each
iteration, the current running executable is demonstrated to the customers. The
customers are asked to evaluate the look, feel, and performance of the project. They
will provide their feedback in terms of new user stories.
• The customers see progress frequently. They can measure velocity. They can predict
how fast the team is going, and they can schedule high-priority stories early. In short,
they have all the data and control they need to manage the project to their liking.

19
Testing

1. Test-First Design[Test Isolation, Coupled module testing, Decoupling]

2. Acceptance Tests[Unit test - White box testing - insufficient | written by folks who do
not know the internal mechanisms of the system - Black box texting - customer or QA
- ultimate documentation of a feature]

20
Refactoring

Figure 9: Code evolution

10
10
https://lvivity.com/wp-content/uploads/2020/09/clean-code.png 21
Refactoring

11
11
https://maddevs.io/blog/code-refactoring/ 22
Metaphor

A metaphor is intended to be agreed upon by all project participants as a method of easily

expressing the project’s objective.

23
Thank You !

24