ZOMATO

A Restaurant Search and Online Food ordering application.

What is the Goal??

1. Rate and Review Restaurant

Scrum — One of the Agile framework

1. Divide the total work in multiple feature work (also known as a user story)
2. Analysis of Feature1
3. Design of Feature1
4. Implementation of Feature1
5. Testing of Feature1
6. Release Feature1 as a working software and move to Feature 2
Let’s go back to Zomato
As mentioned above, let’s use this methodology to develop three features for Zomato. The steps
to be followed for any feature release are:

1. Ideate
2. Design
3. Implement
4. Test
5. Deploy

KRISPY SYSTEM

Krizp Solution was a startup, web-based development company in India. There was no
framework for their software development processes as it was just a startup company with not
many projects and a few employees. The company lacked a structured approach to software
development.

The process and roles of extreme programming

The XP framework normally involves 5 phases or stages of the development process that iterate
continuously:

1. Planning, the first stage, is when the customer meets the development team and presents the
requirements in the form of user stories to describe the desired result. The team then estimates
the stories and creates a release plan broken down into iterations needed to cover the required
functionality part after part. If one or more of the stories can’t be estimated, so-called spikes can
be introduced which means that further research is needed.
2.  Designing is actually a part of the planning process, but can be set apart to emphasize its
importance. It’s related to one of the main XP values that we’ll discuss below — simplicity. A
good design brings logic and structure to the system and allows to avoid unnecessary
complexities and redundancies.
3. Coding is the phase during which the actual code is created by implementing specific XP
practices such as coding standards, pair programming, continuous integration, and collective
code ownership (the entire list is described below).
4. Testing is the core of extreme programming. It is the regular activity that involves both unit tests
(automated testing to determine if the developed feature works properly) and acceptance tests
(customer testing to verify that the overall system is created according to the initial
requirements).
5. Listening is all about constant communication and feedback. The customers and project
managers are involved to describe the business logic and value that is expected.
The team at Krizp System was introduced to the concepts behind the different Agile frameworks.
The XP method was employed over a span of one month and the results were assessed.

The CEO of the company took on 2 roles: the customer representative and the tracker. For his
first role, he prioritized user stories, delegated them to the development team, and had regular
communication with the customer. As the tracker, he kept track of the time to complete specific
tasks. The CEO also initiated the planning game every week (or at least once in four days), as the
project was small and developers could complete tasks in one user story faster. However, the
customer was available for direct communication only twice per month and the rest of the time
he was in contact through phone calls and e-mail.

The Paired Programming technique was adopted whereby both developers worked together.
After task completion, both of the developers reviewed the code with the CEO.

Customer tests were introduced and the team worked on continuous design improvements, which
were about 12-15 per month.
Simplicity

Extreme programming encourages starting with the simplest solution. Extra functionality can
then be added later. The difference between this approach and more conventional system
development methods is the focus on designing and coding for the needs of today instead of
those of tomorrow, next week, or next month. This is sometimes summed up as the "You aren't
gonna need it" (YAGNI) approach.[10] Proponents of XP acknowledge the disadvantage that this
can sometimes entail more effort tomorrow to change the system; their claim is that this is more
than compensated for by the advantage of not investing in possible future requirements that
might change before they become relevant.

Communication

Building software systems requires communicating system requirements to the developers of the
system. In formal software development methodologies, this task is accomplished through
documentation. Extreme programming techniques can be viewed as methods for rapidly building and
disseminating institutional knowledge among members of a development team. The goal is to give all
developers a shared view of the system which matches the view held by the users of the system. To this
end, extreme programming favors simple designs, common metaphors, collaboration of users and
programmers, frequent verbal communication, and feedback.

Feedback

Extreme programming sees feedback as most useful if it is done frequently and promptly. It
stresses that minimal delay between an action and its feedback is critical to learning and making
changes. Unlike traditional system development methods, contact with the customer occurs in
more frequent iterations. The customer has clear insight into the system that is being developed,
and can give feedback and steer the development as needed. With frequent feedback from the
customer, a mistaken design decision made by the developer will be noticed and corrected
quickly, before the developer spends much time implementing it.