Tuesday 12 August 2014

How Can Agile Scrum Reduce Regression During Software Development?

For IT development companies, and organisations developing computer and digital-devices 
(smartphones, tablets, digital diaries, etc.) software projects, one of the
 most important, and also the most troublesome issue is encountering “bugs” or defects in
 the code functionality when a particular application, or a system, is deployed and used in 
a live environment. Software bugs can be very common. Ever since computers were 
designed in the yearly years, bugs have inadvertently, or otherwise, kept on troubling 
coders and project managers, and have tested their ingenuity to resolve them to the 
fullest extent possible. Ask any seasoned programmer - He or she will tend to initially 
confer, and eventually say that the word “Bug” is aptly named – It tends to “bug” you!

Etymology of the word “Bug”

It is interesting to know how the terminology “bug” was first coined, and used to 
describe a state of functioning in which an error, or a flaw in coding can lead to 
flawed results, or “outputs” in IT jargon. There are several stories as to how the 
terminology came into existence. A theory most subscribed to involves the pioneer
 programmer, Grace Hopper, who was a young Naval Reserve officer working on a 
Mark II computer at Harvard University. In 1944, she related an incident in which 
the computer had malfunctioned – an actual moth had, in fact, “managed” somehow 
to get itself embedded between two electrical relays, causing the computer to halt
 in its functioning. She explained that the cause of malfunction was a “bug,” which 
was later removed by a technician. The famous bug was exhibited by the Navy for
 many years, and is now owned by the Smithsonian Institute. 

Bugs and software regression

In a broad sense, a software bug can be understood as an error, failure, flaw, or 
even a fault in the code designed to develop an application or a computer based 
system. Bugs typically create unexpected and incorrect results or outputs, which 
cause the functionality of the particular application to stop, or function in a manner 
other than so desired. Bugs generally arise owing to reasons such as:
  • Mistakes carried out while encoding a program
  • Designing improper code structure or logic
  • Utilising the functionality of the code in a manner other than that recommended
  • Technical errors in the code compilers and/or interpreting resources and agents
Of course, the above are not the only causes which give rise to bugs, however, they 
constitute the major reasons why bugs tend to occur in majority of the cases. When
 the numbers of bugs increase significantly, the overall functionality of the application
 may be compromised upon to a considerable level, rendering it useless and 
non-productive. This can cause severe financial loses, and even force businesses 
to face litigation from troubled end-users and consumers.
Broadly, the word “regression” means to return to a former, or a lesser developed 
state. So, how can regression be understood in terms of “software regression”
 pertaining to software development? In practice, developers write down, 
or generate code, to develop a particular functionality as requested by the 
end-user or the client. During the coding stage, the developer not only develops 
the code, but also checks it and ensures that it is working properly. This is a 
standard practice followed by most experienced programmers and developers.
 However, at times, the testing process may not be carried out properly, or the 
code functionality might work properly in most cases, but fail to work under 
certain circumstances and situations. A second scenario is the code may be 
developed and properly tested at the time of creation, and the application 
deployed in a successful manner. However, a newer version of the deployed 
functionality may be subsequently re-developed to include even more features 
and functionality, to replace the prior one. The reason could be a need 
experienced by end-users to use the functionality for a more specific purpose. 
The newer version may cause some of the older functionality to stop working.
 This, in a rough sense, can be understood as software regression.
For example, you could encode a program to display “Hello World” on the monitor.
 It might work perfectly, and display the message each and every time it is executed.
 Later on, the same code may be re-developed to accept the user’s name, and display
 it in lieu of “World.” The objective of thenew code might be to display 
“Hello John” rather than “Hello World.” However, once the newer code is developed 
and deployed, it actually ends up displaying the user’s name only - “John” - instead 
of the actual greeting “Hello John.” In this case, some of the older functionality associated 
with displaying “Hello” in the greeting is curtailed due to some coding reason and 
“missed out” by 
the newer code. This is software regression. 

Knowing a “bit” about what is Agile Scrum framework

Agile is a framework. It offers guidelines as to how software based projects can be 
effectively developed 

through consistent and sustained delivery of software functionality through short bursts 
of development activities known as “sprints.” Agile is based upon certain principles which 
suggest how the framework ought to be ideally understood and interpreted by people, 
and how the framework should function in an ideal working environment. One of the 
Agile principles state “Our highest priority is to satisfy the customer through early 
and continuous delivery of valuable software.” To support this principle, Agile 
framework supports an iterative (repetitive) product incremental cycle 
(a process through which smaller components or parts of the actual product are individually 
developed,and later integrated to form the complete product). At the end of one product 
increment cycle (sprint),Agile events known as the “Sprint Review” and “Sprint Retrospective” 
are held to ascertain the reliability of the code functionality developed during the sprint, 
and whether it satisfies the acceptance criteria so it can be considered as “bug free” 
and fully functional. Agile promotes “shippable” product increments i.e. small pieces of 
code offering a certain functionality that is complete, perfectly functional, and free 
of any “manufacturing” defects.It is worth knowing about the actual Agile process, events, 
roles, and artefacts which can help to eliminate bugs, and control the factors causing 
regression in software code. People new to Agile concepts and principles may find the 
framework difficult to understand. This article does not aim to educate the reader in 
Agile or Scrum framework. Rather, it aims to explain some of the important Agile 
characteristics which make the framework a very good choice for developing software 
projects. The objective is to describe how Agile can help to reduce regression levels during 
the development process. To understand how Agile can do this, it is important to know a 
“bit” about Agile first.

The product owner “PO” (Role)

He or she is the person who “owns” the project on behalf of the stakeholders or project 
owners. 

The person represents the interests of the stakeholders in the Agile project, and ensures 
that the project delivers a certain business value (importance in terms of market value 
and financial implications) at all times while the product is being developed. The individual 
is primarily responsible for the success or failure of the project.
The product backlog (Artefact)
It is a master list mentioning all features and functionalists to be developed in the 
software project,and to manufacture the software product in totality. Read more at
http://goo.gl/Gy8PXu

No comments:

Post a Comment