Workshop Brasileiro de Metodos Ageis

Conferencia Brasileira sobre Metodos Ageis

de Desenvolvimento de Software
Agile Brazil 2010
PUC - RS
24 de Junho de 2010

Mensagem do Coordenador de
Programa do WBMA
Neste ano, fiquei muito satisfeito ao organizar o primeiro workshop academico dedicado
ao desenvolvimento de metodos a geis no Brasil. Primeiro, gostaria de agradecer todo o
apoio que eu tive dos organizadores do AgileBrazil. Em seguida, gostaria de ressaltar a
importancia do WBMA, pois ja na nossa primeira edica o tivemos 33 submissoes completas. Isto indica que ja havia na comunidade academica uma necessidade por um evento
dedicado, seguindo a mesma linha de eventos tradicionais como as conferencias Agile e
XP.
Os membros do comite de programa foram essenciais na escolha dos melhores
artigos, das 33 submissoes completas apenas 11 artigos foram aceitos. Logo, o WBMA
ja nasce como um workshop grande, com taxa de aceitaca o de tres para um. Neste ano
ainda teremos como palestrante convidado no WBMA o pesquisador Philippe Kruchten,
professor da UBC em Vancouver (Canada).
Finalmente, gostaria de agradecer a todos os autores, membros do comite e revisores externos, sem os quais nao poderiamos ja nesta primeira edica o oferecer um evento
de qualidade.
Alfredo Goldman
IME - USP

Comite de Programa
Alexandre Vasconcelos
Alfredo Goldman (coordenador)
Ana Cristina Rouiller
Cleidson de Souza
Clovis Fernandes
Cristine Gusmao
Fabio Kon
Frank Maurer
Jutta Eckstein
Marcos Chaim
Maria Istela Cagnin
Marcio Delamaro
Rafael Prikladnicki
Raul Sidnei Wazlawick
Rodolfo Resende
Sergio Soares
Tore Dyba
Valter Vieira de Camargo

Revisores Externos
Alexandre Freire
Claudia Melo
Dairton Bassi
Debora Paiva
Eduardo Katayama
Felipe Besson
Fernando Kamei
Hugo Corbucci
Marcelo Fantinato
Marcio Cornelio
Paulino Viana
Renata Moreira
Tiago Massoni
Viviane Malheiros

Andre Abe Vicente

Celio Santana
Danilo Sato
Edson Murakami
Ellen Francine Barbosa
Fernando Castor
Gustavo Alves
Luiz Carlos Miyadaira Ribeiro
Marcelo Morandini
Mariana Bravo
Paulo Cheque
Rohit Gheyi
Vinicius Humberto Serapilha Durelli


Indice
Testes no contexto de metodos a geis: tecnicas, padroes e apoio automatizado
ClassMock: A Testing Tool for Reflective Classes Which Consume Code
Annotations
1
Eduardo Guerra, Fabio Silveira, Clovis Fernandes
ATMM uma ferramenta para gerenciamento de metricas de teste no contexto de metodos a geis
15
Andre Abe Vicente, Marcio Eduardo Delamaro
Ferramentas e tecnicas para metodos a geis
Software Process Improvement in Agile Software Development
30
Mariana Cervino, Celio Santana, Danilo Caetano, Cristine Gusmao
XP Tracking Tool: Uma Ferramenta de Acompanhamento de Projetos

Ageis
43
Carla Adriana Barvinski, Maria Istela Cagnin, Nilson Evaldo S. Lima Filho, Leandro Veronezi
Estudos conceituais com metodos a geis
Desenvolvimento de jogos e (quase) a gil
58
Fabio Petrillo, Marcelo Pimenta
Perspectiva Social, Comunicaca o e Cooperaca o nos Processos de Desenvolvimento de Software
70
Amaury Carvalho, Ciro Coelho
Estudos empricos com metodos a geis
Experiencia Academica de uma Fabrica de Software utilizando Scrum no
Desenvolvimento de Software
86
Alinne Santos, Adauto Filho, Igor Ramos, Joao Paulo Sette, Luciano Souza,
Luis Alberto Lima, Rafael Bacelar, Rebecca Carvalho, Fabio Silva
Agilidade na UFABC - Implantaca o da Metodologia Scrum na Divisao de
Desenvolvimento
99
Maurcio Szabo, Christiane Marie Schweitzer
Adoca o de metodos a geis em uma Instituica o Publica de grande porte - um
estudo de caso
112
Claudia Melo, Gisele Ferreira
Estudo de Caso da Utilizaca o de Scrum no Desenvolvimento Distribudo
de Software
126
Virgnia Chalegre, Wylliams Santos, Leandro Oliveira, Hernan Munoz,
Silvio Meira
Conducting an Architecture Group in a Multi-team Agile Environment 137
Mauricio De Diana, Fabio Kon, Marco Aurelio Gerosa

Sessao 1
Testes no contexto de metodos a geis:
tecnicas, padroes e apoio automatizado

ClassMock: A Testing Tool for Reflective Classes Which

Consume Code Annotations
Eduardo Guerra1, Fbio Silveira2, Clovis Fernandes1
1

Aeronautical Institute of Technology (ITA) , Praa Marechal Eduardo Gomes, 50

Vila das Accias - CEP 12.228-900 So Jos dos Campos SP, Brazil
2

Federal University of So Paulo (UNIFESP), Rua Talim, 330

CEP 12231-280 - So Jos dos Campos SP, Brazil

guerraem@gmail.com, fsilveira@unifesp.br, clovistf@uol.com.br

Abstract. In an automated test, a method can be called with different

parameters to verify its behavior within distinct contexts. Classes which use
reflection and metadata in its processing logic can have distinct behaviors
based on the structure of the class received as a parameter. This fact can
complicate the tests since a different class structure is necessary for each test.
This paper presents the ClassMock, which is an open source tool that can be
used to generate classes at runtime to be used in such tests. As a result, using
ClassMock the test code becomes less verbose and code duplication is avoided
in the test class.

1. Introduction
Automated tests perform an important role in agile methodologies (Beck 2000), since
they provide a fast feedback to the implemented functionality and give confidence and
safety for the developers to refactor the source code. This fact facilitates changes in the
source code, reducing its cost even in advance phases of the application development.
Test Driven Development is a software development technique, widely used with other
agile methods, where the unit tests are coded before the application code (Beck 2002).
This technique helps to ensure a good test coverage, besides other benefits like better
defects detection and a lower complexity in the source code (Canfora et al. 2009).
In this context, the quality and readability of the test code are important, since it
should be modified when a new functionality should be added or an existent one should
be modified (Guerra and Fernandes 2007). Based on that, it is important to avoid code
duplication and unnecessary verbosity on the test classes, aiming a better test code
design that is easier to understand and to modify.
In regular classes, the behavior can vary according to environment
configurations, methods invocation and data passed as parameters. In order to verify
each class behavior, the test should be able to manipulate those elements to simulate the
desired scenario. In classes which uses reflection (Maes 1987), the class structure and
elements of the instance received as a parameter have influence in the behavior. Those
classes can also read code annotations (JSR175 2003) (Schwarz 2004), which is a
metadata definition form that is part of the class structure.

In the test code of those classes, in order to simulate different situations, it is

necessary to create for each test, a new class with a specific structure. Differences
between the structure of each class are usually small, such as a change on a method's
name or a modification in an annotation parameter. The definition of an entire class in
each test makes the test code verbose and with a compromised readability, since
differences between classes can be hard to detect.
This paper presents ClassMock, which is a tool whose main objective is to help
in the generation of classes with a desired structure at runtime, making the test code less
verbose. Additionally, the facilities that it provides to manipulate the class structure can
help to avoid duplication, since code which generates it can be shared among different
test methods. Finally, this paper presents the use of ClassMock as a base to other test
tools, as well as the experience in its use to the tests of a metadata-based framework.
Section 2 presents more details about reflection and code annotations. Section 3
explains how tests to this kind of class are usually created, highlighting the main
problems of this approach. Further, Section 4 presents the ClassMock tool and how it
can be used in a test class, followed by Section 5, which shows how it can be used with
mock objects to test dynamic proxies. Section 6 presents the experience in the use of the
proposed tool in the test of the framework SystemGlue. Next, Section 7 presents the role
of ClassMock in the creation of JQuati, which is a test tool for aspect's pointcut
accuracy. At last, Section 8 highlights the main contributions of this research and
propose some future works.

2. Reflection and Code Annotations

The notion of computational reflection was first introduced by Smith (1982) in the
context of procedural languages. Reflection can be defined as the process by which a
computer program can observe and modify its own structure and behavior (Maes 1987).
A programming language can be classified as reflective if it provides meta-information
about its programs to themselves and a reflective architecture that separate the metainformation from the program itself (Doucet et al. 2003).
Introspection is the subset of reflection that allow a computer program to
obtain information about itself. A prerequisite to introspection is reification, that is a
data structure to store the reflected meta-information about program's structure and
properties. In this context, introspection is the capability to query the structure and
modify information in the base program (Doucet et al. 2003).
The Java programming language is an example of a language with introspection
capabilities. The Reflection API (Forman & Forman 2005) allows the access to the
program meta-information. For example, an instance of the meta class
java.lang.Class for a given class provide information about its superclass,
interfaces, methods and attributes. The meta class java.lang.reflect.Method
provides information about its return type, parameters and thrown exceptions. This
meta-information can be used by a program to instantiate classes and invoke methods.
Metadata is an overloaded term in computer science and can be interpreted
differently according to the context. In the context of object-oriented programming,
metadata is information about the program structure itself such as classes, methods and

attributes. A class, for example, has intrinsic metadata which can be retrieved using an
introspection API.
When a class uses reflection to access the class elements and execute its
responsibilities, sometimes the class intrinsic information is not enough. If its behavior
should differ for different classes, methods or attributes, it is necessary to add a more
specific meta-information to enable differentiation. For some domains, it is possible to
use marking interfaces, like Serializable in Java Platform, or naming conventions
(Chen 2006), like in Ruby on Rails (Ruby et al. 2009). But those strategies can be used
only for a limited amount of information and are not suitable for situations that need
more information.
An alternative to define this additional metadata that is becoming popular in the
software community is the use of code annotations, which is supported by some
programming languages, such as Java (JSR175 2003) and C# (Miller 2003). Using this
technique the developer can add custom metadata elements directly into the class source
code, keeping this definition less verbose and closer to it. The use of code annotations is
a popular practice in recent software development, as can be evidenced by its usage on
highly used frameworks and APIs such as Hibernate (Bauer and King 2006), Struts
(Brown et al. 2008), Spring (Walls and Breidenbach, 2007) and EJB 3 (JSR220 2006).
The use of code annotations is also called attribute-oriented programing
(Schwarz 2004), which can be defined as a program-level marking technique used to
mark program elements, such as classes, methods and attributes, with annotations to
indicate that they maintain application-specific or domain-specific semantics (Schwarz
2004) (Rouvoy e Merle 2006). This technique introduces a declarative approach inside
an imperative programming language.

3. Testing Classes with Reflection and Metadata

As presented in the Section 1, in order to test different possibilities in a class which uses
reflection, it is necessary to vary the class passed as a parameter. Those tests usually
uses classes with a similar structure varying some details which can influence in the
behavior. For instance, if the class under test (CUT) uses naming conventions, classes
passed as parameters should have different names for similar methods or attributes. A
further example, in the tests of classes which processes code annotations, the difference
between the parameter class can be a change in the annotations or in their attributes.
This work define as a mock class, a fake class created to define a test scenario for
classes whose behavior depends on the structure and metadata of the instance received
as parameter.
Those classes defined specifically for the tests can be defined inside the test class
or externally. The external definition has the drawback to keep the mock class apart
from the test code, which can prejudice the test readability. For instance, it is similar to
regular tests to define method parameters in a different file. The other alternative is to
define the mock classes as an inner class in the test code. This approach also has its
drawbacks, such as to make the test code verbose and to duplicate code in the similar
classes definitions.

Figure 1 presents two test methods, based on JUnit 4 (Massol and Husted 2003),
of the class PropertyMapFactory, whose method getPropertyMap()
generates a map from an instance properties by the introspection of its structure. An
inner class named Example is defined in both tests to generate the desired class
structure. The class structure is the same, except for the @Ignore annotation in the
getProp2() method in the second test. The code snippet where the Example class
is instantiated and its properties are set is exactly the same in both of tests. However, it
can not be reused since in each test Example is referring to a different class.
@Test
public void mapCreation(){
class Example{
private String prop1;
private int prop2;
public String getProp1() {return prop1;}
public void setProp1(String prop1) {this.prop1 = prop1;}
public int getProp2() {return prop2;}
public void setProp2(int prop2) {this.prop2 = prop2;}
}
Example example = new Example();
example.setProp1("test");
example.setProp2(13);
Map<String, String> map = PropertyMapFactory.getPropertyMap(example);

Assert.assertEquals("test", map.get("prop1"));
Assert.assertEquals("13", map.get("prop2"));

@Test
public void mapCreationWithIgnore(){
class Example{
private String prop1;
private int prop2;
public String getProp1() {return prop1;}
public void setProp1(String prop1) {this.prop1 = prop1;}
@Ignore public int getProp2() {return prop2;}
public void setProp2(int prop2) {this.prop2 = prop2;}
}
Example example = new Example();
example.setProp1("test");
example.setProp2(13);
Map<String, String> map = PropertyMapFactory.getPropertyMap(example);

Assert.assertEquals("test", map.get("prop1"));
Assert.assertNull(map.get("prop2"));

Figure 1. Two tests of a class which uses reflection.

This example illustrates that in the tests of this kind of class, the main
difference between the scenarios is in the class structure. Subtle differences in those
classes, such as in names or in annotation attributes, can be hard to perceive since the
verbosity in the class definitions hinders the test code readability. As a consequence,
similar code can be hard to be reused because it deals with distinct classes. The authors
did not find a specific tool which helps this kind of test, and the existent alternative is to
create each mock classes individually.

4. Testing with ClassMock

ClassMock is a tool which generates mock classes to be used in the test of classes based
on reflection and code annotation's processing. It can be used to test an individual class
or an entire component. The programmatic class definition enable the reuse of code
which generates part of its structure. For instance, it can be used to define part of the
mock class in the methods that execute before the test methods. ClassMock is opensource and can be downloaded at <http://classmock.sf.net>. Despite the tool support is
only for the Java language, a similar approach can be used to create similar tools for
other languages.
ClassMock is the main class of the tool and each instance of it can be used to
generate one mock class. It has methods to add properties (attributes with getters and
setters ), methods, attributes and annotations. The generated methods can be empty or
abstract depending on the ClassMock's method invoked. It uses the concept of fluent
interface (Fowler 2008), in which each method called returns the class instance. The
class ClassMockUtils provides some static methods that can be used to invoke
methods, create new instances, set properties and get properties on the generated mock
classes. Figure 2 presents the same tests of Figure 1 but now using ClassMock.
public class PropertyMapFactoryTest {
private ClassMock mockClass;
@Before
public void createMockClass() {
mockClass = new ClassMock("ExampleClassMock");
mockClass.addProperty("prop1", String.class).addProperty("prop2",int.class);
}
@Test
public void mapCreation() {
Object instance = createMockClassInstance();
Map<String, String> map = PropertyMapFactory.getPropertyMap(instance);

Assert.assertEquals("test", map.get("prop1"));
Assert.assertEquals("13", map.get("prop2"));

@Test
public void mapCreationWithIgnore() {
mockClass.addAnnotation("prop2", Ignore.class, Location.GETTER);
Object instance = createMockClassInstance();
Map<String, String> map = PropertyMapFactory.getPropertyMap(instance);

Assert.assertEquals("test", map.get("prop1"));
Assert.assertNull(map.get("prop2"));

private Object createMockClassInstance() {

Object instance = newInstance(mockClass);
set(instance, "prop1", "test");
set(instance, "prop2", 13);
return instance;
}

Figure 2. Using ClassMock to test the PropertyMapFactory

In this test class, the main mock class definition occurs in the method
createMockClass(), which executes before each test method. This definition can
be complemented in each method, as occurred in mapCreationWithIgnore() in
5

which the @Ignore annotation was added in the getter method of prop2 property.
Besides the code reuse, this definition makes clear what changes among the class
definition for each test method. The code snippet which deals with the generated classes
can also be reused by using the static methods set() and newInstance() of the
ClassMockUtils class.
Despite the increased code reuse and the reduced verbosity, the great drawback of this
approach is that it makes difficult the use of the test code as documentation. The
programmatic class definition does not provide direct examples of the classes as the
approach presented in Section 3. So, it is important to consider the role of the test code
in the project before using this technique.

5. ClassMock Usage With Mock Objects

A mock object can be considered a fake object which is used to replace class
dependencies, in order to isolate the CUT from them (Mackinnon et al. 2001) (Freeman
et al. 2004). A mock object does not only simulates the desired behavior for the test, but
also verifies if the method invocations performed on it are correct. Examples of
behavior simulation on a method invocation are: returning a value or throwing an
exception, and instances of verifications can involve the number of method invocations,
their parameter values or the sequence in which they are invoked. The mock object must
have the same contract of the one expected as a dependence, which is achieved by
implementing the same interface or extending the class.
The creation of mock objects for a large number of tests can be a hard task,
since a new class implementing the dependence behavior simulation and the
verifications should be created for each test. For that reason, a common practice is to
use a framework for an automated generation of the mock object, such as JMock (2010)
and Mockito (2010). This approach, besides providing a faster test development, also
enable the developer to express the test scenario inside the test method, improving its
readability.
It is important to distinguish between the mock objects and the mock classes,
which is a term introduced by this paper. On one hand, the mock objects simulates a
desired behavior and executes verifications for a given contract which the CUT depends
on. On the other hand, a mock class generates a new contract to enable the test to
simulate different structures for classes whose behavior depends on it.
Consistent with that, the generation of mock objects based on the contract of
mock classes can be used, for instance, for testing dynamic proxies. A dynamic proxy is
a proxy which can assume the wrapped object interface dynamically (Forman and
Forman 2005). The mock class can be used to generate a class or an interface to be
wrapped by the dynamic proxy, whose behavior can be based on its structure or in
annotations present on it. In addition, the mock object can be created based on the mock
class contract, verifying how the invocation is delegated to it by the dynamic proxy.
Figure 3 presents the source code of a test class which uses ClassMock in
conjunction with JMock. The CUT is the AuthorizationProxy, which is a
dynamic proxy that authorizes or not the invocation of the class method based on the
user roles and on the method's @AuthorizedRoles annotation. In the method

createMock(), the mock class called DummyInterface is created with a method

called execute() annotated with @AutorizedRoles(admin). A mock object
is created based on this interface.
The test method simulate the access of the execute() method by users with
different roles. The mock object is used to verify if the method was called or not based
on the scenario. This simple example aims to illustrate the use of mock objects and
mock classes together. In a real example, the security annotations could be varied
among the test methods to simulate a different scenarios.
@RunWith(JMock.class)
public class AuthorizationProxyTest {
Mockery context = new JUnit4Mockery(){{
setImposteriser(ClassImposteriser.INSTANCE);
}};
private Object mock;
@Before
public void createMock(){
ClassMock classMock = new ClassMock("DummyInterface",true);
classMock.addAbstractMethod(void.class,"execute")
.addMethodAnnotation("execute", AuthorizedRoles.class,new String[]{"admin"});
Class interf = classMock.createClass();
}

mock = context.mock(interf);

@Test
public void authorizedMethod() throws Throwable {
Object proxy = AuthorizationProxy.createProxy(mock, new User("john","admin"));
context.checking(new Expectations() {{
invoke(one(mock),"execute");
}});
invoke(proxy,"execute");
}
@Test(expected=AuthorizationException.class)
public void unauthorizedMethod() throws Throwable {
Object proxy = AuthorizationProxy.createProxy(mock, new User("john","oper"));
context.checking(new Expectations() {{
invoke(never(mock),"execute");
}});
}

invoke(proxy,"execute");

Figure 3. ClassMock with mock objects using JMock.

6. Using ClassMock for Framework Tests

This section presents the creation of automated tests for a real framework called
SystemGlue. This framework is open-source (SystemGlue 2010) and the test code
mentioned in this section are available with the main download file. The application of
ClassMock in the test of this framework was used to validate the proposed approach. In
this case study, the tests were created after the framework implementation.
SystemGlue is a framework whose main objective is to reduce the coupling
between the application main functionalities and concerns related to the integration with
other systems. It can be used to generate different integration profiles for the same

application to be deployed in different environments. SystemGlue uses dynamic proxies

to intercept method invocations and reflection to invoke the respective methods to
integrate with other systems. The developers should configure code annotations and/or
XML documents to define which methods should be invoked before and after the
application functionalities.
@RunWith(JMock.class)
public class SystemGlueTest {
Mockery context = new JUnit4Mockery(){{
setImposteriser(ClassImposteriser.INSTANCE);
}};
private Object mock;
private ClassMock baseClass;
private OtherClass mockCalled;
private Object mockBase;
private Object proxyBase;
@Before
public void createBaseClass(){
ProxyFactory.setProxyImplementation(ProxyFactory.REFLECTION);
baseClass = new ClassMock("ApplicationClass",true);
baseClass.addAbstractMethod(void.class,"executeWithParam",int.class);
mockCalled = context.mock(OtherClass.class);
MockFinder.addMock(OtherClass.class, mockCalled);
}
@Test
public void ruleExecution() throws Throwable{

//Add parameter name in parameter

baseClass.addMethodParamAnnotation(0, "executeWithParam",Param.class);
baseClass.addMethodParamAnnotationProperty(0, "executeWithParam",Param.class,
"value", "num");
//Add before annotation with rule
addAnnotation(ExecuteBefore.class, OtherClass.class, "otherExecution",
"executeWithParam");
baseClass.addMethodAnnotationProperty("executeWithParam", ExecuteBefore.class,
"rule", "num < 10");
//Add after annotation with rule
addAnnotation(ExecuteAfter.class, OtherClass.class, "toBeExecuted",
"executeWithParam");
baseClass.addMethodAnnotationProperty("executeWithParam", ExecuteAfter.class,
"rule", "num > 10");
createMock();
final Sequence sequence = context.sequence("sequence");
context.checking(new Expectations() {{
never(mockCalled).otherExecution();
invoke(one (mockBase),"executeWithParam", 15);inSequence(sequence);
one(mockCalled).toBeExecuted();inSequence(sequence);
}});
invoke(proxyBase,"executeWithParam",15);

private void addAnnotation(Class an, Class clazz,

baseClass.addMethodAnnotation(inMethod, an)
.addMethodAnnotationProperty(inMethod,
.addMethodAnnotationProperty(inMethod,
.addMethodAnnotationProperty(inMethod,
}

String call, String inMethod) {

an, "clazz", clazz)
an, "method", call)
an, "finder", MockFinder.class);

private void createMock() {

Class base = baseClass.createClass();
mockBase = context.mock(base);
proxyBase = ProxyFactory.createProxy(mockBase);
}

Figure 4. Using ClassMock for a test of the SystemGlue framework.

Figure 4 presents one of the tests performed on SystemGlue by using ClassMock

and JMock, with the respective auxiliar methods. This test address the functionality to
execute conditionally methods based on rules defined in the annotations.
A mock class is created in order to simulate the application class with the
annotations. The base of the mock class is created in the createBaseClass()
method, which is executed before each test. This class is complemented in the test
methods to define a structure necessary to that test scenario. The annotation @Param is
inserted in the method parameter to configure its name to be used in the rules. The
auxiliar method addAnnotation() is used to simplify the framework annotations
definition. In addition, an annotation property to define the invocation rule is also
defined.
Two mock objects are created in this test: one for the mock class and another for
the class to be invoked by the framework. A sequence is defined for JMock to verify if
the methods are invoked in the correct order. On one hand, according to the scenario,
the method otherExecution() should never be invoked, since the condition
defined in the annotation is not satisfied. On the other hand, the method
toBeExecuted() should be invoked since the condition is satisfied.
The annotations of the mock class methods varies along the other tests to
simulate different configurations. Since the framework should deal with a large number
of possibilities related to parameter mapping and annotation's configuration, ClassMock
was useful to provide a simple way to vary only the relevant pieces of the class structure
for each test.
The testing of frameworks are very important since it is reused in many
functionalities, even in more than one application. Reporting the experience of using
ClassMock for those tests it is important to highlight that the tool configuration for the
first test to run take some time, but the subsequent tests were not hard to create.
Authors consider SystemGlue a hard component to test, because its functionality is more
abstract than usual and it should deal with a lot of possibilities. In this context,
ClassMock was useful since it enables the generalization of the base class structure and
provides ways to specify only the important pieces for each test method scenario.

7. ClassMock Usage for Pointcut Accuracy Tests in JQuati

ClassMock can be used as a component for other test frameworks which needs to
generate classes at runtime. An example is JQuati (Santana et al. 2009) whose objective
is to simplify the creation of pointcut accuracy tests for aspects (Kiczales et al. 1997).
This section presents JQuati usage and how ClassMock is used in its internal structure.
To illustrate the use of JQuati, a simple example presented in (Santana et al.
2009) is used. Figure 5 presents the aspect under test, whose advice shootingSound
should be executed to generate a sound effect before any method named shoot.
Figure 6 presents the test created with JQuati to verify the pointcut accuracy.
The @RunWith annotation from JUnit must be used to configure the JQuati class as
its test runner. The @ExecutionContextCreation determine the classes and the
methods which should be generated to test the pointcut accuracy. Those classes are

created and stored in an instance of ClassExecutionContext, which is injected in

the test class by the test runner.
In
each
test
method,
the
annotations
@MustExecute
and
@MustNotExecute should be used to define which advices are expected or not to be
executed in such a test. The instance ClassExecutionContext can be used to
invoke methods on the generated classes to perform the verifications.
public aspect SoundEffectsTrigger {
@AdviceName("shootingSound")
before():execution(* *.shoot(..)) {
// make sound effect
}
}

Figure 5. Example of aspect under test

@ExecutionContextCreation(
methods={"void shoot (Integer, Integer)"},
className={"Gun", "Pistol", "RocketLauncher"})
@RunWith(JQuati.class)
public class SoundEffectsTriggerTests {
@ExecutionContextElement
ClassExecutionContext cec;
@Before
public void setup(){
cec.instanciateClasses( ) ;
}
@Test
@MustExecute ("shootingSound")
public void shouldCauseAShootingSound() throws ClassExecutionException{
cec.executeMethodOnAll("shoot",0,0);
}
}

Figure 6. Example of test using JQuati (Santana et al. 2009)

Figure 7 presents the architecture of JQuati. The main class, named JQuati, is
the test runner which orchestrates the invocation of the other components. It is
responsible to read the annotations from the test class, create the invocation context
instance and inject it on the test class.
The class ClassExecutionContext uses ClassMock to generate the classes
specified by the annotations. The generated classes are dynamically loaded and weaved
by the existent aspects at load-time. The simple specification using the annotations and
the class generation are important to enable a simple simulation of contexts involving
naming patterns and parameter configurations in which the advices should or not be
invoked.
The component AdviceInspector is responsible for verifying if each advice
are executed or not. The approach is similar to AdviceTracer (Delamare et al. 2009),
which is a very similar tool to the advice inspector and can define and verify
expectations regarding the execution of certain advices. The major JQuati differential is

10

that it supports the generation of the classes using ClassMock to simulate the joint
points, while using AdviceTracer the developer should write the classes for the test
manually.

Figure 7. JQuati Architecture (Santana et al. 2009)

JQuati illustrates how ClassMock can be used to simulate the execution context
for dynamic environments. In aspect-orientation, the pointcut usually depends on class
names and method signatures. In this context, ClassMock was used to simulate different
situations to verify whether the pointcut definition are defined according to the
requirements.
ClassMock also can be used to simulate execution environments for other kinds
of software. For instance, in (Wada and Junior 2009), it was used in a tool to define
metadata for the framework SwingBean (2009), which aims to generate user interfaces
at runtime, like forms and tables based on metadata and in the class structure. Since
SwingBean needs a Java bean class to execute, ClassMock was used to generate such
class at runtime to enable the user interface to be previewed. Based on this experience, it
is possible to state that ClassMock can also be used to simulate execution environments
not exclusively for testing tools.

8. Conclusion
This work addressed the automated tests of classes which uses reflection or consume
code annotations. Those classes usually are used in frameworks or in flexible solutions
which can be reused in different functionalities and contexts. Accordingly, this fact
highlights the importance of the test for those kind of classes. However, due to their
high abstraction level and generality, they comprise a hard task to test.

11

The present work introduced ClassMock, which is a tool whose main objective
is to simplify the test creation for classes which uses reflection or consume code
annotations. It enables a programmatic definition of runtime generated mock classes to
be used in the tests, allowing pieces of the class definition to be reused among them.
The proposed tool was employed in the tests of a real framework and used to compose
other tool for aspect's pointcut accuracy tests.
The following can be considered the major contributions of the present work:

The introduction of the term 'mock class', which is a technique already used in
those tests, which has not yet been differentiated from the concept of 'mock
objects'.

The creation of the framework ClassMock, which enables the definition and the
generation of classes at runtime.

The identification of practices using ClassMock which enable the class

definition code to be reused and its usage with mock objects.

The ClassMock usage as a component to simulate execution environments in

other tools.

The main future work in this subject is the use of ClassMock in further projects
and in different contexts. For instance, it was used in SystemGlue to create tests after
the codification and, in the next step, it can be used with Test Driven Development
approach. An important improvement in ClassMock refers to the simplification of the
class definition. An idea that would be studied is the definition of the method signatures
and annotations using Strings.
Future works could also address an experimental evaluation of the testing
creation using ClassMock. In this experiment, distinct developers should develop tests
for a framework with and without the usage of the proposed approach. Source code
measurements, questionnaires and the development time should be used to assess the
benefits and drawbacks of this approach.

References
Bauer, Christian; King, Gavin. Java Persistence with Hibernate. Manning Publications,
2006.
Beck, K. Extreme Programming Explained, Addison Wesley Longman, 2000.
Beck, K. Test-Driven Development by Example, Addison Wesley, 2002.
Brown, Donald; Davis, Chad Michael; Stanlick, Scott. Struts 2 in Action. Manning
Publications, 2008.
Canfora, G.; Viseggio, C.; Garcia, F.; Piattini, M. Measuring the impact of testing on
code structure in Test Driven Development. Tenth International Conference on
Agile Processes and eXtreme Programming in Software Engineering (XP 2009),
2009.
ClassMock. ClassMock - Test Tool for Metadata-Based and Reflection-Based
Components. Available at http://classmock.sf.net acessed in 2010-03-20.

12

Chen, Nicholas. Convention over Configuration. 2006. Available

http://softwareengineering.vazexqi.com/files/pattern.html acessed in 2009-12-17.

at

Delamare, R.; Baudry, B.; Ghosh, S.; Traon, Y. L. A test-driven approach to

developing pointcut descriptors in aspectj, in ICST 09: Proceedings of the 2009
International Conference on Software Testing Verification and Validation.
Washington, DC, USA: IEEE Computer Society, 2009, pp. 376385.
Doucet, Frederic; Shukla, Sandeep; Gupta, Rajesh. Introspection in System-Level
Language Frameworks: Meta-Level vs. Integrated. In: SOURCE DESIGN,
AUTOMATION, AND TEST IN EUROPE, 1., 2003. Proceedings... p. 382-387.
Forman, Ira ; Forman, Nate. Java Reflection in Action. [S. l.]: Manning Publications,
2005.
Fowler, Martin. Fluent Interface. Last Update 23 June 2008.
Available at
http://martinfowler.com/bliki/FluentInterface.html acessed in 2010-03-22.
Freeman, S. and Mackinnon, T. and Pryce, N. and Walnes, J. (2004) Mock roles, not
objects, In: OOPSLA 04: Companion to the 19th annual ACM SIGPLAN
conference on Object-oriented programming systems, languages, and applications,
New York, NY, USA, ACM, p. 236-246.
Guerra, E.; Fernandes, C. Refactoring Test Code Safely. In: ICSEA, 2007, Tahiti.
ICSEA'07, 2007.
JMock. jMock - A Lightweight Mock Object Library for Java. Available at
http://www.jmock.org accessed in 2010-03-22.
JSR175. JSR 175: A Metadata Facility for the Java Programming Language. 2003.
Available at http://www.jcp.org/en/jsr/detail?id=175 acessed in 2009-12-17.
JSR220.
JSR
220: Enterprise JavaBeans 3.0. 2006.
http://www.jcp.org/en/jsr/detail?id=220 acessed in 2009-12-17.

Available

at

Kiczales, Gregor; Lamping, John; Menhdhekar, Anurag; Maeda, Chris; Lopes, Cristina;
Loingtier, Jean-Marc; Irwin, John. Aspect-oriented programming. In EUROPEAN
CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, 1997. Proceedings...
p. 220242.
Maes, Pattie. Concepts and Experiments in Computacional Reflection. In THE
INTERNATIONAL CONFERENCE ON OBJECT ORIENTED PROGRAMMING,
SYSTEMS, LANGUAGES AND APPLICATIONS OOPSLA 1987. Proceedings...
[S.n.t.] p. 147-169.
Mackinnon, T. and Freeman, S. and Craig, P. (2001) Endo-testing: unit testing with
mock objects, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,
p. 287-301.
Massol, Vincent; Husted, Ted. JUnit in Action. Manning Publications, 2003.
Mockito. Mockito - Simpler & Better Mocking. Available at http://mockito.org
accessed in 2010-03-22.

13

Rouvoy, Romain; Merle, Philippe. Leveraging Component-Oriented Programming with

Attribute-Oriented Programming. In PROCEEDINGS OF THE 11TH ECOOP
INTERNATIONAL
WORKSHOP
ON
COMPONENT-ORIENTED
PROGRAMMING (WCOP 2006), Nantes, France, July 2006.
Ruby, Sam; Thomas, Dave; Hansson, David; Heinemeier, David. Agile Web
Development with Rails. Pragmatic Bookshelf, Third Edition, 2009.
Santana, E. C. ; Tanaka, S. H. ; Guerra, E. M. ; Fernandes, C. T. ; Silveira, F. . Towards
a Practical Approach to Testing Pointcut Descriptors With JQuati. In: III Latin
American Workshop on Aspect-Oriented Software Development - LA-WASP2009,
2009, Fortaleza.
Schwarz, Don. Peeking Inside the Box: Attribute-Oriented Programming with Java 1.5.
[S.n.t.]
2004.
Available
at
http://missingmanuals.com/pub/a/onjava/2004/06/30/insidebox1.html accessed in
2009-12-17.
Smith, Brian. Reflection and Semantics in a Procedural Language, PhD thesis,
Massachusetts Institute of Technology, 1982
SwingBean. Framework SwingBean. Available at http://swingbean.sf.net/ accessed in
2009-12-17.
SystemGlue. SystemGlue. Available at http://systemglue.sf.net/ accessed in 2010-05-14.
Wada, Marcos; Junior, Salomo. Estudo Comparativo de Ferramentas de Apoio ao Uso
de Frameworks Baseados em Metadados. Aeronautical Institute of Technology,
Technical Report, 2009.
Walls, Craig; Breidenbach, Ryan. Spring in Action. Manning Publications; 2nd edition,
2007.

14

ATMM uma ferramenta para gerenciamento de metricas de

teste no contexto de metodos a geis
Andre Abe Vicente1 , Marcio Eduardo Delamaro1
1 Instituto

de Ciencias Matematicas e de Computaca o

Universidade de Sao Paulo (ICMC)
Caixa Postal 668 13560-970 Sao Carlos SP Brasil
{avicente,delamaro}@icmc.usp.br

Abstract. From the characterization of the testing activity applied in agile development methods it was proposed a metrics set adoption to facilitate constant
tracking and improvement of this. Some of these test tracking metrics were implemented in the Agile Testing Metrics Management tool (ATMM). To validate
the tool it is presented a case study of a software project that used agile methods. The case study analyzed the adherence and maturity of the testing activity,
as well as tracking through testing metrics and software quality metrics related
to cohesion and coupling.
Resumo. A partir da caracterizaca o da atividade de teste de software aplicada
dentro de metodos de desenvolvimento a gil foi proposta a adoca o de um conjunto de metricas para facilitar o seu acompanhamento e melhoria constante da
mesma. Algumas dessas metricas de acompanhamento de testes foram implementadas na ferramenta Agile Testing Metrics Management (ATMM). Para validar a ferramenta e apresentado um estudo de caso com um projeto de software
que utilizou metodos a geis. O estudo de caso procurou analisar a aderencia
e maturidade da atividade de teste, alem do acompanhamento por meio de
metricas de teste e qualidade do software utilizando metricas relacionadas a`
coesao e acoplamento.

1. Introduca o
Metodos a geis foram desenvolvidos para beneficiarem a entrega rapida de codigo que
agregue valor ao cliente por meio do desenvolvimento em pequenos ciclos. Para atingir
esse objetivo, esses metodos sao focados na contnua interaca o entre desenvolvedores e
clientes, que garantem que o software atenda as necessidades de mudanca dos requisitos
do cliente [Paetsch 2003]. Os metodos a geis mudam o foco de documentaca o do projeto,
fortemente utilizado em metodos tradicionais, para tecnicas focadas no desenvolvimento
de codigo fonte e testes. Todo esse dinamismo dentro de metodos a geis tem provocado
um grande impacto na forma de se conduzir um projeto de software fortemente sensvel
a mudancas.
A utilizaca o de metodos de desenvolvimento a gil tem crescido sensivelmente.
Segundo [Sato 2007] esses metodos vem sendo adotados em diversos contextos, em
pequenas, medias e grandes empresas e ate agencias governamentais e universidades [Begel and Nagappan 2007, Dyba and Dingsyr 2009]. Em projetos que utilizam
metodos a geis, a atividade de teste de software vem sendo considerada uma atividade primordial, com o objetivo de evitar que a qualidade do produto e a conduca o do projeto nao
sejam afetados por processos menos formais de documentaca o e projeto em relaca o aos
15

metodos tradicionais [Simons 2005]. Os resultados dos testes servem como uma forma
de feedback instantaneo, no qual o desenvolvedor pode detectar em pouco tempo se o
metodo desenvolvido ainda precisa ser refatorado.
Para apoiar o feedback constante da equipe em projetos a geis sao utilizadas diversas praticas como reunioes diarias, reunioes de revisao e retrospectivas. Outra pratica que
apoia o feedback constante e a melhoria contnua e area de trabalho informativa que deve
fornecer instrumentos que fornecam dados sobre o andamento do projeto. Esses dados
serao coletados por meio de metricas de software que devem medir o progresso, apontar
melhorias e dificuldades durante todo o projeto [Crispin and Gregory 2009]. Nesse contexto, e importante que a equipe de desenvolvimento e teste utilize metricas para acompanhar essa atividade de teste, focando principalmente na melhoria contnua do processo,
das praticas e ferramentas de teste utilizadas. Por fim, essa equipe deve conduzir a atividade utilizando metricas para avaliar e estabelecer metas de qualidade para os artefatos
de teste produzidos. A partir de um codigo de teste de qualidade tambem sera possvel
medir de forma eficiente a qualidade do software produzido.
Alguns trabalhos [Sato 2007, Williams et al. 2004, Hartmann and Dymond 2006,
Crispin and Gregory 2009] propuseram abordagens para escolha e utilizaca o de metricas
de software em projetos a geis, alem disso alguns desses trabalhos tambem criaram
metricas especficas para projetos a geis. No entanto, a utilizaca o de metricas para acompanhamento da atividade de teste foi pouco explorada, havendo a necessidade de descrever melhor os objetivos de se utilizar cada metrica de teste e diversos aspectos que influenciam a utilizaca o dessas metricas. Alem disso, ha uma carencia de ferramentas que automatizem a coleta dessas metricas e fornecam a possibilidade de gerenciamento e analise
das metricas durante as iteraco es de desenvolvimento.
Nesse sentido, este artigo propoe a adoca o de um conjunto de metricas que podem ser utilizadas para o acompanhamento da atividade de teste. O principal objetivo
da utilizaca o dessas metricas e a melhoria contnua do processo de teste e tambem dos
artefatos de teste produzidos. As informaco es podem detectar problemas ou evoluco es e
metas de qualidade para os casos de teste produzidos.
O restante do artigo e estruturado conforme discutido a seguir. Na Seca o 2 sao
descritas as praticas ligadas a` atividade de teste no contexto de metodos a geis. Na Seca o
3 e apresentado um conjunto de metricas de teste que podem ser adotadas por uma equipe
de desenvolvimento a gil e tambem sao descritos aspectos gerais da ferramenta ATMM.
Na Seca o 4 e apresentado o estudo de caso com a ferramenta Kalibro e na Seca o 5 sao
apresentadas as contribuico es em relaca o a utilizaca o de metricas de acompanhamento de
teste em projetos a geis e tambem possveis trabalhos futuros.

2. Teste de Software em Metodos Ageis

A atividade de teste assume papeis essenciais dentro do processo de desenvolvimento de
software utilizando metodos a geis. O teste apoia a comunicaca o entre desenvolvedores e
clientes, fornece feedback sobre quais as funcionalidades do sistema estao funcionando
e apoia a manutenca o do sistema em ciclos iterativos e curtos. As mudancas tendem a
ser mais seguras se a equipe tiver um bom conjunto de testes para o sistema. Diversas
abordagens, estrategias e praticas de teste foram criadas ou adaptadas para o contexto de
projetos a geis, apoiando a integraca o contnua e o desenvolvimento de soluco es simples
e que atendam as necessidades do cliente.
Diferentemente de metodos tradicionais nos quais os testes ocorrem mais tarde
dentro do processo de desenvolvimento, os testes a geis devem ocorrer de forma frequente,
16

procurando detectar defeitos o mais cedo possvel dentro de ciclos de desenvolvimento

iterativos e curtos, com um constante feedback do cliente. Em projetos a geis, o codigo e
considerado completo apenas se passar por todos testes de unidade. Alem disso, no fim
de cada iteraca o, todos os testes de aceitaca o (business testing) que foram criados durante
a fase de planejamento serao executados por usuarios e clientes.
Entre as praticas de teste utilizadas em metodos a geis pode-se citar a estrategia de
desenvolvimento dirigido a testes (TDD) [Beck 2002] que pode ser utilizada para explorar, projetar, desenvolver e testar o software, nao devendo ser tratada apenas como uma
atividade de testes. Outras praticas de teste tambem sao utilizadas em projetos a geis: teste
de integraca o contnuo, teste de aceitaca o com o cliente e teste de regressao associado a
pratica de refatoraca o. Para complementar essas praticas a equipe pode utilizar o teste
exploratorio, teste da interface grafica (GUI) e teste de requisitos nao-funcionais que podem envolver por exemplo, requisitos de desempenho, carga ou stress. Na Tabela 1 e
apresentado um comparativo em termos de praticas para retrospectiva e melhoria durante
o projeto, alem das praticas de VV&T aplicadas dentro de projetos a geis.

Tabela 1. Comparativo entre Metodos

Ageis
(Reunioes,
Retrospectiva, Melhoria

e Tecnicas
e Praticas
de VV&T) [Vicente et al. 2009]
Retrospectiva e Melhoria

Tecnicas e Praticas de VV&T

XP

- Ciclos semanais e trimestrais

- Integraca o contnua e testes

- Test-Driven Development
- Testes de aceitaca o associados a historias do usuario

Scrum

- Reunioes diarias (Daily Scrum),

- Reuniao de revisao (Sprint Review)
- Retrospectiva

- Builds diarios e testes (todos os tipos)

- Testes durante o sprint e Teste de sistema

FDD

- Relato e visibilidade dos resultados

- Inspeco es de projeto e codigo

- Inspeca o do projeto e do codigo

- Teste de unidade

Crystal

- Monitoramento do progresso
- Workshops de reflexao

- Teste de regressao de funcionalidades automatizados

ASD

- Revisoes de qualidade

- Teste faz parte da construca o concorrente de componentes

- Inspeco es de codigo
- Revisoes para melhorar a qualidade do produto (Testes de
Aceitaca o e Sistema)

DSDM

- Workshops com o cliente

- Testes integrados durante todo o ciclo de vida

- Todo componente de software e testado pelos desenvolvedores e usuarios assim que sao desenvolvidos

3. Metricas de Software
Metricas de software sao padroes quantitativos de medidas de varios aspectos do projeto de software. A medica o dessas metricas em um projeto de software pode apoiar
estimativas, o controle de qualidade, a produtividade da equipe e o controle do projeto
[Pressman 2006]. Alem disso, um conjunto de metricas bem projetado pode ser utilizado
para medir a qualidade de produtos de trabalho, dar suporte a` tomada de decisao dos
gerentes de projeto e aumentar o retorno de investimento do produto [Kulik 2000]. Em
metodos de desenvolvimento a gil, a utilizaca o de metricas apoia a medica o contnua do
produto e do processo, permitindo que os ciclos de desenvolvimento sejam constantemente inspecionados, adaptados e melhorados [Hartmann and Dymond 2006].
Em [Hartmann and Dymond 2006] e definido um conjunto de sugestoes para que
uma equipe de desenvolvimento a gil defina boas metricas para sua equipe. De forma
geral, as metricas devem reforcar princpios a geis de colaboraca o com o cliente, entrega
de valor, simplicidade, se preocupando com as tendencias demonstradas. A quantidade
17

de metricas tambem deve sempre ser minimizada, facil de ser coletada e demonstrar os
fatores que as influenciam, evitando manipulaco es. Metricas a geis fornecem um guia para
a equipe a gil, medindo o progresso do projeto e procurando apontar quando a equipe esta
desviando dos objetivos da equipe, ou fornecendo o feedback de que a equipe esta no
caminho correto. Metricas podem nos alertar a respeito de problemas, mas analisadas de
forma isolada geralmente nao fornecem valor algum [Crispin and Gregory 2009]. Um exemplo desse cenario e a diminuica o da cobertura de codigo de um projeto, que pode gerar
preocupaco es se for utilizada de forma isolada. Uma das razoes da diminuica o da cobertura de codigo, por exemplo, poderia ser pela remoca o de codigo que nao estava sendo
utilizado e estava coberto por testes. Se removermos esse codigo e os seus respectivos
testes, a cobertura ira diminuir. Se utilizadas da forma correta, metricas podem estimular
o time, que tambem deve focar na qualidade, nao somente em numeros.
No contexto a gil, metricas de qualidade de codigo e de projeto oferecem conselhos objetivos, por exemplo, na identificaca o de a reas da aplicaca o candidatas a`
refatoraca o, assim como metricas de cobertura de codigo fornecem um guia necessario
para o TDD e tambem a refatoraca o [Knoernschild 2006]. Alguns trabalhos relacionados propoem metricas para projetos a geis, um deles e um framework de avaliaca o de
projetos em XP (XP Evaluation Framework) que sugere diversas metricas para projetos XP [Williams et al. 2004]. Em [Sato 2007] um conjunto de metricas organizacionais
e de acompanhamento e aplicada em projetos academicos e governamentais. Diversos
trabalhos avaliam projetos a geis por meio de metricas de programas orientados a objeto [Sato et al. 2007, Ambu et al. 2006]. Tambem ha trabalhos que propoe a automaca o
de metricas de software, como por exemplo a ferramenta GERT (Empirical Reliability
Estimation and Testing Feedback Tool) uma ferramenta de apoio ao TDD por meio do
acompanhamento metricas de teste, que apoiam os ciclos de feedback criados pelos testes
contnuos [Davidsson et al. 2004].
No entanto, ainda verifica-se a necessidade de mais estudos a respeito da utilizaca o
de metricas a geis para o acompanhamento da atividade de teste, os benefcios e dificuldades em utilizar essas metricas para a melhoria contnua da conduca o e dos artefatos
produzidos na atividade de teste. Alem disso, existe a necessidade em se produzir ferramentas que coletem as metricas de teste e facilitem o gerenciamento de iteraco es de
desenvolvimento relacionados a evoluca o dessas metricas.

3.1. Metricas de acompanhamento para Testes Ageis

As metricas de teste de software propostas neste trabalho foram criadas a partir de uma
lista de verificaca o proposta por [Hartmann and Dymond 2006]. Essa lista e baseada
na abordagem GQM (Goal Question Metric) e na abordagem Lean. O objetivo dessas
metricas e facilitar o acompanhamento da atividade de teste, visando a melhoria contnua
dos testes e consequentemente a qualidade do codigo fonte, com menos defeitos, com um
bom design e mais facil de ser mantido. Algumas das metricas foram propostas nesse
trabalho, outras metricas foram adotadas de outros trabalhos e descritas segundo a lista
de verificaca o. A origem das metricas de acompanhamento de teste deste trabalho sao
resumidas na Tabela 2 e uma das metricas e descrita na Tabela 3.
3.2. Ferramenta ATMM
A ferramenta Agile Testing Metrics Management (ATMM) complementa a proposta deste
trabalho, tendo sido desenvolvida como parte de suas contribuico es. Tem como objetivo
apoiar a atividade de teste de software no contexto a gil, especificamente na fase de teste
de unidade, em que os testes sao gerenciados em cada iteraca o de desenvolvimento. O
18


Tabela 2. Origem das metricas
de acompanhamento de teste adotadas no trabalho
Origem

Metrica
M1. Cobertura de Codigo

XP-EF
[Williams et al. 2004]
[Nagappan et al. 2005]

M2. Fator de Teste

Extrada de [Sato 2007]

M3. Quantidade de Casos de Teste e Assertivas

XP-EF
[Williams et al. 2004]
[Nagappan et al. 2005]

M4. Porcentagem de Assertivas de Teste de Unidade Passando e Falhando

Proposta neste trabalho

M5. Quantidade de Testes de Aceitaca o por Funcionalidades

[Nagappan 2004]

M6. Porcentagem de assertivas de teste de aceitaca o passando e falhando

Proposta neste trabalho

M7. Funcionalidades Testadas e Entregues (Running Tested Features ou RTF)

Extrada de [Sato 2007]

M8. Tempo de Execuca o de Testes

Proposta neste trabalho

M9. Quantidade de Defeitos Encontrados

XP-EF [Williams et al. 2004]

objetivo principal da ferramenta, alem de gerenciar essas iteraco es, e exibir metricas relacionadas ao codigo que esta sendo testado e aos casos de teste desenvolvidos utilizando
a ferramenta JUnit (bastante utilizada em projetos a geis). Alem disso, a ferramenta exibe
informaco es de cobertura a partir de informaco es extradas da ferramenta JaBUTi (Java
Bytecode Understanding and Testing)1 que utiliza criterios estruturais de fluxo de controle
e fluxo de dados [Vincenzi 2004].
A maioria das metricas da ferramenta ATMM e coletada de forma automatica (automatizada) e outras dependem da informaca o do usuario que esta utilizando a ferramenta.
Algumas das metricas coletadas pela ferramenta sao relacionadas diretamente ao acompanhamento da atividade de teste, sao elas: fator de teste, qtde de casos de teste, qtde
de assertivas, casos de teste com sucesso/falha/ignorados e tempo total de execuca o dos
casos de teste. O restante das metricas foram implementadas por serem facilmente coletadas e tambem contriburem para a avaliaca o das iteraco es de desenvolvimento, como
por exemplo a quantidade de classes de teste.
A ferramenta ATMM faz interface com a API Java Parser 2 e a ferramenta JaBUTi.
A arquitetura geral da ferramenta e descrita a seguir: (i) Coleta de informaco es do codigo
fonte e testes: a ferramenta utiliza a API Java Parser para coletar informaco es sobre o
codigo fonte e os casos de teste no formato da ferramenta JUnit, desenvolvidos em Java.
(ii) Execuca o dos casos de teste e coleta de informaco es de cobertura: utilizando a
ferramenta JaBUTi, a ferramenta ATMM executa os casos de teste, coleta informaco es
sobre essa execuca o dos testes JUnit e tambem informaco es de cobertura de codigo. (iii)
Gerenciamento das iteraco es: as metricas coletadas sao armazenadas a cada iteraca o de
desenvolvimento.
O primeiro passo da ferramenta ATMM e a criaca o do projeto e a seleca o de
informaco es gerais do projeto. Nesse passo o testador no incio do projeto devera inserir
informaco es que envolvem caractersticas gerais do projeto, a sua descrica o, as estrategias
ou tecnicas de teste que serao utilizadas no projeto, alem de outras praticas a geis que o
projeto utiliza, como programaca o em pares ou refatoraca o. Apos a criaca o do projeto,
o segundo passo e inserir informaco es sobre cada iteraca o de desenvolvimento e testes.
Ao fim de cada iteraca o o testador devera empacotar o codigo fonte e codigo de teste em
diretorios especficos e esses caminhos deverao ser informados a ferramenta. O terceiro
1
2

JaBUTi -(Project site) - http://ccsl.ime.usp.br/pt-br/project/jabuti

AST Java Parser (API) - Disponvel em: http://code.google.com/p/javaparser

19


Tabela 3. Metrica
- Porcentagem de Assertivas de Teste de Unidade Passando e
Falhando
Classificaca o: Objetiva, Quantitativa e Acompanhamento
Objetivo: Verificar qual a porcentagem de assertivas dos casos de teste de unidade/integraca o que estao passando
ou falhando.
Pergunta: Qual a porcentagem de assertivas de testes de unidade/integraca o que estao passando/falhando? Base
da Medica o: A porcentagem de assertivas passando sera dada pelo:
Base da medica o:
Assertivas Passando % = (No de assertivas passando / No total de assertivas )
ou
Assertivas Falhando % = (No de assertivas falhando / No total de assertivas )
Suposico es: A equipe esta desenvolvendo codigo fonte para determinadas funcionalidades do sistema que possuem testes de unidade/integraca o associados. Para cada caso de teste de unidade devem ser criadas assertivas
suficientes para verificar o comportamento (entrada/sada esperada) de uma unidade ou a integraca o dela com
outras unidades.
Tendencia esperada: Todo o codigo de produca o deve passar pelos casos de teste e consequentemente suas
assertivas.
Quando utilizar: Essa porcentagem deve ser utilizada para acompanhamento dos testes de unidade, podendo
verificar a existencia de defeitos em novas funcionalidades ou em funcionalidades alteradas durante a iteraca o.
Quando parar de utilizar: Apenas quando o projeto terminar, pois sempre a equipe de desenvolvimento deve
acompanhar os resultados da execuca o dos testes de unidade/integraca o para verificar a existencia de defeitos no
codigo de produca o.
Formas de manipular: Podem ser criadas diversas assertivas que nao melhorem a qualidade dos testes simplesmente para aumentar a porcentagem de assertivas corretas.
Cuidados e observaco es: Mesmo se todas as assertivas estao passando, isso nao garante que o teste de unidade e
consequentemente a funcionalidade funcionam de acordo com o desejo do cliente. Assertivas falhando podem ser
consequencia de um defeito no codigo desenvolvido como tambem defeito na assertiva.

passo (Figura 1(a)) ira exibir as metricas relacionadas ao codigo que esta sendo testado,
o codigo de testes e tambem uma tabela comparativa que mostra os valores das metricas
em cada iteraca o. Esses dados podem ser exibidos na forma de graficos comparativos
conforme ilustrado na Figura 1(b).
Ao final de cada iteraca o conforme os resultados das metricas apresentadas pela
ferramenta, o testador podera desenvolver mais casos de teste ou refatorar os casos de teste
existentes. A equipe pode decidir se essa tarefa sera realizada antes da retrospectiva da
iteraca o ou sera realizada na proxima iteraca o. Por fim, o resultado das metricas devera
ser discutido durante a reuniao de retrospectiva da iteraca o, e a equipe de desenvolvimento e teste podera estabelecer novas metas de qualidade do codigo-fonte e dos casos de
teste para a proxima iteraca o baseando-se nas metricas obtidas nas iteraco es anteriores. O
tracker devera atualizar as informaco es a respeito das metricas na a rea de trabalho informativa com graficos ou tabelas que mostrem a evoluca o das metricas durante as iteraco es.
Caso a equipe de desenvolvimento, teste e os gerentes do projeto acharem necessario, as
metricas poderao ser avaliadas diariamente e nao somente no final de cada iteraca o.

4. Estudo de Caso
Essa seca o apresenta o metodo utilizado no estudo de caso, as metricas avaliadas, uma
descrica o geral do projeto Kalibro, a analise dos resultados em termos das metricas de
acompanhamento de teste e metricas de qualidade ligadas a coesao e acoplamento.
O estudo de caso consistiu na avaliaca o da maturidade e aderencia a atividade
de teste do projeto Kalibro e a coleta das metricas de acompanhamento de teste propostas neste trabalho. Foi analisada a evoluca o dessas metricas sob a hipotese inicial de
que a utilizaca o de metricas de teste pode colaborar na detecca o de problemas durante a
conduca o dessa atividade, alem de monitorar a evoluca o da qualidade dos casos de teste,
que reflete na qualidade do codigo fonte produzido.
20

(a) Metricas (Tabelas)

(b) Metricas (Graficos)

comparativa das metricas

Figura 1. Ferramenta ATMM - Exibicao

A analise do projeto Kalibro apresentou algumas limitaco es, como a analise das
metricas de teste apos o projeto ter sido desenvolvido e tambem por se tratar de um projeto academico, com um estudo de caso sem um ambiente controlado como em um experimento, sendo difcil a generalizaca o dos resultados obtidos. Apesar dessas limitaco es
e de nao ter sido estabelecido toda a formalidade necessaria para um estudo de caso segundo a engenharia de software experimental, este estudo apresenta diversos resultados a
respeito da utilizaca o metricas para o acompanhamento da atividade de teste em projetos
a geis. Esses resultados podem servir como incentivo e guia para o uso de metricas de
software em projetos a geis para a melhoria contnua da atividade de teste.
4.1. Metodo e Metricas avaliadas
Para coletar as metricas de acompanhamento de testes de forma automatizada, foram
utilizadas as seguintes fontes de informaca o: (i) Ferramenta ATMM: a partir da ferramenta ATMM foram coletadas algumas das metricas de teste propostas nesse trabalho,
alem de metricas relacionadas ao codigo-fonte de cada projeto. (ii) Scripts da ferramenta JaBUTi: foram obtidas informaco es a respeito da cobertura de codigo conforme
criterios estruturais de fluxo de controle e fluxo de dados a partir de um conjunto de
scripts. (iii) Ferramenta Kalibro: foram coletadas algumas metricas da ferramenta Kalibro
para verificar a qualidade do codigo produzido no decorrer das iteraco es. Essas metricas
sao relacionadas a qualidade dos metodos produzidos, e tambem metricas de coesao e
acoplamento. (iv) Questionario: outras metricas quantitativas e subjetivas foram coletadas a partir de um questionario baseado no Extreme Programming Framework (XP-EF)
[Williams et al. 2004]3 .
4.2. Caracterizaca o do Projeto
Nessa Seca o serao apresentadas informaco es gerais do projeto Kalibro4 , que foi analisada
no estudo de caso deste artigo. A ferramenta Kalibro foi projetada para ser incorporada
a qualquer ferramenta de metricas de codigo fonte, extendendo essas ferramentas para
3
4

Questionario disponvel em: http://andvicente.wordpress.com/msc-project/

Ferramenta Kalibro (Projeto Mezuro) - Disponvel em: http://softwarelivre.org/mezuro/kalibro/

21

fornecer um facil entendimento na avaliaca o de qualidade do software analisado. A Kalibro permite que um usuario experiente em metricas de software especifique intervalos de
aceitaca o para cada metrica fornecida pela ferramenta base de metricas e permite a criaca o
de metricas customizadas a partir das metricas nativas da ferramenta base. Alem disso,
a ferramenta permite a configuraca o de categorias e pesos de cada metrica, e resultados
agregados de todo o codigo fonte ou resultados detalhados por classe.
Informaco es gerais do projeto Kalibro foram coletadas a partir de um questionario
subjetivo que tem como objetivo coletar dados gerais sobre projetos que utilizam metodos
a geis e relacionar essas informaco es com as metricas de acompanhamento de teste e
metricas de qualidade. Foram propostos neste trabalho duas novas categorias: a categoria de aderencia a pratica de teste de software e a categoria de maturidade da
atividade de teste de software. Essas duas novas categorias foram baseadas no trabalho
[Krebs 2002] e parte do questionario de metricas de aderencia proposto por [Sato 2007].
A aderencia a pratica de teste e calculada de 0 a 4, conforme as praticas das
seguintes categorias:
Atividades de teste de unidade automatizados [0- Nenhuma das atividades e
4- Segue todas as atividades]: (1) testes de unidade automatizados existem para
o codigo de produca o, (2) uma ferramenta e utilizada para medir a cobertura de
codigo, (3) ha uma forma automatizada de executar todo o conjunto de casos de
teste para todo o programa, (4) todos os casos de teste de unidade sao executados e
passam quando uma tarefa e finalizada e antes de integrarem o codigo, (5) quando
estao sendo consertados os defeitos do software, testes de unidade sao utilizados
para capturar o defeito antes de ser reparado, (6) testes de unidade sao refatorados,
(7) testes de unidade sao rapidos o bastante para serem executados com frequencia.
Atividades de teste de aceitaca o (Business Testing) [0- Nenhuma importancia
e 4- Total importancia]: (1) testes de aceitaca o sao utilizados para verificar uma
funcionalidade do sistema e requisitos do cliente, (2) o cliente fornece o criterio
de aceitaca o, (3) o cliente usa os testes de aceitaca o para determinar o que foi
terminado no fim de uma iteraca o, (4) o teste de aceitaca o e automatizado, (5)
uma historia nao e considerada finalizada ate que os testes de aceitaca o passem, (6)
testes de aceitaca o sao executados automaticamente toda noite, (7) um ambiente
compatvel com o ambiente do usuario final e utilizado para o teste.
Atividades do desenvolvimento dirigido a testes (TDD) [0- Nao aplicado e
4- Totalmente aplicado]: (1) codigo e desenvolvido somente apos um teste
de unidade (que falha) tenha sido escrito, (2) melhoria do codigo por meio de
refatoraco es, (3) uso de padroes para criaca o de testes, buscando a testabilidade e
qualidade dos testes, (4) os testes guiam o design do codigo-fonte, (5) todo codigo
de produca o e desenvolvido utilizando TDD.
A maturidade da atividade de teste de software e dividida em quatro categorias e
elas sao avaliadas da seguinte maneira:
Teste de unidade e TDD: possui seis nveis, que vao desde o projeto que nao
possui nenhum teste formal (0) ate o nvel em que a equipe se preocupa com
padroes para os testes, que incluem a preocupaca o com a testabilidade (5).
Teste de Aceitaca o e Teste de Sistema: possue apenas dois nveis, o de teste de
aceitaca o e o de teste de sistema. O nvel e calculado conforme a porcentagem
de opco es selecionadas (de 0 a 5). Se forem selecionadas 50% das opco es por
exemplo, sera atribudo um valor 2,5 e se nao forem utilizados testes de aceitaca o
e testes de sistema sera atribudo o nvel 0.
22

 Aspectos de automatizaca o do teste: possui seis nveis que tambem serao calculados conforme a porcentagem de opco es selecionadas (de 0 a 5). Se forem
utilizados apenas testes manuais sera atribudo o nvel 0.
Processo de teste e melhoria contnua: possui quatro nveis e o nvel e calculado conforme a porcentagem de opco es selecionadas (de 0 a 5). Se nao forem
utilizadas nenhuma das praticas sugeridas, sera atribudo o nvel 0.
O projeto Kalibro possui licenca de software livre e foi desenvolvido por
academicos de doutorado, mestrado e graduaca o utilizando programaca o extrema (XP)
e tambem a linguagem Java (J2SE). Para auxiliar a atividade de teste sao utilizadas as
seguintes praticas: testes de unidade, testes de GUI / usabilidade, metricas de codigo e
testes. Em relaca o a ferramentas, o projeto utilizou a plataforma Eclipse como ambiente
de desenvolvimento, e a ferramenta Xplanner e Noosfero para gerenciamento de projeto.
Alem disso, foram utilizadas as ferramentas JUnit (teste de unidade), Coverage (cobertura
de casos de teste) e Fest (teste GUI) para auxiliar a atividade de teste de software.
4.3. Analise dos Resultados
Nessa seca o sera apresentada uma analise dos resultados das metricas de acompanhamento de testes, que foram coletados pelos scripts da ferramenta JaBUTi (cobertura de
codigo), pela ferramenta ATMM (metricas do codigo fonte e acompanhamento de testes)
e tambem pela ferramenta Kalibro (metricas de qualidade do codigo produzido). As
metricas foram coletadas a partir do codigo fonte e os testes armazenados nos repositorios
de codigo dos projetos, sendo que no projeto Kalibro foram analisadas quatro iteraco es (4
meses de projeto)
Foram medidos o nvel de aderencia a` pratica de teste de software e tambem a
maturidade do projeto em relaca o a` atividade de teste. O nvel de aderencia (de 0 a` 4) foi
coletado por valores objetivos do questionario. O nvel de maturidade de cada pratica de
testes (de 0 a` 5) tambem foi coletado conforme as opco es selecionadas no questionario.
Esses dados sao apresentados na Tabela 4

Tabela 4. Kalibro - Nveis de aderencia

e maturidade da atividade de testes
Aderencia a` atividade de teste (0 - 4)
Testes de Unidade Automatizados
3
Testes de Aceitaca o com o Cliente (Business Testing)
1
Desenvolvimento Dirigido a Testes (TDD)
2
Maturidade da atividade de teste (0 - 5)
Testes de Unidade e TDD
Testes de Aceitaca o e Testes de Sistema

5
2,5

Max (TDD e Padroes)

Aspectos de Automatizaca o dos Testes

2 de 5 (40%)

Processo de Testes e Melhoria Contnua

2
3,75

Total de Praticas de Teste

2,1

3 de 7 (42%)

1 de 2 (50%)
3 de 4 (75%)

Em termos da aderencia a` atividade de teste, foi constatado uma maior aderencia

relaca o aos testes de unidade automatizados e uma menor aderencia a testes de aceitaca o e
ao TDD. A maturidade da atividade de teste de unidade e TDD e grande no projeto Kalibro
e tambem ha uma grande preocupaca o com o processo de testes e melhoria contnua.
4.3.1. Evoluca o da quantidade de codigo e testes produzidos
A evoluca o da quantidade de classes, e codigo fonte e codigo de testes produzidos no projeto Kalibro e descrita por meio da Tabela 5 e da Figura 2. Constata-se que nao houveram
23

grandes alteraco es no fator de teste na iteraca o 1 a` iteraca o 3, no entanto, na iteraca o 4 foi

produzido uma grande quantidade de codigo de testes (aumento de 66,26%), aumentando
o fator de teste para 0,71 (Figura 2(b)).

Tabela 5. Kalibro - Metricas

de Acompanhamento de Testes (Quantidade de

Codigo
e Testes)
Iteraca o 1

Metrica

Iteraca o 2

Iteraca o 3

Iteraca o 4

# de Classes SUT
# de Classes T

49

47
16

49

12

14

54
27

Metodos / Classes (SUT)

5.89

6.82

7.26

7.46

LOC SUT
LOC T
Fator de Teste
(LOC SUT / LOC T)

2924
1184

3098
1484

3249
1580

3649
2627

0.40

0.47

0.48

0.71

LOC / Classes (SUT)

59.67

65.91

66.30

67.57

LOC / Classes (T)

98.66

92.75

112.85

97.29

(a) Total LOC (SUT e T)

(b) Fator de Teste (LOC SUT / LOC T)

Figura 2. Kalibro - Quantidade de linhas de codigo

(LOC) e Fator de Teste

Adicionalmente tambem foi avaliada a qualidade do codigo produzido, utilizando

algumas das metricas fornecidas pela ferramenta Kalibro. A propria ferramenta sugere os
intervalos para que o resultados das metricas sejam considerados bons, ruins ou regulares
[Oliveira Filho 2009]5 : (i) AMLOC (Average Lines per Method - Numero medio de linhas por metodo), (ii) MMLOC (Max Method LOC - Numero maximo de linhas em um
metodo), (iii) LCOM4 (Lack of Cohesion in Methods - Ausencia de coesao em metodos),
(iv) ACC (Afferent Connections per Class - Conexoes aferentes de uma classe) , (v) CBO
(Coupling Between Objects Ligaco es entre objetos).
Os valores medios das metricas AMLOC e MMLOC mostram que o projeto Kalibro possui metodos pequenos que facilitam o seu entendimento, no entanto ainda apresenta alguns metodos com uma quantidade de linhas maior do que a sugerida. Segundo
a pratica da refatoraca o, sempre que possvel metodos com uma grande quantidade de
linhas devem ser refatorados [Fowler 1999]. Em relaca o as metricas LCOM4, ACC e
CBO que medem o grau de coesao e acoplamento, sugerem que a ferramenta Kalibro tem
classes com um bom grau de coesao entre seus metodos segundo a metrica LCOM4 e um
baixo acoplamento entre suas classes segundo as metricas ACC e CBO .
5

Apesar de ser utilizada pela ferramenta Kalibro, a configuraca o dos intervalos esta sendo avaliada e
ainda nao possui validaca o cientfica.

24


Tabela 6. Kalibro - Qualidade do codigo
fonte (AMLOC, MMLOC, LCOM4, ACC,
COF)
Iteraca o 1

Metrica

Iteraca o 2

11.55 (bom)
157.0 (ruim)
2.65 (regular)
3.16 (regular)
2,18 (regular)

AMLOC
MMLOC
LCOM4
ACC
CBO

7.69 (bom)
86.0 (ruim)
1.48 (bom)
0.98 (bom)
0.92 (bom)

Iteraca o 3
8.06 (bom)
86.0 (ruim)
1.56 (bom)
1.10 (bom)
1.04 (bom)

Iteraca o 4
7.20 (bom)
68.0 (ruim)
1.72 (bom)
1.25 (bom)
1.28 (bom)

4.3.2. Evoluca o do teste de unidade (Casos de Teste, Assertivas e Tempo de

Execuca o)
No projeto Kalibro os testes de unidade foram criados utilizando a ferramenta JUnit e
o framework Fest (para testes da GUI). Por meio da Tabela 7 e possvel constatar uma
evoluca o constante da quantidade de casos de teste e da quantidade de assertivas, sendo
que da iteraca o 3 para iteraca o 4 houve um aumento de 70% na quantidade de casos
de teste e 41,50% na quantidade de assertivas. A partir da relaca o entre esses dados de
evoluca o dos casos de teste e assertivas e o aumento do valor do fator de teste, pode-se
presumir que houve uma evoluca o da cobertura de codigo durante as iteraco es, principalmente da iteraca o 3 para iteraca o 4. O tempo total e o tempo medio de execuca o dos casos
de teste de unidade mantiveram valores aceitaveis, permitindo que sejam executados com
frequencia, a cada alteraca o no codigo fonte.

Tabela 7. Kalibro - Metricas

de Acompanhamento de Testes (Testes de Unidade)
Iteraca o 1

Metrica

Iteraca o 2

Iteraca o 3

Iteraca o 4

Qtde casos de teste

60

87

103

175

Qtde assertivas

231

317

378

535

19 / 40 / 1

85 / 1 / 1

102 / 1 / 0

173 / 1 / 1

0,2s

19s

22s

287s

0,016s

1,187s

1,571s

10,62s

Casos de teste com

Sucesso / Erro / Falha
Tempo Total
Tempo Medio de execuca o

4.3.3. Evoluca o da Cobertura de Codigo

Um dos benefcios do TDD, segundo [Beck 2002] e que a equipe consegue atingir 100%
de cobertura dos testes. No entanto, alguns tipos de codigo sao inerentemente difceis
de testar utilizando TDD (como por exemplo teste de GUI) [George and Williams 2004].
A equipe deve encontrar meios de testar esse tipo de codigo, utilizando um framework,
ferramenta ou ate mesmo executando testes manuais [Martin 2007]. Apesar de alguns estudos experimentais demonstrarem que a utilizaca o do TDD fornece codigos proximos
do 100% para cobertura de linhas e desvios do codigo [George and Williams 2004],
[Madeyski 2010] afirma que o impacto da pratica do TDD em termos de cobertura de
codigo e ainda nao conclusivo. Programadores que utilizam o TDD para escrever teste
de unidade, podem ser beneficiados por medidas que indiquem quando o software foi
testado de forma eficiente [Madeyski 2010]. Nesse contexto e apresentado na Figura 3 a
evoluca o da cobertura do codigo do projeto Kalibro utilizando criterios de teste estruturais
da ferramenta JaBUTi.
Observa-se que no projeto Kalibro houve uma grande evoluca o na cobertura do
25

(a) Criterios estruturais EI - Execution Independent (b) Criterios estruturais ED - Execution Dependent

Figura 3. Kalibro - Cobertura de Testes utilizando Criterios

de Fluxo de Controle
e Fluxo de Dados

codigo, sendo que a equipe constantemente se dedica a desenvolver novos casos de teste
para melhoria da cobertura. A preocupaca o com os testes pode ser constatada tanto
pela evoluca o da cobertura dos testes, como nos diversos comentarios nas revisoes do
repositorio de codigo, que informam a adica o de mais testes, alem dos documentos das
versoes entregues que mostram a cobertura alcancada nos pacotes de classes do projeto.
Outro aspecto interessante do projeto foi a utilizaca o do framework Fest para testar as
classes da interface grafica da ferramenta. Esses testes contriburam para o aumento da
cobertura do codigo de todo o projeto.

5. Conclusoes e Trabalhos Futuros

Os principais resultados obtidos a partir da avaliaca o das informaco es coletadas pelo questionario e pelas demais metricas avaliadas no estudo de caso foram:
Aderencia e maturidade da atividade de testes: apesar do projeto Kalibro possuir um nvel alto em relaca o aos testes de unidade automatizados, os testes de
aceitaca o e a estrategia TDD ainda nao sao utilizados totalmente. Em relaca o a
maturidade da atividade de teste, foi constatado que os testes de unidade ja possuem uma grande maturidade e tambem ha uma preocupaca o com o processo de
testes e melhoria contnua.
Evoluca o do codigo fonte,testes e cobertura do codigo fonte: analisando a
evoluca o do codigo e dos testes no projeto Kalibro, foi possvel verificar iteraco es
que deram uma maior e nfase a quantidade de testes criados. Essas iteraco es trouxeram um aumento visvel da cobertura de codigo. Alem disso, a utilizaca o de um
framework para o teste de classes de interface grafica no projeto Kalibro, contribuiu para o aumento da porcentagem de cobertura.
Qualidade do codigo: alem da equipe de desenvolvimento se preocupar em gerar
codigos com o mnimo de defeitos, a ferramenta Kalibro possui metodos pequenos
que facilitam o seu entendimento, tem classes com um bom grau de coesao entre
seus metodos e um baixo acoplamento entre suas classes.
A partir dos resultados obtidos no estudo de caso foi possvel analisar a evoluca o
do projeto Kalibro durante suas iteraco es de desenvolvimento, que evidenciou uma
preocupaca o com a melhoria dos casos de teste. Por meio do estudo de caso, pode-se
confirmar com suas devidas limitaco es a hipotese de que a utilizaca o de metricas de teste
pode colaborar na detecca o de problemas durante a conduca o dessa atividade, alem de
monitorar a evoluca o da qualidade dos casos de teste, que reflete na qualidade do codigo
fonte produzido. Esta hipotese foi confirmada pelo projeto Kalibro que apresentou bons
resultados em termos de metricas de acompanhamento de teste de unidade que resultaram
em uma alta cobertura de requisitos de teste, com poucos defeitos nos testes de unidade
26

e que possivelmente se refletiu no bom desempenho das metricas ligadas a qualidade do

codigo fonte.
A coleta de metricas de acompanhamento da atividade de teste fornece um feedback constante sobre os conjunto de casos de teste que sao desenvolvidos durante as
iteraco es do projeto. A partir desse cenario, e possvel que a equipe de desenvolvimento e
os gerentes de projeto utilizem as informaco es coletadas em reunioes diarias e retrospectivas de iteraca o para a melhoria contnua do processo de teste e tambem dos artefatos
de teste produzidos. As informaco es podem detectar problemas ou evoluco es em termos
da qualidade dos casos de teste produzidos. Alem disso, a equipe pode estabelecer uma
metodologia na qual sao estabelecidas metas de qualidade para as metricas de acompanhamento de teste antes do incio de uma iteraca o. As metricas podem ser gerenciadas
em um intervalo de tempo pre-estabelecido (diariamente ou por iteraco es) e podem ser
estabelecidos intervalos de referencia para que um determinado valor de uma metrica seja
considerado bom, regular ou ruim.
Tambem foi constatada a importancia de utilizar-se ferramentas de apoio como
a ferramenta ATMM. Utilizando essas ferramentas e possvel coletar as metricas rapidamente, utilizando uma interpretaca o u nica a respeito de cada metrica, com sadas que
possam ser facilmente interpretadas por desenvolvedores e gerentes de projeto.
Para dar continuidade as atividades apresentadas neste artigo, poderao ser realizados os seguintes trabalhos futuros: validaca o mais aprofundada das metricas utilizando metodos de validaca o teorica e experimental, definir valores de referencias para
as metricas, alem de compor novas metricas de acompanhamento de teste e conduzir o
estudo de caso em disciplinas academicas e projetos a geis da industria durante o seu desenvolvimento. Alem disso, seria interesante desenvolver algumas melhorias a ferramenta
ATMM para dar suporte a metricas de outras linguagens, metricas de teste de aceitaca o,
possibilidade de coletar o codigo diretamente do repositorio de codigo e integraca o com
a ferramenta Kalibro para que seja possvel configurar valores de referencia para as
metricas.

Agradecimentos
Este trabalho contou com apoio financeiro do Conselho Nacional de Desenvolvimento
Cientfico e Tecnologico (CNPq).

Referencias
Ambu, W., Concas, G., Marchesi, M., and Pinna, S. (2006). Studying the evolution of
quality metrics in an agile/distributed project. In Extreme Programming and Agile
Processes in Software Engineering, XP 2006, Oulu, Finland, pages 8593.
Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA.
Begel, A. and Nagappan, N. (2007). Usage and perceptions of agile software development
in an industrial context: An exploratory study. In Proceedings of the International
Symposium on Empirical Software Engineering and Measurement, pages 255264.
IEEE.
Crispin, L. and Gregory, J. (2009). Agile Testing: A Practical Guide for Testers and Agile
Teams. Addison-Wesley Professional.
Davidsson, M., Zheng, J., Nagappan, N., Williams, L., and Vouk, M. (2004). Gert: an
empirical reliability estimation and testing feedback tool. In 15th International Symposium on Software Reliability Engineering (ISSRE 2004), pages 269280. IEEE.
27

Dyba, T. and Dingsyr, T. (2009). What do we know about agile software development?
IEEE Software, 26:69.
Fowler, M. (1999). Refactoring: improving the design of existing code. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA.
George, B. and Williams, L. (2004). A structured experiment of test-driven development.
Information and Software Technology, 46(5):337 342.
Hartmann, D. and Dymond, R. (2006). Appropriate agile measurement: Using metrics
and diagnostics to deliver business value. In Proceedings of Agile Conference 2006
(AGILE 06). Minnesota, USA, pages 126134, Washington, DC, USA. IEEE.
Knoernschild, K. (2006). Using metrics to help drive agile software. Agile Journal.
Disponvel em: http://www.agilejournal.com/articles/columns/the-agile-developer/56using-metrics-to-help-drive-agile-software. Acesso em: 15/01/2010.
Krebs, W. (2002). Turning the knobs: A coaching pattern for xp through agile metrics.
In Extreme Programming and Agile Methods - XP/Agile Universe 2002, Chicago, IL,
USA, pages 6069. Springer.
Kulik, P. (2000). A practical approach to software metrics. IT Professional, 2(1):3842.
Madeyski, L. (2010). The impact of test-first programming on branch coverage and mutation score indicator of unit tests: An experiment. Information & Software Technology,
52(2):169184.
Martin, R. C. (2007). Professionalism and test-driven development. IEEE Software,
24(3):3236.
Nagappan, N. (2004). Toward a software testing and reliability early warning metric suite.
In 26th International Conference on Software Engineering (ICSE 2004), Edinburgh,
United Kingdom, pages 6062. IEEE Computer Society.
Nagappan, N., Williams, L., Osborne, J., Vouk, M., and Abrahamsson, P. (2005). Providing test quality feedback using static source code and automatic test suite metrics. In
16th nternational Symposium on Software Reliability Engineering, pages 8594. IEEE.
Oliveira Filho, C. M. d. (2009). Kalibro: Uma ferramenta de configuraca o e interpretaca o
de metricas de codigo-fonte. Trabalho de Conclusao de Curso, IME/USP.
Paetsch, F. (2003). Requirements Engineering in Agile Software Development. PhD thesis,
University of Calgary, Calgary, Alberta.
Pressman, R. S. (2006). Engenharia de Software. McGraw-Hill, Sao Paulo, 6 edition.
Sato, D., Goldman, A., and Kon, F. (2007). Tracking the evolution of object-oriented
quality metrics on agile projects. In Proceedings of Agile Processes in Software Engineering and Extreme Programming (XP 2007), pages 8492. Springer.

Sato, D. T. (2007). Uso eficaz de metricas em metodos Ageis

de desenvolvimento de
software. Masters thesis, IMEUSP, Sao Paulo, SP.
Simons, A. J. H. (2005). Testing with guarantees and the failure of regression testing in
extreme programming. In Proceedings of Extreme Programming and Agile Processes
in Software Engineering (XP 2005), pages 118126. Springer.
Vicente, A. A., Delamaro, M. E., and Maldonado, J. C. (2009). Uma Revisao Sistematica

sobre a Atividade de Teste de Software em Metodos Ageis.

In XXXV Conferencia
Latinoamericana de Informatica (XXXV CLEI), Pelotas - RS, Brasil. CLEI.
Vincenzi, A. M. R. (2004). Orientaca o a Objetos: Definica o, Implementaca o e Analise
de Recursos de Teste e Validaca o. PhD thesis, ICMC-USP, Sao Carlos, SP.
Williams, L., Krebs, W., Layman, L., Anton, A. I., and Abrahamsson, P. (2004). Toward a
framework for evaluating extreme programming. In Empirical Assessment in Software
Engineering (EASE), Edinburgh, Scotland, pages 1120.
28

Sessao 2
Ferramentas e tecnicas para metodos
a geis

Software Process Improvement in Agile Software

Development
Clio Santana2, 3, Mariana Cervio1, Danilo Caetano2, Cristine Gusmo2
1 Departamento

de Sistemas Computacionais, Escola Politcnica de Pernambuco (POLI)

Universidade de Pernambuco (UPE) Rua Benfica, 445, Madalena 50.751-460 Recife,
PE Brasil
2 Curso

de Sistemas de Informao - Faculdades Integradas Barro Melo Av.

Transamaznica, 405, Jardim Brasil 53.300-240 Olinda, PE Brasil
3 Centro

de Informtica Universidade Federal de Pernambuco

Caixa Postal 7.851 50.732-97 Recife PE Brasil

{maricervino, celio.santana, danilocaetano1987, cristinegusmao} @gmail.com

Abstract. Organizations are increasingly adopting agile methodologies and traditional
methods in their software development process. This emerging scenario brings new challenges
and opportunities for process improvement software. The Nokia Test is an effective method to
assess how different teams are using Scrum seeking their adherence to the procedure
proposed by this agile method. Quality and productivity are the key indicators when using
traditional maturity model of software process improvement CMMI. The aim of this study is
analyze the relationship between the traditional methods of software process improvements
that emphasizes continuous improvement of the organizational development. But the agile
approach of software development is iterative, encourage improvements in software
development increasing the individual effectiveness into the team.

Keywords: Scrum, Agile software development, Nokia Test, CMMI, Software Process Improvement.

1 Introduction
Software process improvement (SPI) has become a practical tool for companies where the quality of
the software is of high value [Jarvinem 1994]. In a technical report with results from thirteen
organizations, and with the number of post-release defect reports used as a measure, Herbsleb and

30

others practitioners (1994) showed that due to software process improvement (SPI), the products and
business value (especially return on investment ROI) was improved.
It is generally considered that a well documented and a repeatable process is essential for
developing software products of high quality [Stamelos & Sfetsos 2007]. There is also evidence that
the use of standards and process assessment models has a positive impact on the quality of the final
software product [Kitchenham 1996].
The software engineering community has gradually moved from product quality-centered
corrective methods to process quality-centered, preventive methods, thus shifting the emphasis from
product quality improvement to process quality improvement. Inspections at the end of the production
line have long been replaced by design walkthroughs and built-in quality assurance techniques
throughout the development life cycle [Georgiadou 2004].
In traditional SPI methods and approaches the aspect of organizational improvement has
usually been placed in a central role, due to the fact that the planning and control of the SPI initiatives
are managed by the organizational stakeholders [Basili & Caldiera 1994, SEI 2006]. The reported
positive effects of SPI methods and approaches include reducing indicators such as time to market,
risks and costs, and increasing the productivity and quality in software development organizations
[Krasner 1999, Van Soligen & Berghout 1999].
However, various negative effects have also been encountered, e.g. regarding the costeffectiveness of SPI initiatives, their actual effectiveness in improving the software development
practices of organizations, the volume of the effort needed to implement SPI initiatives and the low
speed at which visible and concrete results are achieved [Krasner 1999, Goldensen & Herbsleb 1995,
Dyb 2000].
In fact, it has been reported that around two-thirds of SPI traditional initiatives fail to achieve
their intended goals [Debou 1999]. From the mid-1990s onwards, agile software development
principles and methodologies have been increasingly challenging the traditional view of software
development, and therefore, provides a highly untraditional approach to SPI, in which the process
improvement knowledge of software developers and software development teams is acknowledged and
valued [Salo 2007].
We have long known that skilled people are the most crucial resource in software
development. Bach (1994) stated that Everyone knows the best way to improve software productivity
and quality is to focus on people. However, it took more than 10 years for the agile manifesto and
agile methods (extreme programming, scrum, crystal, and many others) to truly place the emphasis on
people and their interaction [Stamelos & Sfetsos 2007].
This paper presents a state of the art review about SPI in agile software development, this
work is part of two MSc dissertations and in this light after this introductory section, the Section 2

31

explores software process improvement, the Section 3 explores the Software Process Improvement in
Agile Software Development, the Section 4 will present the conclusions of the paper.

2 Software Process Improvement

A software process can be defined as the sequence of steps required to develop or maintain software
aims at providing the technical and management framework for applying methods, tools, and people to
the software task [Humphrey 1995]. However, even the most exquisitely defined and managed process
may still not meet the context specific needs and objectives of software development organizations and
customers regarding, for example, performance, stability, compliance and capability [Florac et al.
2000].
Thus, SPI aims providing software development organizations with mechanisms for evaluating
their existing processes, identifying possibilities for improving as well as implementing and evaluating
the impact of improvements [Florac et al. 2000].
Traditionally, the ultimate goal of SPI in organizations is to provide a Return on Investment
(ROI) for the organization through the improvement activities yielding more money than is spent on
them [Rico 2004]. ROI has been reported for various SPI achievements, such as improved efficiency of
the development process and reduction of total software costs, increased quality of theend product,
higher predictability of cost and schedule, and increased level of reuse (Krasner 1999).
The focus on quality in SPI is based on the fundamental ideology that quality-driven
development is likely to yield not only better quality but also lower cost and improvement of
competitive position [Deming 1990].
One of the characteristics of SPI, as traditionally defined, is its emphasis on the continuous
improvement of organizational software development processes in terms of performance, stability,
compliance, and capability, for instance. Often the existing SPI methods and approaches seem to
enhance the underlying business goals and needs in the improvement of organizational software
development processes [Salo 2007]. Traditionally, SPI initiatives are also strictly controlled and
managed by the organizational stakeholders (Boehm & Turner 2003).
Salo (2007) identified six different elements in the context of traditional SPI: (1) The
organizational models of continuous improvement, (2) standard processes and assessments, (3)
tailoring, (4) deployment, (5) measurement, and (6) the utilization of knowledge and learning in SPI.
The focus of this work is research related to (1) The organizational models of continuous
improvement, (2) standard processes and assessments because these subjects were investigated widely
in previous researches. The others subjects were not studied or adopted in software industry enough to
present a substantial content about the subject, once that researches are just found in Salo (2007) work.

32

3 Software Process Improvement in Agile Context

Salo (2007) states that agile software development provides new possibilities for conducting SPI,
which may well provide grounds for meeting some of the central challenges of traditional SPI. agile
software development provides a highly untraditional approach to SPI, in which the process
improvement knowledge of software developers and software development teams is acknowledged and
valued.
This difference comes from the idea of the traditional goal of a software process is to provide
high predictability, stability, and repeatability using highly managed and quantitatively monitored
software development processes. On the other hand, agile principles highlight the need for the software
process to be flexible, to be able to rapidly respond to the constant changes and context specific needs
of software development [Salo 2007].
As a result, traditional software development emphasizes up-front contract negotiations where
the requirements, cost and schedule of the product development are fixed and the end product will be
delivered at the end of the project lifecycle. In this mode of software development, traditionally,
extensive documentation and quantitative monitoring of the product development process plays a
central role. The principles and practices of agile software development, in turn, address the constant
changes. [Salo 2007].
The following subsections will present what of the aspects identified in researches based in the
six elements is software process improvement stated by Salo (2007) and is related with agile software
development.

3.1 Agile Software Process Improvement Based on Team Behavior (Salo 2007)
Salo (2007) states when considering the relationship between agile software development and SPI,
there are three principles, in particular, of the agile manifesto that deserve attention: the valuing of
individuals and interactions over processes and tools, the principle that encourages regular reflection
by software development teams in order to become more effective, and the self-organization of
software development teams. Taking regular improvement within project teams as one of the twelve
principles of agile software development highlights the importance of continuous improvement also in
the agile software development context. In order to welcome changes throughout the agile software
development project, whether they concern product requirements or technical aspects, the software
process with its practices, methods, and tools must be able to adapt to the specific context while also to
respond to the changes when needed.
Salo (2007) also states that traditionally, SPI has been approached in a top-down manner, in
which the organizational level has played a major role in defining the goals of SPI and planning,
managing, and controlling the SPI initiatives. In the agile software development context, on the
contrary, the experience and knowledge of software developers and the self-organization of software
developers in improving and adapting their daily working practices have been clearly placed in a
central role.

33

In the agile approach, the role of management is to organize and co-ordinate rather than plan,
execute, or control. Furthermore, the contextual needs for improving and adapting processes
throughout the entire development process are emphasized, rather than the organizational goals in the
regular SPI activities of development teams [Salo 2007].
The strong difference between the traditional and agile SPI could be seen when Salo (2007)
compares both approaches considering the SPI element organizational models of continuous
improvement, these differences are shown in Table 1. The agile view is entirely based on team
behavior.
Table 1: Organizational SPI Models [Lycett at al 2003].

3.2 Agile SPI Based on tools automation - Process Centered Software Engineering
Environments
Gruhn (2002) states that software process denotes the set of all activities which are carried out in the
context of a concrete software development project. It usually covers aspects of software development,
quality management, configuration management and project management. The description of a
software process is called a software process model. A software process model does not only describe
the activities which have to be executed, but also the tools to be used, the types of objects and
documents to be created/manipulated and the roles of persons involved in software development. One
of the key questions for supporting software processes is how software process models and software

34

engineering environments are related or in other words how a supporting infrastructure can be
derived from the information given in a software process model.
Software engineering environments (SEEs) are meant to support software development.
Process-centered software engineering environments (PCSEEs) give up the notion of a predefined
process model. Process models used in this way should define which software development activities
are to be executed when and by whom, they should identify tools to be used and the format of
documents to be created and/or manipulated.
Then, the process model is interpreted at runtime to identify which process behavior has to be
supported. In concrete this means, that software developers are reminded of activities which have to be
carried out, automatic activities are executed without human interaction and consistency between
documents is enforced up to a certain level [Gruhn 2002].
Actually PCSEEs is closely related to the purpose of software process improvement. The
findings gathered during process modeling and the results of process model analysis usually indicate
how actual processes can be improved in order to contribute to improved process productivity and
product quality [Gruhn 2002].
Four elements of PCSEE are important to understanding tools automation in this context these
elements are [Gruhn 2002]:
Workflow management: The idea of workflow management is that process models are used
as basis of real processes, i.e. real processes are governed on the basis of the underlying process
models. A workflow engine checks process models and the actual process state in order to identify
which activities can be executed and lets potential participants know about it.
Automation: The process modeling purpose of automation is closely related to the purpose of
workflow management. While workflow management tries to automate the coordination between
activities, the immediate automation of single activities is another purpose of process modeling. In the
context of software processes, activities like checking in and out of configuration units, building
releases, evaluating test set coverage etc. usually can be automated. If automation is a major goal, then
at least the preconditions for activities to be automated have to be described in detail.
Monitoring: Another purpose of process modeling is to measure the deviation between what
processes are supposed to look like and how they actually behave. Then, traces of real world processes
can be used to identify what the deviations are. Usually, process monitoring is not a self-contained
purpose, but only a first step towards SPIor process automation.
Deriving support for tool integration: Based on the assumption that not all parts of software
processes are suited for workflow management support and that different parts of software processes
deserve different kinds of support and based on the experience that different software processes require
different tools, the integration of which results in process specific challenges, a modest even though
worthwhile purpose of process modeling is to identify the requirements for tool integration in the
context of a concrete process model.
The first value of Agile Manifesto (2001): Individuals and interactions over processes and
tools, lead the agile practitioners to give little importance to using tools. But, seven years later, one of
the agile manifesto signatories, Brian Marick (2008) stated that the first agile value should be revised
once that tools help teams to deal with non creativity tasks.

35

Many agile teams are adopting tools to automate their process. Beck (1999) states that teams
must have one computer testing and integrating source code all time. Adopting the four elements of
PCSEE purposed by Ghrun (2002) and seeking their use in agile in teams
Workflow management: Many Agile teams are using issues tracking tools to control the
stories flow inside the teams [Abrahamsson et al 2002]. In this scenario, these tools are acting as
workflow management tools.
Automation: Agile teams are using continuous integration servers and tests robots to maintain
the high quality of the final product [Abrahamsson et al 2002]. When automating these parts, the team
releases its members for doing creativity tasks while automated tasks ensure that there will not be
occasional failures in the process.
Monitoring: Spreadsheets, Charts, Wiki are commons tools for monitoring the progress of the
projects. But many teams are including process metrics like builds broken or tests cases wrote per story
[Jackobsen 2009]. This is an example of tools monitoring not the project but the process as well.
Deriving support for tool integration: Agile teams usually use different tools for performing
different tasks [Abrahamsson et al 2002]. The integration of all these tools becomes painful for agile
teams challenging them. No one of these elements where formally studied in agile SPI perspective.

3.3 Agile Assessment Methods Nokia Test

Following the Salos (2007) definition for SPIelements, this subsection refers about the element (2)
processes and assessments. An urgent need has been recognized for a set of guidelines for agilitycompatible standard process maturity assessments and also for a set of standards for the
acknowledgement of agile methods by lead assessors (Boehm & Turner 2005).
The agile assessment method has been suggested as providing a lightweight approach for
assessment to identify and adopt the most suitable agile methods amongst the existing organizational
practices [Pikkarainen & Passoja 2005]. Furthermore, techniques have been suggested for increasing
the agility level of a software development team by assessing the current agility level against the
defined agility goals [Lappo & Andrew 2004].
Thus, the current discussion of process assessments in the agile context does not so much
address the certification or define the maturity of the organizational software development processes,
but rather evaluates the purpose of adopting agile practices (Salo 2007).
In this context was emerged the Nokia Test [Vodde 2006]. In 2005, Bas Vodde was coaching
teams at Nokia Networks in Finland and developed the first Nokia Test focused on agile practices. He
had hundreds of teams and wanted a simple way to determine if each team was doing the basics.
It does not provide the secret sauce for hyper performing teams. However, it is the first line of
the recipe for high performance. These tests were applied in scrum teams at OpenView Venture
Partners and to their portfolio companies as the venture group does not expect good performance from
Scrum teams without passing the Nokia Test. They are also very interested in predictability of release
dates which is impossible without passing grades on the test [Sutherland 2008].

36

The test consists in eight questions about how the teams are adopting Scrum. The Nokia Test is
in two parts. The first part consists of three questions asking if the team is doing iterative development.
The questions are [Sutherland 2008]:
Iterations must be timeboxed to less than 4 weeks?
Software features must be tested and working at the end of each iteration?
The iteration must start before specification is complete?
The next part of the test checks whether the team is doing Scrum, in view of the Nokia,
understanding, the remaining five questions are:
You know who the product owner is?
There is a product backlog prioritized by business value?
The product backlog has estimates created by the team?
The team generates burndown charts and knows their velocity?
There are no project managers (or anyone else) disrupting the work of the team?
In 2008 Jeff Sutherland developed a Nokia Test scoring system. Each person on the team takes
a sheet of paper and prepares to score eight questions on a scale of 1-10 and teams must average their
score. In 2009, a team question was added to the Nokia test about teams. Sutherland created four
categories for Nokia Tests results and linked these averages with following revenues [Sutherland
2008]:
ScrumBut (Average < 8,0) - revenue up 0-35%
Pretty Good Scrum (8,0 <= Average > 9,0) revenue up 150% - 200%
Good Scrum (9,0 <= Average > 10,0) - revenue up 300%
Great Scrum (Average = 10) - annual revenue up 400%
Sutherland (2008) stated that in the initial evaluations the teams are average 4.0, but in six
months their average up to 7,0 and the velocity is about 300% of initial velocity. The Return of
Investment (ROI) is about 11000% on first year since that is relatively easy and cheap to change scrum
process for better. Answering the Nokia Test provide to the team some idea about how much it is really
doing Scrum.

3.4 Agile Assessment Methods Comparative Agility

Kenny Rubin & Mike Cohn (2007) launched the Comparative Agility Survey. The Comparative
Agility assessment is based on a simple, but powerful concept, determine how good is one company
compared to it competitors. Rubin & Cohn assume agile teams and organizations strive always to be
better than their competition and their past selves.
Comparative Agility assessments present the results of a set of survey responses in comparison to
some other set of responses. Using Comparative Agility it is possible to compare a team, project or
organization to:
The total set of collected responses; responses from organizations in the same industry;
Responses from similar types of projects (such as commercial software, websites, and so on);

37

 Responses from projects with similar lengths of experience at becoming agile.

The approximately 100 questions of a Comparative Agility assessment are organized into
seven dimensions and thirty-two characteristics. The seven dimensions represent broad classifications
of changes to be expected of a team or organization as it becomes more agile. The seven dimensions
are:
teamwork
requirements
planning
technical practices
quality
culture
knowledge creation
Each dimension is made up of three to six characteristics and a set of questions is asked to
assess a team's score on each characteristic. Questions are answered on a fivepoint Likert scale of:
True
More true than false
Neither true nor false
More false than true
False
Through a combination of Dimensions, Characteristics, and individual Questions, a team or
organization can see how they compare to other organizations, or to themselves. The score ranges start
in -2 (worst scenario) until 2 (Best Scenario). The average Scenario shows the 0 (zero) grade. The
study involving this survey was presented in Cohn (2009).

3.5 Agile and Standards Process

The compatibility of agile software development approaches with the existing standard process models
is one SPI issue that has been addressed in agile literature [Salo 2007]. One central problem has been
posed as follows: How do you merge agile, lightweight processes with standard industrial processes
without either killing agility or undermining the years you have spent defining and refining your
systems and software engineering process assets [Boehm & Turner 2005]?
Some agile proponents have argued that people willing to spend money on CMM
certification are less interested in the agile value proposition, while those needing agility for business
reasons are less interested in getting CMM or ISO 9000 certification [Williams & Cockburn 2003].
Nevertheless, mature software organizations especially are concerned about how the adoption of agile
processes will affect their assessment ratings [Boehm & Turner 2005].

38

It has been argued that the synergy [Paulk 2001] and philosophical compatibility [Reifer 2003]
of XP and CMM have been agreed upon among most of the leaders in the field. However, shortages
also between the ISO and CMM requirements and agile methodologies have been reported, along with
a lack of practices to support the commitment of management to the defined software development
process, and also regarding the setting up and staffing of an independent quality assurance group
[Vriens 2003].
In addition, the degree of documentation and the infrastructure required by current process
standards for lower-level certification are issues of concern [Boehm & Turner 2005].
From 2003 onwards, however, the IEEE Standards Association has conducted agile
1
standardization work in the IEEE 1648 working group to establish and manage the expectations to an
agile customer should when working together with an agile team.

4 Conclusion
SPIwas extensively studied in traditional software development, on the subject of SPI in the context of
agile software development there are several avenues of investigation to be explored in future research.
Even researches related to SPI on agile environments are studied in another point of view and this is a
complicating factor for studying agile SPI in the light of traditional and established methods in
traditional SPI.
Looking for the six elements purposed by Salo (2007), there are several avenues of
investigation to be explored in future research either by lack of direction from the subject to process
improvement or the lack of research itself. These lacks of research will be explored in the two MSc
dissertations that were initiated by this literature review, but also may help other researchers to identify
what kind of research could be performed when software process improvement is related to agile.

http://standards.ieee.org/board/nes/projects/1648.pdf

39

References
[Abrahamsson et al 2002] Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J.: Agile Software
Development Methods Available in: http://www.pss-europe.com/P478.pdf, last access in 3/22/2010.
(2002)
[Agile Manifesto 2001] Agile Alliance: Agile Manifesto for Software Development: Available in
www.agilemanifesto.org, last access in 03/22/2010.
[Bach 1994] Bach, J.: The Immaturity of CMM, American Programmer Magazine Vol 3, pp 7--8
(1994)
[Basili & Caldiera 1994] Basili, V. R., Caldiera, G.: Experience Factory. In: Encyclopedia of Software
Engineering. Marciniak, J. J. (ed.). John Wiley & Sons, Inc. 469--476 (1994)
[Beck 1999] Beck, K.: Extreme Programming Explained Embrace Change. Addison-Wesley. (1999)

[Boehm & Turner 2003] Boehm, B. & Turner, R.: Using Risk to Balance Agile and Plan- Driven
Methods. Computer, Vol. 36, 6 (6), June, pp. 57-66, (2003)
[Boehm & Turner 2005] Boehm, B. & Turner, R.: Management Challenges to Implementing Agile
Processes in Traditional Development Organizations. IEEE Software, Vol. 22(5), September-October,
pp. 30-39, (2005)
[Cohn 2009] Cohn, M.: Succeeding with Agile: Software Development using Scrum.Addison Wesley
Longman, Inc. 504 p. (2009)
[Deming 1990] Deming, W. E.: Out of the Crisis. 10 Printing ed. Massachussetts Institute
of Technology, Center for Advanced Engineering Study. Cambridge (1990)
[Debou 1999] Debou, C.: Goal-Based Software Process Improvement Planning. In: Better software
practice for business benefit: Principles and experience. Messnarz, R. & Tully, C.
(ed.) IEEE Computer Society, pp 107--150, Los Alamitos, CA. (1999)
[Dyb 2000] Dyb, T.: An Instrument for Measuring the Key Factors of Success in Software Process
Improvement. Empirical Software Engineering, Vol. 5, 357-390 (2000)
[Florac et al 2000] Florac, W. A., Carleton, A. D. & Barnard, J. R.: Statistical Process
Control: Analyzing a Space Shuttle Onboard Software Process. IEEE Software, Vol. 17, 4
(4). July, August, pp. 97-106 (2000)
[Georgiadou 2004] Goergiadou E.: Software Process and Product Quality Assurance: A historical
Perspective. Cybernetics and Systems Analysis. 11(4), pp 19--27 (2004)

40

[Goldensen & Herbsleb 1995] Goldensen, D. R., Herbsleb, J. D.: After the Appraisal: A
Systematic Survey of Process Improvement, Its Benefits, and Factors that Influence Success.
CMU/SEI-95-TR-009. Software Engineering Institute. Pittsburgh. (1995)
[Gruhn 2002] Gruhn, V.: Process-Centered Software Engineering Environments A Brief History and
Future Challenges. In: Annals of Software Engineering, 14, pp 363--382,(2002)
[Herbsleb et al 1994] Herbsleb, J., Carleton, A., Rozum, J., Siegel, J., Zubrow, D.: Benefits of CMMbased software process improvement: Initial results. Technical report, CMU/SEI- 94-TR-13 (1994)
[Humphrey 1995] Humphrey, W. S.: A Discipline for Software Engineering. Addison Wesley
Longman, Inc. 242 p. (1995)
[Jackobsen 2009] Jackobsen, C.: Scrum and CMMI: from Good to Great - are you ready - ready to be
done done. In Proceedings of Agile Conference 2009. (2009)
[Jarvinem 1994] Jrvinen, J.: On comparing process assessment results: BOOTSTRAP and CMM. In
Software Quality Management, SQM94, pp 247--261, Edinburgh (1994)
[Kitchenham 1996] Kitchenham, B., Pfleeger, S. L.: Software quality: The elusive target. In IEEE
Software, 13(1), pp 12--21. (1996)
[Krasner 1999] Krasner, H.: The Payoff for Software Process Improvement: What it is and How to Get
it. In: Elements of Software Process Assessment & Improvement. El Emam, K.& Madhavji, N. H.
(ed.). IEEE Computer Society, PP 113-130, Los Alamitos, California(1999)
[Lappo & Andrew 2004] Lappo, P. & Andrew, H. C. T.: Assessing Agility. In: The proceedings of the
Extreme Programming and Agile Processes in Software Engineering. June, 2004. GarmischPartenkirchen, Germany. Eckstein, J. & Baumeister, H. (ed.). Springer. pp. 331--338. (2004)
[Lycett at al 2003] Lycett, M.; Macredie, R. D.; Patel, C.; Paul, R. J. Migrating Agile Methods to
Standardized Development Practice. In: Computer, pp. 79-85. IEEE Computer Society. Jun. 2003
[Marick 2008] Marick, B.: Seven Years Later: What the Agile Manifesto Left Out. In:Agile
Development Practices (2008)
[Paulk 2001] Paulk, M. C.: Extreme Programming from a CMM Perspective. Software, Vol. 18, 6 (6),
Nov. Dec, pp. 19--26. (2001)
[Pikkarainen & Passoja 2005] Pikkarainen, M. & Passoja, U.: An Approach for Assessing Suitability
of Agile Solutions: A Case Study. In: The proceedings of the Sixth International Conference on

41

Extreme Programming and Agile Processes in Software Engineering. Sheffield University, UK. pp.
171--179. (2005).
[Reifer 2003] Reifer, D. J.: XP and the CMM. IEEE Software, Vol. 20, 3 (3), May/June, pp. 14--15.
(2003)
[Rico 2004] Rico, D. F.: ROI of Software Process Improvement: Metrics for Project Managers and
Software Engineers. J. Ross Publishing. Florida, U.S.A. (2004)
[Rubin & Cohn] Rubin, K., Cohn, M.: Comparative
http://www.comparativeagility.com/, last visit in 03/22/2010.

Agility

Survey.

Available

in

[Salo 2007] Salo, O.: Enabling Software Process Improvement in Agile Software Development Teams
and Organisations, PhD Thesis, Oulu, (2007)
[SEI 2006] Software Engineering Institute.: Capability Maturity Model Integration (CMMISM),
Version 1.2. Carnegie Mellon Software Engineering Institute. (2006)
[Stamelos & Sfetsos 2007] Stamelos, I., Sfetsos, P.: Agile Software Development Quality Assurance.
Information Science Reference, (2007)
[Sutherland 2008] Sutherland, J.: Money for nothing: And your change for free Agile Contracts. In
Proceedings of Agile Development Conference (2008)
[Van Soligen & Berghout 1999] Van Solingen, R., Berghout, E.: The Goal/Question/Metric Method: A
Practical Guide for Quality Improvement of Software Development. The McGraw-Hill Companies.
(1999)
[Vodde 2006] Vodde, B.: Nokia Networks and Agile Development. In Proceedings of EuroMicro
Conference. (2006)
[Vriens 2003] Vriens, C.: Certifying for CMM Level 2 and ISO9001 with XP@Scrum. In: The
proceedings of the Agile Development Conference (ADC03). September, 2003. IEEE Computer
Society. pp. 120--124. (2003)
[Williams & Cockburn 2003] Williams, L. & Cockburn, A.: Agile Software Development:
Its about Feedback and Change. IEEE Computer Society, Vol. 36, 6 (6), June, pp. 39-43.
(2003)

42

XP Tracking Tool: Uma Ferramenta de Acompanhamento de

Projetos geis
Carla Adriana Barvinski1, Maria Istela Cagnin2, Nilson E. S. Lima Filho1, Leandro
Veronezi 1
Faculdade de Cincias Exatas e Tecnologia Universidade Federal da Grande
Dourados (UFGD)
Caixa Postal 533 79.804-970 Dourados MS Brasil

Faculdade de Computao Universidade Federal do Mato Grosso do Sul (UFMS)

Caixa Postal 15.064 91.501-970 Campo Grande MS Brasil

carlabarvinski@gmail.com, istela@facom.ufms.br,
nilson.lima.filho@hotmail.com, leandroveronezi@gmail.com

Abstract. The methodology eXtreme Programming (XP) concentrates its

efforts on coding and testing activities, with no emphasis on formal and
bureaucratic. In XP, the game planning plays an important role enabling the
implementation of the project within the principles adopted by the
methodology. In project planning, the use of metrics for tracking, monitoring
and control of the project was essential because it provided information for
making decisions and evaluations. This paper presents a tool, called XP
Tracking Tool, specific for implementation and monitoring of metrics in XP
projects. By focusing specifically on metrics XP, it embodies the essential
tasks of a team of extreme programming, encouraging and strengthening the
principles and practices of the methodology, which provides time
measurements, information, graphics and documentation about projects.

1. Introduo
As mtricas so importantes instrumentos de acompanhamento, monitoramento,
planejamento e administrao de um processo ou produto de software. Composta por
medidas e implementada por meio de medies, elas instrumentalizam a obteno de
dados estatsticos tanto sobre o produto quanto sobre o processo de software,
subsidiando e embasando aes gerenciais [PRESSMAN, 2006; BOURGAULT, et al.,
2002].
No contexto gil, em que um processo de desenvolvimento de software sofre
radicais adaptaes com fortes supresses nas atividades de documentao e produo
de artefatos com o objetivo de liberar releases o quanto antes, as mtricas tm um papel
essencial pois, enquanto as prticas e princpios geis estruturam as atividades de
desenvolvimento, cabem s mtricas viabilizar o monitoramento dos resultados
produzidos, embasando as orientaes e decises da gerncia de projetos geis.
H vrias ferramentas CASE (Computer Aided Software Engineering), como por
exemplo, XPlanner1 VersionOne2, Pivotal Tracker3, voltadas para a gerncia de projetos
1 URL: http://www.xplanner.org
2 URL: http://www.versionone.com
3 URL: http://www.pivotaltracker.com

43

geis, todavia o enfoque primordial de tais ferramentas est na gerncia de projetos,

levando em considerao apenas as mtricas mais convencionais, como o caso de
estimativas de esforo, velocidade do time e horas ideais.
Em desenvolvimento gil, uma mtrica torna-se dispensvel quando o propsito
a que ela atendia foi superado [BECK, 2004], seja por adequao do time ao
desenvolvimento das tarefas ou em decorrncia do aprimoramento do processo
[SOMMERVILLE, 2007]. Em consequncia disso, a quantidade de mtricas
disponibilizada por uma ferramenta um aspecto relevante para a gerncia de projetos
geis.
Este artigo apresenta uma ferramenta, denominada XP Tracking Tool, especfica
para aplicao e monitoramento de mtricas em projetos XP. Esta ferramenta de fcil
utilizao, sendo ideal para atividades prticas do ambiente acadmico nas disciplinas
de Engenharia de Software e Gerncia de Projetos e para o acompanhamento de
pequenos projetos XP. Ela fornece recursos essenciais para o gerenciamento do projeto,
tais como cadastro e pontuao de estrias, definio de iteraes, atividades, tarefas, e
registro de pareamento. A partir dos dados do projeto so extradas automaticamente
medidas e geradas as mtricas de clculo do fator de erro nas estimativas [SATO, 2007],
de grfico de Burn Down, de prazo e de clculo do tempo ideal estimado, adaptada de
Sato (2007). A ferramenta permite o acompanhamento de vrios projetos
simultaneamente e a definio de vrios nveis de usurios; fornece documentao
HTML sobre o projeto, bem como relatrios e grficos de acompanhamento do projeto;
possibilitando tambm que o cliente registre suas estrias via Web.
Na Seo 2 deste artigo aborda-se a metodologia gil eXtreme Programming
(XP), na Seo 3 discorre-se sobre mtricas geis, na Seo 4 faz-se breve descrio de
ferramentas para gerncia de projetos geis, na Seo 5 apresenta-se a Ferramenta XP
Tracking Tool e na Seo 6 discutem-se as concluses e indicam-se sugestes de
trabalhos futuros.

2. eXtreme Programming
eXtreme Programming uma metodologia de desenvolvimento gil adequada para
equipes com poucos desenvolvedores cujos projetos sejam de pequeno a mdio porte,
em que os requisitos so vagos e se alteram com frequncia [BECK, 2004].
XP concentra seus esforos nas atividades de codificao e testes, sem nfase em
processos formais e burocrticos. Alm disso, utiliza o paradigma de desenvolvimento
orientado a objetos com o qual busca elaborar solues simples, desenvolvendo
software de forma iterativa e incremental, entregando verses funcionais de software
constantemente.
Esta metodologia tambm se caracteriza pelo modo peculiar de participao do
cliente em um projeto de software. Isto , em XP as responsabilidades do projeto so
divididas entre o cliente e a equipe, havendo uma separao do papel de cada um, o que
evita conflitos e assegura que cabe ao cliente tomar as decises de negcio e que
compete a equipe de desenvolvimento responder pelas decises tcnicas [BECK, 2004].
Toda abordagem de desenvolvimento do XP baseada em doze prticas que se
fundamentam em quatro valores bsicos que so: a comunicao entre os envolvidos no
projeto, o feedback rpido entre cliente e equipe de desenvolvimento, a simplicidade na
implementao e a coragem para adotar aes inovadoras e vencer os desafios do
desenvolvimento de software. O conjunto formado por valores e prticas XP atua de
44

forma harmnica e coesa, assegurando ao cliente um alto retorno do investimento

[TELES, 2004].
O papel das doze prticas orientar como sero executadas as atividades bsicas
de desenvolvimento, de forma a manter a conformidade com os quatro valores. As
prticas esto divididas em trs grupos abrangendo: prticas organizacionais que so
relacionadas ao planejamento; prticas voltadas equipe; e prticas individuais de
codificao e testes [BECK, 2004]. As prticas de XP so: jogo do planejamento,
entregas frequentes, metfora, projeto simples, testes, refatorao, programao em
pares, propriedade coletiva, integrao contnua, semana de 40 horas, cliente presente e
padres de codificao.
Destas prticas destaca-se o jogo do planejamento, cujo objetivo planejar
globalmente o projeto, elaborando um esboo da ideia principal e detalhando as
funcionalidades com mais importncia. A meta do jogo do planejamento assegurar
que a equipe esteja implementando funcionalidades que realmente proporcionem valor
ao negcio do cliente. O jogo do planejamento elemento-chave em XP. Durante a
execuo do projeto, o planejamento refinado vrias vezes, em perodos cada vez mais
curtos, motivados por necessidade de adaptao a mudanas, alteraes nos requisitos
ou aprimoramento de processos [BECK, 2004]. As mtricas fornecem estimativas cujos
indicadores so considerados no refinamento do planejamento. Tais mtricas (Seo 3)
so de interesse deste trabalho e algumas delas so cobertas pela ferramenta proposta
(Seo 5).
Tanto os princpios quanto as prticas so rigidamente exercitados pela
metodologia XP, o que torna triviais atividades como a reviso permanente do cdigo, o
desenvolvimento de solues o mais simples possveis, o teste e integrao em vrios
momentos em um mesmo dia e a execuo de iteraes curtas como forma de minimizar
os erros [BECK, 2004].
Equipes de desenvolvedores XP tendem a ser pequenas, com um mnimo de trs
at quinze pessoas, desempenhando os papis de treinador, gerente, rastreador, cliente e
programador. papel do rastreador acompanhar um projeto XP, o que envolve coletar e
manter dados sobre o projeto, alimentar as mtricas por ele definidas, comparar os
dados colhidos com os estimados e divulgar a toda equipe as informaes sobre o
andamento geral do projeto [BECK, 2004]. Assim, importante o apoio de ferramentas
computacionais nestas atividades no somente para fornecer dados a partir de mtricas
sobre o andamento de projetos geis em tempo real, mas tambm disponibilizar
histrico contendo registros importantes relativos equipe de projeto, velocidade de
desenvolvimento, pareamento, entre outros.

3. Mtricas geis
As mtricas constituem importante instrumento no acompanhamento,
monitoramento e controle de projetos de software [BOURGAULT et al., 2002]. Elas
esto relacionadas medio de indicadores qualitativos e quantitativos do tamanho e
complexidade de um produto ou processo [PRESSMAN, 2006]. Os indicadores obtidos
referem-se a experincias passadas e permitem aplicar os desempenhos observados
tanto na projeo de previses de desempenho futuro quanto na reformulao do
processo de desenvolvimento ou na reviso do comportamento de times de
desenvolvimento.
Dessa forma, mtricas podem ser usadas para acompanhar o progresso do

45

processo de desenvolvimento de um projeto e/ou para obteno de indicadores da

qualidade do produto, de forma a permitir que gerentes e profissionais tcnicos tenham
a devida compreenso sobre o processo de engenharia de software e sobre o produto.
Para Pressman (2006), a medio do processo de software e do produto por ele
produzido a nica maneira real de determinar se est havendo melhorias ou no no
processo de desenvolvimento e na qualidade final do produto.
As etapas, fases, atividades e tarefas de um processo de desenvolvimento de
software adaptado s metodologias geis esto intrinsecamente vinculados aos
princpios preconizados pelo Manifesto gil que estabelece [BECK et al., 2001]:
indivduos e interaes ao invs de processos e ferramentas; software funcionando
antes que documentao completa; colaborao com o cliente mais que negociao
com contratos; adaptao s mudanas prefervel a seguir um plano.
Estes princpios tm profundos impactos no comportamento de uma equipe de
desenvolvimento de software, seja na sua organizao interna, na interao com o
cliente, no desenvolvimento das atividades, modificando permanentemente a sua forma
de atuao. Por isso, as metodologias geis requerem uma re-contextualizao das
mtricas a serem rastreadas [SCHWABER, 1995], havendo um consenso geral de que
essas devem focar nos objetivos de negcios [BARNETT, 2009; GRIFFITHS, 2007;
BECK, 2004], rompendo total ou parcialmente com algumas medies tradicionais
classificadas como mtricas orientadas a tamanho, orientadas funo, de produtividade
cuja aplicao tendem a influenciar o comportamento das equipes [SATO, 2007;
HARTMAN e DYMOND, 2006; DEMMERe BENEFIELD, 2007].
Vrios autores citam a inconvenincia de se medir projetos geis pelas
abordagens tradicionais [BECK, 2004; GRIFFITHS, 2007; HARTMANN e DYMOND,
2006; BARNETT, 2009], pois na opinio deles as mtricas convencionais tendem a
desencadear comportamentos inadequados em resposta aos estmulos que elas
conferem. Nesse sentido, para auxiliar na seleo adequada de mtricas geis, h na
literatura orientaes [HARTMAN e DYMOND, 2006; SATO, 2007] que apontam para
fatores importantes que um tracker deve considerar quando estiver escolhendo uma
mtrica para sua equipe.
Na realidade, as mtricas so utilizadas pelas metodologias geis como um
sensor, com o objetivo de acompanhar, mensurar, planejar, detectar anomalias,
estimular correes e liberar valor de negcio [BECK, 2004; HARTMANN e
DYMOND, 2006, BARNETT, 2007] durante um ciclo constante de inspeo,
adaptao e melhoria [SATO, 2007]. Por isso, em projetos geis, as medies so
realizadas continuamente de modo a fornecer indicadores do andamento do projeto em
tempo real ao invs de a posteriori. Dessa forma, possvel propiciar ao lder de equipe
a deteco imediata de dificuldades, possibilitando que o time de desenvolvimento faa
a correo de problemas potenciais na medida em que estes surjam, alm de fornecer
dados concretos do andamento do projeto: cronograma, velocidade, qualidade,
satisfao do cliente.
No que se refere a quantidade de mtricas a serem rastreadas em um projeto de
desenvolvimento gil de software, observa-se divergncia entre os autores. Beck (2004)
sugere uma quantidade mxima de quatro mtricas por projeto em um dado instante,
enquanto que Barnett (2007) detectou em pesquisa de campo, a preferncia pelo
rastreamento de mtricas que possibilitem o acompanhamento de um projeto em cinco
grandes dimenses: risco, qualidade, cronograma, esforo/oramento e conformidade.
Independente deste aspecto, ambos recomendam o uso de poucas mtricas simultneas
46

por projeto e as descartam assim que se tornam obsoletas. Isso deve ser feito quando se
detecta que os ndices apresentados esto prximos ao ideal, o que demonstra a
estabilizao das atividades e indica que a mtrica perdeu a finalidade, devendo
portanto ser descartada, com exceo de mtricas voltadas a testes de unidade, que
devem permanecer durante toda durao do projeto [BECK, 2004].
Dadas essas consideraes, pode-se deduzir que durante a execuo de um
projeto de software, incluindo os geis, pode-se fazer necessrio o uso de variadas
mtricas. Definir quais mtricas aplicar a determinado projeto uma tarefa desafiadora,
que requer experincia e tato. Segundo Griffiths (2007), se faltar clareza na utilizao
das mtricas, as medies coletadas no sero importantes para o bom andamento do
projeto e ocasionaro a perda de foco das medidas.
Neste contexto, de acordo com Sato (2007) recomendvel o estudo e a
aplicao de abordagens, como Goal Question Metric (GQM) [BASILI et al., 1996] e
Lean [POPPENDIECK, 2003], que disponibilizam orientaes seguras para a seleo
das mtricas mais adequadas a determinado objetivo/projeto. Sato (2007) sugere ainda o
aproveitamento dos resultados de Reunies de Retrospectivas [COCKBURN, 2001]
como fonte de seleo de mtricas.
Na metodologia XP, a unidade central do processo representada pelo carto de
estrias (story card), que so representaes dos requisitos do sistema e tambm o
ponto de partida para medidas de gerenciamento de projetos e qualidade de negcio.
Sato (2007) sugere vrias medies, as quais apresentam objetivos pontuais que podem
ser utilizados na composio de uma mtrica com objetivo mais amplo de
acompanhamento e/ou controle do processo de desenvolvimento ou do produto de
software. Sato (2007) tambm indica um conjunto de mtricas consideradas as mais
adequadas para acompanhar projetos XP.

4. Ferramentas para Acompanhamento de Projetos geis

Pressman (2006) classifica ferramentas de gerncia de projetos em genricas e
especficas. As primeiras atendem um conjunto amplo de atividades englobando listas
de verificao, guias de planejamento, planilhas inteligentes, entre outros. Enquanto
que ferramentas especficas podem focalizar diferentes reas, tais como: estimativas de
esforo e custo; elaborao de cronogramas; gesto de riscos e mtricas de projeto e
processo. Segundo Pressman (2006), uma ferramenta de mtricas de projeto e de
processo deve dar suporte a definio, coleta, avaliao e relato de medidas e mtricas
de software, devendo disponibilizar mecanismos de coleta e de avaliao que
conduzam ao clculo de mtricas de software.
No mbito de gerncia de projetos geis, h vrias ferramentas CASE
disponveis, como por exemplo, XPlanner, VersionOne, Pivotal Tracker, FireScrum4.
A VersionOne uma soluo comercial de cdigo fechado, com interface Web.
Proporciona um planejamento inicial simplificado, onde so definidas as iteraes do
projeto. Os prazos e entregas so definidos dentro de cada iterao. Tal ferramenta
permite visualizar o status das iteraes, suas entregas e grficos Burn down5.
XPlanner uma ferramenta estritamente voltada ao gerenciamento de projetos
geis XP, de cdigo livre e gratuita, suporta multi-projetos em ambiente colaborativo e
4 www.firescrum.com.
5 Representao grfica das atividades realizadas versus tempo estimado.

47

distribudo. Disponibiliza interface Web, d o suporte para os artefatos e atividades

tpicas de projetos XP, iteraes, estrias de usurio e tarefas, disponibiliza medidas e
estimativas da iterao.
A Pivotal Tracker uma soluo Web, gratuita, colaborativa, em que os cartes
de estria so a base do planejamento de projeto. As entregas so priorizadas em
backlogs. A ferramenta agrupa as estrias automaticamente em iteraes e faz
estimativas a partir dos pontos cadastrados pelo usurio, os quais fornecem a base para
gerao dos grficos de Burn-down (progresso do release), Burn-up (progresso da
iterao), velocidade e story type breakdown (classificao das estrias por tipo e
pontos na iterao). Os dados cadastrados pelo usurio so armazenados no Amazon
Simple Storage Service, bem como documentao adicional que se julgue interessante
anexar ao projeto.
A FireScrum uma soluo de cdigo livre e gratuito, que tem seu foco no
gerenciamento de projetos elaborados segundo a metodologia Scrum. Ela constituda
de um conjunto de aplicaes integradas que do suporte ao desenvolvimento de
projetos desenvolvidos por uma equipe geograficamente distribuda. Devido a sua
vinculao com a metodologia SCRUM, a FireScrum no foi considerada para anlise
durante a fase pr-concepo da XP Tracking tool.

5. Ferramenta XP Tracking Tool

Nesta seo so apresentadas as principais caractersticas da ferramenta XP Tracking
Tool: viso geral, medidas e mtricas implementadas, principais funcionalidades, os
mdulos da ferramenta, aspectos da ferramenta que apoiam e fortalecem a prtica da
metodologia gil XP e a avaliao da ferramenta proposta.
A ferramenta XP Tracking Tool objetiva apoiar a coleta de mtricas de
gerenciamento de processo aplicadas a metodologia de desenvolvimento gil XP, a fim
de auxiliar no acompanhamento de projetos geis que seguem tal metodologia, mais
especificamente, no melhoramento do planejamento da equipe, identificando elementos
para aperfeioamento de suas prticas XP.
Para isso, foram implementadas na verso inicial da XP Tracking Tool as
mtricas de Tempo Ideal Estimado proposta por Sato (2007), Grfico de Burn
Down descrita em Schwaber (2004), e duas mtricas adaptadas do trabalho de Sato
(2007), intituladas Mtrica de clculo do Tempo Ideal Estimado e mtrica de prazo.
A escolha das mtricas seguiu as orientaes apresentadas por Beck (2004), que sugere
que elas sejam de fcil coleta, que respondam a uma questo especfica e reforcem os
princpios geis. Considerou-se tambm que elas auxiliariam na visualizao do
andamento do projeto e oportunizariam a equipe de desenvolvimento rever suas
estimativas, bem como possibilitariam a equipe certificar-se quanto a utilizao correta
das prticas propostas pela metodologia.
Salienta-se que a coleta das mtricas presentes na ferramenta feita
automaticamente a partir de sua base de dados. As mtricas implementadas pela XP
Tracking Tool so apresentadas na Tabela 1.
Na XP Tracking Tool, o controle de acesso ferramenta feito por meio de
autenticao de nome de usurio, senha e da aplicao de regras especficas para cada
tipo de usurio, o que significa que grupos de usurios tm acesso a diferentes
funcionalidades: o administrador tem acesso irrestrito; o programador acessa apenas os
projetos para qual foi designado podendo, neste contexto, manter estrias e tarefas; o
48

cliente acessa apenas os projetos para o qual foi designado, podendo inserir e modificar
estrias e testes de aceitao.
Tabela 1 Mtricas implementadas pela ferramenta XP Tracking Tool

Mtricas

Descrio

Mtrica de clculo do fator de

erro nas estimativas [SATO,
2007]

O valor desta mtrica um nmero positivo. Ele resulta da diviso do

tempo estimado pelo tempo real gasto para concluso das tarefas,
quanto mais prximo de 1 for o valor, mais em conformidade com o
planejado est o projeto.

Mtrica de Grfico de Burn

Down [SCHWABER, 2004]

Esta mtrica formada por dados apresentados em grficos que

mostram uma linha decrescente do andamento do projeto e das
releases.

Mtrica de prazo (adaptado

de Sato(2007))
Mtrica de clculo do Tempo
Ideal Estimado (adaptado de
Sato(2007))

Esta mtrica apresenta o resultado da diviso do nmero de dias

decorridos pelo nmero de dias totais estimados multiplicado por
100, que fornece a porcentagem do tempo estimado j decorrido.
Esta mtrica estima o tempo necessrio para a concluso do projeto,
baseado no fator de erro das estimativas da equipe, seu valor
obtido atravs da multiplicao do tempo estimado para a concluso
pelo fator de erro, importante para a equipe ver quo distante est
de suas metas.

Todo usurio ao acessar o sistema pode visualizar o andamento dos projetos aos
quais tem acesso, alm de poder imprimir diferentes relatrios em formato HTML
(HyperText Markup Language), organizados por release ou por integrao. Esses
relatrios abrangem informaes acerca do projeto, quais sejam: nome e dados
especficos do projeto, como datas de incio e fim, equipe; contedo de todos os cartes
de estria e seus respectivos cartes de tarefa e testes de aceitao; entre outros.
Tambm so disponibilizados dois grficos de Burn Down, um que representa dados
sobre o andamento da release e outro que ilustra a evoluo do projeto como um todo.
As medidas (Seo 5.1) extraem dados sobre projetos que permitem a gerao
automtica de estimativas, mtricas e grficos. Os grficos gerados e as estrias podem
ser exportados em arquivos nos formatos PDF (Portable Document Format), png
(Portable Network Graphics ), jpg (Joint Photographic Experts Group) ou impressos
para documentar o projeto.
5.1. Medidas coletadas
Para a implementao das mtricas, a ferramenta requer a coleta de dezessete
diferentes medidas sobre o projeto. Algumas delas so utilizadas para o clculo das
mtricas suportadas pela ferramenta e as demais apoiam na documentao do projeto.
Na Tabela 2 so apresentadas as medidas consideradas na implementao da ferramenta
proposta. Buscou-se implementar uma quantidade significativa de medidas visando a
expanso do nmero de mtricas em verso futura do software.
Tabela 2 Medidas coletas pela ferramenta XP Tracking Tool
Medidas
Nmero de Clientes
Nmero de Estrias
Nmero de Estrias canceladas
Nmero de Estrias em andamento

Descrio
Representa a quantidade de usurios do tipo cliente,
designados para o projeto
Estabelece a quantidade de estrias de um projeto
Registra a quantidade de estrias que esto com seu
status definido como canceladas
Contm a quantidade de estrias que esto com seu
status definido como em Andamento

49

 a quantidade de estrias que esto com seu status

definido como esperando
a quantidade de estrias que esto com seu status
definido como estimadas
a quantidade de estrias que esto com seu status
definido como pronta
a quantidade de integraes feitas
a quantidade de pessoas cadastradas na ferramenta e
que esto envolvidas no projeto

Nmero de Estrias esperando

Nmero de Estrias estimadas
Nmero de Estrias prontas
Nmero de Integraes
Nmero de Integrantes

a quantidade de usurios do tipo programador,

designados para o projeto

Nmero de Programadores
Nmero de Releases

a quantidade de releases que foram concludos

a quantidade de testes de aceitao escritos pelo
cliente
a quantidade de testes de aceitao que tiveram seu
status alterado pelo cliente para concludo
a quantidade de dias sem os fins de semana que
decorreram desde o incio do projeto
a quantidade de dias estimados pelos programadores
para concluir todas as tarefas ainda no realizadas
Representa o tempo total em dias estimado para
executar todas as tarefas do sistema, admitindo a prtica
de 40 horas semanais e 8 horas dirias

Nmero de Testes de Aceitao

Nmero de Testes de Aceitao
Passando
Tempo Decorrido
Tempo estimado para a concluso
Tempo Total

5.2. Mdulos da XP Tracking Tool

A XP Tracking Tool foi desenvolvida em Java e utiliza o SGBD (Sistema de
Gerenciamento de Banco de Dados) MySQL. composta por dois mdulos, um
denominado mdulo principal e o outro de configurao de base de dados. Sua
arquitetura est ilustrada na Figura 1.
Mdulo de
configurao

Mdulo
principal

Interface com o usurio

Medida e Mtricas
Persistncia

MySQL

JDBC

JAVA

Figura 1 Arquitetura da Ferramenta XP Tracking tool.

No mdulo principal esto presentes as funcionalidades essenciais da
ferramenta, a seguir relacionadas:

Permite ao administrador cadastrar e acompanhar vrios projetos

simultaneamente;

Permite ao cliente efetuar o cadastro dos cartes de estrias e testes de

aceitao, necessrios para a validao dos requisitos da estria;
50

Permite ao administrador ou programador definir a prioridade de cada

carto de estria alta, mdia ou baixa;

Possibilita a todos os usurios acompanhar/monitorar o andamento status de

implementao das estrias de um projeto a que tenham acesso. O status de
uma estria pode ser: em espera, em andamento, concludo ou cancelado;

Permite ao administrador definio de integraes e releases; bem como a

seleo de estrias para cada release;

Possibilita ao programador efetuar a marcao de tempo para cada estria

consiste em informar o tempo estimado para realizao de cada tarefa
necessria a implementao de uma estria e o tempo real gasto na sua
execuo;

Permite ao administrador o acompanhar as combinaes de pares

(programao pareada), formados durante a execuo do projeto;

Centraliza e organiza as informaes gerenciais e de processo relacionadas a

um projeto XP, como por exemplo, estrias, release, membros do time de
desenvolvimento, tarefas;

Gera automaticamente, a partir da insero de medidas sobre o projeto

(Seo 5.1), as mtricas descritas na Tabela 1 disponibilizando-as a todos os
usurios da ferramenta;

Gera grficos de Burndown relativo a releases do projeto e a iteraes de

uma release especfica, possibilitando sua impresso ou exportao,
permitindo a visualizao das medidas inseridas, mtricas e grficos gerados
pela ferramenta. Todos os usurios podem visualizar os grficos.

Disponibiliza a todos os usurios, em formato HTML, documentao de

todos os dados cadastrados e gerados sobre o projeto.

Permite ao administrador o cadastro de diferentes tipos de usurio: cliente,

programador e administrador. Cada usurio possui permisses de acesso
distintas na ferramenta.

O mdulo principal organizado em projetos que contm estrias. As estrias

so apresentadas em uma interface que recorda um painel de indicadores e so o ponto
de partida para definir as atividades de desenvolvimento: atribuio de tarefas,
pareamento, definio de release e testes de integrao. O usurio deve criar ou
selecionar uma estria para iniciar sua interao com a ferramenta. Algumas mtricas
implementadas e todas as medidas coletadas so apresentadas em um painel especfico
na tela de gerncia de projeto, conforme ilustrado na Figura 2. Visualiza-se, na parte
destacada, as mtricas: a) de prazo, nomeada como tempo total, b) de clculo do fator de
erro nas estimativas, identificada no painel como fator de erro nas estimativas, c)de
clculo do Tempo Ideal Estimado, intitulada tempo ideal para concluso.

51

Figura 2 Painel de visualizao das medidas e mtricas

A quantidade de dias por integrao e integraes por release apresentada na
forma de grfico, de acordo com o exibido na Figura 3, e as estrias so agrupadas por
status e visualizadas em um painel especfico na tela de gerncia de projeto, conforme
mostrado na Figura 4.

Figura 3 Painel de visualizao dos grficos de Burn Down

52

Figura 4 Painel de visualizao de estrias cadastradas

O mdulo de configurao de base de dados utilizado para a configurao da
conexo com a base de dados. A XP Tracking Tool permite diversas formas de
configurao da conexo com a base de dados: acesso local, em rede (em um servidor)
ou on-line (em um servidor acessado via Web). Para isso, necessrio indicar o local da
base de dados da ferramenta, como sendo um endereo na rede local, ou um servidor
Web ou, ainda, o prprio computador; informar o nome de usurio e a senha da base de
dados; bem como criar a base de dados a partir de um script prprio, caso ela no exista.
5.3. Prticas e Artefatos de XP presentes na XP Tracking Tool
Algumas caractersticas bsicas da metodologia XP, materializados na forma de prticas
ou artefatos, esto incorporadas na ferramenta XP Tracking Tool de forma explcita ou
implcita, conforme sumarizado na Tabela 3.
Tabela 3 - Prticas e Artefatos XP na ferramenta XP Tracking Tool
Prticas e Artefatos XP
(descrio)
Cartes de Histria
Cartes de Tarefa
Testes de Aceitao
Programao Pareada
Semana de 40 Horas
Releases
Interaes

ARTEFATO

PRTICA

X
X
X
X
X
X
X

EXPLCITO

IMPLCITO

X
X
X
X
X
X
X

So abordados de forma explcita na ferramenta os artefatos especficos de

projetos XP, tais como, cartes de estrias e seus respectivos cartes de tarefas e testes
de aceitao, uma vez que requerem cadastramento. As prticas programao pareada e
integrao contnua, tambm recebem o mesmo tratamento - na ferramenta possvel
indicar se houve ou no pareamento na realizao de uma tarefa. As integraes e
releases, elementos fundamentais para a integrao contnua, devem ser cadastradas.
A semana de 40 horas se faz presente de forma implcita, aparecendo nos clculos das
mtricas, uma vez que considerada uma semana de 40 horas de trabalho.
5.4. Avaliao
Nessa seo so descritos os resultados obtidos com o uso da XP Tracking Tool bem

53

como os pressupostos em que estes se apoiam, uma vez que no foram conduzidos
estudos de casos em ambiente real at o momento da escrita deste artigo.
Em comparativo com as ferramentas VersionOne, Xplanner, Pivotal Tracker
(Seo 4) verifica-se que a XP Tracking tool detm as mesmas propriedades destas
solues, reservadas as propores, porm com o adicional de incluir recurso para o
acompanhamento do pareamento e possibilitar a configurao e acesso de diferentes
nveis de usurios ao sistema. Cada tipo de usurio pode acessar a XP Tracking Tool
para alimentar ou visualizar dados de acordo com suas atividades no processo de
desenvolvimento. Os tipos de usurios so pr-definidos e englobam gerente, tracker,
programador e cliente. Na Tabela 4 so assinalados os aspectos em comum existentes
nas ferramentas Pivotal Tracker, XPlanner, VersionOne e na XP Tracking Tool.
Tabela 4 Comparativo de ferramentas CASE para gerncia de projetos XP
Caracterstica/Ferramenta

Pivotal Tracker

XPlanner

VersionOne

XP Tracking Tool

LEGENDA:
A. Gratuito
B. Opensource
C. Grficos
D. Priorizao

E. Marcao de horas
F. Estimativas
G. Programao pareada
H. Nveis de acesso

X
X

I. Suporta diferentes
metodologias

Os demais benefcios proporcionados pela XP Tracking Tool

so o
fortalecimento das prticas XP de pareamento, desenvolvimento iterativo, interaes
entre a equipe e semana de 40 horas.
No quesito pareamento, a ferramenta fora o cadastramento do par que ir
implementar determinada estria, assim possibilita ao gerente de projetos acompanhar a
diversifio dos pares e interferir quando detectar distrbios de preferncia por pares
ou ainda orientar quando perceber dificuldades de adoo da prtica pela equipe. A
relao pares, estrias, tarefas podem sem acompanhadas por relatrios. Em verses
futuras planeja-se o aperfeioamento desse instrumento de acompanhamento da
prtica.
O fato da ferramenta requerer a associao de cada estria a uma iterao e o
monitoramento de resultados ocorrer sobre o release correlacionado, condiciona a
prtica do desenvolvimento iterativo para que a ferramenta apresente resultados
efetivos.
A visualizao dos grficos de Burn Down referente a um projeto permitida a
todos os membros que formam a equipe alocada ao projeto. Deste modo, a ferramenta
disponibiliza um recurso extra para a divulgao de informaes e dados relativos ao
projeto facilitando a comunicao e interao da equipe e fortalecendo a prtica
correspondente.
Cada mtrica contribui para o fortalecimento de prticas geis enquanto
proporciona informaes significativas sobre o projeto. A mtrica Clculo de Fator de
Erro permite a equipe visualizar a variao entre suas estimativas e os prazos reais de
desenvolvimento, ou seja, ela favorece uma anlise por parte da equipe sobre sua
54

capacidade em estimar com preciso a velocidade de desenvolvimento, estimulando-a

ao aprimoramento das estimativas. A mtrica Grficos de Burn Down fornece uma
medio visual do projeto, uma vez que os grficos podem ser impressos e colocados
em um mural ou anexados a documentao favorecendo a divulgao de informaes
sobre o projeto. A mtrica Prazo auxilia a equipe visualizar como as estimativas feitas
por ela se comportam diante do andamento do projeto, mostrando o prazo prometido
pelo desenvolvedor ao cliente. A mtrica Clculo do Tempo Ideal Estimado indica o
tempo ideal necessrio para concluir o projeto baseando-se no fator de erro e com isso
decidir pelo ajuste na velocidade de desenvolvimento ou na reduo do escopo do
projeto.

6. Concluso
As mtricas fornecem subsdios para a tomada de decises e avaliaes e podem ser
aplicadas durante ou depois do trmino de um projeto. No contexto de desenvolvimento
gil, caracterizado pelo pouco rigor na aplicao de formalidades em processos de
desenvolvimento de software, elas desempenham papel fundamental, pois seus
indicadores asseguram a efetividade das prticas geis utilizadas ou no para apoiar o
desenvolvimento.
A adoo de uma ferramenta para o clculo de mtricas um importante recurso
para a medio, acompanhamento e monitoramento de projetos, no somente devido
agilidade na obteno de indicadores como tambm pelos fatores adicionais tais como
documentao e o histrico de projetos desenvolvidos.
A ferramenta XP Tracking Tool proporciona recursos para o acompanhamento,
monitoramento e controle das atividades fundamentais de um projeto XP quais sejam,
cartes de estrias, releases, integraes contnuas e testes; fortalece as prticas e
princpios preconizados pela metodologia, tais como, o pareamento e o
desenvolvimento iterativo e incremental. Disponibiliza quatro mtricas significativas
para XP e dezesseis importantes medidas de projetos geis. Adicionalmente, permite
que todos os membros da equipe de desenvolvimento acompanhem as mtricas de
andamento do projeto a qualquer momento, tornando-se mais um instrumento de
divulgao de informaes sobre a evoluo do mesmo, aspecto que fator essencial
em XP.
Como trabalhos futuros podem ser elencados: efetuar uma avaliao mais
acurada da ferramenta por meio de estudos de caso em ambiente real; ampliar o nmero
de mtricas XP implementadas pela ferramenta agregando mtricas de qualidade, team
morale e progresso do projeto; incorporar caractersticas de outras metodologias geis;
adaptar a arquitetura da XP Tracking Tool de forma a permitir sua integrao com
outras ferramentas que favoream a coleta automtica de dados.

7. Referncias
BARNETT, L. (2007) Agile Projects Must Measure Business Value. Agile Journal.
http://www.agilejournal.com/articles.
BARNETT, L. (2009) An Agile Approach to Project Management Leveraging Agile
Practices to Improve PMO Effectiveness. http://www.agilejournal.com/articles,
fevereiro, 2010.
BASILI, V. CALDIERA, G. and ROMBACH, D. (1996) The goal question metric
approach, Encyclopedia of Software Engineerin, p.528-532
BECK, K. (2004) Programao Extrema (XP) explicada - acolha as mudanas. Porto

55

Alegre: Bookman.
BECK, K. BEEDLE, M. BENNEKUM, A. COCKBURN, A. CUNNINGHAM,W.
FOWLER, M. GRENNING, J. HIGHSMITH, J. HUNT, A. JEFFRIES, R. KERN, J.
MARICK, B. MARTIN, R. MELLOR, S. SCHWABER, K. SUTHERLAND, J. and
THOMAS, D. (2001) Agile Manifesto for Agile Software Development,
http://www.agilemanifesto.org/, Outubro, 2009.
BOURGAULT, M.(2002) LEFEBVRE, E. LEFEBVRE, L.A. PELLERIN, R. ELIA, E.
Discussion of Metrics for Distributed Project Management: Preliminary Findings
Proceedings of the 35th Hawaii International Conference on System Sciences.
COCKBURN, A. (2001) Crystal Clear: a Human Powered Methodology for Small
Teams, Editora Addison Wesley Longman.
DEMMER, P and BENEFIELD, G. (2007) SCRUM Primer: An Introduction to Agile
Project
Management
with
Scrum.
Version
1.04.
www.goodagile.com/scrumprimer/scrumprimer.pdf .Acessado em fevereiro, 2010.
GRIFFITHS, M. (2007) Most Software Development Metrics Are Misleading And
counterproductive, http://www.agilejournal.com/articles, fevereiro, 2010.
HARTMANN, D. and DYMOND, R. (2006) Appropriate Agile Measurement: Using
Metrics and Diagnostics to Deliver Business Value.
AGILE '06: Proceedings of the conference on AGILE 2006, IEEE Computer Society.
HELDMAN, K. (2006) Gerncia de projetos guia para o exame oficial do PMI. Editora
Campus.
POPPENDIECK. M. (2003) Lean Software Development: An Agile Toolkit, New York:
Addison-Wesley.
PRESSMAN, R. (2006) Engenharia de Software. 6 ed. So Paulo: MacGraw-Hill.
SATO, D. (2007) Uso Eficaz de Mtricas no Desenvolvimento gil de Software,
Universidade de So Paulo.
SCHWABER, K. (1995) SCRUM Development Process. Proceedings of the 10th
Annual ACM Conference on Object Oriented Programming Systems, Languages,
and Applications (OOPSLA), p.117-134 .
SCHWABER, K. (2004) Agile Project Management with Scrum. Microsoft Press.
SOMMERVILLE, I. (2007) Engenharia de Software. 8 ed. So Paulo: Pearson Addison
Wesley.
TELES, V. (2004) Extreme Programming: aprenda como encantar seus usurios
desenvolvendo software com agilidade e alta qualidade, 1. ed. So Paulo: Novatec.

56

Sessao 3
Estudos conceituais com metodos a geis

Desenvolvimento de jogos e (quase) a gil

Fabio Petrillo e Marcelo Pimenta1
1

Instituto de Informatica Universidade Federal do Rio Grande do Sul (UFRGS)

Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil
fabio@petrillo.com, mpimenta@inf.ufrgs.br

Abstract. Software developers recognize game development as a very complex

and multidisciplinary activity. However, the success of games as one of most
profitable areas in entertainment domain could not be incidentally. The goal
of this paper is to investigate if (and how) principles and practices from Agile
Methods have been adopted in game development, by means bibliographic review and mainly through postmortem analysis.
Resumo. Os desenvolvedores de software reconhecem que o desenvolvimento
de jogos e uma atividade complexa e multidisciplinar. No entanto, o fato de
ser uma das mais bem sucedidas do setor de entretenimento, leva a crer que
tal pujanca e lucratividade nao sao obras do acaso. O objetivo deste artigo e
investigar se (e como) alguns princpios e praticas a geis tem sido aplicados no
desenvolvimento de jogos , a partir da analise da literatura sobre desenvolvimento de jogos e principalmente atraves da analise de postmortems.

1. Introduca o
A criaca o de jogos eletronicos e uma atividade incrivelmente complexa
[Gershenfeld et al. 2003] e uma tarefa mais dura do que se pode imaginar inicialmente. Hoje, criar um jogo e uma experiencia muito diferente do que era no passado
e, certamente, mais difcil, tendo explodido em complexidade nos u ltimos anos
[Blow 2004].
O incremento da complexidade, aliado a` natureza multidisciplinar do processo
de desenvolvimento de jogos (arte, som, jogabilidade, sistemas de controle, inteligencia
artificial, fatores humanos, entre muitos outros) interagindo com o desenvolvimento tradicional de software, cria um cenario que aumenta ainda mais essa complexidade, a ponto
de [Callele et al. 2005] recomendarem uma metodologia de engenharia de software especializada para o domnio de jogos digitais.
A industria de jogos pode beneficiar-se tremendamente ao adquirir os conhecimentos da engenharia de software, permitindo que os desenvolvedores utilizem praticas
solidas e comprovadas. De fato, segundo [Flynt and Salem 2004], o claro entendimento
das ferramentas disponveis e como aplica-las pode potencializar os resultados no desenvolvimento de jogos.
Na industria tradicional de software, inumeras obras tratam das boas praticas
de engenharia de software [Pressman 2006, Sommerville 2001, Tsui and Karam 2007].
Contudo, sera que essas praticas tambem sao encontradas no desenvolvimento de jogos eletronicos? Quais sao as praticas mais destacadas? Com que frequencia essas
58

praticas sao encontradas nos projetos de jogos? Que praticas sao encontradas em ambas as industrias? Existiriam boas praticas encontradas somente no desenvolvimento de
jogos? Nossa intenca o neste trabalho e discutir estas questoes.
A comunidade de desenvolvimento de jogos conta com uma vasta literatura especializada, principalmente no que tange a questoes tecnologicas. Entretanto, poucas sao as
obras de engenharia de software dedicadas a` industria de jogos eletronicos, destacandose, principalmente, as obras de [Bethke 2003] e [Flynt and Salem 2004]. E interessante
ressaltar que essas duas sao eminentemente propagadoras da visao filosofica do processo
em cascata de desenvolvimento (mais detalhes adiante na seca o 2) , em especial a obra de
[Bethke 2003], uma das mais citadas pela comunidade de jogos, demonstrando a cultura
arraigada aos processos prescritivos e nao-iterativos. Nela, [Bethke 2003] defende explicitamente a adoca o de um subconjunto confortavel do Processo Unificado (UP - Unified
Software Development Process) como processo de desenvolvimento de jogos eletronicos
[Bethke 2003], pelo simples fato de ser um padrao da industria de software.
O objetivo deste artigo e investigar se (e como) alguns princpios e praticas a geis
tem sido aplicados no desenvolvimento de jogos. Esta investigaca o pode ajudar a desmistificar a impressao de que a adoca o de praticas a geis pelos desenvolvedores de jogos e
um processo difcil. Na verdade, se muitas das praticas a geis ja estiverem sendo (mesmo
que parcialmente) adotadas, acreditamos que muitos desenvolvedores podem tentar compreender melhor os fundamentos do desenvolvimento a gil de software e mais facilmente
encontrar meios de coloca-lo em aca o no seu cotidiano.
O desenvolvimento a gil de software e um conjunto de metodologias para o desenvolvimento de software que promove adaptaca o, fortalecimento do trabalho em equipe,
auto-organizaca o, entregas rapidas de alta qualidade e adoca o de boas praticas, alinhando
o desenvolvimento com as necessidades das empresas. Acima de tudo, a proposta do
desenvolvimento a gil e aumentar a capacidade de criar e responder a` s mudancas, reconhecendo que esta nas pessoas o elemento primario para guiar um projeto ao sucesso
[Highsmith and Cockburn 2001, Marchesi et al. 2002].
O artigo esta estruturado da seguinte forma: apos esta introduca o, a seca o 2 apresenta um resumo do processo de desenvolvimento de jogos. A seca o 3 discorre sobre
as boas praticas de engenharia de software encontradas no processo de desenvolvimento
de jogos eletronicos, a partir da analise da literatura sobre desenvolvimento de jogos e
principalmente atraves da analise de postmortems. A seca o 4 discute os resultados destas
analises. Finalmente, algumas consideraco es finais sao tecidas como conclusao.

2. O processo tradicional de desenvolvimento de jogos

Ao longo dos anos, muito tem sido escrito (ver p.ex. [Bethke 2003],
[Flynt and Salem 2004], [Crawford 1984]) sobre o processo de desenvolvimento de
jogos. Segundo [Flood 2003], e possvel identificar um ciclo comum de desenvolvimento
em varias equipes: o modelo em cascata [Pressman 2006] adaptado a` produca o de jogos.
Em especial, duas etapas deste modelo podem ser apresentadas em destaque: a) a
definica o das regras do jogo e b) a produca o do Documento do Jogo ou Documento de
Projeto.
As regras de um jogo determinam o comportamento e a interaca o entre os agentes
59

que habitam o seu ambiente e na pratica sao encaradas como requisitos. De fato, o projeto
de um jogo nada mais e do que a criaca o de um conjunto de regras [Cook 2001], normalmente definidas em um processo informal, envolvendo todos os membros da equipe de
desenvolvimento [Schaefer 2000].
O Documento de Projeto (Design Document) e a principal, muitas vezes a u nica,
documentaca o de um jogo. Seu objetivo e descrever e detalhar a mecanica do jogo, isto e ,
o que o jogador e capaz de fazer dentro do ambiente do jogo, como ele e capaz de faze-lo
e como isso pode levar a uma experiencia satisfatoria. O documento tambem costuma
incluir os principais componentes da historia e descreve os cenarios no qual o jogo e
ambientado, dando suporte a` descrica o das aco es do jogador. Muitos desenvolvedores
se referem a ele como especificaca o funcional, utilizando-o como base para o projeto de
arquitetura [Rouse 2001].
A criaca o de um Documento de Projeto solido e vista, tradicionalmente, como o
passo mais importante no desenvolvimento de um jogo. As dificuldades na criaca o desse
documento sao provocadas, principalmente, pela natureza da tarefa e pelas ferramentas
usadas na sua concepca o, nao sendo possvel, por exemplo, documentar a diversao
[McShaffry 2003]. A equipe de desenvolvimento pode usar sua experiencia e intuica o na
definica o da mecanica do jogo, mas a qualidade do entretenimento, proporcionado pelo
jogo, em geral so podera ser avaliada nos estagios de teste.
A modelagem de jogos nao evoluiu nos u ltimos anos e continua baseada em
tecnicas narrativas, como roteiros e storyboards, emprestadas de outros meios de entretenimento, como o cinema [Kreimeier 2002]. A idealizaca o de um jogo tambem pode
contar com um nvel de abstraca o maior, organizado no Documento de Conceito ou Proposta (Concept Document ou Proposal). Esse documento pode analisar aspectos como
mercado, orcamento, cronograma, tecnologias, estilo de arte, perfil do grupo de desenvolvimento e alguma descrica o em alto nvel da jogabilidade. No entanto, a elaboraca o o
Documento de Conceito nao e comum a todos os projetos [Rouse 2001].
O processo de desenvolvimento mais usado na produca o de jogos e baseado no
modelo em cascata [Rucker 2002]. Esse processo e composto de fases que sao executadas
sequencialmente, na qual cada uma gera um produto e e independente das demais. As
caractersticas inerentes a` produca o de jogos exigem algumas adaptaco es ao processo
classico, que podem ser visualizadas na figura 1.
Algumas atividades (como p.ex. especificaca o, concepca o, construca o, teste de
qualidade) sao encontradas no desenvolvimento de software tradicional e nao descritas
aqui mas algumas sao especficas para o desenvolvimento de jogos, e por isto as descrevemos sucintamente:
Definica o do Roteiro e Estilo de Arte: o roteiro descreve o fluxo do jogo, isto e ,
como o jogador ira alcancar seu objetivo e como este sera expresso ao longo dos
varios cenarios do jogo. A definica o da arte especifica os estilos que serao usados,
as ferramentas para criaca o e os modelos escolhidos para validar o estilo. Ainda
que esses estagios sejam normalmente mostrados como atividades separadas, a
forte conexao entre o roteiro e o tipo de arte a ser empregada no jogo permite a
sua descrica o como um item u nico.
Teste de Jogabilidade: o produto do estagio de Teste de Qualidade e uma versao
60

Anlise

Projeto

Concepo

Especificaes
tcnicas

Testes de qualidade

Especificao do
jogo

Construo

Testes de jogabilidade

Definio do roteiro e
estilo de arte

Teste e
Qualidade

Testes Alfa e Beta

Verso final ou Gold

Figura 1. Processo em cascata adaptado ao desenvolvimento de jogos

pronta para testes de jogabilidade, na qual sao demonstradas as caractersticas do

jogo para grupos de usuarios. O objetivo das seco es de demonstraca o e validar
ou criticar a mecanica do jogo, indicando as mudancas cosmeticas ou mesmo
estruturais do projeto. Nesse estagio, e possvel a adoca o de um ciclo com a
atividade de Construca o. Dessa forma, as sugestoes e crticas dos usuarios podem
ser encaminhadas diretamente aos desenvolvedores.
Teste Alfa: o produto do estagio de Teste de Jogabilidade e um jogo que atende
(e possivelmente extrapola) as especificaco es do Documento de Projeto. Nesse
momento, o jogo esta pronto para testes com uma audiencia maior, composta por
usuarios selecionados que tem algum conhecimento do projeto. Embora algumas
das alteraco es sugeridas pelos usuarios nesse processo possam ser substanciais,
espera-se que nenhuma mudanca significativa deva ser realizada no projeto.
Teste Beta: nessa atividade o jogo esta pronto para testes com uma audiencia
maior, que detem pouco ou nenhum conhecimento sobre o projeto. O objetivo
desse estagio e medir a receptividade dos usuarios ao jogo, alem de detectar eventuais problemas que possam ocorrer.
Versao final ou Gold: no momento em que as principais alteraco es sugeridas
pelos usuarios no estagio de Teste Beta foram incorporadas ao jogo, o produto
esta pronto para ser entregue ao publico em geral.
Alguns autores argumentam que o modelo em cascata, apesar de servir como de61

nominador comum entre os ciclos existentes, nao pode ser aplicado integralmente. As
caractersticas inerentes a um jogo, como a dinamica do design ou dificuldades no planejamento da jogabilidade, tornam difcil - ou mesmo impossvel - especificar completamente
um jogo sem escrever nenhum codigo, isto e , sem ter nenhuma versao do sistema no qual
o projeto possa ser testado. Isso resulta em ciclos de desenvolvimento que envolvem lacos
entre os estagios de Especificaca o do Jogo e os processos de teste. [Rucker 2002] cita um
ciclo de desenvolvimento incremental, o Staged Delivery Model, como uma alternativa ao
modelo em cascata.

3. Boas praticas na industria

de jogos eletronicos
Nesta seca o descreveremos como foi realizado um levantamento de boas praticas referenciadas na literatura especializada para o desenvolvimento de jogos. Com as praticas
mapeadas, analisaremos sua adoca o no cotidiano do desenvolvimento de jogos, atraves
da analise de postmortems.
A Analise de Postmortems (PMA) e um enfoque de Engenharia de Software
Emprica. A Engenharia de Software Empirica visa investigar e coletar dados relevantes para, posteriormente, poder generalizar os resultados, aprendendo com erros e acertos
detectados, alem de possibilitar um futuro reuso deste conhecimento.
Experimentos controlados, os estudos de caso e surveys sao enfoques mais
frequentemente utilizados e mais conhecidos que a Analise de Postmortems (PMA)
[Shull et al. 2008, Wohlin et al. 2003, Shull et al. 2004]. A principal razao para a PMA
nao ser adotada em projetos de software nos diferentes domnios de aplicaca o nao e sua
dificuldade de operacionalizaca o, nem os recursos envolvidos ou muito menos seu custo,
mas sim a ausencia de postmortems.
Tradicionalmente, as equipes de TI nao tem habito de criar postmortems, embora existam obviamente exceco es (ver por exemplo [Stalhane et al. 2003]) e fortes
recomendaco es para faze-lo [Birk et al. 2002]. Felizmente uma rara exceca o e o domnio
dos jogos.
No desenvolvimento de jogos, a elaboraca o de postmortems e um habito difundido. Esse habito propicia a analise das praticas mais bem sucedidas, assim como a coleta
dos principais problemas enfrentados, atraves da avaliaca o de depoimentos espontaneos e
que contem os aspectos mais relevantes apontados por quem realmente participou do processo, minimizando os problemas relatos por [Shull et al. 2008] na utilizaca o de entrevistas. Exemplos importantes da adoca o dessa pratica sao encontrados no site especializado
em jogos Gamasutra1 [Myllyaho et al. 2004].
Os postmortems do Gamasutra seguem a estrutura proposta pelo Open Letter Template [Myllyaho et al. 2004], trazendo uma descrica o resumida do projeto e as
informaco es mais importantes sobre o desenvolvimento do jogo. Em seguida, o relato e
dividido em duas seco es:
O que deu certo: relata as boas praticas utilizadas no projeto, soluco es, melhoramentos, decisoes de projeto e gerenciamento que foram acertadas, podendo, em
muitos casos, servir de modelo para futuros projetos.
1

http://www.gamasutra.com

62

 O que deu errado: relata dificuldades, enganos e decisoes de projeto que resultaram em problemas durante o desenvolvimento do jogo, tanto na parte tecnica
quando na a rea gerencial.
O relato e encerrado com uma mensagem final do relator e e reservada uma seca o
na qual tipicamente e feita uma ficha do jogo, com algumas informaco es como editor e desenvolvedor; numero de desenvolvedores em tempo integral, tempo parcial e contratados;
tempo de desenvolvimento e data da liberaca o; plataforma do jogo, alem do hardware e
software utilizados no desenvolvimento.
Para realizar a analise de postmortens e a coleta das boas praticas, foi necessario
selecionar postmortems, analisa-los e compilar os resultados, chegando a um conjunto
de praticas que sao aprovadas ou desaprovadas por esses desenvolvedores. Realizamos
o mesmo procedimento (analise de literatura e analise focada de post-mortens) para a
realizaca o de um diagnostico dos maiores problemas e dificuldades encontrados no desenvolvimento de jogos (ver [Petrillo et al. 2009]).
Entre os varios postmortems existentes, selecionamos 20 postmortems publicados
no site Gamasutra, e que estao listados na tabelas 1 e 3. Os 20 postmortems analisados
foram selecionados de foram aleatoria, tendo como u nico criterio a seleca o de projetos
finalizados, isto e , que resultaram em um jogo completo e entregue ao mercado, nao
tendo sido analisado nenhum relato de projeto cancelado ou encerrado sem um produto.
Na fase de preparaca o foram estudadas as principais praticas a geis
[Cockburn 2000, Ambler 2004, Beck 1999, Poppendieck and Poppendieck 2003] e
boas praticas aplicadas na industria de jogos por [Schofield 2007, Gibson 2007]. Desse
estudo, 12 boas praticas foram elencadas para analise.
Os 20 postmortems foram lidos e as sentencas que citavam as praticas foram destacadas. Durante esse fase, mais uma pratica foi encontrada (Crenca no sucesso do
projeto), que foi acrescida ao rol analisado, totalizando 13 praticas, que sao as listadas
nas tabelas 1 e 2 e ainda na figura 2. Finalmente, uma tabela para a coleta dos dados
foi organizada (tabela 1), sendo os projetos arranjados nas linhas e as boas praticas nas
colunas.

4. Discussao
Ao analisarmos os resultados obtidos e presentes na tabela da seca o anterior, vemos que as
boas praticas mais encontradas foram equipe qualificada, motivada ou coesa e a crenca
no sucesso do projeto, com 90% (18 em 20) dos projetos relatando tais praticas. Em
seguida, destacaram-se o estmulo a` criatividade e o foco no produto, com 80% dos
projetos citando-as (16 em 20). A figura 2 apresenta o histograma de ocorrencia das boas
praticas analisadas em ordem decrescente, no qual pode-se fazer uma comparaca o grafica
desses resultados.
4.1. Analise de aderencia das boas praticas ja adotadas em projetos de jogos aos
metodos a geis
A industria de jogos, inumeras vezes de forma ad hoc, vem empregando boas praticas no
desenvolvimento de software, como foi apresentado na seca o 3. De forma mais organizada, podemos agrupar as praticas a geis analisadas, segundo as praticas a geis do Scrum,
do XP e da Modelagem a gil, formando a tabela 2.
63

64

Sim

No

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

No

Sim

Sim

Sim

Sim

Sim

Sim

Sim

No

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

18

Black&White

RangersLeadtheWay

Wild9

TradeEmpires

RainbowSix

TheXFiles

Draconus

CelDamage

ComandandConquer:TiberianSun

Asheron'sCall

AgeofEmpiresII:TheAgeofKings

DiabloII

OperationFlashpoint

HiddenEvil

ResidentEvil2

Vampire:TheMasquerade

UnrealTournament

Tropico

Ocorrncias

90%

No

Sim

GabrielKnights

90%

18

Sim

Sim

BeamRunnerHyperCross

Jogo

Crenano
Sucessodo
Projeto

Equipe
Qualificada,
Motivadaou
Coesa

80%

16

Sim

Sim

Sim

No

Sim

Sim

Sim

Sim

Sim

Sim

No

Sim

Sim

Sim

Sim

Sim

No

Sim

No

Sim

80%

16

Sim

Sim

Sim

Sim

Sim

Sim

Sim

No

Sim

Sim

Sim

No

Sim

Sim

Sim

Sim

No

Sim

No

Sim

65%

13

Sim

No

No

No

Sim

Sim

Sim

Sim

Sim

No

Sim

No

Sim

Sim

Sim

Sim

No

No

Sim

Sim

Estmulo
Controlede
FoconoProduto
Criatividade
Verso

60%

12

Sim

No

Sim

Sim

No

Sim

No

Sim

Sim

Sim

Sim

No

No

No

Sim

Sim

Sim

No

No

Sim

55%

11

No

Sim

Sim

No

No

Sim

Sim

No

Sim

Sim

Sim

Sim

No

No

Sim

No

Sim

No

No

Sim

45%

No

Sim

Sim

Sim

No

Sim

No

No

No

Sim

No

No

No

No

Sim

Sim

No

Sim

No

Sim

Usode
Ferramentas BoasPrticasde
Modelagemgil
Simplesou Programao
Produtivas

45%

No

No

Sim

Sim

No

Sim

Sim

No

Sim

Sim

Sim

No

No

No

Sim

No

No

No

No

Sim

Processo
Definido

40%

No

No

No

No

Sim

No

Sim

Sim

Sim

No

Sim

No

No

No

Sim

No

No

Sim

Sim

No

30%

No

Sim

No

Sim

No

Sim

Sim

No

No

No

Sim

No

No

No

Sim

No

No

No

No

No

25%

No

Sim

No

Sim

No

No

No

Sim

No

No

Sim

No

No

No

Sim

No

No

No

No

No

10%

No

No

No

No

No

No

No

No

Sim

No

Sim

No

No

No

No

No

No

No

No

No

Controlede RetornoRpido BoasPrticasde Integrao

Qualidade
ouIterativo Gerenciamento
Contnua

0,55

143

10

11

12

55%

7,2

46%

62%

62%

62%

46%

77%

69%

54%

69%

62%

85%

31%

38%

38%

92%

54%

15%

46%

23%

69%

%deboas
prticas
Total
encontradasno
projeto

Tabela 1. Ocorrencia
de boas praticas
nos projetos

Equipequalificada,motivadaoucoesa

90%

Crenanosucessodoprojeto

90%

Estmulocriatividade

80%

Foconoproduto

80%
65%

Boas Prticas

Controledeverso
60%

Usodeferramentassimplesouprodutivas
Boasprticasdeprogramao

55%

Modelagemgil

45%

Processodefinido

45%

Controledequalidade

40%
30%

Retornorpidoouiterativo
Boasprticasdegerenciamento

25%

Integraocontnua 10%

10

Ocorrncias

12

14

16

18
16

Figura 2. Ocorrencias
de boas praticas
Boa pratica ja adotada
Equipe qualificada, motivada ou coesa
Crenca no sucesso do projeto
Estmulo a` criatividade
Foco no produto
Controle de versao
Uso de ferramentas simples ou produtivas
Boas praticas de programaca o

Modelagem Agil
Processo definido
Controle de qualidade
Retorno rapido e iterativo
Boas praticas de gerenciamento
Integraca o contnua

E aderente ao metodo...
MA, Scrum, XP
Scrum, XP
Scrum, MA
XP, Scrum
XP
MA, XP
XP
XP, MA
Scrum, XP
XP
XP, Scrum
XP, Scrum
XP

Tabela 2. Aderencia
das boas praticas
ja adotadas em jogos aos metodos
ageis

Mesmo de modo instintivo, as equipes de desenvolvimento de jogos vem adotando

essas praticas. Nesse cenario, a implantaca o de metodos a geis, como o Scrum e XP, pode
ocorrer naturalmente, visto que as equipes ja utilizam, em suas rotinas, varios princpios
da agilidade. Assim, atraves da tabela 2 e possvel justificar a adoca o dos metodos a geis
analisados neste trabalho.
Uma nova analise pode ser proposta ao cotejarmos os resultados apresentados
por [Petrillo et al. 2009], que apresenta os problemas encontrados, com os resultados da
analise de postmortems da seca o 3, que contem as boas praticas levantadas nos postmortems. Ao avaliarmos, por exemplo, o projeto Cel Damage, que adotou 85% das boas
praticas, observamos a menor incidencia de problemas, com somente 20% dos problemas relatados. Existiria uma correlaca o linear entre o numero de problemas encontrados
e as boas praticas adotadas nos projetos de jogos?
65

Para essa analise, foi elaborada a tabela 3, que e formada pelos projetos de jogos
analisados, os percentuais de problemas encontrados e os percentuais de boas praticas
adotadas.
Projeto
Cel Damage
Trade Empires
Diablo II
Command and Conquer
Tropico
Age of Empires II
Resident Evil 2
Beam Runner
Asherons Call
Hidden Evil
Vampire
Unreal
Wild 9
The X-Files
Operation Flashpoint
Black & White
Rainbow Six
Draconus
Rangers Lead the Way
Gabriel Knights

% de problemas
encontrados
no projeto
20,0%
26,7%
33,3%
33,3%
26,7%
33,3%
40,0%
46,7%
46,7%
33,3%
46,7%
46,7%
53,3%
40,0%
80,0%
60,0%
73,3%
80,0%
46,7%
86,7%

% de boas praticas
encontradas
no projeto
84,6%
92,3%
69,2%
61,5%
46,2%
53,8%
61,5%
69,2%
69,2%
46,2%
61,5%
61,5%
53,8%
38,5%
76,9%
46,2%
38,5%
30,8%
15,4%
23,1%

Tabela 3. Comparativo entre o problemas e praticas

encontradas por projeto

A partir do levantamento feito, atraves da analise de postmortems com o foco em

aspectos da engenharia de software, vemos que as boas praticas mais citadas foram a
equipe qualificada, motivada ou coesa e a crenca no sucesso do projeto com 90% (18
em 20) dos projetos relatando essas duas praticas. Em seguida, destacaram-se o estmulo
a` criatividade e o foco no produto, com 80% dos projetos citando-as (16 em 20). Ainda
nesse contexto, as outras duas praticas mais encontradas foram o controle de versao, com
65% (13 em 20) e o uso de ferramentas simples ou produtivas, com 60%.
As praticas gerenciais sao uma carencia clara na industria de jogos. Nao chega
a 50% o numero de projetos nos quais se identifica a adoca o de um processo definido
de trabalho e somente 25% (5 em 20) dos projetos adotaram boas praticas de gerenciamento. Alem disso, somente 40% dos projetos utilizaram praticas de controle de qualidade e foi de 10% (2 em 20) a ocorrencia constatada na aplicaca o da integraca o contnua
nos projetos.

5. Conclusao
A maior contribuica o deste trabalho foi ter ajudado a organizar o universo das praticas
a geis para o domnio de jogos, a partir da analise dos problemas e das boas praticas
encontrados na industria de jogos, sendo um ponto de partida para o uso dos metodos
a geis no processo de desenvolvimento de jogos eletronicos.
Se pensarmos que todos os principais problemas da industria tradicional de software sao encontrados tambem na industria jogos (ver [Petrillo et al. 2009], e possvel
constatar que estao correlacionados e que as soluco es que podem ser adotadas na industria
tradicional de software deveriam tambem ser investigadas para a industria de jogos.
66

Mesmo de forma ad hoc e isolada, as equipes de desenvolvimento de jogos vem

adotando um conjunto de praticas a geis. Nesse cenario, a implantaca o de metodos a geis,
como o Scrum e o XP, pode ocorrer naturalmente, visto que as equipes ja utilizam, em
suas rotinas, varios princpios da agilidade.
Nossa reflexao sobre os resultados descritos neste artigo nos levam a crer que
os desenvolvedores de jogos muitas vezes nao adotaram deliberadamente estas boas

praticas por serem Ageis.

Talvez, como muitos desenvolvedores de software, eles achem
que - por serem informais - nao correspondam a` s noco es de rigor e sistematizaca o geralmente associadas a` Engenharia de Software.
Entretanto, elas sao praticas estudadas e aplicadas cada vez mais pela comunidade de Engenharia de Software, embora nem sempre reconhecidas e divulgadas como
formas disciplinadas de resolver os problemas cronicos do desenvolvimento. Como vimos, muitas das praticas a geis ja estao sendo adotadas (mesmo que parcialmente), e e
nossa convicca o que desenvolvedores - se estiverem dispostos a conhecer melhor os fundamentos do desenvolvimento a gil de software - podem facilmente incorpora-lo a` s suas
atividades.
Uma vez que ainda sao poucos os estudos academicos sobre a utilizaca o de
metodos a geis no desenvolvimento de jogos, este trabalho abre perspectivas para novas
pesquisas. Acreditamos por exemplo que a modelagem (de preferencia a gil) de elementos
complexos como a jogabilidade e a diversao merece mais investigaca o.
Os estudos realizados por [Xu and Rajlich 2006], [Kasperavicius et al. 2008] e
[Gibson 2007] nos levam a acreditar que a adoca o de praticas a geis no processo de desenvolvimento de jogos pode atingir resultados promissores. As praticas a geis parecem
contemplar melhor as caractersticas da industria de jogos, como a multidisciplinaridade e
as dificuldades na modelagem de aspectos como experiencia do usuario (user experience),
a diversao e prazer, visto que processos empricos sao mais adaptativos e reagem melhor
a mudancas durante a implementaca o do projeto. Esperamos que este artigo seja uma
contribuica o para aumentar a adoca o de praticas a geis no processo de desenvolvimento
de jogos.

Referencias

Ambler, S. W. (2004). Modelagem Agil.

Bookman, Sao Paulo.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley
Professional, Reading, MA, 1st edition.
Bethke, E. (2003). Game Development and Production. Wordware Publishing, Plano.
Birk, A., Dingsoyr, T., and Stalhane, T. (2002). Postmortem: never leave a project without
it. IEEE Software, 19.
Blow, J. (2004). Game development: Harder than you think. ACM Press Queue, 1(10):28
37.
Callele, D., Neufeld, E., and Schneider, K. (2005). Requirements engineering and the
creative process in the video game industry. In 13th IEEE International Conference on
Requirements Engineering.
67

Cockburn, A. (2000). Agile Software Development. Addison Wesley Longman, Reading,

MA, 1st edition.
Cook, D. (2001). Evolutionary design - a practical process for creating great game designs. GameDev.net.
Crawford, C. (1984). The Art of Computer Game Design. Mcgraw-Hill Osborne Media.
Flood, K. (2003). Game unified process. GameDev.net.
Flynt, J. P. and Salem, O. (2004). Software Engineering for Game Developers. Software
Engineering Series. Course Technology PTR, 1st edition.
Gershenfeld, A., Loparco, M., and Barajas, C. (2003). Game Plan: the insiders guide
to breaking in and succeeding in the computer and vieo game business. St. Martin s
Griffin Press, New York.
Gibson, A. (2007). Agile game development and fun. Technical report, University of
Colorado Department of Computer Science.
Highsmith, J. and Cockburn, A. (2001). Agile software development: The business of
innovation. IEEE Computer, 34:120122.
Kasperavicius, L. C. C., Bezerra, L. N. M., Silva, L., and Silveira, I. F. (2008). Ensino de

desenvolvimento de jogos digitais baseado em metodologias Ageis:

o projeto primeira
habilitaca o. In Anais do XXVIII Congresso da SBC - Workshop sobre Educaca o em
Computaca o, pages 89 98, Belem do Para.
Kreimeier, B. (2002). The case for game design patterns. Gamasutra - The Art & Business
of Making Games, http://www.gamasutra.com/features/20020313/kreimeier 01.htm.
Marchesi, M., Succi, G., Wells, D., and Williams, L. (2002). Extreme Programming
Perspectives. Addison Wesley.
McShaffry, M. (2003). Game Coding Complete. Paraglyph Press, Scottsdale.
Myllyaho, M., Salo, O., Kaariainen, J., and Koskela, J. (2004). A review of small and
large post-mortem analysis methods. In Proceedings of the ICSSEA, Paris.
Petrillo, F., Pimenta, M., Trindade, F., and Dietrich, C. (2009). What went wrong? a
survey of problems in game development. ACM Computer in Entertainment, CIE:
7(1).
Poppendieck, M. and Poppendieck, T. (2003). Principles of lean thinking.
Pressman, R. S. (2006). Engenharia de Software. McGraw-Hill, Sao Paulo, 6th edition.
Rouse, R. (2001). Game Design: theory & practice. Wordware Publishing, Inc.
Rucker, R. (2002). Software Engineering and Computer Games. Addison Wesley.
Schaefer, E. (2000). Postmortem: Diablo ii. Gamasutra - The Art & Business of Making
Games.
Schofield, B. (2007). Embracing fun: Why extreme programming is great for game development. Gamasutra: The Art & Business of Making Games.
Shull, F., Mendonca, M., Basili, V., Carver, J., Maldonado, J. C., Fabbri, S., Travassos,
G. H., and Ferreira, M. C. (2004). Knowledge-sharing issues in experimental software
engineering. Empirical Software Engineering, 9(1-2):111137.
68

Shull, F., Singer, J., and Sjberg, D. I. (2008). Guide to Advanced Empirical Software
Engineering. Springer-Verlag, London.
Sommerville, I. (2001). Software Engineering. International computer science series.
Addison-Wesley, London, 6th edition.
Stalhane, T., Dingsoyr, T., Hanssen, G. K., and Moe, N. B. (2003). Post Mortem? An
Assessment of Two Approaches, chapter Empirical Methods and Studies in Software
Engineering, pages 129141. Springer Berlin / Heidelberg.
Tsui, F. and Karam, O. (2007). Essentials of software engineering. Jones and Barlett
Publishers, Sao Paulo, 6th ed edition.
Wohlin, C., Host, M., and Henningsson, K. (2003). Empirical Methods and Studies in
Software Engineering, chapter Empirical Research Methods in Software Engineering,
pages 723. Springer Berlin / Heidelberg.
Xu, S. and Rajlich, V. (2006). Empirical validation of test-driven pair programming in
game development. Computer and Information Science, 5th IEEE/ACIS International
Conference on, 0:500505.

69

Perspectiva Social, Comunicao e Cooperao nos

Processos de Desenvolvimento de Software
Amaury Soares Pires de Carvalho1, Ciro Carneiro Coelho1
1

Ps-Graduao em Engenharia de Software - Faculdade Sete de Setembro (Fa7)

amauryspires@gmail.com, ciro@fa7.edu.br
Abstract. This work presents a study on the social aspects contained in both
predictive and adaptive software development processes. It points human
factors that influence and are influenced by these processes. It also analyzes
practices that favors cooperation based on the Theory of Games and indicates
characteristics that improve cooperation between team members in software
development based on Axelrods cooperation factors.
Resumo. O presente trabalho investigou os aspectos sociais contidos nos
processos preditivos e adaptativos de desenvolvimento de software. So
apontados os fatores humanos que influenciam e so influenciados pelos
processos. So analisadas, com base na Teoria dos Jogos, prticas que
favorecem a cooperao entre membros das equipes de desenvolvimento com,
bem como identificando, com base nos fatores de cooperao de Axelrod,
caractersitcas que propiciam uma maior cooperao nas equipes de
desenvolvimento.

1. Introduo

O crescente aumento na complexidade dos produtos de softwares ocasionou uma forte

demanda por recursos humanos devidamente capacitados para sua produo, bem como
por processos que possam suportar e potencializar tal fora produtiva.
Dessa forma durante muito tempo o desenho de novos processos de
desenvolvimento que permitissem a produo em massa de software eficiente e de
qualidade foi uma preocupao importante na rea de engenharia de software.
Na ltima dcada, porm, o foco vem mudando do processo para o indivduo,
como evidenciam os trabalhos de Beck (1999), o movimento liderado pela Agile
Alliance com o Manifesto gil, e a proposta do quinto valor do manifesto gil
(MARTIN, 2008), Craftsmanship over Execution, e o conseqente Manifesto for
Software Craftsmanship (ISCC, 2009).
Desenvolvimento de software, segundo McBreen (2001), no uma atividade
realizada de forma solitria por indivduos que escrevem programas para uso prprio.
Ao invs disso, trata-se de uma tarefa intelectual social que requer muita comunicao e
colaborao. A construo de sistemas, portanto, requer trabalho em equipe.
Num contexto onde o indivduo e suas interaes em equipe emergem como um
fator relevante no cenrio do desenvolvimento de software mundial, o estudo das
caractersticas cooperativas e sociais presentes nos processos de desenvolvimento tornase relevante para elucidar deficincias produtivas em equipes de software, uma vez que
essas caractersticas so fortemente influenciadas pelo tipo de processo utilizado.
Highsmith et al. (2001) defende que processos geis so desenhados para
capitalizar o potencial nico de cada indivduo e cada equipe, porm tais mtodos no
so para qualquer um. Pessoas com grande foco em processo e no colaborativas tero

70

dificuldade em aderir s idias do desenvolvimento gil, as quais funcionam melhor em

culturas organizacionais voltadas para pessoas e que valorizam a colaborao.
Em contrapartida, os processos tradicionais, de acordo com Cockburn (2006),
costumam apoiar-se em aspectos comportamentais pouco confiveis das pessoas, tais
como exigir que estas sejam lgicas e precisas, que no cometam erros, ou que
pesquisem e usem solues prontas quando em geral preferem criar, ser conservadoras
nas aes e escravas do hbito.
Nesse contexto, Cockburn (2006) prope que o desenvolvimento de software
seja visto sob o prisma de um processo onde os indivduos interagem entre si segundos
as regras de um jogo, onde a inveno, a comunicao e a cooperao atuam como
peas importantes nesse quadro.
Este trabalho faz uma anlise social dos processos de desenvolvimento de
software sob o prisma da Teoria dos Jogos (DAVIS, 1997) e dos fatores de cooperao
de Axelrod (1996; 2007). Algumas prticas so analisadas quanto sua capacidade de
promover cooperao entre os membros da equipe de desenvolvimento e so apontados
os fatores sociais que influenciam os processos estudados, analisando pontos que
favorecem uma maior cooperao entre os membros das equipes de desenvolvimento.

2. Teoria dos jogos

Teoria dos Jogos, segundo Morgenstern (apud DAVIS, 1997), uma disciplina que vem
ganhando grande interesse por parte do pblico em geral devido suas aplicaes nas
mais variadas reas. Embora inicialmente a teoria focasse apenas o estudo do campo de
exatas, a sua estrutura matemtica atual consegue explicar com sucesso fenmenos
sociais e seus problemas, tais como conflitos que levam a competio ou colaborao
entre indivduos.
A importncia do estudo de problemas tericos relacionados a jogos, segundo
Davis (1997), que:
Num jogo existem outros indivduos tomando decises baseadas em seus
prprios desejos. [...] Num jogo cada jogador deve perceber se seus
objetivos esto alinhados ou no aos dos demais e decidir cooperar ou
competir com todos ou [somente] alguns deles.

Conforme Fiani (2006), a teoria dos jogos ajuda a entender teoricamente o

processo de deciso de agentes que interagem entre si, a partir da compreenso da
lgica da situao em que esto envolvidos. Para o autor (2006), toda situao que
envolva interaes entre agentes racionais que se comportam estrategicamente pode ser
considerada e analisada como um jogo.
Um ponto importante da teoria que esta diferencia basicamente dois tipos de
jogos: os de soma-zero e de soma-no-zero. Jogos como xadrez ou damas so somazero devido o fato da vitria de um jogador significar a derrota do adversrio, fazendo
com que a soma do ganho positivo de um e a perda negativa do outro resulte em zero.
Embora o estudo de tais jogos tenha seu valor, jogos de soma-zero diferenciamse de problemas reais, pois o primeiro permite encontrar solues deterministas,
enquanto o segundo em geral traz consigo mltiplas, indiretas ou simplesmente
nenhuma soluo universalmente aceitvel (DAVIS, 1997). Nesse contexto, jogos de
soma-no-zero so mais comuns no nosso dia-a-dia, alm de serem mais interessantes e
difceis de analisar. Tais jogos caracterizam-se por no haver necessariamente relao
direta entre o ganho de um jogador e a perda do adversrio. Na verdade, no
necessrio nem mesmo existirem perdedores para haver ganhadores.

71

Os jogos podem ainda ser caracterizados como cooperativos ou nocooperativos. De acordo com Fiani (2006), um jogo dito no-cooperativo quando os
jogadores no podem estabelecer compromissos garantidos em relao ao jogo. Caso
contrrio, se os jogadores podem estabelecer compromissos relacionados ao jogo, e
esses compromissos possuem garantias efetivas, diz-se que o jogo cooperativo. Nessa
definio, jogos de soma-no-zero so por natureza caracteristicamente cooperativos,
pois permitem que tais compromissos sejam efetuados, mesmo que na prtica os
jogadores no o faam.
O nvel de comunicao entre os jogadores tem papel preponderante em jogos de
soma-no-zero, o que no acontece nos de soma-zero devido estes serem
intrinsecamente competitivos. Em geral, quanto mais cooperativo o jogo, mais crucial
para o resultado final deste torna-se a habilidade de comunicar-se (DAVIS, 1997). A
comunicao importante em jogos cooperativos devido a exigncia de que cada
indivduo conhea os desejos e pretenses dos demais para que se possa tomar a deciso
que melhor alinhe suas expectativas s dos envolvidos.
Embora notavelmente identificados com jogos de soma-no-zero, problemas do
mundo real so difceis de serem diretamente estudados devido no poderem ser
analisados em ambientes cientificamente controlados (DAVIS, 1997). Ento, uma
forma de faz-lo substituindo-os por modelos de jogos mais simplificados que possam
ser simulados quantas vezes se fizer necessrio.
Um dos modelos mais estudados dos jogos de soma-no-zero o problema do
Dilema do Prisioneiro, originalmente formulado por A. W. Tucker (DAVIS, 1997):
Dois suspeitos [cmplices] de cometerem um crime foram presos pela
polcia e colocados em celas separadas. Cada suspeito deve confessar ou
manter-se em silencio, e cada qual sabe as possveis conseqncias de sua
ao. Essas so: (1) Se um suspeito confessar e o outro no, o que
confessou fornece evidencias ao Estado e libertado enquanto o outro
preso por vinte anos. (2) Se ambos confessarem vo juntos para a priso
por cinco anos. (3) Se ambos ficarem em silencio, vo para a priso por
um ano por porte ilegal de armas. [...] Cada jogador tem duas escolhas
bsicas: agir cooperativamente ou no cooperativamente. Quando
todos os jogadores cooperam, obtm melhores resultados de quando no o
fazem.

Jogos de soma-no-zero so intrincados, altamente sujeitos a interferncias

causadas pelo ambiente e comunicao envolvidos. Quando os interesses de mltiplos
indivduos entram em jogo o problema cresce de forma surpreendente. A interao entre
indivduos inseridos em um mesmo jogo expe os jogadores a uma vasta possibilidade
de situaes, afetando-os individualmente e ao grupo como um todo.
Em geral sistemas profissionais no so escritos por desenvolvedores solos, mas
sim por equipes de pessoas com objetivos em comum. Dessa forma, de suma
importncia considerar-se tal aspecto comportamental dos jogos de soma-no-zero entre
mltiplos indivduos quando da anlise dos processos de desenvolvimento de software.

3. Desenvolvimento de software: um jogo de comunicao e cooperao

Desenvolvimento de software, segundo Cockburn (2006), uma atividade de cognio
e expresso realizada por pessoas que pensam e comunicam-se medida que trabalham
contra limites econmicos, de tempo e de recursos, condicionadas s suas culturas e
sensveis aos indivduos envolvidos no processo.

72

Assim, Cockburn prope que a construo de um software por uma equipe pode
ser visto como um jogo de inveno e cooperao onde os indivduos s vezes
cooperam e s vezes competem entre si.
Na teoria dos jogos, tal tipo de jogo classificado na categoria de soma-no-zero
posto ser cooperativo, podendo assim gerar relaes ganha-ganha , com mltiplos
indivduos. Assim, no desenvolvimento de software, como em todos os jogos de somano-zero, a comunicao tem um papel preponderante. Logo, a qualidade dos
participantes como um time pode ser medida atravs de sua capacidade de comunicao
e cooperao durante o jogo. Para que isso acontea, os indivduos devem agir como
especialistas em comunicao (COCKBURN, 2006).
No entanto, alguns desenvolvedores no gostam de desenvolvimento
colaborativo, preferindo trabalhar sozinhos e mostrar o produto aos usurios somente
quando a aplicao estiver pronta. Outros no lidam bem com ciclos incrementais de
requisitos e preferem uma especificao formal e completa no inicio do projeto. H
ainda os que no abraam o aprendizado contnuo, no aceitando facilmente novas
idias. Todos esses problemas minam a efetividade do desenvolvimento colaborativo.
Cockburn (2006) sugere estratgias que uma equipe deve seguir no jogo de
desenvolver sistemas, tais como: a) manter a equipe original intacta o mximo de tempo
possvel; b) jogadores que so aprendizes em uma partida devem tornar-se lideres no
jogo seguinte; c) utilizar um modelo de aprendizagem para treinar novatos na equipe; e,
d) jogar de forma simples na primeira partida, reservando tempo para melhorar o jogo
nas partidas seguintes (o que significa realizado, no campo de software, pelo
desenvolvimento iterativo e refatorao).

4. Processos de software analisados como dilema do prisioneiro

Desenvolvimento de software uma tarefa intelectual social que requer muita
comunicao, colaborao e, portanto, trabalho em equipe. Para que isso de fato ocorra,
os indivduos envolvidos no processo devem trabalhar de forma coesa, permitindo que
estes evoluam de mero grupo de pessoas para o status de equipe.
Uma forma de analisar os padres comportamentais apresentados por grupos de
indivduos expostos a determinados ambientes e situaes consider-los imersos em
um jogo, pois, segundo a Teoria dos Jogos, toda situao que envolva interaes sociais
pode ser analisada como tal.
Blumen (1995) afirma que, sob o ponto de vista da Teoria dos Jogos, toda
interao social contida no desenvolvimento de software explica-se como dilemas do
prisioneiro, sendo freqentemente dilemas iterados. Como exemplo, o autor cita a
relao comercial entre desenvolvedor e cliente, que se baseia na promessa de entrega
de um bom produto pelo primeiro em troca do devido pagamento pelo segundo.
Lieberman (2001) cita que o dilema do prisioneiro emerge tambm na relao
cliente versus desenvolvedor durante a negociao do escopo de projetos de software,
quando se abre a possibilidade de apoio mtuo (cooperao) ou disputa (competio),
esta ltima na forma de ditadura, extorso ou impasse entre eles.
Semelhantemente, Hazzan & Dubinsky (2005) lembram que o dilema do
prisioneiro tambm ocorre dentro da equipe de desenvolvimento, conforme demonstra o
cenrio de cooperao/competio entre dois desenvolvedores em um mesmo projeto
(Quadro 1). Para os autores a competio entre membros da equipe a fonte de alguns
dos problemas que caracterizam os processos de desenvolvimento de software.
Os autores afirmam que, num ambiente de desenvolvimento de sistemas, a
cooperao e competio expressam-se em diferentes formas, tais como
compartilhamento ou restrio de informao, o uso ou no dos padres de codificao

73

Coopera
Com
pete

Desenvolvedor A

da companhia, cdigo de simples ou complexo entendimento, entre outras situaes. A

cooperao vital em processos de engenharia de software, sendo importante mesmo
quando apenas parcial durante os projetos, como expresso nos quadrantes cooperacompete demonstrado no cenrio do Quadro 1.
Hazzan & Dubinsky (2005) afirmam que os membros da equipe so
freqentemente solicitados a cooperarem entre si, mas, quando h incerteza se haver
reciprocidade por parte dos demais membros do projeto a tendncia natural a
competio, resultando no pior cenrio (quadrante compete-compete do Quadro 1).
Desenvolvedor B
Coopera
Compete
O projeto completado no tempo Cooperao de A leva o projeto a ser completado no
previsto.
tempo previsto. Porm, desde que A dedica parte do
tempo analisando e corrigindo o cdigo escrito por B,
Contribuio pessoal de A e B so enquanto B continua trabalhando em sua prpria
iguais, compartilhando o bnus pelo parte, a contribuio de A para o projeto avaliada
sucesso do projeto.
como menor que B. Como resultado, B aparenta ser
responsvel pela produtividade e sucesso do projeto.
Semelhante ao apresentado em A Desde
que ambos exibem comportamento
coopera versus B compete, porm A competitivo, no completam o projeto no tempo
apresenta melhor produtividade.
previsto, cancelando-se o projeto.
Quadro 1. Dilema do prisioneiro em equipes de desenvolvimento de software.

Nesse contexto, de acordo com os autores (2005), a anlise da interao da

equipe mais especificamente os processos que estes aplicam no seu dia a dia na
forma de cenrios de competio e cooperao modelados como dilema do prisioneiro
pode auxiliar na soluo de conflitos existentes dentro de projetos de software.
4.1 O modelo ganha-ganha de negociao de conflitos
Egyed & Boehm (1998) propem um modelo que visa identificar solues para
situaes que envolvam dilema do prisioneiro, mais especificamente a conciliao de
interesses conflitantes atravs de negociao, objetivando estabelecer relaes de ganhaganha entre os envolvidos.
O modelo, segundo os autores, possui quatro artefatos principais, conforme
apresentado na Figura 1: condies de ganho, problemas, opes e acordos.
envolvem
Condies de ganho
Problemas

lidam com

Opes
cobrem

adotam
Acordos

Figura 1. Artefatos do modelo ganha-ganha de negociao de conflitos.

De acordo com o modelo, condies de ganho capturam os interesses na

forma de objetivos e preocupaes de cada um dos envolvidos no dilema. Em seguida,
caso no sejam controversos, estes so logo cobertos por um acordo. Em caso
contrrio um problema estabelecido para registrar o impasse entre os mesmos.
Na existncia de um problema, opes so registradas na forma de aes e
alternativas que possam eliminar ou pelo menos mitigar a situao. Aps a negociao

74

do problema atravs da exposio aos envolvidos das opes um acordo

estabelecido registrando qual opo foi utilizada para resolver o problema.
Dessa forma, o modelo expe metodicamente as questes levantadas no dilema
vivido pelos envolvidos e como os acordos foram estabelecidos, provendo uma
documentao que pode ser utilizada no futuro para promover lies aprendidas alm de
tornar transparentes as decises tomadas.
4.2 Prticas geis mapeadas como dilema do prisioneiro
Extreme Programming (XP), segundo Astels et al. (2002), um jogo produtivo e
rpido, no qual os elementos importantes [...] so seus princpios, suas prticas e
seus jogadores, e onde ganhar [...] significa entregar um produto. Adicionalmente,
Beck (2004) afirma que XP um jogo que objetiva construir relaes ganha-ganha entre
as partes, mais notadamente a rea de negcios e desenvolvimento.
XP possui prticas organizacionais (ex: desenvolvimento iterativo, cliente
presente), prticas de equipe (ex: propriedade coletiva, ritmo sustentvel) e prticas
individuais (ex: projeto simples, refatorao) (ASTELS et al., 2002).
Sero analisadas aqui, na forma de cenrios de impasse mapeados como dilema
do prisioneiro, uma prtica de equipe, representada pela programao em pares, uma
individual, constituda pelo desenvolvimento baseado em testes, e uma
organizacional, o desenvolvimento iterativo.
O primeiro cenrio (Quadro 2), expe problemas e opes disponveis quando
membros do projeto discordam na adoo da programao em pares.
Programao em pares , segundo Beck (2004), um dilogo entre duas
pessoas tentando programar simultaneamente (e analisar, projetar e testar) e entender
em conjunto como programar melhor, sendo tambm uma conversao em muitos
nveis, assistida por um computador e focada nele.
De acordo com Williams (2000), muitos rejeitam a idia de programao em
pares porque assumem que o custo homem-hora ir duplicar quando aloca-se dois
desenvolvedores na mesma atividade. Porm, ainda segundo o autor, o que ocorre de
fato a reduo no tempo total de desenvolvimento, diminuindo os custos.
PRTICA:
Programao em pares
DILEMA DO PRISIONEIRO:
Cooperao:
Todos os membros formam pares, alternando-se periodicamente, para conduzir em
conjunto suas atividades de desenvolvimento conforme sugerido pelo processo
(ASTELS et al., 2002; BECK, 2004).
Competio:
Um ou mais membros no seguem a recomendao de trabalhar em par, ou o fazem
aqum do recomendado pelo processo (ASTELS et al., 2002; BECK, 2004).
MODELO DE NEGOCIAO GANHA-GANHA:
Cooperador
Competidor
Condies
Ganha quando compartilha suas atividades Ganha quando analisa, desenvolve e testa de
de ganho:
de desenvolvimento com um parceiro.
forma individual, sem interferncias de
terceiros.
Problemas:
Quando a programao em pares no Programao em pares uma prtica difcil e
feita perde-se em oportunidade de cansativa (SHARP; ROBINSON, 2006). Falta
comunicao, coeso da equipe, maior de espao fsico, monoplio do teclado,
compromisso
entre
os
indivduos, conflitos de propriedade ou prioridade entre
produtividade, melhor relao custo- atividades, ou simples desavenas pessoais
benefcio e qualidade de cdigo (BECK, entre indivduos podem impactar na
2004). A programao solo restringe a produtividade quando estes codificam em par
viso do desenvolvedor, tendendo este a se (ASTELS et al., 2002; BECK, 2004). Tal
ater apenas s partes e no ao todo do prtica aumenta o custo do desenvolvimento
problema (ASTELS et al., 2002).
ao alocar dois recursos a uma nica atividade.
Opes:
Pode-se usar o papel treinador coach Pode-se estabelecer um horrio para a prtica

75

como um comunicador para divulgar o ao invs de t-la em tempo integral. Outras

processo como um todo para a gerncia e a prticas como jogo do planejamento,
equipe, instigando-os a desenvolver suas padres de codificao, ritmo sustentvel
habilidades tcnicas e de abstrao de e projeto simples minimizam desavenas na
problemas, auxiliando na adoo de outras equipe. Alm disso, deve-se evitar pares entre
prticas, alm de estar disponvel como indivduos que no se do bem no campo
parceiro
de
desenvolvimento,
em pessoal, e deve-se rearranjar o espao fsico de
particular para desenvolvedores iniciantes forma a propiciar a prtica (BECK, 2004;
na prtica de programao em pares WILLIAMS, 2000).
(BECK, 2004).
Acordos:
Adotar o papel treinador na equipe, incentivar o uso das outras prticas individuais e de
equipe, estabelecer horrio para a programao em par e redispor o espao fsico do local de
trabalho da equipe, o que est de acordo com o princpio de adaptao local da XP pela
gerencia como proposto por Beck (2004).
Quadro 2. Prtica programao em pares mapeada como dilema do prisioneiro.

Em contrapartida, Astels et al. (2002) lembra que a programao em pares no

afeta a velocidade em si do desenvolvimento, isto , produz-se em par pelo menos
tanto quanto individualmente, porm, a qualidade final do produto superior.
Beck (2004) afirma que a programao em pares pode ser desconfortvel no
princpio, devendo-se ser rgido em aplic-la. A viso de uma prtica intensa e
cansativa compartilhada tambm por Sharp & Robinson (2006), que desaconselham
sua aplicao em tempo integral. Alm disso, Astels et al. (2002) diz que muitos
desenvolvedores sentem que a programao em pares limita sua independncia.
Para Kniberg (2007) essa averso prtica se deve principalmente falta de
experincia real na mesma e que, quando dada uma oportunidade para tal, em geral,
esta viso modificada. Mesmo assim, segundo o autor, certos indivduos simplesmente
no se adaptam a ela, viso tambm compartilhada por Beck (2004).
Williams et al. (2000) cita que, numa experincia realizada com alunos da
universidade de Utah em 1999, identificou-se que cerca de 90% dos envolvidos
preferiram a programao em par do que a solo e que nela viam-se mais confiantes do
resultado entregue, mas que sentiram a prtica mais eficaz nos momentos de anlise,
projeto e testes do que de codificao propriamente dita. O autor cita tambm que as
principais preocupaes apresentadas pelos alunos eram a quantidade de comunicao
adicional requerida, a adaptao aos hbitos, estilo de programao e ego do parceiro
tanto excesso, por no deixar-se ajudar, quanto falta, quando no ajuda o parceiro
alm das possveis desavenas sobre aspectos de implementao.
Assim, a prtica programao em pares expe um forte vis social ao quebrar
o paradigma do desenvolvedor solo. A anlise ganha-ganha constante no Quadro 2
demonstra que impasses em sua adoo na equipe podem ser mitigadas seguindo-se
prticas e conselhos simples constantes no prprio processo XP.
J a prtica desenvolver o software iterativamente, demonstrada no Quadro 3,
discute o cenrio onde a cultura tradicional de desenvolvimento, representado por
defensores do modelo cascata, confronta-se com a proposta de desenvolvimento
iterativo e incremental, gerando impasse dentro da equipe.
Kruchten (2003) descreve que o modelo iterativo quebra o ciclo de
desenvolvimento em uma sucesso de iteraes, alm disso, cada iterao parece
pequenos projetos envolvendo atividades de captura de requisitos, projeto,
implementao e garantia da qualidade. Alm disso, o autor defende que a importncia
do modelo iterativo incremental est em mitigar riscos de projeto, em acomodar mais
facilmente mudanas, promover reuso e tambm permitir a equipe aprender sobre os
requisitos medida que desenvolve o sistema.

76

Defensores do modelo tradicional, por sua vez, relatam a dificuldade gerencial

de estimar o esforo total do projeto (KRUCHTEN, 2003), bem como de substituir
princpios de engenharia h muito tempo estabelecidos na industria de software e
baseadas em tcnicas exaustivamente testadas por outras industrias por novos conceitos
que exigem treinamento por parte dos desenvolvedores (LARMAN et al., 2002).
Alm disso, o tamanho e quantidade de iteraes a serem aplicados em cada
projeto tambm podem motivar conflitos na equipe, no que tange o confronto da viso
mais preditiva de longas iteraes versus mais adaptativa de pequenas e rpidas entregas
(LARMAN et al., 2002).
Novamente o impasse na equipe, quando analisado sob o ponto de vista de
dilema do prisioneiro mostrado no Quadro 3, pode ser solucionado com a situao
ganha-ganha de treinamento e adaptao do desenvolvimento iterativo, principalmente
em relao durao das iteraes, adequando-o ao projeto e estilo cultural vigentes.
PRTICA:
Desenvolver o software iterativamente.
DILEMA DO PRISIONEIRO:
Cooperao:
Todos os membros da equipe desenvolvem de forma iterativa e incremental de
acordo como recomendado pelo processo (KRUCHTEN, 2003).
Competio:
Um ou mais membros no desenvolvem iterativamente isto , adotam o modelo
tradicional cascata ou o fazem aqum do sugerido pelo processo (LARMAN et
al., 2002).
MODELO DE NEGOCIAO GANHA-GANHA:
Cooperador
Competidor
Condies de Ganha
quando
os
sistemas
so Ganha
quando
os
sistemas
so
ganho:
desenvolvidos de forma iterativa e desenvolvidos de forma menos iterativa e
incremental.
mais tradicional.
Problemas:
No desenvolver iterativamente significa Desenvolver iterativamente vai contra as
enfrentar problemas de acomodao de prticas de engenharia tradicionais e
mudanas e mitigao de riscos, originado dificultam a estimativa de esforo do
pela impossibilidade de congelamento de projeto, principalmente quando contratos
requisitos cliente e projeto mudam com o de preo fixo so exigidos (LARMAN et
tempo o que impacta no modelo al., 2002).
preliminar que foi proposto no inicio do
projeto (KRUCHTEN, 2003).
Opes:
O desenvolvimento iterativo presume Pode-se reduzir o nmero de iteraes,
mini-cascatas dentro de cada iterao, com aumentando proporcionalmente o tamanho
pores de elicitao de requisitos, anlise destas, de acordo com o tipo de projeto
e projeto, implementao, integrao e enfrentado e o tamanho da equipe alocada,
teste
(LARMAN
et
al.,
2002; fazendo com que a prtica se aproxime do
KRUCHTEN, 2003).
modelo tradicional cascata facilitando
Pode-se promover e valorizar o uso da assim sua adoo (LARMAN et al.,
prtica atravs de treinamento da equipe e 2002).
demais
interessados
no
projeto,
principalmente com o estabelecimento de
mentores e uso do papel engenheiro de
processo (LARMAN et al., 2002;
KRUCHTEN, 2003)
Acordos:
Promoo de treinamento na prtica para os envolvidos no projeto. Alm disso,
considerar o tamanho e tipo de projeto, bem como o tamanho da equipe, na deciso do
nmero de iteraes necessrias, o que est de acordo com o principio de adaptao do
processo RUP empresa e projeto (KRUCHTEN, 2003; LARMAN et al., 2002).
Quadro 3. Prtica desenvolver software iterativamente mapeada como dilema do prisioneiro.

O terceiro cenrio analisado como dilema do prisioneiro, trata da adoo pela

equipe da prtica individual desenvolvimento guiado por testes (Quadro 4).

77

Desenvolvimento guiado por testes , conforme Beck (2004), uma atividade

feita pelos desenvolvedores para aumentar sua confiana no cdigo. Nela, testes so
escritos antes de codificar o programa, para ento serem guardados e executados
posteriormente sempre quando o programa for modificado.
Segundo Beck (2004), testar o que se faz vai contra a natureza humana, por isso
deve-se buscar motivos que tornem a prtica benfica para o praticante. O principal
motivo em curto prazo para escrever testes antes do cdigo que estes aumentam a
confiana do desenvolvedor sobre o que est sendo escrito.
Alm disso, quando a anlise ganha-ganha feita na situao de impasse de
adoo da prtica, conforme mostrado no Quadro 4, observa-se novamente que o
processo XP possui dispositivos reguladores sociais intrnsecos que auxiliam na
mitigao de tais ocorrncias, evitando-se apoiar-se somente em normas para isso.
PRTICA:
Desenvolvimento guiado por testes
DILEMA DO PRISIONEIRO:
Cooperao:
Todos os membros escrevem os testes antes do cdigo conforme sugerido pelo
processo (ASTELS et al., 2002; BECK, 2004).
Competio:
Um ou mais membros no seguem a recomendao de escrever testes antes do
cdigo, ou os escrevem aqum do recomendado pelo processo (ASTELS et al.,
2002; BECK, 2004).
MODELO DE NEGOCIAO GANHA-GANHA:
Cooperador
Competidor
Condies
Ganha quando equipe escreve testes Ganha
em
no
escrever
testes
de ganho:
automatizados.
automatizados.
No escrever testes reduz a confiana no Escrever testes diminui a produtividade da
Problemas:
cdigo.
Alm
disso,
ganhos
de equipe. Alm disso, a maioria do cdigo
produtividade em curto prazo por no ter existente
foi
escrita
sem
testes
que construir testes automatizados resultam automatizados, de onde se pode inferir que
em longo prazo em atrasos por retrabalho estes ltimos no so essenciais para o
causado por excesso de depurao e anlise desenvolvimento de software (BECK,
de cdigo desnecessrio (ASTELS et al., 2004). Outro ponto que testes devem ser
2002; BECK, 2004). Outro ponto que escritos por outra equipe, composta por
manter um testador que s age no final do especialistas em testes, os quais
ciclo de desenvolvimento retarda a verificaro e validaro o sistema
identificao de problemas, encarecendo o exaustivamente aps o mesmo tiver sido
processo (ASTELS et al., 2002).
escrito, gerando um extenso e detalhado
relatrio de problemas a serem resolvidos
pelos desenvolvedores (ASTELS et al.,
2002; BECK, 2004).
Opes:
Pode-se utilizar programao em pares Estabelecer claramente para a equipe de
para promover a prtica de testes, pois a desenvolvedores o nvel de erro tolervel
primeira diminui a probabilidade de que em determinado perodo de tempo ajuda a
ambos os desenvolvedores esqueam equacionar
o
nmero
de
testes
simultaneamente de seguir a segunda devido automatizado que deve ser escrito (BECK,
ao efeito presso dos pares (ASTELS et 2004).
al., 2002; BECK, 2004; KNIBERG, 2007).
Acordos:
Adoo da programao em pares buscando unir programadores com nveis diferentes
de experincia em teste, estabelecimento do nvel de teste que ser escrito pela equipe
ajustado s exigncias de cada projeto e sugesto de foco primeiro na escrita dos testes
mais simples e urgentes s equipes iniciantes (ASTELS et al., 2002; BECK, 2004;
KNIBERG, 2007).
Quadro 4. Prtica desenvolvimento guiado por testes mapeada como dilema do prisioneiro.

5. Cooperao e os processos de desenvolvimento de software

Cooperao um aspecto social que desempenha importante papel no mbito das

relaes humanas por permitir agregar indivduos em torno de um fim comum,
otimizando a utilizao de recursos e maximizando os benefcios advindos dessa

78

interao. Nesse contexto, tal aspecto merece, portanto, anlise terica dos fatores que a
fazem emergir, manter-se e disseminar-se em uma dada sociedade.
Com base na literatura sobre o assunto publicada por Axelrod (1997; 2006), o
corrente estudo extraiu 17 condies (Quadro 5), que, de acordo com a freqncia de
ocorrncia em um sistema social, incentivariam a cooperao entre indivduos.
Para melhor organizao didtica, prope-se ainda a diviso de tais fatores em
quatro grupos distintos, a saber: comportamento, contexto, estratgia e territrio.

Territrio

Estratgia

Contexto

Comportamento

Grupo

Condio
Admirao

Descrio
Admira qualidades dos indivduos do grupo, no cultua a inveja.

Arrependimento

No retalia a resposta a uma defeco prvia do prprio jogador.

Bondade

Inicia a interao cooperando, nunca ataca primeiro.

Generosidade

Permite que parte das defeces ocorra sem retaliao principalmente

devido possibilidade de rudos de comunicao.

Gratido

Coopera quando recebe cooperao.

Distino

Tem capacidade de reconhecer caractersticas que diferenciam um

indivduo ou situao de outra.

Irritabilidade

Retalia a defeco sofrida.

Memria

Recorda as interaes passadas.

Futuro

Futuro vantajoso em relao ao presente.

Periodicidade

Traz alta probabilidade de novas interaes.

Recompensa

Mtodos e normas que tornam a cooperao mais atrativa que a

defeco.

Clareza

Tem clareza de comportamento, usa estratgias simples.

Maleabilidade

Mantm estratgias lucrativas, modifica as de baixo valor.

Reciprocidade

Adota estratgias baseadas na reciprocidade aplicando os fatores

gratido e irritabilidade, mesmo que em medidas diferenciadas.

Compatibilidade

Ocorre compatibilidade cultural entre os grupos.

Comunicao

Existncia abundante de comunicao entre as partes.

Liberdade
Multiplicidade de estratgias permitidas.
Quadro 5. Resumo dos fatores de cooperao de Axelrod.

No grupo comportamento tem-se caractersticas inerentes ao indivduo

propriamente dito. O grupo contexto traz fatores oriundos da situao em que o
indivduo est imerso. J no grupo estratgia lista-se os fatores relativos ao modus
operandi do indivduo perante os demais membros da sociedade. Por fim, o grupo
territrio traz caractersticas da regio onde o indivduo est incluso.
De acordo com Axelrod (1997; 2006), a freqncia com que tais fatores ocorrem
em uma dada sociedade diz se h incentivo cooperao muita ocorrncia ou
competio pouco vestgio entre seus indivduos.
No campo do desenvolvimento de software, equipes trabalham
cooperativamente com o objetivo de produzir sistemas. Porm, de acordo com
Highsmith (apud PRESSMAN, 2006), colaborao no algo fcil de se obter, uma vez

79

que trata-se, sobretudo, de uma questo de confiana entre os membros da equipe. Para
que tal nvel de confiana ocorra, faz-se necessria ampla e irrestrita comunicao entre
os membros da equipe (COCKBURN, 2006).
Nesse contexto, buscou-se no corrente estudo identificar evidncias da
existncia dos fatores de cooperao propostos por Axelrod (1997; 2006) em dois
processos de desenvolvimento, RUP (KRUCHTEN, 2003) e XP (BECK, 2004),
representando, respectivamente, processos preditivos e adaptativos.
5.1 Evidncias dos fatores de cooperao na literatura sobre o processo RUP
Para que a relao entre os fatores de cooperao e o processo RUP seja determinada de
forma mensurvel, a conduo de uma pesquisa de campo faz-se necessria, no sendo
este objetivo do corrente trabalho. Porm, podem-se identificar evidncias iniciais dessa
relao atravs do estudo das caractersticas intrnsecas do processo descritas de forma
emprica na literatura pesquisada.
Dessa forma, o Quadro 6 demonstra a anlise dos fatores sociais de cooperao
relacionados ao processo RUP, indicando, atravs da pontuao caracteristicamente
competitiva da maioria dos itens, sua natureza metodolgica preditiva na medida em
que requer a presena de uma autoridade central fiscalizadora que garanta a colaborao
entre os indivduos, alm de normas com fora de lei que apiem tal agente.
Tal autoridade central representada pelo papel gerente de projeto, sendo que
as normas constantes no processo apiam-se predominantemente em mecanismos como
dominncia, dissuaso e lei para que motivem a colaborao dos indivduos.
PROCESSO:
Rational Unified Process (RUP)
FATORES PARA COOPERAO:
Coopera

Reduz
Indifere
Incentiva

Compete

Comportamento

Admirao

Arrependimento

Bondade

Generosidade

Gratido

Distino
Irritabilidade

X
X

Contexto

Memria
Futuro

X
X

Periodicidade

Recompensa

Comentrio
A especializao de papis leva pulverizao das atividades que por sua
vez promove o distanciamento funcional resultando em inveja e
descontentamento quando h papeis mal alocados ou insatisfao devido a
gargalos motivados por centralizao excessiva de tarefas.
Grande cerimnia, fluxos bem definidos e incentivo a um gerenciamento
iterativo e incremental permite que problemas sejam identificados e
corrigidos no decorrer do projeto.
Papis e responsabilidades bem definidas levam cada membro a cooperar
quando uma ao sua requerida.
Papis e responsabilidades bem definidas fazem cada membro esperar que
seu parceiro cumpra risca sua parte no projeto.
Papis e responsabilidades bem definidas levam cada membro a cooperar
indiferentemente da reao dos demais indivduos.
Papis e responsabilidades bem definidas deixam claros a cada membro o
que os demais fazem e a fase atual do projeto.
No cooperao na equipe retaliada de forma indireta atravs do
acionamento do papel gerente de projeto.
Por manter artefatos detalhados ao longo do projeto, a rastreabilidade de
quem fez o qu e quando garantida.
O processo foca-se apenas na execuo do projeto e entrega do produto
requisitado, sendo indiferente s questes relativas a qualquer futura
solicitao das partes interessadas.
As interaes freqentes entre os mesmos membros so garantidas pela
abordagem iterativa e incremental.
Por ter fluxos bem definidos o processo apia-se em normatizao

80

Estratgia
Territrio

(diretrizes) para garantir a cooperao entre os membros da equipe.

Papis e responsabilidades bem definidas trazem clareza de
Clareza
X
comportamento no nvel individual, contra balanceada, porm, por uma
estratgia complexa no nvel de equipe.
Mesmo instanciado em cada projeto, os fluxos de atividades bem
Maleabilidade X
definidos apiam-se fortemente em regras que inibem comportamentos e
aes no previamente estabelecidos.
Por ser indiferente ao fator gratido e tornar indireta a irritabilidade, o
Reciprocidade X
processo reduz a ocorrncia de reciprocidade dentro da equipe.
A especializao de papis causa o aumento tanto da diversidade cultural
Compatibilidade X
quanto dos grupos antagnicos no projeto, devido reduo dos aspectos
culturais comuns.
Por basear-se em artefatos como principal forma de comunicao, reduz o
Comunicao X
nmero de canais comunicativos disponveis, desencorajando
comunicados no documentados.
Sendo um processo preditivo, adere melhor em organizaes centradas em
Liberdade
X
documentao onde a liberdade de ao culturalmente limitada.
Quadro 6. Anlise dos fatores de cooperao no processo RUP.

5.2 Evidncias dos fatores de cooperao na literatura sobre o processo XP

Nos mesmos moldes da anlise realizada na seo 6.3.1 para o RUP, a literatura
pesquisada sobre o XP pode ser explorada de forma a encontrar indicaes empricas de
caractersticas cooperativas no processo.
O Quadro 7 demonstra a anlise dos fatores sociais de cooperao relacionados
ao processo XP, indicando, atravs da pontuao caracteristicamente cooperativa da
maioria dos itens, sua natureza metodolgica adaptativa na medida em que dispensa a
existncia de uma autoridade central para garantir o comportamento colaborativo entre
os indivduos, apoiando-se em normas sociais motivadoras de cooperao por presso
dos pares. Tais normas sociais valem-se principalmente de mecanismos como
aprovao social, participao e reputao para que motivem a presso dos pares.
PROCESSO:
Extreme Programming (XP)
FATORES PARA COOPERAO:
Coopera

Reduz
Indifere
Incentiva

Compete

Admirao

Comportamento

Arrependimento
Bondade

Generosidade
Gratido
Distino
Irritabilidade

Comentrio

Valorizao do indivduo ao invs do processo (AMBLER, 2004) alm

X de papis flexveis e aderentes aos talentos disponveis incentivam e
expem as qualidades da equipe.
O estilo iterativo e incremental e o incentivo a valores como
X feedback e coragem, bem como humildade, promovem na
equipe confiana para correo de equvocos.
Os envolvidos so levados a comprometerem-se com o projeto, j que
X os desenvolvedores so incentivados a candidatarem-se a tarefas e a
auxiliarem uns aos outros.
Valores como comunicao e feedback, bem como as prticas
propriedade coletiva, refatorao e programao em pares
X
estimulam a parceria no grupo permitindo a soluo de mal
entendidos.
Prticas como jogo do planejamento e programao em pares
X
promovem a camaradagem dentro da equipe.
O pouco registro das situaes vivenciadas nos projetos e interaes
ocorridas reduz o nvel de distino na equipe, restringindo-a aos
envolvidos em cada ocorrncia.
X Feedback e coragem incentivam a exposio de problemas.

81

Contexto
Estratgia
Territrio

Programao em pares e testes promovem retaliao direta a

comportamentos no cooperativos.
Foco na comunicao face-a-face ao invs de formas documentadas
Memria
X
reduz a memria de ocorrncias, restringindo-a s pessoas diretamente
envolvidas nessas situaes.
Constante preocupao com o envolvimento do cliente e com os
Futuro
X
futuros trabalhos resultantes do corrente projeto.
O estilo iterativo e incremental, bem como as prticas entregas
Periodicidade
X freqentes e programao em pares, garantem vrios ciclos de
interaes entre os envolvidos.
Padres de codificao e programao em pares estabelecem
Recompensa
X
regras e meios de auto policiamento da equipe.
Papis e responsabilidades amplas inibem a clareza de comportamento
Clareza
X
no nvel individual, contra balanceada, porm, por uma estratgia
simplificada no nvel de equipe.
O processo pode ser aplicado parcialmente e em conjunto com prticas
Maleabilidade
X
de outros processos.
Propriedade coletiva estimula o senso de unidade e auto preservao
Reciprocidade
X no grupo. Reciprocidade promovida atravs dos fatores gratido e
irritabilidade supracitados.
Papis generalistas reduzem a diversidade cultural na equipe, porm
aumentam os aspectos culturais comuns entre os indivduos. Prticas
Compatibilidade
X
como propriedade coletiva e padres de codificao incentivam o
senso de unidade na equipe.
Incentiva uma comunicao direta face-a-face, aberta e honesta entre
Comunicao
X
os envolvidos no projeto.
O processo estimula e estimulado por ambientes culturais
Liberdade
X organizacionais onde h liberdade de adoo de novas idias e
confiana nos profissionais.
Quadro 7. Anlise dos fatores de cooperao no processo XP.

6. Concluso
Desenvolvimento de software no uma atividade solitria, mas uma tarefa intelectual
social que requer comunicao, colaborao e trabalho em equipe. Este trabalho
apresentou um estudo dos aspectos sociais facilitadores dessa cooperao, analisando
algumas prticas geis sob o prisma da Teoria dos Jogos. Foi realizada tambm uma
comparao entre processos preditivos e adaptativos com base nos fatores de
cooperao de Axelrod.
Concluiu-se que processos preditivos e adaptativos so metodologias que se
apiam, respectivamente, em prticas de engenharia de software e engenharia social.
Processos adaptativos capitalizam o potencial individual e coeso da equipe, mas
requerem uma cultura organizacional centrada em pessoas. Processos preditivos, por sua
vez, se adequam melhor a pessoas centradas em processo e no colaborativas, bem
como a uma cultura organizacional mais tradicional.
Processos preditivos pressupem a existncia de normas com fora de lei
acompanhadas por uma autoridade central fiscalizadora bem estabelecida e reconhecida
pela equipe no caso, o papel gerente de projeto para que o processo seja seguido,
ocorra cooperao e eventuais conflitos sejam dirimidos.
Processos adaptativos, por sua vez, no do grande nfase a uma autoridade
central mediadora de conflitos, pois delegam tal papel a normas sociais que agem nos
indivduos atravs da presso dos pares. Hazzan & Dubinsky (2005) afirmam que a
anlise do mtodo XP como dilema do prisioneiro ilustra claramente como este
promove a confiana nos membros da equipe e paulatinamente leva-os a situaes
cooperativas de ganha-ganha. Essa afirmao corroborada pelo presente estudo, como
pode-se perceber pela anlise realizada na seo 5.2. O uso conjunto dos mecanismos

82

sociais providos pelas prticas propostas pelo processo e o estabelecimento de um

ambiente fsico propcio para que negociaes possam ocorrer de forma justa entre as
partes, permite aos membros da equipe dirimir conflitos sem interferncias externas.

7. Referncias
ASTELS, D.; MILLER, G.; NOVAK, M. Extreme Programming. Campus, 2002.
AXELROD, R.M. The evolution of cooperation, revised edition. Basic Books Inc
Publishers. 2006.
AXELROD, R.M. The complexity of cooperation: agent-based models of competition
and collaboration. Princeton University Press. 1997.
BECK, K. Programao extrema explicada: acolha as mudanas. Bookman. 2004.
BLUMEN, J. The prisoner's dilemma in software development. Ethical Spectacle, Vol.
I, No. 9, September, 1995.
COCKBURN, A. Agile Software Development, second edition. Addison-Wesley
Professional, 2006.
DAVIS, M. D. Game Theory: a nontechnical introduction. Dover Publications. 1997.
EGYED, A.; BOEHM, B. Telecooperation Experience with the WinWin System. 15th
IFIP World Computer Congress, 1998.
FIANI, R. Teoria dos jogos: com aplicaes em economia, administrao e cincias
sociais, 2.ed.rev e atual. Elsevier. 2006.
HAZZAN, O.; DUBINSKY, Y. Social Perspective of Software Development Methods:
The Case of the Prisoner Dilemma and Extreme Programming, 2005.
HIGHSMITH, J.; COCKBURN, A. Agile Software Development: The People Factor.
Computer, Los Vaqueros Cir., p. 131133, nov. 2001.
ISCC. Manifesto for Software Craftsmanship. International Software Craftsmanship
Conference, 2009.
KNIBERG, H. Scrum and XP from the trenches. InfoQ, 2007.
KRUCHTEN, P. Introduo ao RUP: rational unified process, nova edio revisada.
Cincia Moderna. 2003.
LARMAN, C. Agile and Iterative Development: A Manager's Guide, 11th printing.
Addison Wesley. 2004.
LIEBERMAN, B. Project Scope Management: Effectively Negotiating Change. The
Rational Edge, November 2001.
MARTIN, R.C. Quintessence: The fifth element for the Agile Manifesto. 2008.
McBREEN, P. Software Craftsmanship: The New Imperative. Addison Wesley. 2001.
PRESSMAN, R.S. Engenharia de Software, 6 edio. McGraw-Hill. 2006.
SHARP, H.; ROBINSON, H. Collaboration in mature XP teams. Centre for Research in
Computing, The Open University, PPIG Newsletter, september 2006.
WILLIAMS, L; KESSLER, R; CUNNINGHAM, W; JEFFRIES, R. Strengthening the
case for pair-programming. University of Utah, 2000.

83

Sessao 4
Estudos empricos com metodos a geis

Experincia Acadmica de uma Fbrica de Software

utilizando Scrum no Desenvolvimento de Software
Alinne C. Corra dos Santos1, Joo Paulo F. Sette1, Adauto T. de Almeida Filho1,
Igor Cavalcanti Ramos1, Luciano Soares de Souza1, Luis Alberto L. Lima1, Rafael
de Araujo Bacelar1, Rebecca C. Linhares de Carvalho1, Fbio Q. B. da Silva1
1

Centro de Informtica Universidade Federal de Pernambuco (CIN UFPE)

CEP 50732-970 Recife PE Brasil
{accs,jpfs,ataf,icr2,lss2,lall,rab5,rclc,fabio}@cin.ufpe.br

Abstract. In recent years, has been seen a growing movement around the use of
agile methodologies in distributed software development environment.
However, according to the literature, this scenario has been little discussed
and the major Software factories doesn't have current process models , which
can accommodate this peculiarity. This paper will present the results from a
software factory's academic experience on Distributed Development based on
the Scrum process, for developing the FireScrum tool.
Keyword: Distributed Software Development, Scrum, FireScrum, Desktop
Agent
Resumo. Nos ltimos anos, tem-se observado uma crescente movimentao em
torno da utilizao de metodologias geis em ambientes de Desenvolvimento
Distribudo de Software. Entretanto, de acordo com as literaturas, este cenrio
foi pouco discutido e a maioria das fbricas de Software, atuais, no possuem
processos modelados que possam contemplar esta peculiaridade. Neste artigo
sero apresentados os resultados da experincia acadmica de uma fbrica de
Software, baseada no processo de Desenvolvimento Distribudo de Software
embasada na metodologia gil Scrum para o desenvolvimento da ferramenta
FireScrum.
Palavra-chave: Distributed Software Development, Scrum, FireScrum,
Desktop Agent

1. Introduo
Nos ltimos anos, pode-se perceber um grande avano em direo globalizao dos
negcios, em particular, aos que esto relacionados com um intenso investimento na
tecnologia de desenvolvimento de software. Dada esta evoluo, sabe-se que o software
tem se tornado um componente vital para quase todos os negcios. Neste sentido, para
as organizaes que buscam sucesso, clara a necessidade do uso da Tecnologia da
Informao (TI) de forma mais estratgica, o que tm estimulado o Desenvolvimento
Distribudo de Software (DDS) em escala mundial.

86

Atualmente, notvel que o nmero de empresas que esto distribuindo seus

processos de desenvolvimento de software ao redor do mundo cada vez mais
significativo. Assim, essas empresas visam obter vantagens competitivas associadas ao
custo, qualidade e flexibilidade no desenvolvimento de software, buscando um aumento
de produtividade, assim como, diminuio de riscos (SENGUPTA, 2006).
Em busca dessas vantagens no ambiente de negcio, um nmero significativo de
empresas passou a viver, a partir do ano 2000, uma tendncia para o desenvolvimento
gil de aplicaes. Este processo ocorre devido ao ritmo acelerado de mudanas e
inovaes na tecnologia da informao (BOEHM, 2006). A essncia desse movimento
a definio do novo enfoque de desenvolvimento de software, calcado na agilidade, na
flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos
produtos e servios de valor ao mercado, em curtos perodos de tempo (HIGHSMITH,
2004).
Em paralelo a essa discusso, a adoo de abordagens geis tem sido crescente
na indstria de software, apresentando resultados positivos em termos de prazo, custo e
qualidade (VERSIONONE, 2008). Tais abordagens visam desburocratizao das
atividades (SCHWABER, 2004), e empregam princpios como ciclos iterativos e
entregas rpidas de software funcionando (BECK et al., 2001). A essncia desse
movimento calcada na agilidade, flexibilidade e habilidade de comunicao
(HIGHSMITH, 2004). Dentre as metodologias geis propostas, o Scrum tem se
apresentado como uma das mais adotadas. Observa-se em pesquisas que 70% das
empresas que utilizam metodologias geis, adotam o Scrum (VERSIONONE, 2008).
importante ressaltar que a combinao de metodologias geis com DDS est
crescendo no mercado. Soares et al. (2007), em seu estudo, apresenta a utilizao do
mtodo gil, Scrum, em um processo de desenvolvimento de software open source, com
fortes caractersticas de DDS. Luna et al. (2008) tambm ressalta essa combinao no
desenvolvimento, de forma distribuda e apoiada no Scrum, de uma biblioteca
multimdia, para o compartilhamento de objetos de aprendizagem, utilizados pelos
projetos de telemedicina e telesade do Ncleo de Telesade da UFPE. Portanto,
notvel que a utilizao de DDS com Scrum, pode ser considerado um processo simples
e objetivo, focado nas necessidades do cliente, e no, na documentao do projeto,
apresentando resultados satisfatrios de acordo com os estudos de Soares et al. (2007) e
Luna et al. (2008).
Motivado por este cenrio, o artigo apresenta um experimento acadmico, que
consiste na vivncia de uma fbrica de software na disciplina de Engenharia de Software
do curso de ps-graduao em Cincia da Computao, baseado no mtodo Scrum, em
um processo de Desenvolvimento Distribudo de Software.
O artigo est organizado em cinco sees. A seo 2 apresenta o contexto
relacionado ao Desenvolvimento Distribudo de Software; A seo 3 aborda a
metodologia gil, Scrum; A Seo 4 exibe o processo de desenvolvimento da ferramenta
FireScrum, detalhando o mdulo Desktop Agen; A seo 5 evidencia os resultados
obtidos e as ferramentas utilizadas, bem como, os problemas identificados e suas
respectivas solues. Por fim, a seo 6 apresenta as consideraes finais e perspectivas
de trabalhos futuros.

87

2. Desenvolvimento Distribudo de Software

Motivados, principalmente, pela globalizao, muitas empresas nas ltimas dcadas
passaram a distribuir seus processos de desenvolvimento em lugares diferentes, levando
suas equipes a trabalharem de forma distribuda. Segundo Zanoni (2002), com a
distribuio geogrfica de recursos e investimentos, surge uma nova tendncia de
desenvolvimento de software, em que usurios e equipes de desenvolvimento esto em
locais fsicos diferentes, s vezes, com culturas diferentes. O Desenvolvimento
Distribudo de Software, incluindo a terceirizao, subcontratao e parcerias, tornou-se
uma realidade empresarial comum.
Para Audy e Prikladnicki (2007), o desenvolvimento distribudo de software
ganha cada vez mais fora, motivado por trs fatores ligados ao ambiente de negcios: a
globalizao; o crescimento da importncia dos sistemas de informao nas empresas e
os processos de terceirizao, que geram ambiente propcio a esse cenrio de
desenvolvimento. Portanto, justificvel que as empresas de software, em sua grande
maioria, esto adotando a prtica de DDS para construir seus softwares, assim
conseguem recrutar trabalhadores qualificados e de baixo custo em todo mundo
(LIANG, 2008). Times distribudos podem aumentar o aprendizado e a criatividade da
equipe, j que os membros tm a chance de interagir com uma grande variedade de
culturas, experincias e pontos de vista. Um time formado por uma gama de
conhecimentos diferentes capaz de realizar um variado nmero de aes (BAROFF,
2002).
O DDS tem sido caracterizado, principalmente, pela colaborao e cooperao
entre departamentos de organizaes e pela criao de grupos de pessoas que trabalham
em conjunto, porm, esto localizados em cidades ou pases diferentes, distantes
temporal e fisicamente. Assim, as principais caractersticas que diferenciam o
desenvolvimento co-localizado do desenvolvimento distribudo so: distncia (a
distncia entre os desenvolvedores e entre os desenvolvedores e clientes), diferenas de
fuso horrio e cultural (incluindo a lngua, tradies, costumes, comportamentos e
normas). A literatura reconhece no s a distncia fsica, mas tambm os seguintes tipos
de distncia: temporal, cultural, organizacional (diferentes culturas organizacionais
envolvidas), e a distncia entre os stakeholders (a quantidade de pessoas interessadas no
projeto com diferentes objetivos em mente).
A engenharia de software global tornou-se parte da estratgia de crescimento das
empresas, pois podem estar mais prximas dos mercados locais e entender melhor as
necessidades regionais. Alm disso, alguns pases no tm recursos suficientes para a
demanda de TI de produtos e servios de software (EBERT et al., 2008). Logo,
aproveitar os recursos globais para o desenvolvimento de software tornou-se quase uma
regra para grandes empresas. Alguns fatores (Figura 2.3) so citados como principais
motivos do crescimento do DDS, segundo os estudos Prikladnicki (2003) e Freitas
(2005):
Necessidade de recursos globais para serem utilizados a qualquer hora, inclusive
profissionais qualificados em reas especializadas;
Incentivos fiscais para o investimento de pesquisas em informtica;
Disponibilidade de mo-de-obra especializada e de custos reduzidos em pases
em desenvolvimento;
Vantagem de estar perto do mercado local, incluindo o conhecimento, os clientes
e as condies locais;
88

Rpida formao de organizaes e equipes virtuais para explorar as

oportunidades locais;
Grande presso para o desenvolvimento time-to-market (velocidade no trabalho,
tempo entre a concepo e a comercializao do produto) utilizando as
vantagens do fuso horrio diferente, no desenvolvimento conhecido como
follow-the-sun (24 horas contnuas);
Necessidade de integrar recursos resultantes de aquisies e fuses
organizacionais.

possvel perceber, com as razes mencionadas, que, embora as empresas

queiram reduzir os custos no desenvolvimento e aproveitar as oportunidades dos
mercados locais, elas tambm querem ter equipes cada vez mais capacitadas, o que nem
sempre plausvel encontrar em um nico local. Porm, com pessoas capacitadas em
lugares diferentes, difcil e financeiramente invivel deslocar todas para um mesmo
ambiente fsico, o que estimula o desenvolvimento distribudo.
O ambiente global apresenta grande impacto na forma como os produtos so
concebidos, desenvolvidos, testados e entregue aos clientes. Alm disso, Herbsleb
(2001) destaca que trabalhar com DDS um dos maiores desafios que o atual ambiente
de negcios apresenta, do ponto de vista do processo de desenvolvimento de software.
Segundo MacGregor et al. (2005), so de conhecimento dos profissionais da
rea, as dificuldades e baixas taxas de sucesso de projetos de software com equipes colocalizadas. Novas variveis como: distncia, comunicao virtual, diferenas de fusos
horrios e culturais, no contribuem para que essas taxas de sucesso melhorem.
Enquanto a abordagem clssica de desenvolvimento de software com equipes colocalizadas permite a resoluo de problemas no corredor, durante um caf ou ao redor
de uma mesa, equipes distribudas so formadas por pessoas culturalmente, etnicamente
e funcionalmente diversificadas. Pessoas que trabalham em diferentes horrios e locais
nem sempre so, facilmente, acessveis para uma conversa sobre como criar uma
interface ou resolver um bug que impede um teste de prosseguir (EBERT et al., 2008).
Para Liang (2008), o tempo e a distncia em um projeto que trabalha de maneira
distribuda um dos grandes desafios para o sucesso, pois significa mais infraestrutura e
maior coordenao para estabelecer uma comunicao eficaz, dentro do projeto. Alm
disso, a distncia fsica e as diferenas culturais entre os membros so, na sua maioria,
muito grandes e a comunicao pode ser ineficiente, j que, as pessoas que no estejam
fisicamente ao seu lado, so mais fceis de ser ignoradas.
Uma soluo bvia, para os inmeros desafios que a distribuio intensifica,
seria evitar o desenvolvimento distribudo de software. No entanto, para organizaes
que esto sempre em busca de vantagens competitivas em escala global, os benefcios
potenciais de desenvolvimento distribudo podem ser muito atraentes para,
simplesmente, serem ignorados (MAK, 2007).

3. Metdos geis e Scrum

O termo Metodologias geis tornou-se popular em 2001, quando especialistas em
processos de software estabeleceram princpios comuns, sendo criada a Aliana gil e o
estabelecido o Manifesto gil (BECK, et al., 2001).
Alinhado aos princpios geis, o Scrum foi criado, inicialmente, como um
framework para gerenciamento de projetos na indstria convencional e publicado no

89

artigo The New Product Development Game (TAKEUCHI, 1986). O primeiro

desenvolvimento de software com Scrum foi realizado em 1993 por Jeff Sutherland na
Easel Corporation (Sutherland, 2004), e junto com Ken Schwaber formalizaram o
Scrum (Sutherland, 2007), como processo de desenvolvimento na OOPSLA
(SCHWABER, 1997).
O Scrum congrega atividades de monitoramento e feedback, atravs de
reunies rpidas e dirias com toda a equipe, visando identificao e correo de
quaisquer deficincias e/ou impedimentos, no processo de desenvolvimento
(SCHWABER, 2004). A proposta baseada em um ciclo iterativo e incremental, onde
cada iterao planejada de acordo com a prioridade definida pelo cliente.
O mtodo baseia-se nos seguintes princpios: equipes pequenas; requisitos que
so pouco estveis ou desconhecidos; e iteraes curtas. Este mtodo apresenta trs
papis principais e independentes (BEEDLE, 2004). Product Onwer (PO), que
estabelece objetivos do produto, define e prioriza as funcionalidades, ou itens de
backlog e participa, ativamente, do desenvolvimento, validando o produto de cada
sprint; Scrum Master (SM), cujo papel facilitar o trabalho do time, removendo os
impedimentos levantados pelo time e apoiando o mesmo no uso do Scrum; Time,
responsvel pelo desenvolvimento dos itens de backlog, define como transformar o
product backlog em incremento de funcionalidades, gerenciando seu prprio trabalho.
So responsveis, coletivamente, pelo sucesso da iterao e, conseqentemente, pelo
projeto como um todo.
O Scrum no requer ou fornece qualquer tcnica ou mtodo especfico para a
fase de desenvolvimento de software, apenas estabelece conjuntos de regras e prticas
gerenciais que devem ser adotadas para o sucesso de um projeto. As prticas gerenciais
do Scrum esto divididas em artefatos e cerimnias. Os artefatos so compostos por:
Product Backlog, Sprint Backlog e Burndown; as cerimnias so compostas por: Daily
Scrum, Sprint Planning Meeting, Sprint Backlog e Sprint Review Meeting.
3.1. Ciclo do Scrum
O incio do projeto de Scrum ocorre a partir da existncia de uma viso do produto que
ser desenvolvido (SCHWABER, 2004). O ciclo de vida de projetos Scrum definido
em iteraes que podem durar de duas a quatro semanas, conhecidas como sprint. Ao
final de cada sprint entregue um incremento do produto tendo passado por todo o
processo de desenvolvimento, auditoria e teste.
Segundo Schwaber (2004), cada Sprint inicia-se com uma reunio de
planejamento (Sprint Planning Meeting), na qual o PO e o time decidem, em conjunto,
o que dever ser implementado (Selected Product Backlog). A reunio dividida em
duas partes. Na primeira parte, Sprint Planning 1, o PO apresenta os requisitos de maior
valor e prioriza aqueles que devem ser implementados. O time, ento, define
colaborativamente, o que poder ser desenvolvido na prxima Sprint, considerando sua
capacidade de produo. Na segunda parte, Sprint Planning 2, o time planeja seu
trabalho, definindo o Sprint Backlog, que so as tarefas necessrias para implementar as
funcionalidades selecionadas no Product Backlog.
Durante a execuo das Sprints, o time faz, diariamente, uma reunio de quinze
minutos para acompanhar o progresso do trabalho. Nessa reunio diria (Daily Scrum
Meeting), cada membro do time responde a trs perguntas bsicas: O que eu fiz no

90

projeto desde a ltima reunio? O que irei fazer at a prxima reunio? Quais so os
impedimentos?

Figura 1. Viso geral do processo do Scrum (fonte: adaptada de (GLOGER, 2007)).

No final da Sprint realizada a reunio de reviso (Sprint Review Meeting)

para que o time apresente o resultado alcanado na iterao ao Product Owner. Neste
momento, as funcionalidades so inspecionadas e adaptaes do projeto podem ser
realizadas. Em seguida, o ScrumMaster conduz a reunio de retrospectiva (Sprint
Retrospective Meeting), que ocorre no final de uma Sprint para identificar o que
funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar o
processo.
3.2. Scrum Distribudo
O Scrum, assim como outras metodologias geis, enfatiza a interao do time atravs de
comunicao constante e face-to-face. No entanto, o desenvolvimento por equipes
remotas tem apresentado um crescimento contnuo, particularmente visvel desde a
ltima dcada (DAMIAN & MOITRA, 2006). Entre as razes para a adoo por times
distribudos, pode-se destacar facilidade de envolvimento de especialistas em reas
chave, flexibilidade para criao e desativao de equipes de trabalho e a reduo de
custos de locomoo. Neste contexto, o modelo de Scrum de Scrums distribudo
recomendado pela ScrumAlliance (www.scrumalliance.com), que divide o trabalho em
partes (times Scrum) isoladas, eliminando a maioria das dependncias (SUTHERLAND,
et al., 2007).

4. Estudo de Caso: Ferramenta FireScrum

4.1. FireScrum
O FireScrum uma ferramenta open source que rene um conjunto de aplicaes
integradas para suportar equipes que utilizam o Scrum como base para o
desenvolvimento de seus projetos, sendo, especialmente, til para equipes que
trabalham remotamente.
A ferramenta um produto idealizado por Eric Cavalcanti, que nasceu das
atividades desenvolvidas durante o programa de mestrado de engenharia de software do
CESAR.EDU, no Centro de Estudos e Sistemas Avanados do Recife (C.E.S.A.R).

91

O FireScrum foi desenvolvido utilizando conceitos da Web 2.0 e de Rich

Internet Applications (RIA), apresentando foco em usabilidade para garantir a
simplicidade do seu uso. uma aplicao Web, o que significa que a mesma acessvel,
remotamente, atravs de um browser, podendo ser utilizada em um ambiente de Internet
ou Intranet, apresentando uma arquitetura modular e extensvel.
A primeira verso do FireScrum, somente era composta pelo mdulo Task
Board, que foi desenvolvido por uma equipe de alunos do Mestrado Acadmico do
Centro de Informtica (CIN) da Universidade Federal de Pernambuco (UFPE). Diante
deste cenrio, com a finalidade de continuar a desenvolver e melhorar a ferramenta,
cerca de sessenta alunos da disciplina de Engenharia de Software do curso de psgraduao em Cincia da Computao do CIN da UFPE constituram um grande time
para desenvolver os novos mdulos para o FireScrum.
O projeto da ferramenta foi composto por seis novos mdulos: Planning
Pooker, Test, Task Board, Core, Bug Tracking e Desktop Agent. Esses mdulos foram
desenvolvidos durante os quatro meses da disciplina e por seis grupos distintos
compostos pelos os alunos da disciplina, os quais foram formados de forma aleatria
pelos responsveis que conduziram a Fbrica de Software. Esses grupos interagiram por
meio da troca de emails, ferramenta oro-aro1, compartilhamento de conhecimentos e
ferramentas, durante as aulas da disciplina e reunies entre os SM. Cada grupo tinha, em
mdia, cerca de dez pessoas, as quais se encontravam geograficamente dispersas. Dentre
os mdulos desenvolvidos, na prxima subseo ser detalhada a realidade do time
responsvel pelo desenvolvimento do mdulo Desktop Agent, abordando a experincia
do time, procedimentos adotados para a execuo das sprints, ferramentas utilizadas, as
dificuldades enfrentadas, bem como os problemas identificados e suas respectivas
solues.
4.1. Mdulo Desktop Agent
O Dektop Agent um dos mdulos que compem a ferramenta FireScrum,
desenvolvido seguindo os princpios geis do Scrum. Neste mdulo, foi desenvolvido
um aplicativo que executado no prprio desktop, facilitado o acesso s funcionalidades
do FireScrum, uma vez que, quando executado, estar disponvel atravs da bandeja do
Sistema Operacional. O usurio ter acesso s funcionalidades atravs de um menu
suspenso. Dentre as funcionalidades destacam-se: visualizar tarefas e tarefas do usurio,
editar tarefas, receber alertas do sistema, reportar bugs e fornecer um chat entre os
integrantes do time.
O desenvolvimento do mdulo foi constitudo por seis sprints e compostas por
histrias. O status delas foi definido por cores distintas. Inicialmente, foram definidas
doze histrias pelo PO e, dentro de cada sprint, eram realizadas reunies do SM com
PO, com a finalidade de acordar quais histrias agregavam maior valor de negcio.
Cada sprint foi dividida em duas semanas e, ao final do prazo, um conjunto do novo
produto era apresentado ao PO e aos demais times.
As priorizaes das histrias de cada sprint foram realizadas de acordo com o
Business Value (BV) fornecido pelo PO. Juntamente com o BV, o PO definia o objetivo
1

Ferramenta online que se trata de um meio de comunicao, interao e disponibilidade de

conhecimentos entre alunos e professores.

92

da sprint, onde sugeria quais itens eram mais importantes para serem feitos na sprint. De
acordo com os itens priorizados pelo PO, o time jogava o planning poker para realizar a
estimativa, em seguida, verificar quais dos itens priorizados eram possveis de serem
realizados na sprint.
Em seguida, com as histrias acordadas com o PO, o time dividia em tarefas
com mdia de execuo de, aproximadamente, dois dias. As tarefas, bem como, o
controle das sprints e o burndown eram disponibilizados no Google Docs, onde, o PO e
os demais times podiam acompanhar o andamento da execuo dos mesmos.
Durante as sprints, o time utilizava o skype para simular o Daily Scrum
Meeting, assim, permitindo que todos os membros do time ficassem cientes do
andamento das atividades e dos impedimentos encontrados. Em paralelo ao Daily Scrum
Meeting, aconteciam as reunies presenciais do time (uma vez por semana). Assim,
como a comunicao do time imprescindvel durante a sprint, a comunicao entre o
SM, os demais membros do time e o PO era realizada por email ou por meio da
ferramenta oro-aro, seja para aprovao de documentos, para o esclarecimento de
dvidas ou alinhamento do andamento da sprint.
Antecedendo o final da sprint, precisamente, s vsperas, era realizada uma
reunio de review interna e de retrospectiva. A reunio de review interna contava
somente com a participao do time e tinha por finalidade discutir o que foi
desenvolvido, verificando se foi atendida a proposta da histria, bem como, obter
sugestes de melhorias.
O final da sprint acontecia s segundas-feiras, com a presena de todos os seis
times, objetivando apresentar ao PO o produto e o desempenho da equipe, por meio do
burndown, at o presente momento. Cada time era representado por um de seus
membros durante a apresentao. A anlise do esforo planejado e realizado ocorria
durante a reunio de retrospectiva da sprint, onde os membros do time faziam
levantamento dos pontos positivos e pontos a serem melhorados que ocorreram na
sprint.
5. Resultados
Os resultados do desenvolvimento do mdulo Desktop Agent foram obtidos por
meio da execuo de seis sprints. Ao trmino de cada sprint foi apresentado uma parte
do mdulo geral ao PO. Os registros da obteno desses resultados sero apresentados
por sprints e so de extrema importncia, pois evidenciam a experincia da equipe, as
ferramentas utilizadas, as dificuldades enfrentadas, os problemas identificados e suas
respectivas solues.
Na sprint 1 foi acordado com PO o desenvolvimento de uma nica histria, a
qual tratava da criao de um cone que aparecesse no systray, apresentando os menus
que, futuramente, seriam as funcionalidades dessa aplicao. Foi escolhida apenas uma,
pois constatou-se a necessidade de aprofundamento no estudo das tecnologias a serem
utilizadas como o AdobeAir; bem como ambientao com a metodologia adotada
(Scrum).
Nesta sprint foram realizadas trinta e oito tarefas, dentre as quais podem ser
citadas: ambientao do time s tecnologias a serem utilizadas durante o
desenvolvimento do mdulo; estudos referentes forma de comunicao do aplicativo
Desktop Agent com o servidor; escolha da melhor tecnologia (AMF ou WebService);
estudo referente tecnologia Adobe Air para obter o resultado proposto pela histria
93

desta sprint e, por ltimo, definio do processo de testes referente criao e execuo
de casos de teste. O fato de ser a primeira sprint, a inexperincia do time e a falta de
afinidade com essa metodologia ocasionou alguns problemas que foram solucionados.
Dentre esses problemas pode-se enfatizar a preciso referente ao tempo, onde as
reunies demoravam cerca de uma hora e a escolha da ferramenta para a realizao do
primeiro Daily Scrum Meeting. Nas reunies realizadas posteriormente esses problemas
foram solucionados. Definiu-se o skype como ferramenta padro para as reunies, pois,
os membros encontravam-se fisicamente dispersos, e notava-se a necessidade de
realizar vdeo conferncia. Outros chats testados (Gtalk e MSN) apresentaram
instabilidades.
Na sprint 2 foi acordado com o PO, o desenvolvimento de trs histrias: 1 Deixar usurio e senha cadastrados no login: tem por objetivo armazenar as
informaes do usurio no momento do login, bem como permitir o login automtico; 2
- Visualizar minhas tarefas: permite que o usurio tenha acesso s tarefas alocadas a ele
na sprint corrente, referente a um determinado produto; 3 - Visualizar todas as tarefas
da sprint: acesso listagem de todas as tarefas da sprint corrente.
Nessa sprint foram realizadas cinqenta e uma tarefas, dentre as quais podem
ser citadas: a criao de prottipos das telas de acordo com os requisitos levantados,
sendo estes validados com o PO e, conseqentemente, utilizados pelos membros do
time, responsveis pelo desenvolvimento das histrias citadas acima; a criao de casos
de teste para cada histria, onde foi utilizada a ferramenta open source, Test Link, que
permitiu agilidade no processo de criao, execuo, e controle dos testes. Essa
ferramenta de teste foi selecionada para uso, devido afinidade e experincia dos
membros do grupo com a mesma. Dentro do processo de execuo dos testes, quando
um bug era identificado, abria-se uma Change Request (CR), utilizando o Mantis. Este
software um sistema de anlise de erros, open source, baseado em tecnologia Web, e
permite especificar os responsveis pela declarao de bugs, bem como, seus
respectivos analisadores. Esse sistema foi utilizado por todos os mdulos do FireScrum.
Ao longo dessa sprint foram identificados problemas como: pouco tempo dos
participantes; indisponibilidade dos integrantes com maiores habilidades em
programao; afastamento de um dos desenvolvedores do time e, o fato de ser o
primeiro contato dos programadores com as tecnologias utilizadas e com a arquitetura
do FireScrum. Estes problemas demandaram maior trabalho e esforo do time e foram
solucionados quando os mesmos passaram a se dedicar, exclusivamente, ao
adiantamento das tarefas.
Na sprint 3 foi acordado com o PO o desenvolvimento de trs tarefas: 1 Editar minhas tarefas: o usurio pode alterar as informaes referentes s tarefas
alocadas a ele na sprint corrente; 2 - Alocar-me nas tarefas: permite ao usurio se alocar
e desalocar em quaisquer tarefas da sprint, mesmo se essas estiverem alocadas a outros
usurios; 3 - Reportar bugs: permite ao usurio reportar bugs encontrados por meio do
Desktop Agent, no havendo a necessidade de acessar o FireScrum para reporta-los.
Nessa sprint foram realizadas setenta e trs tarefas e criadas mais treze tarefas,
referentes s correes de bugs encontrados durante a sprint anterior e rework de CR.
Ao longo dessa Sprint foram identificados problemas referentes dependncia da
realizao de tarefas de outros mdulos para o desenvolvimento das histrias. Um caso
a citar, foi a necessidade de merge dos times dos mdulos Core e Bug Tracking, para
possibilitar o desenvolvimento das histrias dessa sprint.
94

Na sprint 4 foi acordado com o PO o desenvolvimento de trs histrias: 1 Exibir contatos: tem como objetivo listar os usurios do FireScrum por produto, para
que o usurio logado no Desktop Agent possa iniciar o chat com cada contato, sendo
estes classificados em online e offline, os quais foram controlados utilizando o servidor
multimdia Red5; 2 - Trocar o produto que o usurio est logado: permite ao usurio
realizar suas atividades em diversos produtos em que esteja alocado, bastando somente
a troca de produto; 3 - Preparar a arquitetura do chat: objetivando a criao de
diagramas de seqencia e a interao da comunicao entre as partes envolvidas no
chat.
Nessa sprint foram realizadas cinqenta e oito tarefas e criadas mais dezesseis.
Tornando-se um grande desafio por ser o primeiro contato com a tecnologia Red 5. Esta
tecnologia foi utilizada para fazer o controle de quais usurios estariam ou no logados
no FireScrum. O servidor Red5 um servidor de cdigo aberto dedicado interao
entre o Adobe Flash Player e um servidor gratuito orientado conexo utilizando
RTMP (Real Time Message Protocol). Ao longo dessa sprint foram identificadas
poucas dificuldades, pois o time se encontrava mais maduro e auto-gerencivel. No
entanto, a adoo da nova tecnologia demandou tempo de estudo e implementao de
acordo com as necessidades do mdulo Desktop Agent. Alm disso, na negociao
inicial com o PO foram definidas trs histrias, onde as tarefas j estavam sendo
realizadas, porm houve a necessidade de abortar uma das histrias, implicando em uma
reorganizao do time para no afetar a concluso das demais tarefas. O desempenho do
time nessa sprint pode ser visualizado por meio da Figura 2.

Figura 2. BurnDown sprint 4.

Na sprint 5 foi acordado com o PO o desenvolvimento de quatro histrias: 1 Abrir uma conversa de bate papo com algum contato: objetivando escolher outro
usurio que esteja logado pelo Desktop Agent para iniciar o chat; 2 - Adicionar
funcionalidades na tela de reportar bug: selecionar em qual histria e a quem, o bug
estava associado, o deadline do bug e o seu tempo de resoluo; 3 - Ver os contatos
separados por produto: objetivando visualizar os contatos de acordo com os produtos
existentes; 4 - Configurar o endereo de acesso aos servidores: permitindo ao usurio a
opo de colocar os endereos do servidor FiresScrum e Red5 que foram utilizados.
Nessa penltima sprint foram realizadas quarenta e seis tarefas, nas quais o
time obteve muita dificuldade, ocasionando no abortamento de uma histria. Essa
95

histria era referente melhoria da qualidade do cdigo e foi abortada em funo dos
seguintes problemas: o mdulo Desktop Agent inerentemente dependia,
significativamente, de funcionalidades de outros mdulos e a pgina do SourceForge se
encontrava indisponvel. Portanto, dois dias de trabalho foram perdidos,
conseqentemente, causaram atrasos na execuo das tarefas.
Para finalizar no ocorreu oficialmente a sprint 6, pois ao finalizar a sprint
anterior, todos os times de forma organizada fariam os merges, para, em seguida, serem
realizados testes e, conseqentemente, os bugs identificados serem corrigidos. Nessa
sprint o time do referido mdulo foi o ltimo a realizar os merges, permitindo a
concluso de algumas tarefas que foram abortadas na sprint passada. Alm disso, foram
realizadas correes de CRs e aps a concretizao do merge, algumas modificaes
foram discutidas com o Comit de Controle de Mudanas para serem implementadas.
Aps a finalizao das 6 sprints ,o produto final, mdulo Desktop Agent, foi
apresentado ao PO e aos professores da disciplina.

6. Consideraes Finais e Trabalhos Futuros

Este artigo apresentou a experincia de uma equipe formada por estudantes e
profissionais de TI na concepo de uma Fbrica de Software, utilizando o mtodo gil
Scrum como base para o desenvolvimento do produto para um cliente, simulando um
ambiente real com prazos, cronogramas, entregas e acordos entre os membros da fbrica
e o cliente.
A principal contribuio deste artigo est em uma detalhada descrio da
vivncia de uma fbrica de software visando os aspectos positivos e negativos no
desenvolvimento do software utilizando a metodologia Scrum.
O mdulo, Desktop Agent, componente desenvolvido para a ferramenta
FireScrum apresenta resultados, at o momento, considerados satisfatrios. Acredita-se que
os ganhos conseguidos com o mdulo, podem ser, efetivamente, superiores com o
amadurecimento dos processos e da viso do time. As dificuldades encontradas na sua
implantao mostraram-se superveis e inerentes a qualquer mudana significativa na
ferramenta.
Os resultados alcanados at o presente momento propiciam expectativas de
trabalhos futuros, onde se pretende dar continuidade ao projeto FireScrum a fim de
realizar alguns ajustes e refin-los, visando sempre a otimizao do projeto, bem com
sua melhoria contnua e difuso para empresas ou modelos de negcio.

Referncias
AUDY, J.; PRIKLADNICKI, R. Desenvolvimento Distribudo de Software:
Desenvolvimento de software com equipes distribudas. Rio de Janeiro: Elsevier, 2007.
BAROFF, L. E. Distributed teaming on JPL projects. IEE Aerospace Conference, vol 7,
p. 3461- 3466, 2002.
BEEDLE, M. Agile Development with Scrum. 3 ed, Addison Wesley Press, 2004.
BOEHM, B. A View of 20th and 21st Century Software Engineering. ICSE 2006.
DAMIAN, D.; MOITRA, D.
Guest Editors' Introduction: Global Software
Development: How far Have We Come?.IEEE Software, 2006. 23(5), pp.1719.

96

EBERT, C. et al. Managing Risks in Global Software Engineering: Principles and

Practices. Proc. IEEE International Conference on Global Software Engineering ICGSE
2008, p. 131-140, 2008.
FREITAS, A. V. APSEE-Global: a Model of Processes Management of Distributed
Software Processes. Faculdade de Informtica UFRS RS- Brazil, 2005.
GLOGER, B. The Zen of Scrum. Disponvel em: http://www.glogerconsulting.com.
Acesso: jan. de 2010.
HERBSLEB, J. D.; MOITRA, D. Global Software Development. IEEE Software
Magazine, IEEE Computer Society, EUA, 2001.
HIGHSMITH, J. Agile Project Management Creating Innovative Products.
AddisonWesley Press, 2004.
LIANG, H. Distributed Software Development. Leading Edge Forum. CSC
Experience e Results, 2008.
LUNA, A. et al. Desenvolvimento Distribudo de uma Aplicao de Telessade com a
Metodologia gil SCRUM. X Congresso Brasileiro de Informtica em Sade. So
Paulo, 2008.
MACGREGOR, E. et al. The impact of intercultural factors on global software
development. Proc. Canadian Conference on Electrical and Computer Engineering, p.
920-926, 2005.
PRIKLADNICKI, R. MuNDDoS - Um modelo de referncia para desenvolvimento
distribudo de software. Dissertao de Mestrado, PUC/RS, Porto Alegre, RS, Brasil,
2003.
SCHWABER, K. et al. Scrum Development Process, OOPSLA Business Object
Design and Implementation Workshop, Eds. London: Springer. 1997.
SCHWABER, K. Agile Project Management With Scrum. Microsoft, 2004.
SENGUPTA, B.; CHANDRA, S.; SINHA, V. A Research Agenda for Distributed
Sofwtare Development. In: 28th ICSE, Xangai, China.
SOARES, F. et al. Adoo de Scrum em uma Fbrica de Desenvolvimento Distribudo
de Software. I Workshop de Desenvolvimento Distribudo de Software. Joo Pessoa,
2007.
SUTHERLAND, J.; VIKTOROV, A.; BLOUNT, J.; PUNTIKOV, N. "Distributed
Scrum: Agile Project Management with Outsourced Development Team," HICSS'40,
Hawaii International Conference on Software Systems, Big Island, Hawaii, 2007.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard
Business Review, 1986. Janeiro-Fevereiro, pp137-146.
VERSIONONE. The State of Agile Development Survey Results. Disponvel em:
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf. Acesso
em: maio de 2010.

97

ZANONI, R. Modelo de Gerncia de Projeto Baseado no PMI para ambientes de

Desenvolvimento de Software Fisicamente Distribudo. Dissertao de Mestrado,
PUC/RS, Porto Alegre, RS, Brasil, 2002.

98

Agilidade na UFABC - Implantao da

Metodologia Scrum na Diviso de Desenvolvimento
Maurcio Eduardo Szabo1, Christiane Marie Schweitzer2
1

Ncleo de Tecnologia da Informao (NTI) - Universidade Federal do ABC

(UFABC) - Santo Andr - SP - Brasil

Centro de Matemtica, Computao e Cognio (CMCC) Universidade Federal do

ABC (UFABC) Santo Andr SP - Brasil
mauricio.szabo@gmail.com, chris@ufabc.edu.br

Abstract. The adoption of agile software development methodologies breaks

rigid paradigms in institutions, bringing innovation, flexibility and new
challenges to software development process. This paper presents Scrum
implementation for software development in Federal University of ABC
(UFABC), describing used Scrum practices, their evolution, and pointing
successes, errors and solutions.
Resumo. A implantao de metodologias geis de desenvolvimento de
software quebra paradigmas antes estruturados e rgidos dentro de uma
instituio, trazendo inovao, desafios, e flexibilidade a todo o processo de
desenvolvimento. Este artigo tem por objetivo apresentar a implantao da
metodologia Scrum no desenvolvimento de sistemas na Universidade Federal
do ABC (UFABC), identificando processos da metodologia implantados, a
evoluo, acertos, erros, e solues de contorno.

1. Introduo
Criada em 2005 com o intuito de ser uma "Universidade de Ponta para o Sculo XXI", a
Universidade Federal do ABC (UFABC) oferece cursos nas reas tecnolgica e
cientfica. A UFABC apresenta uma estrutura curricular diferenciada, de forma a
atender as novas demandas que o profissional se depara tanto em aspectos sociais,
quanto tecnolgicos e econmicos que caracterizam o mundo moderno. Sobretudo, esta
proposta pedaggica visa tornar os acadmicos capazes de enfrentar novos problemas,
com confiana nas suas potencialidades e demonstrando capacidade de investigao e
inovao. A partir destes princpios norteadores, a proposta pedaggica da UFABC
visa:
Ampliar o currculo bsico em extenso e profundidade no que diz respeito
Informtica, Computao Cientfica, s Cincias Naturais, s Cincias de
Engenharia e Matemtica
Estruturar o currculo profissional, de modo a atender as demandas das
tecnologias modernas e emergentes e incorporar disciplinas que permitam uma
insero mais rpida dos formandos na sociedade moderna

99

Incorporar disciplinas como a Histria da Cincia, Histria da Tecnologia e

Histria do Pensamento Contemporneo com o intuito de desenvolver a
capacidade crtica no exerccio da atividade profissional e da cidadania
Estimular e desenvolver nos estudantes as habilidades de descobrir, inventar e
sistematizar, caractersticas respectivamente das Cincias Naturais, das
Engenharias e das Matemticas
Individualizar, ainda que parcialmente, o currculo de modo que o aluno possa
desenhar sua formao profissionalizante de acordo com sua vocao e suas
aspiraes.

Objetivando a operacionalizao da proposta pedaggica, a estrutura curricular

divide-se em duas etapas: (i) ciclos iniciais de trs anos, conduzindo ao Bacharelado em
Cincia e Tecnologia (BC&T), (ii) ciclo complementar de um ano para licenciatura ou
bacharelado especfico (Fsica, Qumica, Matemtica, Computao, Biologia) ou ciclo
profissional de dois anos para Engenharia.
Desta forma, atravs do ciclo bsico o aluno tem condies de moldar seu perfil
profissional de acordo com suas aptides e preferncias atravs de um conjunto
disciplinas tanto do BC&T quanto j direcionadas ao ciclo complementar ou
profissional.
Alm disso, procurando evitar uma separao muito grande entre reas de
conhecimento, a UFABC no se organiza em um modelo de diviso departamental. A
eliminao de departamentos um avano que permite uma interlocuo permanente
entre os docentes e discentes trabalhando em uma forma interdisciplinar. Sendo assim
organizou-se a UFABC em trs grandes centros, quais sejam: Centro de Cincias
Naturais e Humanas, Centro de Matemtica, Computao e Cognio e Centro de
Engenharia, Modelagem e Cincias Sociais Aplicadas.
A estrutura curricular do curso de BC&T da UFABC est organizada em torno
de seis eixos principais: Estrutura da Matria, Processos de Transformao, Energia,
Comunicao e Informao, Representao e Simulao, e por fim Humanidades.
Para viabilizar esta proposta inovadora a UFABC recebeu seus primeiros
servidores, tcnicos administrativos, concursados em 2006. Inicialmente, na rea de
Tecnologia da Informao (TI), foram contratados dois Analistas de TI e dois Tcnicos
de Laboratrio -rea Computao, e mais tarde (incio de 2007) mais um Analista de
TI e um Tcnico. At incio de 2009, nenhum outro funcionrio da rea de TI foi
contratado o que impedia a criao de uma diviso de desenvolvimento de software
durante os primeiros anos de exerccio da UFABC. importante ressaltar que as
demandas de solues automatizadas de software para os setores administrativos e
acadmicos eram contnuas e crescentes.
Assim, em meados de 2009, com a contratao dos novos servidores da rea de
TI, foi possvel a implantao de uma diviso de desenvolvimento, criando uma equipe
coesa e dedicada ao estudo de metodologias para dar incio ao desenvolvimento de
aplicaes para os setores da UFABC, de forma rpida e eficiente, a fim de atender as
demandas engavetadas.
Para isto, a equipe deparou-se com diversos desafios: como vencer o atraso de
quase dois anos e meio, ainda assim garantindo uma qualidade de servio? Como criar
100

uma diviso de desenvolvimento de software para uma Universidade de Ponta para o

Sculo XXI? A resposta parecia apontar para o pragmatismo e estudo de metodologias
geis. Desta forma, o presente artigo tem por objetivo apresentar a experincia da
UFABC no processo de investigao e implantao de metodologias geis em seus
processos de desenvolvimento, identificando seus erros e acertos.

2. Metodologias
Desde o artigo de Royce [Royce, 1970] at os tempos recentes, metodologias tm
passado por diversas transformaes ou modificaes. Com o intuito de qualificar o
"nvel de maturidade" que uma empresa ou instituio possui no desenvolvimento de
software, foram criados modelos de capacitao e qualidade, tais como o o ISO/IEC
9126 e o CMM/CMMI [COUTO, 2007]. Porm, conforme cita Schwaber [Schwaber,
2004], modelos como o CMM, se no forem corretamente implantados, podem
aumentar a burocracia interna de uma instituio, o que implica naturalmente em atrasos
na entrega dos projetos. Como uma resposta s metodologias mais tradicionais, foi
publicado em 2001 o Manifesto gil [MANIFESTO, 2001], e em seu site oficial,
possvel encontrar a seguinte frase:
"Estamos descobrindo melhores maneiras de desenvolver software fazendo-as e
ajudando outros a faz-lo." (Grifo meu)
O grifo acima demonstra claramente o pragmatismo inerente s metodologias
geis, um pragmatismo que parece em conformidade com a proposta inovadora da
UFABC, em ser uma instituio que no se guia pelos padres de outras universidades
(principalmente na estrutura de cursos). Este pragmatismo e adaptabilidade tambm est
presente nas metodologias Scrum e Extreme Programming, nas quais o processo de
desenvolvimento (e gerncia) est constantemente em alterao e evoluo, de acordo
com a experincia da equipe como um todo. Alm disso, metodologias geis esto
constantemente preocupando-se em entregar, aps um perodo curto de tempo, software
que j pode ser implantado e utilizado, e no futuro estender as suas funcionalidades,
para que se evite um levantamento prvio de requisitos muito extenso que
provavelmente ser completamente alterado.
Antes de decidir qual seria o caminho da implantao de uma metodologia gil,
foi feito um levantamento das principais prticas das metodologias Extreme
Programming [Wells 2009] e Scrum [Schwaber 2004].
2.1. Extreme Programming [Wells, 2009]
A metodologia Extreme Programming foca-se no apenas na gerncia do
desenvolvimento, mas tambm na codificao do software. Esta metodologia possui
diversas definies sobre como um cdigo deve ser escrito, quais as melhores prticas
de escrev-lo, e define tambm algumas reunies que devem ser feitas. As principais
prticas do Extreme Programming so:
1. Durante o levantamento de requisitos, so escritas user stories. Semelhantes s
definies formais de requisitos, user stories diferenciam-se principalmente pela
facilidade de l-las e pela vantagem de serem escritas na linguagem do usurio.
2. Todos os dias, antes do incio de qualquer atividade, faz-se uma stand-up
meeting. Este tipo de reunio semelhante reunio apresentada pela

101

metodologia Scrum, sendo uma reunio executada em p (para evitar demoras) e

cujo nico objetivo promover comunicao entre os desenvolvedores.
3. Toda a codificao do software feita em pares. Dois programadores trabalham
juntos, no mesmo computador, para evitar cansao excessivo de apenas uma
pessoa, e tambm para identificar erros mais cedo (seja em lgica ou em
codificao propriamente dita).
4. Todo cdigo deve estar coberto por testes automatizados, de preferncia
escrevendo o teste antes do cdigo.
5. Quando um erro for encontrado no software, necessrio escrever um teste para
que o erro no recorra em verses futuras Assim como em outras metodologias
geis, as pessoas que solicitaram o desenvolvimento do sistema devem estar
sempre disponveis e presentes.
Adicionalmente, Extreme Programming promove certos conceitos como
planning poker, uma forma de estimar prazos usando cartas numeradas, alguns
conceitos como story points, uma medida de complexidade de uma tarefa, usada na hora
de estimar um prazo, e outros conceitos que, estando fora do escopo deste artigo, no
sero a seguir plenamente descritos.
2.2. Scrum
A metodologia Scrum mais voltada para a gerncia do desenvolvimento do software
ao invs das prticas. Criada por Ken Schwaber e Jeff Sutherland, o propsito ser uma
metodologia simples, de poucas regras, porm muita mudana de paradigma. Scrum
define mais reunies e planejamento do que a metodologia Extreme Programming, no
focando na codificao do software propriamente dito. Esta metodologia tambm
diferencia claramente as pessoas interessadas em um projeto e as comprometidas no
mesmo. Para as pessoas comprometidas, h trs papis:
1. Product Owner: na metodologia Scrum, responsabilidade do Product Owner
controlar quais funcionalidades o sistema possuir, quais so as prioridades,
acompanhar e guiar o desenvolvimento do sistema e informar ao Scrum Master
todas as alteraes que ocorreram nos requisitos. sua responsabilidade tambm
manter atualizado o Product Backlog, uma lista de funcionalidades que o
sistema deve possuir, cada uma com suas prioridades.
2. Scrum Master: semelhante ao gerente de projetos, o Scrum Master deve
reportar-se constantemente ao Product Owner, apresentar as dificuldades que a
equipe possui e tambm as alteraes feitas nos planos (caso haja alguma).
Tambm suas responsabilidades esto em marcar as reunies previstas pelo
Scrum, bem como garantir que todos estejam seguindo as regras evitando assim
interrupes no desenvolvimento.
3. Team: Todos os desenvolvedores do software esto presentes neste papel. A
responsabilidade da Equipe se auto-organizar, definir melhores prticas,
reportar-se um ao outro durante o desenvolvimento do sistema, e tambm
apresentar ao Product Owner o resultado do trabalho, quando for apropriado.
Scrum pede algumas reunies, tanto para comunicao entre os membros da Equipe
quanto para o planejamento do desenvolvimento. H tambm reunies para apresentar o

102

que foi desenvolvido e para melhorar o prprio modelo de trabalho. As reunies so as

que seguem:
1. Sprint Meeting: toda a codificao dividida em perodos de trinta dias corridos
chamados sprints (Figura 1, Iteration). No incio de cada sprint, feita uma
reunio com o Product Owner para priorizar os itens mais importantes do
Product Backlog.
2. Scrum Daily: durante um sprint, diariamente e sempre no mesmo horrio feita
uma reunio de, no mximo, trinta minutos no qual o Scrum Master pergunta
aos membros da Equipe o que cada um fez entre o Scrum Daily anterior e o
atual, o que cada um pretende fazer no dia, e se h alguma dificuldade que
impede a continuidade do trabalho (Figura 1, 24-hour inspection).
3. Sprint Review: aps o trmino do sprint, feita uma reunio para que a equipe
apresente ao Product Owner tudo o que foi desenvolvido durante o perodo.
4. Sprint Retrospective: logo depois do Sprint Review, feita uma reunio na qual
a Equipe, junto com o Scrum Master, discute melhores maneiras para melhorar o
processo de desenvolvimento.
Este ciclo repetido at o desenvolvimento completo do sistema. A figura 1 mostra o
ciclo de desenvolvimento do Scrum:

Figura 1: Ciclo de desenvolvimento da metodologia Scrum [Schwaber, 2004]

3. Idia e Filosofia
Aps o estudo das metodologias geis, foi feito um pequeno levantamento do que se
esperava de uma diviso de desenvolvimento, para priorizar aspectos da implantao de
uma metodologia gil sobre a outra. Foram consultados diversos artigos, porm um
deles foi mais incisivo sobre a idia da diviso, o artigo "Provocaes", do professor
Xxeo [Xxeo, 2009]. Entre todos os tpicos do artigo, vale citar os seguintes:
1. Pensamos em computadores e algoritmos, PORM nossos egressos trabalham
com pessoas e processos.
2. Pensamos em preparar pessoas especializadas capazes de aplicaes como se
detivessem um segredo do universo, programadores mticos, PORM qualquer
um pode gerar aplicaes, basta um pouco de vontade, uma planilha eletrnica
ou outros super-meta-aplicativos fceis de usar, como o Access.

103

3. Pensamos em linguagens de programao do tipo "bondage and discipline",

PORM linguagens libertrias, como Python e Ruby nos provam que podemos
ser mais produtivos de forma totalmente diferente.
4. Pensamos em equipes de trabalho pr-organizadas, PORM o desenvolvimento
de software livre e mesmo nas empresas cada vez mais auto-organizado.
Aps a leitura de outros artigos sobre o assunto, todos os membros da diviso de
desenvolvimento sentaram-se para definir um conjunto de idias sobre qual seriam as
responsabilidades da diviso, bem como um conjunto de preceitos sob os quais
quaisquer decises futuras se baseariam, e os dois principais (e que mais esto
relacionados com a implantao da metodologia) foram:
No tratar a diviso como uma "fbrica de software": este conceito foi
extremamente importante para indicar quais seriam as prticas a serem adotadas. Por
exemplo, a prtica do pair programming, como pede o Extreme Programming, exige
uma rigidez que num primeiro momento no era desejada. Alm disso, seria necessrio
atentar-se para uma metodologia que permitisse que todos os envolvidos, caso
desejassem, pudessem pesquisar assuntos diversos e implant-los. Tal preceito foi
baseado principalmente no primeiro e quarto itens, do artigo acima.
Desenvolvimento de sistemas deselitizado: permitir que futuros usurios e
pessoas interessadas no desenvolvimento acompanhem todo o projeto, desde seu incio,
sem a necessidade de regras formais. responsabilidade da Equipe ouviras idias do
usurio e evitar jarges ou diagramas complexos. Por exemplo, caso fosse necessrio
apresentar um diagrama para um usurio, o ideal seria que o diagrama fosse "traduzido"
em uma linguagem mais simples para ser apresentado. Tal pensamento foi
principalmente baseado no segundo item do artigo acima.
Alm destes preceitos, havia tambm a necessidade de manter claro para todos
os envolvidos em desenvolvimento de software, tanto da diviso de desenvolvimento
como o restante da universidade, qual o auxlio que o setor de TI da universidade pode
oferecer no desenvolvimento de sistemas, e at onde estes sistemas poderiam auxiliar
tanto no controle interno das atividades como na tomada de decises. Para tal, a equipe
comprometeu-se a evitar determinadas pr-concepes comuns entre os
desenvolvedores, como a afirmao de que o usurio nunca sabe o que deseja. Portanto,
seria atribuio, tambm, da equipe de desenvolvimento auxiliar o demandante de um
sistema a organizar as idias e pensamentos sobre o que um sistema deveria fazer, ao
invs de reclamar da falta de definies ou da ausncia de informaes. Alm disso,
foram definidas as seguintes idias, que dizem especificamente a respeito do software a
ser desenvolvido:
No "frear" a universidade: o software no pode ser um fator decisivo para
evitar a inovao prevista, e sim ser dinmico para acomod-la.
Apresentar falhas, mas no impor condies: se for identificado algo que no
daria certo no desenvolvimento de um aplicativo (tais como excees constantes de
regras), apresentar o problema, propor solues e confiar que os comprometidos com o
projeto definiro a melhor forma de solucion-lo.
Solucionar apenas os problemas que foram apresentados: quando uma
dificuldade for apresentada, ver se existe uma soluo que atende previamente o
problema. Se for necessrio um desenvolvimento, fazer um levantamento de requisitos e
104

codificar apenas o que foi pedido, atentando-se para as prioridades. Nos mtodos geis,
comum a utilizao do termo YAGNI (do ingls You Ain't Gonna Need It, ou "voc
no vai precisar disto").
Aprender a conviver com as mudanas, ao invs de reclamar delas: um fato
presente em metodologias geis e no prprio projeto pedaggico da UFABC a
mudana constante. Aceitar que as mudanas so naturais, e garantir um software que se
adapte a elas. No caso, se um software tornar-se instvel por mudanas excessivas,
necessrio pesquisar melhores tecnologias ou prticas (possivelmente de testes
automatizados) para manter o produto final flexvel.
Software como "arte" e "ferramenta": uma das principais idias que o
desenvolvimento precisa manter clara a importncia de manter-se um cdigo limpo,
claro, e sem construes "obscuras" nem "solues paliativas", principalmente para
facilitar a manuteno futura. Uma frase que ainda muito citada na diviso : "jamais
escreva um cdigo que voc ter vergonha de mostrar para algum". Entretanto,
necessrio tambm entender que o produto final do desenvolvimento, embora tenha que
atender uma srie de critrios, apenas uma ferramenta para outra pessoa-portanto, se o
software no atender as demandas e necessidades do outro, ele no ter utilidade,
independente de estar estvel, bem codificado e testado.

4. Implantao de Scrum na UFABC

No primeiro semestre de 2009, novos funcionrios (Tcnicos e Analistas) oficialmente
entraram em exerccio, e conseqentemente foi possvel a criao de um setor de
desenvolvimento de sistemas. Com o apoio da chefia, os pedidos de projetos foram
anotados, porm nenhum projeto comeou a ser desenvolvido at que todos os
funcionrios recebessem treinamento na tecnologia adotada na UFABC (linguagem de
programao Ruby e framework Rails, alm de prticas de teste automatizado). Durante
um ms, foram feitos treinamentos e, em paralelo, foram escolhidos aspectos das
metodologias que seriam adotadas. Decidiu-se que seria implantado Scrum, e algumas
prticas do Extreme Programming referentes aos testes automatizados.
Logo no primeiro projeto, foi definido que atentaramos para algumas regras do
Scrum. Num primeiro momento, entretanto, as reunies do Scrum Daily eram
executadas a cada trs dias, e as outras reunies previstas pela metodologia no foram
adotadas. Do Extreme Programming, era desejado que se obedecesse prtica de
escrever os testes antes do cdigo (Test-Driven Development), evitando-se deixar
qualquer fragmento do cdigo-fonte sem estar coberto por algum teste, porm devido
pouca experincia da equipe com testes automatizados, nos primeiros projetos isto foi
apenas parcialmente atendido. Outros aspectos do Scrum, tais como o papel do Product
Owner e Scrum Master no estavam claros para a equipe de desenvolvimento,
demonstrando que a maior parte da metodologia Scrum no havia sido implantada.
Porm, conforme os projetos foram sendo desenvolvidos, mais aspectos de ambas as
metodologias foram sendo implantados, at consolidarem-se nas prticas que temos
hoje, apresentadas mais frente.

105

4.1. Projetos de Implantao

Este estudo de caso est dividido cronologicamente por projeto. feita uma breve
descrio dos problemas enfrentados em cada um (relativos apenas metodologia) e so
apresentadas as solues adotadas e implantadas.
4.1.1. Primeiro Projeto - Melhoria na Definio de Requisitos
Necessidade: automatizar o processo de avaliao em estgio probatrio.
Demandante: setor de Recursos Humanos.
Problemas enfrentados: falha na definio das funcionalidades do sistema (chamadas
de user-stories nos mtodos geis). Na metodologia Scrum, as descries de cada
funcionalidade devem ser escritas na linguagem mais prxima possvel do usurio. Tais
descries so chamadas de user-stories, e consistem em uma linguagem sucintal, tal
como "o sistema deve permitir um cadastro de usurios". Porm, no projeto
desenvolvido, as tarefas foram descritas em uma linguagem que facilitaria a
transformao das mesmas em testes de aceitao, tais como "na tela de cadastros, deve
haver o campo 'nome', 'endereco', 'telefone'...". Quando estas descries de
funcionalidade foram repassadas ao Product Owner, ele no conseguiu identificar as
falhas, e alguns problemas emergiram devido mudana de rumo no desenvolvimento
do sistema no meio de um sprint.
Solues implantadas: melhores maneiras de descrever as funcionalidades. Foi
estudado o formato de user-stories, melhorado o formato do Product Backlog e tambm
foram estudadas wireframes, formas de apresentar um esboo das telas para o usurio.
4.1.2. Segundo Projeto - Reviso do Papel do Scrum Master
Necessidade: criar um formulrio de inscrio em concurso pblico.
Demandante: setor de Recursos Humanos.
Envolvidos no projeto: setor de Finanas.
Problemas enfrentados: falha grave de comunicao entre os dois setores envolvidos
no desenvolvimento, que resultou em um atrito entre um dos funcionrios do
desenvolvimento com o de outro setor. A maior falha, porm, consistiu em no se
obedecer s regras do Scrum no que diz respeito ao papel do Scrum Master, no qual ele
o nico responsvel em manter o canal de comunicao entre a equipe e todos os
agentes externos a ela.
Soluo implantada: reviso do papel do Scrum Master. A partir deste projeto
qualquer contato com a Equipe deveria passar pelo Scrum Master, para evitar atritos
futuros.
Melhoria implantada: adotao do Google Spreadsheets como forma de manter o
Product Backlog disponvel para todas as pessoas interessadas no projeto ou
comprometidas com ele.
4.1.3. Terceiro Projeto - Adoo de Test-Driven Development
Necessidade: desenvolvimento de um sistema de matrcula em disciplinas.
Demandante: Pr-reitoria de Graduao.
106

Problema enfrentado: repentina alterao no sistema de matrculas, prximo do prazo

de entrega. No ltimo perodo de matrcula em disciplinas, cada disciplina era separada
em um determinado grupo de horrios, cada um contendo os dias da semana e horrios
de incio e fim de cada aula. Este tipo de separao se dava devido ao fato que a
matrcula era feita de forma manual, ento garantia-se que os grupos jamais se
chocariam uns com os outros. Porm durante o desenvolvimento do sistema, foi feita
uma alterao brusca, onde a idia de grupo de horrios foi abolida e cada disciplina
recebeu seus prprios horrios, independentemente das outras. Tal mudana foi
efetuada faltando poucas semanas para a matrcula dos alunos, e representou uma
alterao em aproximadamente um tero do sistema.
Melhoria implantada: seguir rigorosamente a prtica de Test-Driven Development.
Durante o desenvolvimento deste sistema, foi adotado Test-Driven Development, num
primeiro momento apenas como meio de estudo. Graas a esta prtica a alterao foi
efetuada em apenas seis horas corridas, e o prazo de entrega foi atendido. Os projetos
seguintes, ento, passaram a adotar rigorosamente a prtica de Test-Driven
Development, e tambm foi adotada a prtica de escrita do modelo entidaderelacionamento, como forma de documentao da base de dados.
4.1.4. Quarto Projeto - Apresentao ao Usurio das Regras do Scrum
Necessidade: criao de um questionrio socioeconmico para os alunos, integrado
com o sistema de matrcula.
Demandante: setor de Planejamento.
Problemas enfrentados: dificuldades para o usurio se reportar a apenas uma pessoa.
Neste projeto, o Product Owner estava se dirigindo a vrios membros da Equipe,
quebrando a regra do Scrum que pede que, durante um Sprint, somente o Scrum Master
faa a intermediao entre a Equipe de trabalho e quaisquer outros envolvidos no
desenvolvimento.
Solues implantadas: limitar o contato do usurio ao Scrum Master. Como o Product
Owner evitava se reportar apenas ao Scrum Master, mesmo aps alguns pedidos, a
Equipe foi instruda a encaminhar todos os e-mails que chegavam pedindo informaes
sobre o projeto ao Scrum Master, indicando ao remetente que estavam repassando a
correspondncia para a pessoa competente.
Melhorias implantadas: otimizao das reunies e instalao de um quadro-branco.
Com o objetivo de manter a Equipe a par do que cada um de seus membros fazia, foi
definido que a reunio Scrum Daily seria executada a cada vinte e quatro horas.
Tambm foi implantada a reunio Sprint Retrospective. Alm disso, houve a instalao
de um quadro-branco que facilitou a comunicao entre todos os desenvolvedores. Com
a instalao do quadro, algumas prticas comearam a emergir, tais como escrever
fragmentos e cdigo que outros poderiam aproveitar, ou mesmo deixar o modelo
entidade-relacionamento (ou um fragmento dele, referente quele sprint) desenhado
apenas no quadro, e depois passado a limpo.
4.1.5. Quinto Projeto - Melhoria na Comunicao
Necessidade: desenvolvimento de um sistema acadmico, para atender as demandas
especficas da universidade.

107

Demandante: Pr-Reitoria de Graduao.

Problemas enfrentados: indefinies nos requisitos. Durante o desenvolvimento deste
sistema, havia muitas indefinies que precisavam de uma resposta. Infelizmente, o
Product Owner no se apresentava muito presente no desenvolvimento, e embora esta
mesma situao tivesse ocorrido nos outros sistemas, devido complexidade deste
projeto o problema foi exposto. Alm disso, depois do primeiro Sprint, ficou claro que
os envolvidos com o projeto no sabiam quanto do sistema estava desenvolvido, ou
mesmo em que estado ele se encontrava.
Solues implantadas: implantao das reunies Sprint Meeting e Sprint Review, e
desta forma todas as reunies previstas pelo Scrum passaram a ser marcadas por projeto.
Foram feitas tambm tentativas de aproximar mais o Product Owner do
desenvolvimento, e tambm e-mails com questionamentos passaram a ser mandados
com cpia para outras pessoas que possuam conhecimento dos processos. Por fim, foi
instalada uma Wiki para a equipe de desenvolvimento e os envolvidos em cada projeto,
contendo manuais dos sistemas, documentaes, e manuais de boas-prticas.
4.1.6. Sexto Projeto - Esboo do Q/A
Necessidade: criar um formulrio para os docentes com perguntas sobre quais
disciplinas cada um est apto a ministrar.
Demandante: comit de Alocao Didtica.
Envolvidos no projeto: Pr-Reitoria de Graduao.
Problemas enfrentados: queda na qualidade do cdigo-fonte, alm de erros
introduzidos no cdigo devido falta de testes de aceitao. Neste projeto, devido ao
prazo apertado, muitas das boas-prticas e convenes de sintaxe acabaram sendo
desobedecidas, bem como o uso de Test-Driven Development. Adicionalmente, a
ausncia dos testes de aceitao (Acceptance Tests no Extreme Programming, tambm
chamados de testes funcionais ou testes de caixa-preta) comearam a expor alguns bugs.
Solues implantadas: estudos de bibliotecas de teste que pudessem facilitar a criao
de testes de aceitao, e reviso de algumas polticas de teste. Tambm, foi criado um
processo denominado Q/A (do ingls Quality Assurance), que consiste em revisar cada
tarefa, a fim de determinar se ela segue os padres de qualidade do cdigo-fonte.
4.1.7. Stimo Projeto - Maior Participao do Product Owner
Necessidade: desenvolver um formulrio para cadastramento de reagentes controlados.
Demandante: setor de Reagentes e Descartes.
Envolvidos no projeto: laboratrios de Qumica.
Solues implantadas: formalizaes no processo de Q/A. Este projeto, por ser bem
simples, no apresentou problemas no desenvolvimento. Mesmo assim, melhorias
foram implantadas, tais como formalizaes no processo de Q/A, que consistiu em
incluir na wiki uma lista de passos a serem vistoriados no momento de anlise do
cdigo, bem como padres de qualidade a serem seguidos. Durante este projeto tambm
foi escrito um resumo de cada projeto desenvolvido, bem como um guia completo de
utilizao do sistema de controle de verso (para consulta pelos novos servidores).
Durante o projeto, o Product Owner apresentou-se bem presente, comparecendo ao
108

setor uma vez por semana para acompanhar o desenvolvimento e respondendo dvidas
e questionamentos quase imediatamente.
4.2. Evoluo dos Processos
Muitas alteraes foram feitas desde o primeiro projeto da UFABC at o final do stimo
projeto. As principais mudanas desde o incio da implantao at a situao hoje, so
as seguintes:
1. Num primeiro momento, acreditava-se que as reunies dirias pedidas pelo
Scrum incorporariam rigidez desnecessria ao desenvolvimento, o que provou
ser falso: tais reunies facilitam o sincronismo da equipe. Em sistemas
complexos, esta prtica indispensvel para que todos os membros estejam
trabalhando no mesmo ritmo.
2. A prtica de escrever testes automatizados, especialmente antes do prprio
cdigo-fonte, a maior (ou talvez, a nica) garantia de que o software
desenvolvido est e permanecer estvel. No processo de desenvolvimento gil,
onde no h diviso entre desenvolvedores, testadores, ou designers, o teste
automatizado torna-se simplesmente indispensvel, e a cobertura de cdigo
sempre dever
/// ser muito alta (nos projetos desenvolvidos, a cobertura sempre
maior que noventa e cinco porcento das linhas de cdigo).
3. No incio da implantao, fora o Scrum Daily, nenhuma outra reunio era
efetuada a no ser um levantamento preliminar de requisitos. Durante o
desenvolvimento dos diversos projetos, notou-se que a regra do Scrum de que
cada Sprint deve contar com uma reunio de planejamento (Sprint Meeting),
com toda a equipe de desenvolvimento, permite uma percepo melhor do
problema a ser resolvido e das prticas a serem adotadas.
4. Aps a implantao da reunio Sprint Retrospective e instalao do quadrobranco, diversas mudanas emergiram e a qualidade do desenvolvimento no
geral subiu consideravelmente. Tais melhoras se justificam especialmente pela
maior comunicao entre a Equipe.
5. A prtica de apresentar um esboo das telas ao usurio (wireframes) consolidouse, em projetos futuros, como uma forma de capturar falhas no levantamento de
requisitos. Em projetos futuros, ao apresentar as wireframes ao usurio notavamse situaes que no haviam sido pensadas, e que eram prontamente adicionadas
ao Product Backlog.
4.3. Situao Hoje
Todo o desenvolvimento na Universidade Federal do ABC, hoje, atende as maiores
prticas da metodologia Scrum. Os processos no desenvolvimento so:
1. Pedido do sistema, e um breve resumo com a montagem do Product Backlog. O
Product Backlog deve ficar sempre visvel a qualquer pessoa interessada.
2. Definio da Equipe que trabalhar no projeto, marcao do Sprint Meeting,
priorizao das tarefas no Product Backlog.
3. Durante o Sprint Meeting, so definidos at mesmo esboos de tela (chamados
wireframes) para facilitar o entendimento tanto dos desenvolvedores quanto dos
109

demandantes do sistema. Normalmente, no esboo do wireframe, so

identificadas novas tarefas que so includas no Product Backlog.
4. Durante o Sprint, s 9h 30min, todos os desenvolvedores devem atender ao
Scrum Daily.
5. Cada desenvolvedor pode escolher qualquer tarefa, e deve marcar seu nome ou
iniciais nela. A partir deste momento, a tarefa considerada "Em andamento".
6. Uma tarefa considerada "Aberta" quando no h ningum trabalhando nela
porm foi selecionada para compor o Sprint, "Em andamento" quando est
sendo codificada por uma pessoa, "Em Q/A" quando a tarefa foi concluda
porm ainda precisa passar pela vistoria, ou "Fechada" quando cluda e revisada.
7. Usa-se sempre o sistema de controle de verso durante o desenvolvimento. Alm
disso, no se pode subir a cpia de trabalho atual no sistema de controle de
verso se houver testes falhando.
8. Todo o cdigo deve estar coberto por testes. Escreve-se o teste antes de escrever
o cdigo.
9. O Modelo Entidade-Relacionamento normalmente montado junto com a
codificao, e seu esboo fica no quadro-branco. Aps o trmino do Sprint, o
modelo passado a limpo e compe a documentao auxiliar do software.
10. Toda definio de classe ou mtodo deve conter um comentrio antes, definindo
o que aquele cdigo faz (num formato semelhante ao Javadoc). Esta
documentao "em cdigo" tambm compe a documentao do software.
11. O Product Owner livre para entrar em contato em qualquer momento com o
Scrum Master para pedir informaes, e tambm pode participar do Scrum
Daily.
12. Aps o trmino do Sprint, faz-se uma reunio para demonstrar o que foi
desenvolvido (Sprint Review). Caso o Product Owner deseje, o software pode
ser publicado.
13. Logo aps o Sprint Review, faz-se a reunio Sprint Retrospective, e analisa-se o
que deve ser melhorado. Normalmente, h dois ou trs dias para pesquisar uma
melhora, e ento planeja-se outro Sprint Meeting.
Como possvel ver, houve uma grande evoluo no processo de
desenvolvimento, embora ainda existam muitos aspectos que possam evoluir. Outros
projetos, feitos em paralelo, tambm auxiliaram muitas tomadas de deciso que
permitiram uma evoluo constante do processo e da metodologia.

5. Consideraes Finais
Desde o incio, a diviso de desenvolvimento de software foi montada sob uma tica
pragmtica e orientada de acordo com a prpria filosofia da universidade. Este fator,
principalmente, auxiliou muito a implantao de Scrum e o incio do desenvolvimento
de sistemas que garantissem padres de qualidade e atendessem a universidade. Outro
fator extremamente auxiliador foi o apoio da chefia do Ncleo de Tecnologia da
Informao, auxiliando sempre que possvel para que as regras de Scrum fossem bem
atendidas e no houvesse informaes cruzadas.
110

 possvel tambm perceber que, desde o incio at o momento presente, houve

uma grande evoluo na metodologia, o que resultou em grandes avanos na qualidade
do software entregue. Tambm, todos os projetos desenvolvidos tiveram seus prazos
cumpridos, apesar das dificuldades inerentes de cada um.
Por fim, Scrum uma metodologia que sempre est em evoluo. Na diviso de
desenvolvimento, praticamente todos os aspectos inicialmente implantados foram
revisados, e alguns esto passando por sua segunda reviso. A cada Sprint, seja ele no
mesmo projeto ou em projetos diferentes, h uma nova mudana a ser implantada, ou
algum aspecto a ser revisado-e isto torna a metodologia dinmica, havendo sempre uma
alterao com o intuito de atender demandas cada vez mais especficas.
Na experincia da UFABC, as poucas regras da metodologia devem ser
rigidamente seguidas, pelo menos em um primeiro momento. A cada Sprint, uma nova
alterao dever ser implantada, mas nunca quebrando qualquer regra. Apenas depois
que todos os desenvolvedores estiverem confiantes na metodologia, at mesmo os
aspectos do prprio Scrum podem ser repensados, dessa forma garantindo-se que cada
membro da equipe j esteja pensando de acordo com o paradigma gil.
Scrum representa uma mudana de paradigma, na qual o processo de
desenvolvimento de sistemas deixa de ter prticas bem definidas e controlveis e
comea a ter passos flexveis, mutveis e auto-organizveis. Esta metodologia, junto
com outras metodologias geis, tem como natureza estar sempre sendo adaptada pela
prpria Equipe, e no deve nunca cair em estagnao. Sua natureza ser, sempre, uma
"metodologia sem fim".

6. Agradecimentos
Agradecemos UFABC, pela oportunidade de inovao na criao de uma equipe de
desenvolvimento, ao NTI, pela confiana depositada na implantao de uma
metodologia gil como soluo demanda de desenvolvimento, e principalmente
Equipe que compe a diviso de Desenvolvimento de Sistemas, por manter-se sempre
comunicativa, desta forma permitindo o bom funcionamento de uma metodologia gil.

Referncias Bibliogrficas
Couto, Ana Brasil (2007) "CMMI -Integrao dos Modelos de Capacitao e
Maturidade de Sistemas", ed. Cincia Moderna.
Portela, Carlos S., Oliveira, Sandro R. B. (2009) "Uma Proposta de Adaptao do
Processo de Gerenciamento do CTIC-UFPA adotando Prticas geis", apresentado
no III Workshop de TI das IFES, Belm - PA
Royce, Winston W. (2003) "Managing the Development of Large Software Systems",
disponvel
em:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.
Schwaber, Ken (2004) "Agile Project Management with Scrum", Microsoft Press.
Xxeo, Geraldo B. (1999), "Estamos Ficando Ultrapassados", disponvel em:
http://xexeo.wordpress.com/2009/10/24/estamos-ficando-ultrapassados/
Wells, J. D. (2009) "Extreme Programming", http://www.extremeprogramming.org

111

Adoo de mtodos geis em uma Instituio Pblica de

grande porte - um estudo de caso
Claudia de O. Melo1, Gisele R. M. Ferreira2
1

Instituto de Matemtica e Estatstica

Universidade de So Paulo (USP) - So Paulo, SP - Brasil
2

Banco Central do Brasil

Departamento de Informtica - Braslia - DF - Brasil
claudia@ime.usp.br, gisele.ferreira@bcb.gov.br

Abstract. An increasing need of software quality and the pressure for faster
software delivery are the main reasons that lead companies to adopt agile
software development methodologies. This paper describes a case study of a
Brazilian government organization that adopted agile methods after a long
time of using traditional software development techniques. This article
describes the organizational context that motivated and supported this change,
describes two pilot projects and discusses the observed results from technical
and management perspectives. The results after 18 months were satisfactory
and decisive to encourage new experiences with agile methods within the
organization.
Resumo. A busca crescente por qualidade de software e a presso por
entregas rpidas so os principais motivos que levam as empresas a adotarem
mtodos geis de desenvolvimento de software. Este artigo descreve um estudo
de caso de uma Instituio Pblica Brasileira de grande porte que optou por
adotar mtodos geis aps anos de experincia com mtodos tradicionais de
desenvolvimento. O artigo detalha o contexto organizacional que motivou e
apoiou o processo de adoo, descreve dois projetos pilotos e discute os
resultados observados, sob perspectivas tcnicas e gerenciais. Os resultados
aps 18 meses de implantao foram considerados satisfatrios e decisivos
para encorajar novas experincias com mtodos geis dentro da organizao.

1. Introduo
Mtodos geis de desenvolvimento de software vm ganhando crescente popularidade
desde o incio da dcada de 2000 e, de acordo com Parsons et al. (2007), em algumas
circunstncias podem oferecer melhores resultados para projetos de desenvolvimento de
software quando comparados s abordagens mais tradicionais. Eles so regidos pelo
Manifesto gil (2001), conjunto de valores e princpios criados por 17 desenvolvedores
experientes, consultores e lderes da comunidade de desenvolvimento de software.
Segundo Dyb (2000) e Nerur et al. (2005) estes mtodos podem ser vistos como uma
reao aos mtodos tradicionais (tambm conhecidos como dirigidos por planos) que
enfatizam o planejamento e a predio de solues para cada problema do
desenvolvimento.

112

De acordo com Ambler (2006) e VersionOne (2009), dentre os mtodos geis

existentes, a Programao Extrema de Kent Beck (2001), ou XP, e o Scrum de
Schwaber (2004) so os mais conhecidos e adotados na indstria. XP prope um
conjunto de valores, princpios e prticas que visam a garantir o sucesso no
desenvolvimento de software, em face a requisitos vagos e com alto grau de incerteza.
XP promete produzir software de alta qualidade com alta produtividade, o que atrai a
ateno das empresas que demandam cada vez mais velocidade e qualidade em seus
produtos. J o Scrum uma metodologia gil para gesto e gerenciamento de projetos,
muitas vezes associada a outros mtodos e processos de desenvolvimento de software.
Dyb e Dingsyr (2008) apontam que diversos trabalhos sobre mtodos geis j
foram publicados, no entanto pouco se sabe sobre como esses mtodos so realizados na
prtica e que efeitos geram. Dentre os estudos de caso levantados nesta pesquisa sobre
implantao de mtodos geis, apenas o reportado por Freire et al. (2005) tratava da
adoo por empresas brasileiras. Alm disso, nenhum trabalho foi encontrado sobre a
implantao de mtodos geis em rgos pblicos brasileiros.
Este trabalho tem como objetivo analisar empiricamente a adoo de mtodos
geis e seu impacto no aprendizado, qualidade do cdigo-fonte, produtividade e
satisfao do cliente. Para isso foi conduzido um estudo de caso em uma instituio
pblica brasileira de grande porte. Foram levantados dados quantitativos e qualitativos
para responder s questes de pesquisa. Os ganhos e limitaes da adoo sero
discutidos e contrastados com alguns resultados da literatura. Espera-se tambm gerar
uma contribuio para outras empresas brasileiras que desejem adotar mtodos geis,
sejam elas pblicas ou privadas.
O artigo est organizado da seguinte forma: a Seo 2 apresenta uma reviso da
literatura acerca da adoo de mtodos geis e os principais resultados obtidos. A Seo
3 descreve os objetivos de pesquisa e detalha a metodologia usada. A Seo 4 descreve
o estudo de caso realizado em uma instituio pblica brasileira de grande porte,
enquanto a Seo 5 descreve e analisa os primeiros efeitos da adoo de mtodos geis
na instituio. A Seo 6 discute os resultados, suas implicaes e limitaes. A Seo 7
conclui o trabalho e aponta alguns trabalhos futuros.

2. Reviso da literatura
Um estudo apresentado por Svensson e Hst (2005) descreveu os resultados da adoo
de XP em uma organizao considerada de grande porte (emprega 1500 pessoas, 250 em
desenvolvimento de software). A avaliao se deu por meio de um projeto piloto que
durou oito meses. Trs pessoas foram escolhidas para representar os diferentes pontos
de vista da organizao, duas lderes de projeto e uma representante de cliente. Como
resultado, a organizao percebeu que a adoo de mtodos geis teve um efeito
positivo sobre a colaborao entre os membros da empresa. Os autores aconselham no
subestimar o esforo necessrio para introduzir e adaptar XP em uma organizao.
Ilieva et al. (2004) descrevem um estudo de caso que compara um projeto XP
com um projeto tradicional da organizao. Os projetos eram similares em tamanho,
esforo e tecnologia adotada. O time do piloto foi composto de 4 pessoas e o projeto foi
organizado para realizar uma entrega com 3 iteraes. Como resultado final foi
113

observado o aumento da produtividade em 41,23%, reduo de esforo (homem/hora)

de 11,45% e reduo de defeitos em 13,33%.
Freire et al. (2005) descrevem a experincia de introduo de XP em uma startup brasileira. Eles discutem as adaptaes feitas nas prticas de XP e como os aspectos
culturais e econmicos brasileiros afetam a implantao do mtodo. Todas as prticas
foram implantadas de uma s vez e 4 sistemas foram desenvolvidos ao longo de 12
releases com iteraes de 2 semanas. Os autores relatam a dificuldade de se implantar
mtodos geis em times heterogneos, o que pode ser resolvido com pacincia e paixo
brasileira. No entanto, o artigo no apresenta uma avaliao dos times envolvidos
acerca das dificuldades e benefcios percebidos com a implantao.
Loftus e Ratcliffe (2005) apresentam um estudo realizado com estudantes de
psgraduao para verificar, dentre diversos objetivos, se XP promove o aprendizado de
novas tecnologias. Como resultado, a maior parte dos estudantes relatou ter adquirido
muito conhecimento em um perodo curto de tempo e que o uso de XP auxilia a
introduo de novas tecnologias. Os autores recomendam que os estudantes sejam
apresentados s metodologias tradicionais em projetos de grupo antes de aprender XP
em sua forma completa. Por outro lado, os resultados de McAvoy e Butler (2007)
mostraram que o aprendizado do time pode no ser efetivo em XP, possivelmente em
funo da presso social sobre um indivduo em estar sempre em conformidade com a
viso do grupo (fenmeno conhecido como o Paradoxo de Abilene). Portanto,
necessrio manter um certo nvel de conflito no time para que haja maior comunicao,
contestao e, por fim, aprendizado.

3. Projeto do estudo de caso

Este trabalho tem como objetivo explorar a adoo de mtodos geis (MAs) e seu
impacto em uma organizao por meio de quatro questes de pesquisa (QP):
QP1. MAs aceleram o aprendizado de novas tecnologias, conceitos e padres?
QP2. MAs aumentam a qualidade do cdigo do sistema?
QP3. MAs aumentam a produtividade do time?
QP4. MAs aumentam a satisfao do cliente?

Para descrever e explorar os efeitos da adoo de mtodos geis foi usada a

metodologia de pesquisa de estudo de caso. Segundo Zelkowitz e Wallace (1998),
estudo de caso um estudo observacional em que o pesquisador monitora projetos em
profundidade e coleta dados ao longo do tempo. As unidades de anlise utilizadas foram
os dois projetos piloto de mtodos geis da organizao.
Mtodo de coleta de dados. Os dados foram coletados de vrias maneiras e fontes,
incluindo observao, entrevistas, questionrios online e bases de dados
organizacionais. Os questionrios tinham o objetivo de coletar dados qualitativos e
quantitativos a respeito do time, sua experincia prvia, seu nvel de aprendizado e
opinies sobre produtividade, qualidade e satisfao. Dados de observao e entrevistas
complementaram os questionrios sob o ponto de vista qualitativo. As pesquisadoras
atuaram como observadoras participantes em parte dos projetos. Dados quantitativos
sobre a produtividade e a qualidade foram coletados ao final de cada projeto piloto para
possibilitar a comparao entre os projetos anteriores (tradicionais) e os pilotos geis.
Bases de dados organizacionais continham as medies dos projetos passados.

114

De acordo com Svensson e Hst (2005), a maior parte das pesquisas sobre
introduo e uso de mtodos geis em organizaes baseada na opinio dos times que
aplicaram os mtodos. Dois questionrios foram criados, um para a equipe tcnica,
outro para os clientes dos projetos estudados, ambos com trs sees. A primeira seo
continha perguntas demogrficas sobre o perfil do participante e sua experincia prvia
em desenvolvimento de software e mtodos geis. A segunda seo tratava das
experincias durante os pilotos executados, como o nvel de dificuldade no aprendizado
das prticas, dificuldades enfrentadas e fatores que favoreceram o aprendizado. Para
medir o nvel de aprendizado, uma escala Likert de 4 pontos foi usada para refletir o
nvel de percepo de cada participante sobre seu prprio aprendizado. Para colher a
opinio sobre as dificuldades enfrentadas no aprendizado, assim como os fatores
positivos no processo, foram feitas perguntas abertas. A terceira seo era sobre a
percepo sobre o aumento ou diminuio do aprendizado, produtividade, qualidade e
satisfao do cliente aps o uso de mtodos geis. As percepes foram medidas com
uma escala Likert de 5 pontos, projetada para ser compatvel com a usada no
questionrio online de Ambler (2008) e, assim, permitir comparao entre os resultados.
O questionrio online1 foi aplicado aps a finalizao dos pilotos e ficou
disponvel durante uma semana para os 24 participantes dos projetos e 20 pessoas
responderam, representando 83,3% do total. O restante no trabalhava mais na
organizao ou estava em perodo de frias ou licena.
Validade. As principais ameaas aos estudos de caso aplicveis a este estudo de caso
so mencionadas por Yin (2009). Dentre elas, destaca-se a confiabilidade dos dados
coletados e dos resultados obtidos. Para Seaman (1999), o uso de vrias fontes de dados
e mtodos de coleta permite a triangulao, uma tcnica para confirmar se os resultados
de diversas fontes e de diversos mtodos convergem. Dessa forma possvel aumentar a
validade interna do estudo e aumentar a fora das concluses. Nesta pesquisa houve
triangulao de dados, de observador e de metodologia. A triangulao de dados se deu
pelo uso de bases organizacionais, questionrios e entrevistas para coletar dados,
enquanto a de observador se deu pelo uso de dois observadores. Por fim, a triangulao
de mtodos ocorreu pelo uso de mtodos de coleta quantitativos e qualitativos.

4. Estudo de caso
4.1. A organizao em estudo
A empresa em estudo uma instituio pblica que atua no sistema financeiro. Ela
emprega cerca de 5000 pessoas, 700 delas na rea de informtica. A preocupao com
processos padronizados e documentados foi inserida no contexto de desenvolvimento de
software em 2002. Uma infraestrutura de apoio implantao de um processo derivado
do RUP, de Kruchten (2000), foi montada com disciplinas e fases, alm da
especializao de papis. O departamento de informtica foi dividido em subreas por
especialidade, criando reas de relacionamento com o negcio (com a maior parte dos
funcionrios), a rea de testes, a de projeto de software, alm de outras reas de apoio
como a de gesto do relacionamento com as fbricas e a de controle da qualidade,
padronizao e reuso.

Os questionrios e as respostas esto disponveis em www.ime.usp.br/~claudia/wbma

115

Por mais de 8 anos, toda a organizao utilizou (e ainda utiliza) esse processo no
desenvolvimento. Houve uma aposta na terceirizao como chave para o aumento de
escala de produo, porm mantendo o foco nas competncias principais dentro da
instituio, seguindo as tendncias do mercado apontadas por Paisittanand e Olson
(2006). O modelo de terceirizao adotado garantia que o conhecimento dos requisitos
de negcio e a definio da soluo arquitetural fosse propriedade da organizao,
enquanto a implementao do sistema ficava a cargo das fbricas de software.
A formalizao de um processo de desenvolvimento corporativo, com
especializaes em papis, e a adoo de fbricas de software representaram um
aumento de escala a um curto prazo, porm trouxeram problemas novos relatados pela
organizao. Havia dificuldade de comunicao derivada da alta especializao em
papis. Os prazos de entrega eram longos e faltava objetividade na definio do escopo
de sistemas. Os funcionrios estavam desmotivados por trabalhar grande parte do tempo
em tarefas burocrticas de gerenciamento das fbricas ou em atividades muito
especializadas. Alm disso, criou-se uma dependncia das fbricas para todas as
atividades relacionadas implementao. Neste contexto, a adoo de mtodos geis
apareceu como uma proposta de soluo para os diversos problemas apresentados,
inclusive como uma alternativa para a soluo do problema de escala de produo.
Infraestrutura tecnolgica. O ambiente de desenvolvimento da organizao foi
projetado para aumentar a produtividade dos times, pois adotava um servidor de
aplicao leve - Jetty (2010), um banco de dados em memria - Hsqldb (2010), uma
ferramenta de gerncia do build - Maven (2010) e, por fim, uma ferramenta para
integrao contnua - Hudson (2010). A arquitetura de referncia estava bem
documentada e disseminada. Ela baseava-se em Java, em alguns frameworks de
aumento de produtividade como Wicket (2010), Hibernate 3 (2010) e Spring (2010) e
dispunha de um conjunto de componentes de infraestrutura e negcio.
Alm disso, o entendimento sobre qualidade interna de sistemas j era um
conceito compreendido. A organizao fazia uso de ferramentas de anlise esttica de
cdigo como PMD (2010) e CheckStyle (2010) com regras j adaptadas arquitetura de
referncia e tambm praticava inspeo de cdigo por meio do grupo de controle da
qualidade. Testes de unidade, mesmo que aps a implementao, j haviam sido
experimentados em projetos recentes de desenvolvimento. Seus desafios iniciais j
haviam sido superados e a organizao j estava convencida dos seus benefcios.
4.2. Planejamento e execuo da implantao
Em 2007 foi a primeira vez que mtodos geis foram discutidos em mbito
organizacional. Porm, a idia apenas ganhou fora um ano depois, quando um grupo de
trabalho foi montado para planejar as etapas da implantao. O grupo foi formado por
pessoas que defendiam a adoo de mtodos geis e pessoas responsveis pela
manuteno dos processos de desenvolvimento corporativo da organizao. O
planejamento e a execuo foram cuidadosos e seguiram algumas das melhores prticas
sugeridas por Griffiths (2003), como a obteno de apoio gerencial, a escolha do mtodo
e das prticas, a realizao de pilotos, alm de educao e suporte ao time.
O apoio da chefia do departamento foi obtido no incio do planejamento. Foi
decidido que os primeiros projetos adotariam todas as prticas das metodologias XP e

116

Scrum para fins de aprendizado. Alm disso, como j mencionado, a organizao j

tinha uma infraestrutura tecnolgica adequada disponvel e se sentia preparada para
iniciar novas experincias.
Foram planejados dois pilotos iniciais. Tambm foram discutidas as
caractersticas dos sistemas a serem construdos nos pilotos e dos times de
desenvolvimento alocados. Antes do incio dos pilotos, as pessoas envolvidas buscaram
estudar XP e Scrum. Ainda dentro do planejamento de implantao, o trabalho de
preparao do time de desenvolvimento no durou mais do que uma semana. Foram
repassados conceitos, valores e princpios geis para um nivelamento inicial. A partir
da, todo o aprendizado tcnico e do mtodo aconteceria na prtica, orientado por
pessoas mais experientes da prpria organizao. A contratao de um treinamento
externo de prticas de XP foi previsto para o primeiro projeto piloto e aconteceria
quando a maturidade adquirida pelo time j favorecesse um melhor aproveitamento.
De acordo com o planejado, o 1 projeto piloto foi iniciado em outubro de 2008,
com durao prevista de 6 meses. O treinamento externo aconteceu aps 3 meses do
inicio do projeto e, como esperado, surgiu um efeito muito positivo. Em seguida foi
preparado o 2 projeto piloto, nos mesmos moldes anteriores, e planejado para 10 meses.
Como os resultados observados aps o 1 projeto piloto haviam sido
satisfatrios, o plano de implantao de mtodos geis foi estendido com um novo ciclo
de desenvolvimento do 1 projeto piloto e planejado a subcontratao da evoluo do
sistema em uma fbrica de software como mostra a Figura 1. Todo processo de
implantao foi acompanho pela equipe de qualidade e processos de desenvolvimento
organizacional que, ao fim do 2 projeto piloto, montou um planejamento para
institucionalizao dos mtodos em toda a organizao.

Figura 1 Implantao de mtodos geis na organizao

4.3. Projetos pilotos

Para os projetos pilotos foram escolhidos sistemas que no eram crticos sob o ponto de
vista de negcio e nem possuam restries de prazo severas. Estas escolhas visavam
minimizar os riscos que a experimentao de novos mtodos poderia trazer para o
negcio da organizao.
Os projetos pilotos foram organizados em ciclos, releases e iteraes, de acordo
com as recomendaes de Scrum e XP. Os ciclos representavam marcos formais com a
entrega de uma verso completa do sistema para uso em produo. Releases
117

representavam marcos intermedirios com entrega de funcionalidades para fins de

homologao ou, eventualmente, de produo. As iteraes representavam pequenos
marcos de planejamento e controle do desenvolvimento. Funcionalidades da aplicao
eram colocadas para validao pelos clientes ao final das iteraes. A Tabela 1
caracteriza os projetos piloto executados. Vale ressaltar que houve troca de membros
nos projetos, por esse motivo o nmero de Tamanho mdio do time no equivale ao
nmero total de participantes de cada projeto (e de respondentes aos questionrios).
Nenhum participante do Projeto 1 trabalhou no Projeto 2 e vice-versa.
Tabela 1 - Informaes gerais sobre os projetos pilotos
Caractersticas
Tamanho (mdio) do time
Durao do projeto
Domnio
Time coalocado
Tamanho da iterao
Nmero de entregas (em
homologao)
Nmero de entregas (em
produo)
Prticas adotadas

Projeto 1
7 (6 desenvolvedores e 1
gerente)
1 ano e 2 meses
Clculo de dvidas de
contratos
Time e cliente na mesma
sala
1 ao 4 ms: 2 semanas
5 ms em diante: 1 semana
10

Projeto 2
6 (5 desenvolvedores e 1
coach com papel gerencial)
10 meses
Controle
de
aes
educacionais
Time e cliente separados por
1 andar.
1 semana

Todas de XP e Scrum

Todas de XP e Scrum

As equipes eram compostas essencialmente por pessoas com perfil de

desenvolvedor, como mostra a Tabela 2, mas 50% delas vinham exercendo atividades
de analista de requisitos, analista de qualidade, gerentes de projetos e testadores antes da
experincia gil.
Tabela 2 - Perfis dos membros dos projetos pilotos
Perfis do projeto
Desenvolvedor
Gerente
Especialista em testes
Projetista
Analista de requisitos
Analista de qualidade
Total

Time do Projeto 1
4
2
0
3
0
1
10

Time do Projeto 2
6
0
2
0
1
1
10

A experincia tcnica dos membros da equipe tambm era bem heterognea

como mostra a Tabela 3. 40% do time possuam menos de dois anos de experincia com
desenvolvimento de software orientado a objetos, 10% sequer j havia trabalhado com
desenvolvimento OO. 90% do time conheciam pouco ou quase nada da recente
arquitetura de referncia da organizao, seja pela alta especializao dos papis j
mencionada, seja pelo pouco tempo de trabalho na instituio. Com relao aos mtodos
geis, no mais de 15% das pessoas possuam experincia profissional com alguma
prtica gil. Durante o acompanhamento dos pilotos foi possvel observar que algumas

118

pessoas possuam conhecimento terico do assunto e outras sequer sabiam os desafios

trazidos pelo novo paradigma de desenvolvimento.
Tabela 3- Experincia das equipes antes dos pilotos
Tempo

Desenvolvimento
de software

Orientao a
objetos

Arquitetura
de referncia

Na
instituio

Mtodos
geis

10%

10%

60%

0%

85%

De 1 a 6 meses

5%

0%

30%

35%

5%

7 meses a 2
anos

25%

30%

5%

25%

10%

De 2 a 5 anos

30%

35%

5%

15%

0%

De 6 a 9 anos

25%

15%

0%

25%

0%

10 ou + anos

5%

10%

0%

0%

0%

Total

100%

100%

100%

100%

100%

5. Primeiros efeitos da adoo

5.1 Efeitos sobre o aprendizado
Para analisar o ganho em aprendizado, primeiro foi levantado o nvel de
facilidade/dificuldade em aprender as prticas geis, particularmente as de XP mais
visveis ao corpo tcnico. Segundo a percepo da equipe tcnica, as prticas de pares e
de equipe so facilmente compreensveis e aplicveis como pode ser observado pela
Figura 2. Dentre as prticas de pares, exceto a programao em pares, que foi a mais
facilmente absorvida pela equipe, as demais apresentaram em mdia o mesmo grau de
dificuldade. Dentre as prticas de equipe, apenas a Metfora apresentou alguma
dificuldade de compreenso e aplicao.

Figura 2 - Aprendizado de Prticas de pares e equipe

O aprendizado das prticas organizacionais foi avaliado segundo as perspectivas

da equipe tcnica e dos clientes como pode ser observado na Figura 3. A equipe tcnica
sentiu mais dificuldades na aplicao da prtica Time completo. Em ambas as

119

perspectivas, a aplicao da prtica de Testes do cliente apresentou certa dificuldade.

As anlises qualitativas tambm indicaram dificuldades maiores na adoo das prticas
de testes em relao s demais. Os principais pontos destacados esto relacionados
tcnica de testes de unidade, legibilidade e manutenibilidade dos testes dos clientes. Em
ambos os projetos pilotos, a introduo da prtica de testes dos clientes foi implantada
aps certo tempo de projeto (cerca de 4 meses), quando a equipe se sentiu madura o
suficiente para compreender e aplicar tal prtica.
Quanto ao emprego da prtica de Releases curtas, embora facilmente
compreendida, no apresentou a mesma facilidade na sua aplicao. Ambos os projetos
pilotos relataram ter enfrentado dificuldades em convencer os clientes a realizar
publicaes parciais do sistema em produo. Percebeu-se que a organizao no estava
acostumada a receber solues ainda no completamente finalizadas, mesmo que
agregassem valor ao negcio. Alm disso, em funo da cultura de desenvolvimento de
sistemas existente na organizao, ambos os projetos relataram dificuldades em realizar
um projeto simples que no tivesse a inteno de antecipar mudanas futuras.

Figura 3 - Aprendizado de prticas organizacionais

Em uma escala de 1 (Definitivamente no) a 5 (Definitivamente sim), a Tabela 4

mostra a percepo do time e dos clientes sobre a Questo de Pesquisa 1 (QP1). As
entrevistas e respostas abertas do questionrio confirmaram a opinio das pessoas sobre
a facilidade de aprender mtodos geis e a rapidez em acumular novos conhecimentos.
Tabela 4 - Percepes sobre o aprendizado do time
Percepo
(mdia / desvio padro)
QP1. Acelera o aprendizado
de novas tecnologias,
conceitos e padres

Percepo
tcnica

% de respostas
entre a escala 4 e 5

4,45 / 0,69

90%

Percepo dos % de respostas

clientes
entre a escala 4 e 5
5/0

100%

Esses resultados confirmam os achados de Loftus e Ratcliffe (2005). No houve

evidncia de que o aprendizado foi prejudicado em funo do pensamento de grupo,
conforme mencionado por (McAvoy e Butler 2007).

120

5.2. Efeitos da implantao sobre a qualidade do cdigo

A qualidade do cdigo de um sistema pode ser avaliada por diversas mtricas. Das
mtricas usadas na instituio, trs foram selecionadas para efeitos de comparao entre
os sistemas desenvolvidos com o processo tradicional e os pilotos geis. O critrio de
seleo foi unicamente baseado na disponibilidade e facilidade de acesso aos dados pelos
pesquisadores. As mtricas escolhidas foram 1) Porcentagem de aderncia s regras de
anlise esttica (implementadas pelas ferramentas j mencionadas PMD e Checkstyle), 2)
Porcentagem de cobertura de cdigo e 3) Porcentagem de testes de unidade executados
com sucesso. Dezesseis projetos tradicionais, feitos com a mesma tecnologia dos projetos
piloto, foram usados para o clculo da mdia e desvio padro de projetos tradicionais. A
Tabela 5 apresenta, para cada mtrica selecionada, a mdia e desvio padro obtidos nos
projetos tradicionais (QualidadeTRAD) e a qualidade obtida nos pilotos geis (QualidadeAGIL).
Tabela 5 Comparaes de qualidade do cdigo
Atributos de qualidade

QualidadeTRAD QualidadeAGIL
(mdia/desvio) Projeto 1

QualidadeAGIL
Projeto 2

Aderncia s regras de anlise

esttica (PMD/ CheckStyle)

98,8%/0,03

100%

99,8%

Cobertura de cdigo

78,25%/0,25

93,4%

92,8%

Testes de unidade executados

com sucesso

98,10%/0,06

100%

100%

Os nmeros mdios de qualidade dos projetos tradicionais confirmam que a

preocupao com qualidade de cdigo e o uso de testes de unidade j estavam presentes
na instituio. Dentre as mtricas de qualidade analisadas, a mtrica de cobertura de
cdigo foi a que apresentou um aumento significativo, aproximadamente 19% de
aumento da cobertura.
Mais importante do que a cobertura de cdigo por testes de unidade a qualidade
dos testes escritos pelos clientes e equipe de desenvolvimento. Como no escopo deste
trabalho medir a qualidade dos testes de forma quantitativa e objetiva, foi considerada a
percepo tcnica do time. A Tabela 6 mostra, em uma escala de 1 (Definitivamente
diminuem) a 5 (Definitivamente aumenta), a percepo da equipe tcnica sobre a
Questo de Pesquisa 2 (QP2). Os resultados foram mais otimistas que os descritos por
Ambler (2008), em que 77% das respostas ficarem entre a escala 4 e 5.
Tabela 6 - Percepes sobre a qualidade do cdigo-fonte do sistema
Percepo
tcnica

Percepo (mdia / desvio padro)

QP2. Aumentam a qualidade do cdigo do sistema

4,6 / 0,60

% de respostas
entre a escala 4 e 5
95%

5.3 Efeitos da implantao sobre a produtividade

A mtrica de produtividade usada na organizao a razo entre tamanho do sistema em
pontos de funo e a quantidade de horas gastas no projeto. Essa medio em geral
realizada ao final do projeto ou em algum marco especificado pela gerncia. Uma
equipe especializada em contagem de pontos de funo realiza a medio do tamanho
do projeto e as horas so apontadas por toda a equipe em um sistema corporativo. A
Tabela 7 apresenta o ganho de produtividade dos pilotos geis (GanhoAGIL) em relao
121

produtividade mdia dos projetos tradicionais da organizao2. No piloto 1, houve um

ganho de produtividade de 8,21%. J no piloto 2 foi constatado um ganho de
produtividade de 30,89% em relao mdia da organizao. O Projeto 1 era mais
complexo (envolvia diversos clculos com alta preciso) do que o Projeto 2. Alm
disso, foi o primeiro piloto de geis, o que sugere uma curva maior de aprendizado e
adaptao. O projeto 2 pde aprender com os erros do projeto 1. Por fim, a
produtividade obtida pelo projeto 2 foi considerada satisfatria, entretanto a organizao
acredita que o ganho pode ser aumentado.
Tabela 7 - Comparaes de produtividade
GanhoAGIL Projeto 1 (%)

GanhoAGIL Projeto 2 (%)

8,21%

30,89%

Em uma escala de 1 (Definitivamente diminuem) a 5 (Definitivamente aumenta)

a Tabela 8 apresenta a mdia e o desvio padro da opinio do time e do cliente sobre
Questo de Pesquisa 3 (QP3). Para a equipe tcnica, em mdia a produtividade aumenta,
sendo que 90% dos participantes acreditam que ela aumenta ou definitivamente aumenta.
Os resultados foram prximos aos descritos por Ambler (2008), onde 82% das respostas
ficaram entre 4 e 5. Todos os clientes acreditam que a produtividade aumenta muito.
Tabela 8 - Percepes sobre a produtividade do time
Percepo
(mdia / desvio padro)
QP3. Aumentam a
produtividade do time

Percepo
tcnica

% de respostas entre
a escala 4 e 5

Percepo
dos clientes

% de respostas
entre a escala 4 e 5

4,35 / 0,67

90%

5/0

100%

A anlise qualitativa confirma essa percepo do time e do cliente sobre o

aumento da produtividade. Em entrevistas realizadas com alguns membros ao final do
projeto, sempre que questionados sobre a percepo de aumento da produtividade, os
entrevistados afirmavam que houve um aumento. No entanto, a produtividade no foi
um tema muito comentado nos questionrios online, principalmente pela equipe tcnica,
ao contrrio da qualidade e da satisfao do cliente. Isso leva concluso de que o
aumento da produtividade no to perceptvel para os participantes quanto os demais
ganhos. Isso tambm pode ser observado na mdia da percepo tcnica apresentada na
Tabela 9, a menor dentre as mdias de aprendizado, qualidade e satisfao do cliente.
5.4 Efeitos sobre a satisfao do cliente
Os clientes de ambos os projetos pilotos j haviam participado em projetos anteriores de
desenvolvimento de software e puderam ento fazer um comparativo da experincia gil
e experincias anteriores. A Tabela 9 apresenta a anlise quantitativa das opinies do
time e do cliente sobre a Questo de Pesquisa 4 (QP4). 90% dos respondentes acham que
o uso de mtodos geis aumenta ou aumenta muito a satisfao do cliente. Os resultados
foram mais otimistas que os descritos por Ambler (2008), onde 78% das respostas
ficarem entre 4 e 5. Os clientes avaliaram, em unanimidade, que sua satisfao aumentou
muito.
2

os dados reais no foram divulgados por serem usados em negociao contratual entre a instituio e
seus subcontratados.

122

A satisfao tambm pde ser observada durante o desenrolar dos projetos

pilotos, medida que os clientes foram incorporando as prticas geis s suas rotinas de
trabalho dirio. Alm disso, a satisfao foi avaliada pelo questionrio online e por
entrevistas. Dentre os benefcios destacados pelos clientes, os principais foram: 1)
reduo significativa do prazo de entrega do sistema; 2) possibilidade de alterao do
escopo ao longo do desenvolvimento e assim obter um software mais aderente s
necessidades do negcio; 3) aumento do entendimento sobre os custos de
implementao de uma funcionalidade, conscientizando o cliente sobre a importncia da
priorizao das demandas e 4) Maior segurana com relao qualidade dos sistemas
por possurem testes automatizados, escritos e revisados por eles.
Tabela 9 - Percepes sobre satisfao dos clientes
Percepo
(mdia / desvio
padro)
QP4. Aumentam a
satisfao do cliente

Percepo
tcnica

4,5 / 0,69

% de respostas
entre a escala 4 e
5
90%

Percepo dos
clientes

5/0

% de respostas
entre a escala 4
e5
100%

5. Discusso
A implantao de mtodos geis em uma organizao um processo lento e complexo.
Em organizaes pblicas, onde os processos burocrticos prezam pelo maior controle,
em detrimento dos resultados mais rpidos, particularmente mais complicado. A
simples realizao de alguns projetos pilotos no suficiente para tornar as prticas,
valores e princpios geis de fato implantados.
Este estudo de caso permitiu observar que as principais dificuldades enfrentadas
na implantao de mtodos geis no esto relacionadas ao aprendizado das prticas
geis e sim com a necessidade de mudana da cultura organizacional. Enquanto apenas
o projeto de desenvolvimento de software pensar e agir de forma gil e o restante da
organizao mantiver os vcios e culturas derivadas dos processos tradicionais no ser
possvel usufruir realmente dos benefcios geis.
O fato da instituio j ter um ambiente tecnolgico favorvel permitiu a rpida
adoo e o aprendizado de prticas como Integrao contnua, Releases curtas, Projetos
Simples, Cdigo padronizado, Cdigo coletivo e TDD. Isso contribuiu para os
resultados positivos observados na Questo de pesquisa 1. Alm disso, a obteno de
patrocnio gerencial, a escolha adequada de projetos pilotos e a preparao do time e da
infraestrutura tecnolgica foram destacados pelos participantes como pontos muito
importantes na adoo de mtodos geis.
Os primeiros resultados obtidos aps 18 meses de implantao de mtodos geis
motivaram a organizao a explorar novas possibilidades de trabalho com fbricas de
software. O primeiro projeto piloto foi subcontratado como manuteno evolutiva em
uma fbrica em outro estado. Segundo relatos dos clientes, os testes de aceitao e
documentao do cdigo fonte foram suficientes para que a fbrica pudesse
compreender o sistema e o processo de negocio. A equipe tcnica destacou ainda que o
projeto simples, os testes automatizados e o cdigo padronizado foram prticas que
favoreceram a subcontratao da evoluo do software de forma mais eficiente que a
tradicional documentao do sistema.

123

As limitaes dos resultados obtidos neste estudo so relacionadas aos mtodos

de coleta de dados e preciso do dado em si. Segundo Sue e Ritter (2007), a conduo
de questionrios online pode levantar informaes incompletas e estimular opinies que
s foram geradas, porque foram solicitadas, no pelo fato do participante ter certa
opinio. Alm disso, o nmero de projetos (dois) e de participantes (20) representa
apenas uma pequena amostra da instituio. As mdias de qualidade e produtividade
tradicionais representam todo o universo de sistemas e profissionais da empresa e no
so necessariamente um critrio de comparao justo com os pilotos. Por isso, para
aumentar a validade interna do estudo, foram usados dados qualitativos que permitem a
confirmao dos resultados quantitativos. Alm disso, resultados de outros estudos
foram citados para permitir mais uma anlise dos resultados deste estudo de caso.

6. Concluso
Os mtodos geis para desenvolvimento de software so uma alternativa ao
desenvolvimento tradicional, dirigido por planos. Para adotar mtodos geis em uma
organizao, so necessrios diversos passos de planejamento e uma execuo
cuidadosa. Neste artigo foram apresentados os resultados empricos obtidos no estudo
de caso de adoo de mtodos geis em uma instituio pblica brasileira de grande
porte. Os resultados mostraram que a adoo teve um efeito positivo no aprendizado de
novas tecnologias e na satisfao dos clientes e um discreto aumento na qualidade do
cdigo e na produtividade dos times estudados. O trabalho gera uma contribuio tanto
para as empresas (pblicas e privadas) que desejam adotar mtodos geis, quanto para a
academia, pois relata e analisa os resultados empricos observados no estudo de caso.
Alm dos benefcios percebidos nos dois projetos pilotos sob estudo, a adoo de
mtodos geis pode vir a ser uma opo de aumento de escala de produo em
organizaes pblicas frente contratao de fbricas de software. A adoo de
mtodos geis, alm de reduz os prazos de entregas, reduz tambm os problemas de
comunicao e a necessidade de negociaes contratuais com empresas subcontratadas.
Como trabalho futuro, pretende-se investigar o impacto da subcontratao de
manutenes evolutivas de sistemas desenvolvidos com mtodos geis.

Agradecimentos
As autoras agradecem o apoio financeiro recebido da Fapesp (processo 09/10338-3) e ao
Banco Central do Brasil3 pela autorizao e colaborao na conduo do estudo de caso.

Referncias
Ambler, S. (2006) Agile
agileMarch2006.html.

adoption

rate

survey.

http://www.ambysoft.com/surveys/

Ambler, S. (2008) Agile

agileFebruary2008.html.

adoption

rate

survey.

http://www.ambysoft.com/surveys/

Beck, K. (2000) Extreme Programming Explained - Embrace Change. Addison-Wesley.

Chekstyle (2010). Disponvel em: http://checkstyle.sourceforge.net/. Abril de 2010.
Dyb, T e Dingsyr, T. (2008) Empirical studies of agile software development: A systematic
review. In: Information and Software Technology, 50(9-10):833859.
3

As opinies aqui expressas no necessariamente espelham o pensamento do Banco Central do Brasil.

124

Dyb, T. (2000) Improvisation in small software organizations. In: IEEE Software, 17(5):8287.
Freire, A., Kon, F. e Torteli, C. (2005) XP south of the equator: An experience implementing XP in
Brazil. In Proceedings of the 6th International Conference on Extreme Programming and Agile
Processes in Software Engineering (XP2005), p. 1018. Springer.
Griffiths, M. (2003) Crossing the Agile Chasm: DSDM as an Enterprise Friendly Wrapper for
Agile
Development,
Quadrus
Development
White
Paper,
www.dsdm.org/knowledgebase/download/91/crossing_the_agile_chasm.pdf
Hibernate (2010) Relational persistence for Java. Disponvel em http://www.hibernate.org/.
HSQLDB (2010). HyperSol data base. Disponvel em http://hsqldb.org/. Abril de 2010.
Hudson (2010). Hudson CI. Disponvel em: http://hudson-ci.org/. Abril de 2010.
Ilieva, S., Ivanov, P., and Stefanova, E. (2004). Analyses of an Agile Methodology Implementation.
In Proceedings of the 30th EUROMICRO Conference. IEEE, Washington, DC, 326-333.
Jeffries, R. (2001) "What is XP?", http://xprogramming.com/xpmag/whatisXP. Novembro.
Jetty (2010). Jetty WebServices. Disponvel em: http://jetty.codehaus.org/jetty/.
Kent Beck et al. (2001) Manifesto for agile software development. http://agilemanifesto.org/.
Kruchten, P. (2000) The Rational Unified Process - An Introduction. Addison Wesley.
Loftus, C. and Ratcliffe, M. (2005) Extreme programming promotes extreme learning?. In:
SIGCSE Bull. 37, 3 (September), p.311-315.
Maven (2010). Disponvel em: http://maven.apache.org/. Abril de 2010.
Nerur, S., Mahapatra, R. e Mangalaraj, G. (2005) Challenges of migrating to agile methodologies.
In: Communications of the ACM, 48(5):7278.
Paisittanand, S. e Olson, D. L. (2006) A simulation study of IT outsourcing in the credit card
business, In: European Journal of Operational Research, v. 175, Issue 2, p.1248-1261.
Parsons, D., Ryu, H. e Lal, R. (2007) The impact of methods and techniques on outcomes from
agile software development projects. In: Organizational Dynamics of Technology-Based
Innovation: Diversifying the Research Agenda, v.235 of IFIP, p. 235249. Springer Boston.
PMD (2010). Disponvel em: http://pmd.sourceforge.net/. Abril de 2010.
Schwaber, K. (2004) Agile Project Management with Scrum, Microsoft Press, 163pp.
Seaman, C. B. (1999) Qualitative Methods in Empirical Studies of Software Engineering, In:
IEEE Trans. Softw. Eng. 25, 4, 557-572.
Spring (2010) Disponvel em http://www.springsource.org/ Abril de 2010.
Sue, V. M. e Ritter, L. A. (2007). Conducting online surveys. Thousand Oaks, CA: Sage.
Svensson, H. e Hst, M. (2005) Views from an organization on how agile development affects its
collaboration with a software development team, In: Lecture Notes in Computer Science, vol.
3547, Springer Verlag, Berlin, p. 487501.
VersionOne
(2009).
State
of
Agile
Development
4th
annual
survey.
http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf
Wicket (2010). Apache Wicket. Disponvel em http://wicket.apache.org/. Abril de 2010.
Yin, R. K. (2009) Case Study Research: Design and Methods. 4 ed. Thousand Oaks, CA: Sage.
Zelkowitz, M.V. e Wallace, D. (1998) Experimental models for validating Technology. IEEE
Computer, 31(5): 23-31.

125

Estudo de Caso da Utilizao de Scr um no

Desenvolvimento Distr ibudo de Softwar e
Vir gnia C. Chalegr e, Wylliams B. Santos, Leandr o O. de Souza, Her nan J .
Muoz, Silvio Romer o de Lemos Meir a
1

Centro de Informtica Universidade Federal de Pernambuco (UFPE)

Caixa Postal 7851, Cidade Universitria 50.732-970 Recife PE Brasil
{vcc, wbs, los2, hjm, srlm}@cin.ufpe.br

Abstract. The use of agile software development has grown recently by the
benefits brought with incremental deliveries of the product which add value to
the customer's business, more interaction among the customer and team
members and therefore greater customer satisfaction. Another widely used
form of development is the distributed development, aiming to reduce the
delivery time and costs. When used jointly, agile methods can help alleviate
some of the problems of distributed teams such as the lack of management and
communication. Thus, this paper describes the experiences in adopting the two
forms development jointly with the aim of raising the problems and report
possible solutions that have been taken and can be applied in other distributed
teams.
Keywords: Agile Methodologies, Scrum, FireScrum, Distributed development
Resumo. O uso de metodologias geis de desenvolvimento de software vem
crescendo nos ltimos tempos graas aos benefcios trazidos com entregas
incrementais do produto que agregam valor ao negcio do cliente, maior
interao com o cliente e os membros da equipe e consequentemente maior
satisfao do cliente. Outra forma de desenvolvimento muito utilizado o
desenvolvimento distribudo, com o objetivo de reduzir o tempo de entrega e
os custos. Quando utilizadas de forma conjunta, as metodologias geis podem
ajudar a amenizar alguns dos problemas de equipes distribudas como a falta
de gerenciamento e comunicao. Desse modo, este trabalho descreve as
experincias ao adotar as duas formas de desenvolvimento em conjunto, com
o objetivo de levantar os problemas enfrentados e relatar possveis solues
que foram tomadas e podem ser aplicadas por outras equipes distribudas.
Palavras-chave: Metodologias geis, Scrum, FireScrum, Desenvolvimento
Distribudo

1. Intr oduo
Diante do cenrio em que condies de mercado e necessidades dos usurios mudam
constantemente, surgiram os mtodos geis de desenvolvimento de software, com a
proposta de tornar as equipes mais dinmicas e o desenvolvimento mais rpido. Uma
dessas abordagens a metodologia Scrum, que enfatiza o uso de um conjunto de

126

padres, permitindo que o time se envolva, participando ativamente do processo de

desenvolvimento de software e que haja uma comunicao intensa entre as pessoas.
Outra grande tendncia do mercado de software o desenvolvimento distribudo
caracterizado pela construo de software por equipes dispersas geograficamente. Essa
configurao de desenvolvimento traz algumas vantagens competitivas, buscando
solues globais, como a reduo do tempo de entrega do projeto, atravs de times
paralelos trabalhando alm das limitaes de fuso-horrio [Herbsleb 2001]. O baixo
custo de manter uma estrutura fsica para comportar muitas pessoas e a carncia de
pessoas qualificadas numa mesma localidade so outras vantagens descritas do
desenvolvimento distribudo de software [Sutherland 2008]. Entretanto, para que esse
ambiente seja realmente produtivo, esforos adicionais na gesto do projeto so
necessrios para acompanhar o trabalho dos times, sendo importante dar nfase
comunicao e interao entre os membros da equipe, j que segundo Sutherland
[Sutherland 2008] esse um ponto crucial em projetos com times distribudos.
A utilizao de metodologias geis como o Scrum tem sido uma forma adotada
por muitas empresas para contornar os problemas enfrentados por times distribudos,
uma vez que as metodologias geis focam numa maior comunicao entre os membros
da equipe e com o prprio cliente [Sutherland 2008]. Entretanto a prpria utilizao de
mtodos geis de forma distribuda pode ser vista como um problema, j que todas as
formas de comunicao proposta devem ocorrer face a face e no de forma distribuda,
com o objetivo de criar um senso de equipe e prover a autoconfiana e liderana dos
membros.
Atualmente existem ferramentas que visam auxiliar as empresas no
gerenciamento de projetos geis, dentre elas vale ressaltar o FireScrum, ferramenta
open source desenvolvida inicialmente durante o programa de Mestrado de Engenharia
de Software do CESAR.EDU. Aps o desenvolvimento inicial, surgiu a necessidade de
adicionar novos mdulos e funcionalidades importantes com o objetivo de dar mais
apoio a equipes distribudas.
Um dos mdulos acrescentado foi o Planning Poker. A implementao desse
mdulo foi realizada por uma equipe distribuda que aplicou a prpria metodologia
Scrum em todo seu desenvolvimento. Sua implementao desse mdulo
contextualizada na Seo 5, que se refere ao estudo de caso.
Baseado nesse estudo de caso, esse trabalho tem como objetivo apresentar os
problemas encontrados durante o desenvolvimento, como esses problemas foram
resolvidos e como as solues encontradas podem ser adotadas por outras equipes
distribudas. Assim como, fazer um paralelo entre as prticas do uso Scrum em equipes
no mesmo espao fsico e os problemas dessas prticas quando aplicado o Scrum de
forma distribuda.
Este trabalho est organizado da seguinte maneira: a Seo 2 apresenta detalhes
sobre Desenvolvimento Distribudo de Software; a Seo 3 descreve uma viso geral do
Scrum; a Seo 4 apresenta a o projeto de desenvolvimento da ferramenta FireScrum e
suas caractersticas; na Seo 5 apresentado o estudo de caso desse artigo, o processo
de desenvolvimento do mdulo Planning Poker do FireScrum; na Seo 6 so
apresentadas os problemas encontrados e as solues adotadas, e por fim na Seo 7 as
consideraes finais referentes ao estudo de caso.
127

2. Desenvolvimento Distr ibudo de Softwar e

O Desenvolvimento Distribudo de Software (DDS) surgiu como uma alternativa para
solucionar o problema da falta de mo-de-obra especializada das empresas. Como
afirma Karolak [Karolak 1998], a demanda por aplicaes cresce exponencialmente e a
oferta de profissionais no tem sido suficiente para suprir a necessidade de tantos
projetos.
O DDS busca acelerar o desenvolvimento e com isso reduzir o tempo de entrega,
trazendo assim, uma maior satisfao para o cliente. Essa reduo do tempo de
desenvolvimento pode ser obtida atravs de equipes trabalhando em paralelo, assim
como equipes trabalhando alm do fuso-horrio. Alm disso, as empresas podem
formar parcerias com o objetivo de explorar mercados maiores, alm da facilidade em
selecionar profissionais com competncias especficas em qualquer espao geogrfico
[Herbsleb 2001].
Mas, para que esse ambiente seja realmente produtivo, esforos adicionais na
gesto do projeto so necessrios para sincronizar o trabalho dos times, fazendo uso de
tecnologias de comunicao e informao para gerenciar interdependncias. O uso de
sistemas de controle de verso, o uso compartilhado de ferramentas de comunicao e a
integrao dos resultados gerados so grandes desafios. Alm disso, a intercomunicao
cultural e lingustica pode ser um dos grandes entraves na comunicao dos times
distribudos [Sutherland 2008].

3. Viso Ger al do Scr um

O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland e destaca-se dos
demais mtodos geis pela maior nfase dada ao gerenciamento do projeto. Rene
atividades de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a
equipe, visando identificao e correo de quaisquer deficincias e/ou impedimentos
no processo de desenvolvimento [Schwaber 2004].
O Scrum uma metodologia cujas prticas so aplicadas em um processo
iterativo e incremental. Assume-se que os projetos no qual o Scrum se insere so
complexos e difceis de prever tudo que ir acontecer. Por essa razo, ele oferece um
conjunto de prticas que torna tudo isso visvel [Schwaber 2004]. Atualmente, uma
das metodologias mais utilizadas pela sua estrutura simples, de fcil aprendizado, com
papis claramente definidos [Schwaber 2004].
Na Figura 1, notamos que o Scrum inicia-se com uma viso do produto que ser
desenvolvido, contendo as caractersticas definidas pelo cliente, premissas e restries.
Em seguida, o Product Backlog criado contendo a lista de todos os requisitos
conhecidos. O Product Backlog ento priorizado e dividido em releases. Cada release
contm um conjunto de requisitos, denominado Sprint Backlog, que ser desenvolvido
em uma iterao, denominada de Sprint [Maral et al 2007]. Na execuo da Sprint,
diariamente a equipe faz reunies de 15 minutos (Daily Scrum Meeting) para
acompanhar o andamento do projeto. Ao final da Sprint, realizada uma reunio (Sprint
Review Meeting) de modo que o time apresente o resultado alcanado ao representante
do cliente (Product Owner ). Em seguida, o responsvel por resolver os impedimentos
do time (Scrum Master ) conduz a reunio de lies aprendidas (Sprint Retrospective

128

Meeting) com o objetivo de que a equipe proponha melhorias de processo e/ou produto
para a prxima Sprint [Maral et al 2007].
Como em outras metodologias geis, o Scrum se fundamenta na interao
constante e eficiente dos membros de um time. Por outro lado, com o crescimento
contnuo do desenvolvimento de software por equipes remotas , fortemente visvel
desde a ltima dcada [Damian & Moitra 2006], torna-se essencial o uso de
ferramentas de apoio que minimizem os impedimentos gerados na aplicao do Scrum
como metodologia de desenvolvimento em equipes distribudas. Assim, embora
recomendada pela ScrumAlliance (www.scrumalliance.com), o uso de ferramentas de
gerenciamento tradicional de projetos pode resultar no comprometimento de algum
princpios do Scrum, como o apelo visual e simplista defendido pela metodologia, o
uso de artefatos no automatizados como cartes e murais, podem representar um
desafio adoo da metodologia por equipes remotas [Cavalcanti 2009]. Neste
contexto uma boa iniciativa pode ser o desenvolvimento de ferramentas de apoio
ao Scrum em equipes distribudas [Cristal 2008].

Figura 1: Viso geral do processo do Scrum (adaptada de [Gloger 2007])

4. O Pr ojeto Fir eScr um

O FireScrum uma ferramenta open source e foi desenvolvida para dar suporte ao
gerenciamento de times Scrums distribudos, evitando a perda de histrico das
atividades, propiciando o levantamento de mtricas sem demandar esforo excessivo do
time e principalmente, facilitando sua adoo sem burocratizar o processo. O aplicativo
utiliza a tecnologia RIA (Rich Internet Application) e tem como princpios: interfaces
focadas em usabilidade e praticidade.
A ideia do FireScrum surgiu a partir de pesquisas realizadas como
fundamentao para uma dissertao de mestrado de Engenharia de Software do
CESAR.EDU, motivada pelas lacunas existentes em ferramentas similares de apoio a
metodologia Scrum [Cavalcanti 2009]. A ferramenta agora um produto INES
(Instituto Nacional de Cincias e Tecnologia para Engenharia de Software) disponvel
no Sourceforge [SourceForge 2010].
129

Durante o desenvolvimento da dissertao, as funcionalidades foram

implementadas por 60 ps-graduandos da disciplina de Engenharia de Software [IN953,
2009] do programa de ps-graduao do Centro de Informtica (CIn) da Universidade
Federal de Pernambuco (UFPE), a partir da qual foram desenvolvidos cinco novos
mdulos, totalizando seis com o j criado mdulo core, como ilustrado na Figura 2.
Durante o desenvolvimento do projeto os 60 integrantes da disciplina foram
distribudos em seis times responsveis, cada um, por um mdulo do sistema, onde cada
time funcionava como um fbrica de desenvolvimento independente com um Scrum
Master cada. Os Scrum Masters de cada time de desenvolvimento se reuniam para
reunies entre Scrums Masters. A proposta da disciplina foi simular um ambiente
prximo da realidade da indstria de software, proporcionando aos alunos o exerccio
da engenharia de software (Conceitos, Mtodos, Prticas e Ferramentas), permitindo
aos estudantes adquirirem uma experincia prtica de vivencia de problemas e
imprevistos que acontecem em uma fabrica de software e que precisam ser resolvidos.

Mdulos Fir eScr um

Core

Planning

TaskBoard

Bug
Tracking

Poker

Desktop

Test

Agent

Module

Figura 2: Mdulos queFigura

compem
2 o FireScrum

5. Estudo de Caso Mdulo Planning Poker

A fbrica composta por nove alunos do Mestrado ficou incumbida de desenvolver o
mdulo Planning Poker da ferramenta FireScrum, utilizando a metodologia Scrum, de
forma distribuda, j que os integrantes estavam dispersos entre quatro cidades
diferentes. Essa abordagem possibilitou identificar problemas e propor solues que
foram integradas ferramenta, o que possibilita melhor suporte ao Scrum em ambiente
distribudo.
O processo utilizado foi: A cada incio de Sprint, eram acordadas, com o
Product Owner , as estrias que seriam desenvolvidas, assim como suas priorizaes, a
partir da, eram feitas reunies de definio de funcionalidades, arquitetura e atividades
necessrias para a implementao. Essas atividades ficavam disponveis em uma
planilha compartilhada via web, com a informao do responsvel, status e tempo
estimado, fazendo com que todos pudessem analisar e atualizar o andamento das suas
atividades. Ao trmino de cada Sprint, reunies de Sprint Review e Retrospective eram
realizadas, para que fossem identificados os erros e acertos, assim como os pontos de
melhoria para o prximo sprint. Uma vez por semana, era feita a reunio Scrum de
Scrums, em que os seis Scrum Masters se encontravam com os responsveis da
disciplina para resolverem os impedimentos das suas respectivas fbricas.
Uma prtica muito comum no Scrum, durante o Sprint Planning 1, o planning
poker , uma tcnica para se realizar a estimativa de estrias e tarefas. uma atividade
importante, pois nesse momento que todo o time se rene para entrar em um consenso
sobre as estimativas das estrias, o que normalmente gera muitas discusses. Com isso,

130

todo o time passa a ter um entendimento maior do que ser realmente necessrio fazer,
alm de facilitar o entendimento de como as atividades devero ser desenvolvidas.
O objetivo do mdulo do Planning Poker simular sesses de estimativas, de
modo que os participantes possam discutir e argumentar como se estivessem reunidos
presencialmente. Para isso, foi criado um ambiente com recursos multimdia, como
udio, vdeo e chat, de forma a facilitar a comunicao do time.
Para as estimativas, o usurio define a sequncia de cartas a serem usadas,
exemplo, a sequncia de Fibonacci, assim como feito na reunio presencial. A reunio
inicializada pelo Scrum Master , na qual todas as estrias referentes ao produto so
disponibilizadas. Para que a estimativa seja iniciada, o time se conecta sesso criada, o
Scrum Master seleciona uma estria, cada membro do time a visualiza e escolhe uma
carta. Com o objetivo de simular o ambiente real, a imagem dos usurios conectados
aparecem na tela e as suas respectivas cartas s so mostradas depois que a votao
encerrada. O chat pode ser usado para a discusso/argumentao, bem como os recursos
de udio e vdeo, que so controlados pelo Scrum Master , j que ele o moderador da
Sprint Planning. Em resumo, estas so as funcionalidades do mdulo Planning Poker,
representadas nas Figuras 3 e 4.

Figura 3: Tela do Scrum Master

131

Figura 4: Tela do Time

6. Pr oblemas Enfr entados e Solues Encontr adas

So apresentados a seguir, os problemas enfrentados, assim como as solues
encontradas pela fbrica durante o desenvolvimento do mdulo. No total, foram
realizadas cinco Sprints, de duas semanas cada uma.
Na primeira sprint, foram iniciados os planejamentos, no entanto o time no
tinha total proficincia com a metodologia e tecnologias adotadas na implementao do
projeto. O primeiro grande desafio da fbrica foi o nivelamento tcnico de seus
integrantes nas prticas do scrum, assim como nas tecnologias utilizadas no projeto.
Para tal, workshops foram elaborados e o estudo das tecnologias utilizadas foi incluso
no sprint.
Questes de comprometimento e interao entre os integrantes da equipe so
pontos fortes na metodologia Scrum, no entanto a fbrica enfrentou a problemtica
relacionada ao no comprometimento de duas, dentre os dez integrantes. Contudo,
reestimativas das atividades tiveram que ser realizadas com base no esforo de oito
membros. Isso demonstrado pelo grfico de burndown apresentado na Figura 5, na
qual a linha mais clara, que representa as atividades pendentes, se distancia muito da
linha mais escura, que representa um prazo ideal para a realizao das atividades.

132

Figura 5: Burndown da Sprint 1

Um aspecto bastante relevante a ser destacado nos grficos de burndown a

aproximao da linha de estimativa e a linha real. A previso de esforo para cada
atividade, ao longo das sprints foi se tornando mais precisa. Isso mostra o ganho de
experincia do time, tanto nos aspectos tcnicos, quanto no autogerenciamento,
conforme Figura 6.

Figur a 6: Bur ndown das Sprints 2, 3, 4 e5

Podemos observar na tabela a seguir, os principais problemas enfrentados,
assim como as principais solues adotadas para minimizar os conflitos relacionados s
prticas Scrum, quanto utilizados em um projeto de forma distribuda.

133

Problemas
Equipe
geograficamente
distribuda

Scrum
Um dos aspectos definidos no Scrum
a
unidade
do
time
de
desenvolvimento.
Aspecto
estritamente relacionado a presena
fsica do time com atividades de
monitoramento e feedback, em geral,
reunies rpidas e dirias com toda a
equipe, de forma a identificar e
corrigir possveis deficincias e/ou
impedimentos no processo de
desenvolvimento [Schwaber 2004].

Solues
O desafio de proporcionar a efetiva interao
entre os membros do time geograficamente
distribudo foi obtido atravs do uso
sistemtico de listas de discusses e
ferramentas de comunicao via web. Estas
abordagens aliadas ao comprometimento e pro
atividade do time, aspecto importante na
metodologia Scrum, possibilitaram uma boa
interao entre os membros do time.

Reunies dirias

O Scrum prev reunies dirias

presenciais de quinze minutos entre o
time para que todos respondam s trs
perguntas bsicas.

Esta caracterstica do Scrum torna-se

complexa quando aplicada em um time
geograficamente distribudo. No entanto, este
problema foi solucionado atravs do uso de
ferramentas de comunicao e conferncia.
Porm, o controle por parte do Scrum Master
nesta atividade foi de vital importncia
intervindo e gerenciado a conferencia.

Visibilidade

Todos os membros do time vem o

quadro de atividades, onde podem
visualizar e manipular o quadro de
atividades de forma prtica e rpida.

Atribuies
Scrum Master

Acoplamento
componentes
sistema
e
atividades

Uma planilha compartilhada com todas as

atividades planejadas foi utilizada para que
cada membro cada membro realizasse a
atualizao de status de suas atividades,
mantendo assim a transparncia entre todos os
integrantes.
do Atribuio de auxiliador da equipe e Com o time geograficamente distribudo
Product Owner, alm de resoluo de aumentam as atribuies e responsabilidades
impedimentos.
do Scrum Master que, neste contexto, alm de
ter parte de seu tempo dedicado ao
gerenciamento dos impedimentos reportados
pelo time, tambm precisa estar atento a
eficiente interao entre os membros.
dos Embora exista no desenvolvimento
do tradicional com Scrum, o acoplamento
das das atividades pode ser facilmente
solucionado quando se est em
constante contato com o responsvel
pela tarefa dependente, pois as equipes
trabalham de forma integrada.

A prtica de distribuir os requisitos do sistema

de forma que proporcionasse o mnimo de
dependncias entre as atividades dos membros,
minimizando os impedimentos por atividades
relacionadas.

Tabela 1: Solues adotadas par a o desenvolvimento distr ibudo com Scr um

134

Como foram relatados na Tabela 1, alguns problemas foram enfrentados ao

longo do desenvolvimento distribudo como podem ser vistos na coluna 1. Muitos
desses problemas possivelmente no existiriam numa equipe Scrum tradicional como
descrito na coluna 2, porm a coluna 3 explica as aes adotadas pela equipe para
contornar esses problemas. Desse modo acreditamos que essas aes poderiam ser
aplicadas por outras equipes distribudas e que atravs de um maior apoio ferramental,
principalmente durante as reunies dirias, ajudariam a amenizar os problemas
enfrentados por equipes distribudas.

7. Consider aes Finais

Com a necessidade do mercado por sistemas mais complexos em um curto espao de
tempo, alinhado com os requisitos que mudam a todo instante, alm da necessidade de
captao recursos humanos de diferentes localidades, levaram as empresas a adotarem
essa combinao de desenvolvimento gil e distribudo com o objetivo de reduzir o
tempo de entrega e custo, trazendo muitos benefcios, mas em contrapartida,
enfrentando uma srie de problemas.
Esse trabalho descreveu a experincia obtida ao desenvolver um mdulo de uma
ferramenta open source dentro desse cenrio distribudo. Durante o seu
desenvolvimento, problemas foram encontrados, relatados e foram amenizados ao longo
do desenvolvimento das sprints.
O principal objetivo desse trabalho foi destacar os problemas encontrados,
levantando eventuais solues que amenizariam tais problemticas e como essas
solues poderiam ser aplicadas por outras equipes distribudas. A partir dos problemas
e solues, foi possvel fazer um paralelo entre as prticas do uso Scrum em equipes no
mesmo espao fsico e os problemas dessas prticas quando aplicado o Scrum de forma
distribuda. Dentre os problemas podemos destacar o gerenciamento da equipe e
comunicao entre os membros distribudos. Em consequncia desses problemas, a
equipe sentiu falta de um apoio ferramental, o que motivou o desenvolvimento da
prpria ferramenta FireScrum.
Sendo assim, esse trabalho apresenta como contribuio, possveis solues que
podem ser adotadas por equipes distribudas que adotam as metodologias geis, assim
como os principais problemas enfrentados pelo Scrum tradicional quando aplicado de
forma distribuda. Desse modo, como o desenvolvimento distribudo e o Scrum so
fortes tendncias do mercado de software, o relato dessa experincia pode colaborar
tanto com fbricas de software que j esto ou planejam estar alinhadas com essa
tendncia, quanto com a rea acadmica que tenha um foco mais prtico, almejando
desafios iguais ao do mercado real.
A partir dos problemas encontrados durante o estudo de caso, algumas melhorias
foram identificadas para tornar o FireScrum mais colaborativo e dar mais apoio as
equipes distribudas. Desse modo, como trabalho futuro, importante que o FireScrum
fornea mais apoio a etapas importantes na interao e comunicao entre os membros
da equipe como ambiente para discusso, interao entre os integrantes e o cliente. O
mesmo pode dar apoio as reunies dirias, sprint review e retrospectiva.

135

Refer ncias
Carmel, E. (1999) Global Software Teams: Collaboration Across Borders and Time
Zones. Prentice-Hall, EUA.
Cavalcanti, E. O.; Maciel, T. M. M.; Alburquerque, J. O. (2009). Ferramenta OpenSource para Apoio ao Uso do Scrum por Equipes Distribudas, III Workshop de
Desenvolvimento Distribudo de Software (III WDDS).
Cristal M., Wildt D., Prikladnicki, R. (2008) Usage of Scrum Practices Within a global
Company, "Usage of SCRUM Practices within a Global Company", 2008
IEEE.
International Conference on Global Software Engineering, pp. 222226.
Damian, D., Moitra, D. (2006). Guest Editors' Introduction: Global Software
Development: How far Have We Come?, IEEE Software, 23(5), pp.1719.
Gloger, B. (2007), The Zen of Scrum, http://www.glogerconsulting.de.
Herbsleb, J. D.; Moitra, D. (2001). Guest editors introduction: global software
development. IEEE Software.
IN953 (2009). Software Engineering: Building Open Source Software Factories.
Disponvel em http://www.cin.ufpe.br/~in953/.
Karolak, D. W. (1998) Global Software Development Managing Virtual Teams and
Environments. IEEE Computer Society, EUA.
Maral, A. S. C.; Freitas, B. C. C.; Soares, F. S. F.; Maciel, T. M. M.; Belchior, A. D.
(2007) Estendendo o SCRUM segundo as reas de Processo de Gerenciamento de
Projetos do CMMI, In: CLEI Eletronic Journal.
Schwaber, K. (2004), Agile Project Management with Scrum, Microsoft Press.
SourceForge (2010) SourceForge.nethttp://sourceforge.net/projects/firescrum/develop
, Acessado em Janeiro/2010.
Sutherland, Jeff. (2008) Fully Distributed Scrum: The Secret Sauce for Hyperproductive
Offshored Development Teams. Agile 2008. IEEE Software.

136

Conducting an Architecture Group in a Multi-team

Agile Environment
Mauricio Jose de Oliveira De Diana1 , Fabio Kon1 , Marco Aurelio Gerosa1
1

Department of Computer Science University of Sao Paulo (USP)

Sao Paulo SP Brazil
{mdediana,kon,gerosa}@ime.usp.br

Abstract. An important agile principle is that the best designs and architectures are emergent. It is completely feasible in low-complexity systems and / or
in a single development team context. However, when systems grow, development is usually split among many teams. When it happens, implementing agile
principles that lead to emergent architecture becomes harder. Although there
is discussion on scaling agile in general, it is not clear how to deal specifically
with software architecture in a multi-team scenario. This article presents an experience report on how a medium-sized company created an architecture group
to tackle this problem, and how this group adopted the same agile principles
and practices that development teams use in its arrangement and operation.

1. Introduction
In Agile Methods, the design of an application starts as simple as possible and incrementally evolves from that moment on. Practices such as automated testing, continuous integration, and refactoring together with simplicity principles such as do the simplest thing
that could possibly work and You Arent Going to Need It (YAGNI) [Fowler 2001] are
the foundation of emergent design, an important agile principle [Beck et al. 2001].
In a single-team scenario, an emergent architecture is feasible. However, when
development involves a bigger system composed of sub-systems built by several teams,
systems architectures become more complex. In such a scenario, the simplest solution
for one team may not be so simple for other teams. In this case, the lack of a big picture
may jeopardize the whole system conceptual and architectural integrity [Brooks 1975,
Bass et al. 2003]. When this vision does not exist, it is hard for those independent teams
to find adequate solutions to their architectural issues just by talking to each other and
expecting that the whole system architecture will emerge.
In this situation, the first approach that may come to mind is to name a chief architect or create an architecture board, responsible for defining and enforcing the whole
systems architecture. The main drawback of this approach is that it creates the necessary
conditions to the rise of an anti-pattern observed by Phillipe Kruchten, Ivory Tower architects architects disconnected from the development day-to-day reality [Kruchten 2008].
This anti-pattern can hurt teams self-organization, teams motivation, and architecture
emergence, all cornerstones of Agile Methods.
We addressed the problem of handling architecture in a multi-team agile environment in a medium-sized company by creating an architecture group composed of team
representatives. To manage the group, we adopted the same agile principles and practices

137

that work for development. In this article, we show how the group is organized, what it
delivers, how it operates, and the lessons we have learned. We believe this approach may
be useful for other multi-team organizations facing the challenge of balancing software
architecture concerns and agility.
Section 2 describes the scenario which led to the creation of the architecture group.
Section 3 explains the groups organization and lists its objectives. Section 4 describes
the expected groups deliverables, while section 5 describes the groups practices and
operation. Section 6 presents alternative approaches on architecture and multi-team agile.
Section 7 concludes this article reporting the main lessons learned.

2. Scenario
Locaweb is a 10-year-old Brazilian web hosting provider, the leader in its market with
22% market share and an annual growth of about 40% over the last few years. The company has around 100 developers in its IT department, who produce applications such as
control panels and account administration tools for the companys customers and operational support systems such as provisioning and billing. For many years, the company
used an ad hoc software development method or, in better terms, no method at all. Developers were allocated and deallocated to tasks as needed. There was no notion of teams
nor projects.
The lack of methodology was not a crucial issue while the company was still
small. But as the company grew, so did the complexity of its products and back-end
systems. Slipped schedules and quality problems in the IT department became more
frequent. Systems maintenance costs rose steadily due to bad design and workarounds.
Big Balls of Mud [Foote and Yoder 1999] were common. This situation directly impacted
business growth. Good ideas, from a business point of view, were discarded due to their
high implementation costs.
By the end of 2007, the company restructured the IT department to fix this situation. After many presentations and discussions, the company decided to adopt agile
methodologies, and Scrum was chosen for its ability to organize the development from a
managerial point of view, with little dependence on technical issues. It would be harder to
implement a method such as Extreme Programming (XP) in the early stages, as most of
the codebase was composed of old web scripting technologies such as ASP, which would
make essential XP practices, such as automated testing, very hard to adopt.
The department was divided into 13 teams, each one with up to 9 developers and
a development manager. These teams and the systems they build are loosely coupled,
each team being responsible for everything regarding their respective systems, including
the software architecture we stuck to XPs practice of Whole Team as much as possible
[Beck 2005]. Most of these systems are constantly evolving as the companys product
portfolio and the business rules change. Although the teams must work as independent
as possible, some coordination between them is necessary in crucial situations such as
integration with central provisioning and billing systems, which is a must for virtually
every system. At first, to decide on issues affecting the whole department, a department
board composed of development managers, the product management director, and the
CTO was created.
Agile practices usually need to be adapted to the context where they are being

138

used; what perfectly works for one team may not work for another. Therefore, during the
following year, each team experimented with different practices and learned what worked
best for them. Each team shared the lessons learned with each other, with the department
board serving as the formal channel to exchange experiences. Team independence and
autonomy grew considerably as the process improved. Teams were truly becoming Whole
Teams, with each responsible for system development from inception to deployment, and
from maintenance to operation. In other words, they had total control of their own work.
That environment helped to resolve many problems for each team, including architectural ones. Although individual subsystems improved, the architecture of the whole
system, composed of each subsystem and their interactions and interfaces, was still undefined and unmanaged. For instance, most systems communicated with others, usually
through RPC. But there were no constraints on what protocols the systems should use.
Consequently, a team could build a system using W3C Web Service standards and another team would use an XML-RPC based protocol they created. Any system that needed
to talk to both would have to implement both communication mechanisms. Such duplication is wasteful, since implementation costs rise and no real value is added. Furthermore,
this approach is error-prone as each new protocol increases system complexity. Each team
embraced the XP value of Simplicity [Beck 2005], however what would be the simplest
solution for a team often imposed complexity upon the others.
In a scenario with only a few teams, it is relatively easy for each to know each
others particularities and to work out architectural issues as they arise. Naturally, the agile
principle that states the best architectures, requirements, and designs emerge from selforganizing teams [Beck et al. 2001] would be the most appropriate approach. But with
13 teams in place, the company noticed that communication, and consequently decision
making, became cumbersome. It was even more difficult because the teams did not share
the same technical background. The company presents a wide range of platforms and
programming languages, and teams specializes in one or two of them (e.g., Java or .NET).
Self-organization inside each team worked well, but the same could not be said at the
department level.

3. The Architecture Group

The company needed to find an approach to balance architectural issues and team agility.
The first attempt was to centralize cross-system architectural decisions via the department
board. However, the board was composed of managers who, despite having some technical background, had little technical responsibility on their teams. They usually played the
role of product owner or project manager. The most technically skilled member on many
teams were not necessarily the manager.
In light of this, the company created the Architecture Group, composed of each
teams most skilled members, appointed by their respective development managers, and a
leader responsible for facilitation, not decision making. The first author of this article has
been the architecture group leader since its inception. Due to the difficulties with large
scale self-organization, we believe this approach provides an effective way to handle architectural concerns in an environment with many teams building interdependent systems.
We believe this approach stands valid while the architecture group size is at most twenty
members. If the group grows beyond that, communication problems will likely arise, and

139

a scale-up strategy may be necessary [Lindvall et al. 2002].

According to Bass et al. [Bass et al. 2003], the software architecture of a program or computing system is the structure or structures of the system, which comprise
software elements, the externally visible properties of those elements, and the relationships among them. This definition is very important for the group to understand the
relationship between each subsystem architecture and the whole system architecture, and
consequently understand how the group actions must take place. The group also sees
value in Martin Fowlers more relaxed definition [Fowler 2003] that states that architecture is the set of things that people perceive as hard to change. Such a broad definition
helps the group tackle important issues that may fall outside more formal definitions.
Linked to Fowlers definition, another important concept is the difference between an
emergent and an evolutionary architecture [Ford 2009]. Since the process of creating the
architecture involves addressing what will be hard to change later, to depend on emergence to get there is risky. But it does not mean that all architectural decisions must be
made and implemented from the beginning of a project. If a team constantly pays attention to the architecture, it can be implemented incrementally, evolving over time as
needed.
The group is mainly concerned with three topics, namely architectural management, development quality, and technical debt. We explain them in the next subsections.
3.1. Architectural management
The architecture group cares about the whole system architecture. From the groups point
of view, the subsystems built by each team are the software elements from the Bass et
al. definition. This vision bears strong resemblance to the Architecture Team pattern
[Coplien and Harrison 2004] defined by James Coplien and Neil Harrison, where the
architecture teams task is to create a high-level partitioning. Much architectural work remains to be completed at lower levels. In this respect, the architecture group influences
each team at the boundaries, including issues such as systems integration mechanisms,
operational support systems, and quality attributes that must be met by any system. The
group does not make, review, nor approve decisions on specific systems architectures.
Each team is still responsible for its systems architectures. In reference to Fowlers classification [Fowler 2003], the group is closer to the way the Architectus Oryzus works
(whose most noticeable part of the work is the intense collaboration) than to the Architectus Reloadus (who is the person who makes all the important decisions). Fowler
states that an architects value is inversely proportional to the number of decisions he or
she makes. This attitude is aligned with the agile concept of an empowered team, where
the developers know the best course of action in each context (something confirmed by
our observations).
It is crucial to recognize that it is difficult to make good decisions when detached
from day-to-day reality. This was the main reason for creating an architecture group composed of members from all teams instead of creating a separate architecture team, a Community of Practice as advised by Craig Larman and Bas Vode [Larman and Vode 2010].
In describing what a Core Architecture Team is, Scott Ambler says that creating such a
group helps to increase the chance that each subteam learns and follows the architecture
as well as increases the chance that the core architecture team will not ignore portions of
the system [Ambler 2002].

140

3.2. Development quality

Even though the architecture group is mainly concerned with architectural issues, it has
also a stake in each teams development processes. As such, its second goal is to define
development quality standards. In a distributed systems environment, the lack of quality
in a specific system can leak and affect other systems. For example, if a system is poorly
tested, it will present more defects, which in turn decreases its reliability. Therefore,
the group is concerned with quality in all subsystems development. An effective way to
improve quality is the systematic use of software development best practices and testing
tools at all levels where validation is necessary. Therefore, the group demands actions
from teams regarding testing coverage, code standards, and continuous integration, for
example. A software development quality group may be a more suitable way to handle
development quality issues than the architecture group. At the time of this writing the
department is investigating creating such a group, but until it is completely functional, the
architecture group undertakes this responsibility.
3.3. Technical debts
At the time of this writing, many teams struggle with technical debts in their systems.
Technical debt is a metaphor to show the costs involved in bad design and/or implementation [Fowler 2004]. The idea is that whenever developers neglect the design of their
system, they incur in technical debt. In financial debts, there is interest payment. The
same happens with technical debts the longer it takes for the developers to correct the
results of bad decision making from the past, the more interest they will have to pay, and
the more expensive the correction will become.
Although paying down technical debts is each teams responsibility, it is common
for legacy systems to impede or even prevent the appropriate architectural decisions. Because of this, the group set a temporary goal of supporting teams in paying down technical
debts. The group can be especially helpful in situations where specific architectural debts
affect many systems. For example, high coupling between systems by different teams
makes it difficult for them to maintain and evolve those systems. In such cases, the group
helps coordinate efforts to cleanly separate the systems, usually by designing strategies
for legacy migration that concerns more than one system. In addition, this help can take
the form of informal consultancy services that members offer to each other.
Upon recognizing that much technical debt was the direct result of lack of knowledge and experience, the department implemented many training and knowledge sharing
initiatives. By helping its developers to become more knowledgeable, the company expects them to both attack existing debts and to build quality into new systems from the
ground up in order to avoid new debts. Although the architecture group is not responsible
for training, it strongly supports many such initiatives.

4. Architecture Group Deliverables

The architecture group does not decide on subsystems architecture nor produce code.
Instead, its members discuss what they see as important issues affecting the whole system
architecture, analyze ways to address those issues, and request teams to take actions on
them. The group basically delivers these requests in three different forms: standards,
goals, and definition of shared infrastructure.

141

4.1. Standards
Standards definition is the preferred way for the group to manage the whole system architecture. The group uses the same principles behind standardization groups such as IETF
and the Java Community Process, i.e., it states what should be done, but not how. In other
words, the group does not make recommendations regarding implementation details, it
just defines the interfaces between the subsystems.
The group asserts the quality of its standards by observing each groups adherence
to them. One of the groups key principles is that if developers do not see value in what the
group is advocating they will just bypass it, especially in an environment where autonomy
is so intense. This is similar to when de facto standards become more popular in an
industry than their formal counterparts. Consequently, whenever a standard is not broadly
adopted, the group understands that it failed to create something of value. With that
in mind, the group tries to make all the standards as lightweight as possible and then let
them evolve naturally. For example, when discussing a substitute for the in-house systems
integration mechanism, the group adopted RESTful web services, the simplest solution it
could find that would meet the requirements.
4.2. Goals
Another important mechanism put in place by the architecture group is quarterly goals.
Every three months the group members discuss the most important issues affecting their
teams, looking for commonalities. Based on that, the group defines goals to be achieved
by all teams with the aim of solving two different problems. The first one is related to
architectural integrity. Goals are a good way to know that every team has worked on a
common issue. For example, if teams require information for capacity planning, a possible goal may be that every system must have an attached monitoring component to gather
operational information. The second problem is related to backlog prioritization. Our
experience shows that although product owners see value in architectural development,
when it is completely up to them, they may discard architectural work to make room
for user stories contemplating new features, which are more valuable from the customer
point of view. Furthermore, they rarely have the technical knowledge to evaluate architectural activities, so it is hard for them to prioritize them. The quarterly goals make the
architecture group a project stakeholder as any other to each team.
The group maintains an evolving architecture manifesto which lists the requirements every subsystem must conform to. At the end of each quarter, the goals related
to quality attributes are added to the manifesto. By doing that, the architecture group is
periodically incrementing and standardizing what is expected from all subsystems architecture. Creating a manifesto incrementally instead of trying to completely define it from
the first moment is a pragmatic way to assume what is feasible at the moment and to
always focus on the priorities.
The quarterly goals are composed of a few specific items, usually sharing a common theme. For example, the goals for Q1 2009 had the theme build the basic infrastructure needed to support development (continuous integration servers, code coverage tools,
etc.) and operations (monitoring and statistics), and were:
All projects that are not considered legacy systems must have continuous integration in place.

142

 All projects not considered legacy must have their testing coverage measured.
All production systems infrastructure must be monitored by an alert system (e.g.,
Nagios).
Statistics about all systems not considered legacy must be harvested and displayed
by a graphical information system (e.g., Cacti).
Each team must prepare a lightweight plan describing its actions regarding their
legacy systems.
4.3. Definition of shared infrastructure
Many systems share common needs, especially infrastructural ones. For example, a single
sign-on solution is desired so the customers, who access many distinct web applications,
do not need to login again every time they switch from one to another. Another example
is the definition and creation of a system integration environment where each team can
test their systems by running their automated test suite using other subsystems. In these
situations, the group defines which team should be responsible for this particular concern.
Usually a member from the team which will get the most from it steps in as volunteer to
do the job. The team may be helped by developers from other teams while implementing
the solution, but it will be the only responsible for the maintenance of the system after its
deployment.

5. Conducting the Architecture Group

The architecture group uses agile principles and practices that work for development
teams, i.e., concepts such as iterations, backlog prioritization, planning, and review meetings. Since its actions happen across many teams and are perceived in the long term,
the group adopts these concepts in another scale for example, instead of 1 or 2-week
iterations, monthly ones; instead of daily meetings, bi-weekly ones. Following are some
adaptations that the group has made to other practices as well.
5.1. Self-organization
In an empowered team, all technical decisions are collectively made by the team members.
The same happens in the architecture group, its leader basically has coordination and
facilitation responsibilities, not decision ones. Decisions are not made by majority either,
since the group believes that in many situations one or two group members have special
knowledge that others may not have, so all members have to discuss until rough consensus
is reached. It is the same principle behind Planning Poker [Cohn 2005]. In very rare
situations when consensus is not reached the leader makes a decision so the group does
not get stuck in endless discussions. But the group believes these situations actually are
bad smells (similar to code smells) after some time, it discusses what happened that
we couldnt agree on something even after discussion?. We have noticed that it can be
for many different reasons, lack of knowledge on the subject being the most common.
5.2. Demand management
The group has a backlog open to the whole company in an internal wiki. Anyone, group
member or not, can add items to it. The backlog is prioritized by the groups leader after
listening to other members and stakeholders ranging from the CTO to product owners. A
constant worry is to always be aligned to the business, the group should attack the most
relevant issues from the companys point of view. So the group considers any demand
coming from the outside a very positive sign that it is on the right track.

143

5.3. Planning and review

The group runs planning and review meetings, occurring every other week, with different
purposes. At the beginning of the month there is a 3-hour meeting, mandatory to all
group members, when work-in-progress is reviewed and new work is started. After two
weeks, the group meets again in an 1-hour review meeting, just to follow-up ongoing
work. Presence in this meeting is optional. Since all members have about 10% of their
time dedicated to the architecture group, this frequency is sufficient to keep them and
their teams informed. These meetings are also a good moment for teams to share what
they have been working on regarding architecture specifically, or general issues affecting
architecture. In a way, it works as an informal Scrum of Scrums, but focused on the
engineering side of ongoing projects.
5.4. Working groups
The group quickly learned that it is almost impossible to keep long technical discussions
productive with around 20 people talking. Moreover, many of the discussed topics need
profound analysis and research. To deal with this situation, the group found inspiration
in the way IETF manages RFCs [Bradner 1998]. Working groups are typically created to
address a specific problem or to produce one or more specific deliverables (a guideline,
standards specification, etc.). Working groups are generally expected to be short-lived in
nature. After the tasks are completed, the group is disbanded. However, if a working
group produces a Proposed or Draft Standard, it frequently becomes dormant rather than
disband. When the deliverable produced by the working group is a draft, it is presented at
the next review or planning meeting to public appreciation.
Not everything needs a working group to be worked out. Actually, the group
solves most issues during the planning meeting. Working groups are created when the
group notices that a particular issue will not be solved with a quick discussion or when
it takes too long to reach an agreement. The group leader and up to six volunteers comprise the working groups. Normally, someone volunteers for a working group due to two
reasons: their team may have a stake in the target issue or they can be particular fond of
the subject. For example, it would be expected that a working group formed to address
user access policies has members from the core team, the hosting team, and people interested in security. The usual working groups mode of operation is to meet once a week to
discuss the issue and divide research and/or development between its members until their
next meeting.

6. Related Work on Architecture and Multi-team Agile

While agile methods were seeing broader adoption in industry, their first limitations
started to show up. How to apply agile methods away from their sweet spot (single
collocated teams, greenfield projects, etc) became a common concern for practitioners
and academics, and we have seen the growth in literature on how to scale agile as a consequence. Scaling agile usually involves a wide range of concerns, we limit this section
to works which deal with architecture in multi-team agile environments.
Dean Leffingwells approach [Leffingwell 2007] is to organize systems in components, and have the components assigned to teams. From that, an architecture team,
formed by senior architects or technical leaders from the teams, defines the initial architecture in the beginning of the project. A prototyping team may also be formed to test the

144

architecture. The process follows important agile concepts such as working in time-boxed
iterations and focusing primarily on implementation rather than just modeling. After the
initial phase, work is assigned to development teams. They start by building what Leffingwell named the architectural runaway, which contains existing or planned infrastructure
sufficient to allow incorporation of current and anticipated requirements without excessive
refactoring. It is expected that the runaway get extended to accommodate new features.
However, development teams must not necessarily be responsible for extending the runaway. If architectural expertise is mainly concentrated in the architecture team, this team
may work in advance and prepare the runaway so development teams find the needed
infrastructure ready when they start to implement a new feature. Leffingwells approach
seems more suited to deal with scenarios where systems are more tight coupled, teams
work closer to each other and there are few ongoing strongly related projects at a time, a
scenario different from ours.
Jutta Eckstein, following Frederick Brooks observations, recognizes that a systems conceptual integrity is lost when a team becomes too large [Eckstein 2004]. To
avoid that, she suggests the assignment of a lead architect. This person is responsible for
making final architectural decisions, remembering the rationale behind those decisions,
and, most importantly, spreading the systems architectural ideas so people have a better
understanding of its architecture. Besides the presence of the technical lead, Eckstein
suggests what she calls architecture as a service. The term means that an architecture
teams work should be guided by, instead of guide, the development teams work. The
architecture team build only what is requested by the development teams that, by their
turn, only ask for work related to their respective customers. By doing that, an organization sticks to the YAGNI principle, keeps its architecture simple, and ease the burden on
developers to understand the architecture. Ecksteins approach seems a good fit in a more
homogeneous and stable environment, where the lead architect can keep enough details
of the systems architectures in his head. In our case, the number and diversity of systems,
platforms, and technologies are such that it is difficult to have only one person looking at
them all. Regarding architecture as a service, we follow Ecksteins advice, in a different
way. One could see the groups goals as the group guiding the development teams, but
the groups members come from each team exactly for the same reason Eckstein suggests
her approach: to keep the group working in issues those teams see as valuable.
Roland Faber presents a case study describing how he has organized an architecture team to act as a service provider [Faber 2010], similar to Ecksteins approach. In his
organization, architects are responsible for nonfunctional requirements, while developers
are responsible for functionality. The architecture process is divided in two phases, preparation and support. During preparation, an architect specifies system qualities, creates an
overview of the architecture, creates prototypes and a system skeleton to be used by developers to test and integrate their work early. In the support phase, an architect is collocated
with the development team, and helps the developers implement the application, coding
with them. Faber notes this is important because it builds trust between developers and
architects and provides valuable feedback for architects about their architectural decisions
and frameworks. Fabers approach particularly aims at the architecture of each separated
system, but with overall issues such as reuse in sight. In our approach, the main concern
of the architecture group is the whole system architecture, and each team is responsible
for its systems architecture. Another difference is that instead of working with a sepa-

145

rated architecture team that collocates its members in teams, we followed the other way
around, and formed the group with development team members.

7. Conclusion
The architecture group has been working for almost a year by the time of this writing. It
already has presented considerable results, maybe the most important being an unplanned
one: the increasing of architecture awareness by all company developers. It is an important achievement, since architecture was seen as unworthy two years ago. Besides, so far
many mechanisms have been put in place to improve the quality of both customer products and back-end systems, such as the system integration standard, and an extensive use
of testing and continuous integration.
Up to now, we have had spotted difficulties of operating an architecture group that
others following this approach can face:
Sometimes, members have a hard time dealing with conflicts between activities
in their teams and in the architecture group, specially regarding agenda. For example, a team planning meeting may be scheduled to occur at the same time as a
working group meeting. There is no general rule to deal with those situations, but
usually one takes the team activities since most architecture group work is aimed
at the long-term, and thus can wait.
There are very few controversial issues where consensus is unreachable. In these
cases, enforcing a decision is better than just skipping the issue.
In a heterogeneous environment, there are situations when the technical lead must
conduct discussions, but he does not have sufficient knowledge about the topic or
the details involved to do so. When this is the case, the lead has to admit ones
lack of confidence, ask for help and study as much as possible about the problem
in hand.
In this article, we presented the practices that have been working for the architecture group. They may be useful for other organizations interested in adopting an architecture group following the approach proposed in this article. Table 1 provides a summary
of the practices:

146

Table 1. Summary of the architecture groups practices.

Practice
Fill the architecture
group with members of
each team
Create standards

Responsible
Managers

Create goals

Architecture
group

Define shared infrastructure

Architecture
group

Decide on technical issues collectively

Architecture
group

Create and prioritize a

backlog

Anyone
add
items,
the
architecture
group
leader
prioritizes
Architecture
group
leader
organizes,
architecture
group members
and any other
interest
party
attends
Architecture
group

Run planning and review

meetings

Form working groups

Architecture
group

147

Objective
Connect the group to the dayto-day reality of the organization
Address technical issues affecting multiple teams while
preserving each teams autonomy
Make multiple teams consistently apply specific practices and standards and / or
help balancing architectural
related development and new
features in teams backlogs
Avoid duplicate efforts when
multiple teams share the
same infrastructural needs
Find the better solutions by
summing the knowledge and
points of view of members
coming from different backgrounds and specialties
Organize the architecture
groups work and make it
visible

Details
Section 3

Organize the architecture

groups work and keep track
of work being done at the
moment

Section 5.3

Avoid long discussions when

current information on technical or business is not sufficient

Section 5.4

Section 4.1

Section 4.2

Section 4.3

Section 5.1

Section 5.2

When the number of people involved in a system goes much beyond the suggested agile team size, it becomes very difficult to keep the whole system architectural
integrity. Our approach recognizes the need to balance architectural integrity with team
self-organization and autonomy. Although having a central coordinating group in an agile
environment may seem contradictory at first, it makes sense if the group not only respects,
but also uses, the agile values, principles and practices guiding the whole organization.

8. Acknowledgements
We thank Locaweb for supporting this work and to Andrew de Andrade for revising preliminary versions of this article. Fabio Kon and Marco Gerosa receive individual grants
from CNPq.

References
Ambler, S. W. (2002). Agile Modeling: Effective Practices for eXtreme Programming
and the Unified Process. John Wiley & Sons.
Bass, L., Clements, P., and Kazman, R. (2003). Software Architecture in Practice.
Addison-Wesley Longman.
Beck, K. (2005). Extreme Programming Explained: Embrace Change. Addison-Wesley
Longman.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.,
Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Agile manifesto.
http://agilemanifesto.org/.
Bradner, S. (1998). IETF working group guidelines and procedures, IETF RFC 2418.
http://www.rfc-editor.org/rfc/rfc2418.txt.
Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
Cohn, M. (2005). Agile Estimating and Planning. Prentice-Hall.
Coplien, J. O. and Harrison, N. B. (2004). Organizational Patterns of Agile Software
Development. Prentice-Hall.
Eckstein, J. (2004). Agile Software Development in the Large: Diving Into the Deep.
Dorset House Publishing.
Faber, R. (2010). Architects as service providers. IEEE Software, 27(2):3340.
Foote, B. and Yoder, J. (1999). Big ball of mud. In Pattern Languages of Program Design
4. Addison-Wesley Longman.
Ford, N. (2009). Evolutionary architecture and emergent design: Investigating architecture and design.
http://www.ibm.com/developerworks/java/
library/j-eaed1/index.html.
Fowler, M. (2001). Is design dead? In Extreme Programming Examined. Addison-Wesley
Longman.
Fowler, M. (2003). Who needs an architect? IEEE Software, 20(5):1113.

148

Fowler, M. (2004). Technical debt.

TechnicalDebt.html.

http://martinfowler.com/bliki/

Kruchten, P. (2008). What do software architects really do? The Journal of Systems &
Software, 81(12):24132416.
Larman, C. and Vode, B. (2010). Practices for Scaling Lean & Agile Development.
Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises.
Addison-Wesley Professional.
Lindvall, M., Basili, V. R., Boehm, B. W., Costa, P., Dangle, K., Shull, F., Tesoriero, R.,
Williams, L. A., and Zelkowitz, M. V. (2002). Empirical findings in agile methods.
Lecture Notes in Computer Science, pages 197207.

149