01-introduction.tex
3.92 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
\section{Introduction}
The complexity of writing software is an old subject on computer science dating
back to 1968 \cite{mcilroy1968software} when the term software crisis was
coined. Understanding and implementing client's requirements is a hard task,
due to the human aspects. Several development processes were introduced with
the intention to increase the chances of success in software projects, the
traditional and agile methods are the most popular. The former is a
process-centric based on the belief that variation on the project can be
detected in advance, consequently, it is possible to control the project by
continuous measure and refine\cite{agileSoftwareDevelopment}. Latter is based
on the belief that project is unpredictable, hence, it centered on small
interaction. The agile method has shown a great increase in productivity
\cite{onTheProductivityOfAgile, anAnalysisOfTrends}, as a result, many
researchers investigate how to make the transition from traditional to agile.
In this work, we demonstrated a less abrupt approach in which we tried to
harmonize different processes in the same project.
The traditional method has been used for a long time as a way to discipline the
software development process. This methodology can be characterized by the
predictive approach, focus on documentation, processes oriented, and heavy
based on tools\cite{comparisonAgileTraditional}. The agile method, on the other
hand, embraces the adaptative approach. It is characterized by the
people-oriented approach \cite{agileSoftwareDevelopment}, the collaboration
with clients \cite{theNewMethodology}, small self-organized teams
\cite{peopleFactor}, and the flexibility regarding planning
\cite{agileSoftwareDevelopmentEco}. In a nutshell, both methodologies intend to
increase the chance of the project success. Organizations like governments,
already absorb the traditional methodology as a part of its own culture. This
situation may produce tensions when two or more development teams with
different methodology have to collaborate [?].
%TODO: Achar ref para a última linha
As the agile methodology became popular, some researchers demonstrated an
increase in the software production due to this methodology
\cite{onTheProductivityOfAgile, anAnalysisOfTrends}. Additionally, companies
and organizations became interested to migrate from traditional to the agile
approach. However, the transition from traditional to agile is not an easy task
and have to deal with challenges related to people, process, management, and
technology\cite{challengesOfMigrating}. The organization culture is another
important factor to be considered for adopting agile
methodology\cite{impactOfOrganizationalCulture}. Finally, when we bring those
challenges and organizational barriers to the government context the situation
became more challenge.
In this paper, we argued that Layered approach can be used to harmonize
different processes in the same project with a little effort. We created
multiple layers in a project with a Brazilian government, wherein the
government is on the outer layer and the development team in the inner. All
layers are isolated, but they communicated with each other via interfaces. We
make two key contribution in this work:
\begin{enumerate}
\item We present quantitative and qualitative evidence that (i) Layered
approach can be applied to manage different processes in the same
project; and (ii) show the drawback and advantages of using Layered
approach.
\item We identify elements that, based on our experience, make Layered
approach viable.
\end{enumerate}
% TODO: Verificar as seções
Section \ref{sec:background} describe the layered approach. Section
\ref{sec:research_design} describes our research questions and methodology.
Section \ref{sec:discussion} presents findings derived from our quantitative
and qualitative analyses. Section \ref{sec:results} we describe the results.
Finally, we present the limitations, related work and conclusions.