01-introduction.tex
2.15 KB
\section{Introduction}
The difficulty of writing software is an old subject on computer science dating back to 1968 \cite{mcilroy1968software} when the term software crisis was coined. It refers to recurrent problems on software development such as exceeding time and budget expectations, inefficiency, low quality and maintainability among many others that usually culminate in the software not meeting the user expectations or not even being delivered.
Particularly, in the public sector the pessimism and failure ratios are even deeper than in the general industry \cite{goldfinch2007pessimism,anthopoulos2016government}. Because governments have rigid processes and organizational structures, it's hard to apply software development techniques that have been achieving good results in the private sector such as the broad spectrum of agile methods \cite{dybaa2008empirical}.
Introducing a new development methodology on a company is not an easy task. Introducing it on a government project can be even more challenging, specially on a low-budget scenario, in a politically unstable period and with a development team mostly formed by undergraduate students.
Knowing it would probably be a waste of time to persuade the government on adopting an agile methodology, we've chosen a less abrupt approach. Aiming to make minimal changes to the government's culture and still have the best possible result, our solution was to adapt some agile practices to our context. That included changes both on the government's and our team organization and processes.
In this paper, we report our experiences on a three-year-long project funded by the Brazilian government, focusing on the development process evolution made throughout that period. Despite all the risks and obstacles, the project final release was delivered one year ago and now has thousands of registered users. This report is not expected to be the final recipe on software development with the public sector, its main goal is to report which techniques have been successful, what adaptations were necessary and what has failed as means to provide other developers a reference when they meet similar situations.
% TODO: Maybe add a roadmap?