ArticlePDF Available

Scrum no Serviço Público: um Relato de Implantação nas Secretarias Estaduais da Fazenda e da Gestão Pública do Estado de Alagoas

Authors:

Abstract

Resumo:A busca pela melhoria contínua na qualidade de software proporcionou o surgimento de metodologias de desenvolvimento de software, entre elas as Metodologias Ágeis. Baseado nestas, surgiu o Scrum, um framework para gerenciamento ágil de projetos. Este trabalho objetiva relatar como ocorreram as implantações do Scrum em dois órgãos públicos do Estado de Alagoas, apresentando as características positivas e negativas obtidas em cada projeto, bem como as dificuldades encontradas durante o processo. Como resultado, constatou-se que o uso do Scrum proveu melhorias no gerenciamento dos projetos analisados. Porém, tal sucesso depende dos diversos fatores analisados no decorrer do processo. Palavras Chave: Metodologias Ágeis -Scrum -Gestão de Projetos --1. INTRODUÇÃO A indústria de software tem crescido rapidamente em conjunto com o aumento da complexidade das aplicações, onde muitas vezes os requisitos são mutáveis. Por isso, a busca pela excelência e melhoria contínua da qualidade de software tem sido aprimorada ao longo do tempo (SOMMERVILLE, 2007), sendo propostos diversos métodos, técnicas e ferramentas (TEIXEIRA E DELAMARO, 2007). Surgindo como parte de uma reação contra as metodologias tradicionais, as Metodologias Ágeis têm como proposta uma dinâmica de processos flexíveis e adaptativos, incorporando as mudanças como parte inseparável do seu processo de desenvolvimento. Baseado em tais práticas surgiu o Scrum, um framework para gerenciamento de projetos que tem como premissa o desenvolvimento iterativo e incremental.
Scrum no Serviço Público: um Relato de
Implantação nas Secretarias Estaduais da
Fazenda e da Gestão Pública do Estado de
Alagoas
Fernando Kenji Kamei
fkenjikamei@gmail.com
UFPE
Felipe Buarque de Queiroz
fbq@cin.ufpe.br
UFPE
Ricardo Rubens G. Nunes Filho
ricardo.rubens@gmail.com
IFAL
Alexandre J. B. Silva
alex.professor@gmail.com
FAL
Marcílio F. Souza Júnior
marcilio@cefet-al.br
IFAL
Resumo:A busca pela melhoria contínua na qualidade de software proporcionou o surgimento de
metodologias de desenvolvimento de software, entre elas as Metodologias Ágeis. Baseado nestas, surgiu
o Scrum, um framework para gerenciamento ágil de projetos. Este trabalho objetiva relatar como
ocorreram as implantações do Scrum em dois órgãos públicos do Estado de Alagoas, apresentando as
características positivas e negativas obtidas em cada projeto, bem como as dificuldades encontradas
durante o processo. Como resultado, constatou-se que o uso do Scrum proveu melhorias no
gerenciamento dos projetos analisados. Porém, tal sucesso depende dos diversos fatores analisados no
decorrer do processo.
Palavras Chave: Metodologias Ágeis - Scrum - Gestão de Projetos - -
1. INTRODUÇÃO
A indústria de software tem crescido rapidamente em conjunto com o aumento da
complexidade das aplicações, onde muitas vezes os requisitos são mutáveis. Por isso, a busca
pela excelência e melhoria contínua da qualidade de software tem sido aprimorada ao longo
do tempo (SOMMERVILLE, 2007), sendo propostos diversos métodos, técnicas e
ferramentas (TEIXEIRA E DELAMARO, 2007).
Surgindo como parte de uma reação contra as metodologias tradicionais, as
Metodologias Ágeis têm como proposta uma dinâmica de processos flexíveis e adaptativos,
incorporando as mudanças como parte inseparável do seu processo de desenvolvimento.
Baseado em tais práticas surgiu o Scrum, um framework para gerenciamento de projetos que
tem como premissa o desenvolvimento iterativo e incremental.
Schwaber (2004) define que o Scrum não é um processo prescritivo, pois acredita-se
que não é possível prever no início de um projeto tudo o que ocorrerá durante o
desenvolvimento do mesmo. O Scrum oferece ferramentas e práticas que permitem maior
visibilidade do projeto, de forma a facilitar os ajustes e manter o foco sempre na direção da
meta desejada.
Segundo uma pesquisa (AMBLER, 2009) que entrevistou 2.570 pessoas envolvidas
com desenvolvimento de software de 88 países, 50% dos entrevistados têm utilizado as
práticas do Scrum no gerenciamento de projetos para aprimorar os seus produtos. Neste
contexto, em busca pela melhoria na qualidade de seus processos e dos produtos finais
desenvolvidos, dois órgãos públicos do Estado de Alagoas realizaram a implantação da
metodologia.
Este trabalho objetiva relatar como ocorreu o processo de implantação do Scrum
nesses dois órgãos públicos, apresentando os pontos positivos e negativos de cada processo,
bem como os resultados obtidos.
O restante do trabalho está organizado como segue: a Seção 2 apresenta o referencial
teórico; a Seção 3 apresenta os métodos de pesquisa utilizados; a Seção 4 apresenta a
descrição dos processos de implantação; a Seção 5 apresenta uma discussão com os resultados
obtidos com a pesquisa; e por fim, a Seção 6 apresenta as considerações finais do trabalho.
2. O SCRUM COMO FRAMEWORK ÁGIL PARA GERENCIAMENTO DE
PROJETOS
O Scrum é baseado nas metodologias ágeis voltado especificamente para o
gerenciamento de software com base na colaboração com o cliente, trabalho em equipe,
desenvolvimento iterativo e incremental, e com respostas às mudanças (RICO et al., 2009).
Tais características objetivam eliminar a dependência em realizar um extenso planejamento
inicial e documentação de todos os requisitos do sistema (FERREIRA E COHEN, 2008),
assim como é observado na utilização de métodos tradicionais.
Segundo Schwaber (2004), o Scrum é desenvolvido por meio de três papéis principais:
i) o Product Owner (PO), que representa os interesses do dono do produto; ii) o Time, que
desenvolve as funcionalidades do produto e; iii) o Scrum Master, que garante que as regras e
práticas do Scrum estejam sendo utilizadas no projeto, além de ser responsável por remover
qualquer tipo de impedimento.
Todo o trabalho do Scrum é realizado em iterações com duração de 02 a 04 se manas
cada, chamadas de Sprints. As Sprints são iniciados sempre com uma reunião de
planejamento, conhecida como Sprint Planning Meeting, onde o Time decide quais as estórias
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 2
do Product Backlog serão trabalhadas (Selected Product Backlog) na Sprint para atingir a
meta proposta pelo Product Owner. Após essa reunião, outra deve ocorrer com a presença dos
membros do Time e o Scrum Master, para definirem e planejarem as tarefas de cada estória
que deverão compor a Sprint (Sprint Backlog).
Durante as Sprints devem ocorrer reuniões diárias, conhecidas como Daily Scrum
Meeting, visando o acompanhamento diário do projeto. No final de cada Sprint, ocorrem as
reuniões de revisão, chamadas de Sprint Review, para apresentar ao Product Owner o que foi
desenvolvido, e obter o feedback (SCHWABER, 2004). Também deve ser realizada ao final
da Sprint a reunião de retrospectiva (Sprint Retrospective), para avaliar quais os pontos
positivos do que ocorreu na Sprint e o que deve ser melhorado.
Uma técnica muito utilizada em conjunto com o Scrum é a estimativa colaborativa do
projeto entre os membros do Time, chamada de Planning Poker. Nesta técnica são utilizadas
cartas similares ao de um baralho com valores de 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100, para estimar
a complexidade de cada estória (COHN, 2006).
3. MÉTODOS DA PESQUISA
Este trabalho utilizou o método de pesquisa-ação, o qual é um método
intervencionista, que permite ao pesquisador testar hipóteses sobre o fenômeno de interesse
implementando e acessando as mudanças no cenário real (LINDGREN et al., 2004).
Conforme Stringer (1996), a pesquisa-ação compreende uma rotina composta por três
ões principais: observar, para reunir informações e construir um cenário; pensar, para
explorar, analisar e interpretar os fatos; e agir, implementando e avaliando as ões. Tais
ões se refletem no contexto dos órgãos analisados, onde se fizeram necessários as
observações dos ambientes, e a percepção dos problemas reais relacionados ao gerenciamento
de projetos de software dos órgãos pelo pesquisador, de modo buscar e implantar uma
solução, com o foco essencial de investigar a adoção da metodologia Scrum em tais
ambientes.
A escolha dos sujeitos se fez de maneira intencional pelo pesquisador, pois eram
órgãos na qual prestava serviços, possuindo livre-acesso ao ambiente de trabalho. Assim,
foram selecionadas quatro equipes de desenvolvimento de software de dois órgãos públicos
do Estado de Alagoas, para realizar a implantação e acompanhamento do Scrum nos projetos.
Os dados primários da pesquisa foram coletados por meio de observações dos fatos e
por meio de conversas informais constantes do pesquisador, primeiro autor deste trabalho,
com todos os participantes e envolvidos nos processos de implantações, durante todas as
etapas dos projetos.
4. PROCESSO DE IMPLANTAÇÃO
Neste trabalho foram investigados aspectos qualitativos da implantação do Scrum em
projetos de desenvolvimento de software de dois órgãos públicos do Estado de Alagoas. Nas
subseções abaixo o processo das implantações são descritos.
4.1. SEFAZ-AL
A motivação para a implantação do Scrum na Secretaria da Fazenda do Estado de
Alagoas - SEFAZ-AL - surgiu visando prover melhorias ao processo de desenvolvimento de
software do órgão, que seguia um processo com ciclo de vida dividido em 04 fases (Iniciação,
Elaboração, Construção, Transição), e estas em subfases. Em cada subfase um produto ou
artefato era gerado e formalmente documentado. Esta documentação formal, que muitas vezes
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 3
realizadas em excesso, ocasionava em atrasos no cronograma dos projetos, aumento o custo
do mesmo e levando ao descontentamento dos gestores do órgão.
Em conseqüência dos problemas observados, o órgão designou uma equipe para
estudar abordagens para gerenciamento de projetos de software, constatando que o uso do
Scrum seria mais adequado por adotar um processo iterativo e incremental, facilitando assim a
entrada de mudanças durante o projeto. Outro fator importante foi o conhecimento prévio do
Scrum de pessoas do órgão, incluindo o autor deste trabalho.
Para iniciar o processo de implantação algumas medidas foram adotadas: (1) reunião
de planejamento estratégico, objetivando analisar a viabilidade de implantação do Scrum
nos projetos, onde foi definido que apenas os novos projetos poderiam ser selecionados como
projetos pilotos; (2) estudo para alinhar as práticas do Scrum aos processos da SEFAZ-
AL, no qual ficou decidido que a prática do Planning Poker deveria estar alinhada a métrica
de Análise de Pontos por Função (APF). Contudo, em caso de grande disparidade entre estas,
ajustes ou uma nova contagem de Ponto de Função seria realizada; (3) foi definido que o
coach (primeiro autor deste trabalho) seria responsável por implantar e acompanhar a
implantação do Scrum nos projetos; (4) Realização de uma palestra introdutória de
apresentação do Scrum pelo coach a todos os funcionários do órgão.
Nas próximas subseções, são descritos os processos de implantação do Scrum nos
projetos pilotos na SEFAZ-AL, que por questões de confidencialidade são identificados como
projeto SFZ-A e SFZ-B.
4.1.1. PROJETO SFZ-A
O projeto SFZ-A foi composto por 03 programadores (dois com um pouco mais de 02
anos de experiência, e um com 06 meses) e 01 analista (06 meses de experiência), e
desenvolvido utilizando a linguagem Java para plataforma Web, e os frameworks JSF 2.01 e
Spring 2.0, juntamente com a abordagem de desenvolvimento guiado por testes (Test Driven
Development).
O Scrum foi iniciado neste projeto após a reunião de planejamento estratégico no
órgão, em uma reunião realizada entre os membros do projeto, o coach e o cliente, onde foram
definidos os papéis: Product Owner e Scrum Master ficaram a cargo do analista, e o Time
formado pelos programadores.
Após a definição dos papéis, a visão e meta do projeto foram discutidas, e a
apresentação do Product Backlog foi realizada. A estimativa das estórias do Product Backlog
foi realizada através da técnica de Planning Poker pelos membros do Time. As estórias foram
selecionadas e formaram a primeira Sprint, na qual foram discutidas e definidas as tarefas para
cada estória. Todas as decisões da reunião, como estimativa e definição das tarefas foram
registradas em um documento no formato de planilha eletrônica.
O projeto SFZ-A utilizou as práticas do Scrum por três Sprints, até que o uso das
mesmas foi descontinuado por completo. Tal fato ocorreu devido a grande resistência dos
envolvidos no projeto em adotar as práticas propostas pelo Scrum, como as reuniões diárias,
onde o próprio Scrum Master afirmava serem desnecessárias.
4.1.2. PROJETO SFZ-B
O projeto SFZ-B foi composto por 04 programadores (todos com aproximadamente 02
anos de experiência) e 02 analistas (um com 04 anos de experiência, e outro com 05 anos), e
desenvolvido utilizando a linguagem Java para plataforma Web, fazendo uso dos frameworks
JBoss Seam e JSF 2.0. Para o desenvolvimento de aplicações front-end foi utilizado o Adobe
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 4
Flex 3.0 juntamente com o framework BlazeDS para facilitar a integração com a linguagem
Java.
Assim como no projeto SFZ-A, o Scrum foi iniciado neste projeto após a reunião de
planejamento estratégico no órgão, em uma reunião realizada entre os membros do projeto, o
coach e o cliente, onde foram definidos os papéis: o papel do Scrum Master ficou a cargo de
um analista, o papel de Product Owner com um segundo analista, e os demais atuaram como
membros do Time.
Durante a reunião de planejamento da Sprint foram definidos os objetivos do projeto e
as primeiras estórias que compuseram o Product Backlog, as quais foram explicadas pelo
próprio cliente. As estórias foram estimadas pelo Time utilizando a técnica de Planning
Poker, e definidas as que compuseram a primeira Sprint com duração de 02 (duas) semanas.
Algumas adaptações à prática da Reunião Diária (Daily Meeting) proposta pelo Scrum
foram realizadas pelo Time, sendo realizadas duas reuniões a cada dois dias, seguindo a
mesma abordagem de serem realizadas em e com duração de 15 (quinze) minutos. Estas
ocorreram nas segundas, quartas e sextas. Nas segundas e quartas, uma reunião no início do
expediente, e outra ao final. Nas sextas, apenas uma reunião no início do expediente. Esta
abordagem permitiu uma melhoria na comunicação, e sincronização nas atividades do projeto.
Desse modo, as perguntas do Daily Meeting foram adaptadas para: perguntas do início
do dia (O quê você fez desde a última reunião? O quê você vai fazer hoje? Existe algum
impedimento?) e perguntas do final do dia (O quê você fez hoje? Existe algum impedimento?
O quê você vai fazer amanhã?).
O projeto fez uso da ferramenta Virtual Scrum Board1 para gerenciar as Sprints pelos
seguintes motivos: os papéis adesivos caíam do quadro; armazenar o histórico das Sprints se
via necessário para futuras análises do projeto pelos gestores do mesmo; e o acompanhamento
remoto do projeto, pois em alguns momentos o Product Owner encontrava-se em um
ambiente diferente da equipe, fazendo uso também de ferramentas de mensagens instantâneas
como o Spark2, que permite a troca de mensagens de textos, conversas por voz e troca de
arquivos.
Mesmo com os motivos apresentados em utilizar a ferramenta de gerenciamento,
também foi utilizado o quadro para o acompanhamento das Sprints, pois este oferece maior
visibilidade e auxilia na discussão durante as reuniões.
Durante a coleta dos dados do projeto para esta pesquisa, apenas duas Sprints haviam
sido finalizadas. Nessas Sprints, todas as estórias foram concluídas com sucesso e no prazo
determinado. Ao final de cada Sprint foram realizadas as reuniões de revisão e retrospectiva,
as quais permitiram uma melhoria do processo.
4.2. SEGESP-AL
Na Secretaria de Gestão Pública do Estado de Alagoas - SEGESP-AL - a motivação
para implantação do Scrum surgiu devido à inexistência de um processo bem definido para os
projetos de desenvolvimento de software do órgão. Essa ausência ocasionava em atrasos,
dificuldades no acompanhamento dos projetos e sérios problemas na comunicação entre os
envolvidos.
O órgão contava com serviços contratados de empresas terceirizadas, onde estas
recebiam o pagamento pela estimativa de duração dos projetos (horas). Este valor era
1 http://virtualscrumboard.com/
2 http://www.igniterealtime.org/projects/spark/
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 5
calculado com base na quantidade de pessoas necessárias e pelo valor da hora de cada perfil
profissional. Este tipo de estimativa tornava-se muitas vezes irreal, pois muitos projetos
atrasavam em sua entrega, consumindo mais horas de cada profissional envolvido.
Devido aos problemas relatados e a busca pela melhoria na qualidade dos projetos
desenvolvidos, surgiu a proposta para implantação do Scrum por uma empresa terceirizada do
órgão. Tal proposta foi viabilizada devido à experiência e conhecimento prévio no Scrum por
parte da equipe de desenvolvimento da empresa, o que inclui o autor principal deste trabalho,
que atuou como coach na implantação e acompanhamento das práticas do Scrum nos projetos
do órgão.
Nas próximas subseções são descritos os processos de implantação do Scrum nos
projetos pilotos na SEGESP-AL, que por questões de confidencialidade são identificados
como projeto SEG-A e SEG-B.
4.2.1. PROJETO SEG-A
O projeto SEG-A foi composto por 04 programadores (três com 03 anos de
experiência, e um com quase 01 ano) e 02 analistas (um com 04 anos de experiência, e outro
com 06 anos), e foi desenvolvido na linguagem Java para plataforma Web e utilizando o
framework JSF 2.0. Para os relatórios gráficos foi utilizado o Adobe Flex 3.0.
A implantação do Scrum neste projeto foi iniciada com uma reunião de planejamento
entre um analista e o gestor do órgão, onde foram definidos os papéis de cada membro do
projeto: o Time ficou composto pelos programadores, o papel de Scrum Master foi atribuído
ao analista com mais tempo de experiência e o papel do Product Owner (PO) foi designado ao
outro analista, pelo fato do mesmo ter conhecimento sobre as necessidades reais do projeto.
Ao final dessa reunião, as estórias do Product Backlog foram definidas e priorizadas pelo PO.
Neste projeto as reuniões diárias do Scrum não foram seguidas a rigor, porém este fato
não comprometeu o andamento do projeto, nem o funcionamento do Scrum, pois a
comunicação entre os membros do Time era constante. O projeto utilizou a ferramenta
Microsoft Project3 e o quadro na parede para auxiliar no acompanhamento d Sprint.
Durante a coleta das informações do projeto para este trabalho, uma única Sprint havia
sido finalizada e no prazo estipulado, com êxito na realização de todas as cerimônias do
Scrum (planejamento, reunião diária, Review e retrospectiva).
4.2.2. PROJETO SEG-B
Este projeto foi composto de 02 analistas (ambos com mais de 06 anos de
experiência), 04 programadores (três com mais de 04 anos de experiência, e um com 02 anos)
e 01 estagiário (08 meses de experiência). No quadro tecnológico, o projeto utilizou as
mesmas tecnologias que o projeto SEG-A.
O início do processo de implantação ocorreu em conversa com o cliente, explicando o
funcionamento do Scrum, que concordou em utilizá-lo no projeto. Para isso foi definido que o
Product Owner ficaria a cargo de um analista, e o Scrum Master com o outro analista. Os
demais membros da equipe formaram o Time.
Com a definição dos papéis, a concepção do projeto foi formada, onde o PO elaborou
e priorizou os itens que compuseram o Product Backlog. Em reunião de planejamento o Time
selecionou os itens do Product Backlog que entregariam na primeira Sprint. Todas as estórias
da Sprint foram entregues e aceitas pelo PO na reunião de Review. Durante a reunião de
Retrospectiva foi constatado que as estórias puderam ser entregues com a realização de
horas extras de trabalho de alguns membros do Time, percebendo que isso ocorreu devido a
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 6
falta de uma análise mais profunda das estórias, que como conseqüência tiveram suas
estimativas subestimadas.
Na segunda Sprint, todas as estórias foram entregues e aceitas pelo Product Owner,
sem necessidade de horas extras, pois nesta Sprint houve uma discussão mais detalhada na
etapa de Sprint Planning, permitindo uma estimativa mais refinada das tarefas a serem
realizadas.
5. DISCUSSÃO DOS RESULTADOS
Para a análise dos resultados da implantação do Scrum nos dois órgãos públicos foram
utilizados métodos qualitativos baseados na observação dos fatos pelo pesquisador e a partir
de conversas informais junto aos integrantes dos projetos. Um resumo dos fatores positivos e
negativos encontrados durante os processos de implantação é apresentado na Tabela 1.
Tabela 1: Fatores positivos e negativos resultantes dos processos das implantações
Fatores
Projetos
SFZ-A
SFZ-B
SEG-A
Positivos
Palestra introdutória sobre o Scrum
x
x
Experiência prévia da equipe na
metodologia
x
x
Equipe motivada
x
Aceitação à mudança
x
x
Negativos
Uso de ferramentas
computacionais de apoio ao
processo
x
x
Resistência à mudança
x
Falta de empenho/motivação
x
Para iniciar o processo de implantação, foi perceptível a importância da realização de
uma palestra explicando o fluxo e as práticas do Scrum, o que facilitou a compreensão no
assunto. Além disso, o envolvimento de pessoas com experiência prévia no uso Scrum
contribuiu para as implantações de sucesso.
Na SEFAZ-AL dois projetos foram submetidos à implantação do Scrum. Porém,
apenas o projeto SFZ-B conseguiu realizar a implantação de maneira satisfatória, devido a
motivação da equipe para o aprendizado nas novas práticas do framework, realizando
adaptações a essas práticas visando atender melhor as particularidades do projeto. O oposto
ocorreu no projeto SFZ-A, não obtendo êxito na implantação do framework.
No projeto SFZ-B, o uso do Scrum melhorou a comunicação entre os membros da
equipe; possibilitou melhoria na visibilidade do projeto; aumentou a qualidade do produto; e
aumentou a satisfação do cliente. Ainda foi possível alinhar o uso da estimativa de Análise de
Pontos por Função com o uso do Planning Poker.
Na SEGESP-AL os dois projetos as implantações do Scrum foram realizadas de
maneira satisfatória, com a obtenção de bons resultados. Isso ocorreu pelo fato de que em
ambos os projetos as equipes possuíam experiência prévia com o uso do Scrum, facilitando
assim a sua implantação. No projeto SEG-B que finalizou mais de uma Sprint, uma melhoria
significativa foi obtida com o uso das práticas propostas pelo framework, como as reuniões de
VIII SEGeT Simpósio de Excelência em Gestão e Tecnologia 2011 7
retrospectiva em que foram discutidos os pontos de melhorias para o projeto, melhorando
assim a execução da Sprint seguinte.
Foi perceptível que em ambos os órgãos o uso de ferramentas como o Virtual Scrum
Board ou o Microsoft Project em conjunto com o uso do quadro, contribui para auxiliar o
gerenciamento dos projetos.
6. CONSIDERAÇÕES FINAIS
O uso do Scrum permitiu um melhor envolvimento do cliente e comprometimento da
equipe perante os resultados, permitindo assim melhorias na qualidade de entrega dos
projetos. Houve melhorias na comunicação tanto entre os clientes e os membros da equipe,
quanto entre os próprios membros das equipes, o que permitiu um trabalho mais colaborativo.
Nem todas as implantações obtiveram resultados satisfatórios, pois as resistências dos
membros de alguns projetos inviabilizaram a implantação. Assim, foi perceptível que equipes
motivadas e abertas às mudanças no trabalho facilitaram o processo de implantação do Scrum,
permitindo o amadurecimento e a busca por melhorias no processo, de modo a atender as
particularidades de cada projeto.
Uma das limitações deste trabalho está na quantidade de projetos analisados, não
permitindo uma comparação e análise mais profunda dos resultados encontrados, de modo a
generalizá-los. Porém, isto se deve a limitação do tempo da pesquisa.
Outra limitação está na falta de descrições mais ricas dos contextos e da natureza dos
projetos, que por questões de confidencialidade de cada órgão, não foi permitida a divulgação
desses dados.
Como trabalho futuro espera-se realizar novos estudos em diferentes projetos,
utilizando a aplicação de questionários e o uso de métricas para analisar e comparar os
resultados através de dados estatísticos.
7. REFERÊNCIAS
AMBLER, S. W. State of agile survey. Version One Website, 2009.
BECK, K. Test Driven Development: By Example. Addison-Wesley, 2002.
COHN, M. Agile Estimating and Planning. Prentice Hall, 2006.
FERREIRA, C. AND COHEN, J. Agile systems development and stakeholder satisfaction: a south african
empirical study. In Proceedings of the 2008 annual research conference of the South African Institute of
Computer Scientists and Information Technologists on IT research in developing countries: riding the wave of
technology, SAICSIT 08, pages 4855, New York, NY, USA. ACM, 2008.
LINDGREN, R., HENFRIDSSON, O., AND SCHULTZE, U. Design principles for competence management
systems: A synthesis of an action research study. In Mis Quartely, volume 28, pages 435472, 2004.
RICO, D. F., SAYANI, H. H., AND SONE, S. The Business Value of Agile Software Methods: Maximizing
Roi With Just-in-time Processes and Documentation. J. Ross Publishing, 2009.
SCHWABER, K. Agile ProjectManagement with Scrum. Microsoft Press, 1st edition, 2004.
SOMMERVILLE, I. Engenharia de Software. Addison-Wesley, S˜ao Paulo, 8th edition, 2007.
STRINGER, E. T. Action Research: A Handbook for Practitioners. Sage, 1996.
TEIXEIRA, V. S. E DELAMARO, M. E. Geração de metadados para apoio ao teste estrutural de
componentes. In Workshop de teses e dissertac¸ ˜oes em qualidade de software - Simpósio Brasileiro de
Qualidade de Software (SBQS07), volume 1, pag 18, Porto de Galinhas, PE, 2007.
Powered by TCPDF (www.tcpdf.org)
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
O uso de componentes no desenvolvimento de software traz benefícios, em termos de qualidade e produtividade, mas, por outro lado, acrescenta complexidade em algumas atividades, em particular, para a atividade de teste. Nesse contexto, podem-se destacar as perspectivas do desenvolvedor e do usuário do componente. Dentre os principais problemas relacionados ao teste de aplicações baseadas em componentes está a falta de informação. O desenvolvedor não conhece os contextos de utilização do componente e o usuário ignora os requisitos e a forma de validação do componente. Propõe-se neste trabalho a utilização de medidas de cobertura de teste estrutural, fornecidas pelo desenvolvedor, para auxiliarem na integração do componente nas aplicações do usuário. Tais informações são agregadas ao componente na forma de metadados e geradas por meio de uma ferramenta que auxilia na automatização deste processo.
Conference Paper
The high rate of systems development (SD) failure is often attributed to the complexity of traditional SD methodologies (e.g. Waterfall) and their inability to cope with changes brought about by today's dynamic and evolving business environment. Agile methodologies (AM) have emerged to challenge traditional SD and overcome their limitations. Yet empirical research into AM is sparse. This paper develops and tests a research model that hypothesizes the effects of five characteristics of agile systems development (iterative development; continuous integration; test-driven design; feedback; and collective ownership) on two dependent stakeholder satisfaction measures, namely stakeholder satisfaction with the development process and with the development outcome. An empirical study of 59 South African development projects (using self reported data) provided support for all hypothesized relationships and generally supports the efficacy of AM. Iteration and integration together with collective ownership have the strongest effects on the dependent satisfaction measures.
Article
Even though the literature on competence in organizations recognizes the need to align organization level core competence with individual level job competence, it does not consider the role of information technology in managing competence across the macro and micro levels. To address this shortcoming, we embarked on an action research study that develops and tests design principles for competence management systems. This research develops an integrative model of competence that not only outlines the interaction between organizational and individual level competence and the role of technology in this process, but also incorporates a typology of competence (competence-in-stock, competence-in-use, and competence-in-the-making). Six Swedish organizations participated in our research project, which took 30 months and consisted of two action research cycles involving numerous data collection strategies and interventions such as prototypes. In addition to developing a set of design principles and considering their implications for both research and practice, this article also includes a self-assessment of the study by evaluating it according to the criteria for canonical action research.
State of agile survey. Version One Website
  • S W Ambler
AMBLER, S. W. State of agile survey. Version One Website, 2009.
The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation
  • D F Rico
  • H H Sayani
  • S Sone
RICO, D. F., SAYANI, H. H., AND SONE, S. The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation. J. Ross Publishing, 2009.
Action Research: A Handbook for Practitioners
  • E T Stringer
STRINGER, E. T. Action Research: A Handbook for Practitioners. Sage, 1996.