1.3.1 Objetivo Geral
Identificar limitadores de práticas ágeis do método Scrum, em projetos de desenvolvimento de software e suas soluções de contorno, no contexto da organização e de projeto.
1.3.2 Objetivos Específicos
A fim de alcançar o objetivo geral deste trabalho faz-se necessária a execução dos seguintes objetivos específicos, no âmbito do método Scrum:
Descrever o método Scrum de desenvolvimento ágil de software, detalhando papéis, instrumentos e práticas;
Identificar práticas ágeis críticas;
Identificar e relacionar limitadores de projeto e organizacionais à adoção de práticas ágeis; e
Identificar e relacionar soluções de contorno para limitadores à adoção de práticas ágeis.
1.4 RELEVÂNCIA
A relevância teórica deste trabalho reside na ampliação do conhecimento científico- acadêmico acerca dos limitadores à adoção de práticas ágeis, mais especificamente as práticas do método Scrum, que é o mais adotado no momento, no âmbito de desenvolvimento de software. Essa ampliação se dará pela identificação de novos limitadores e respectivas soluções de contorno.
A relevância prática deste trabalho está na possibilidade de empresas interessadas em adotar o método Scrum vejam as práticas críticas e os limitadores identificados nesta pesquisa como pontos de atenção. Por outro lado, as empresas que já adotam o método poderão se beneficiar das soluções de contorno encontradas neste trabalho, a fim de minimizar as consequências dos limitadores.
1.5 ESTRUTURA DO TRABALHO
Além da presente seção de Introdução, esta dissertação é composta das seguintes seções: 2) Métodos Ágeis, onde é descrita a origem desses métodos, seus princípios e valores; 3) Método Scrum, que detalha a história do método, bem como seus componentes e dinâmica, relacionando limitadores e soluções de contorno presentes na teoria; 4) Metodologia, onde são relatados todos os passos e instrumentos utilizados na execução do presente trabalho; 5) Scrum na Infoglobo, que expõe as particularidades da adoção do método Scrum no local de pesquisa; 6) Resultados e Análises, onde são discutidos os dados levantados durante a pesquisa de campo e suas contribuições para o alcance do objetivo geral; e 7) Considerações Finais, que apresenta a conclusão, contribuições e limitações desta dissertação, além de sugerir trabalhos futuros.
2 MÉTODOS ÁGEIS
2.1 VISÃO GERAL
Os métodos ágeis, conforme mencionado anteriormente, surgiram na década de 90 como uma reação às limitações dos métodos tradicionais. No Quadro 6, traduzido do trabalho de Nerur, Mahapatra e Mangalaraj (2005), é possível analisar as diferenças entre os dois grupos de métodos.
Quadro 6 - Método Tradicional versus Método Ágil
Dimensões Tradicional Ágil
Pressupostos Fundamentais
Sistemas são totalmente
especificáveis, previsíveis e podem ser construídos por meio de meticuloso e extenso planejamento.
De alta qualidade, o software pode ser desenvolvido por equipes pequenas, utilizando os princípios de melhoria contínua e testes com base no feedback rápido e mudanças.
Controle Focado em processos Focado em pessoas Estilo de gestão Comando e controle Liderança e colaboração Gestão do conhecimento Explícito Tácito
Atribuição de papéis Individual - favorece a especialização Equipes autogerenciadas - incentiva troca de papéis
Comunicação Formal Informal
Papel do cliente Importante Crítico
Ciclo do projeto Guiado por tarefas ou atividades Guiado pelas características do produto Método de
desenvolvimento Cascata, Espiral e outras variações Modelo de entregas evolutivas Forma/estrutura
organizacional desejada
Mecanicista (burocrática com alta formalidade)
Orgânica (flexível e participativa, incentivadora de ação social cooperativa) Tecnologia Sem restrições Favorecido por tecnologia orientada a objeto. Fonte: Nerur, Mahapatra e Mangalaraj (200, p. 75), traduzido pela Autora.
Nerur, Mahapatra e Mangalaraj (2005) sugerem o contexto mais apropriado para cada grupo de métodos. Os tradicionais se adequam melhor aos ambientes estáveis, com poucas mudanças e às empresas com alta formalidade. Já os métodos ágeis estão preparados para lidar com um ambiente em constante mudança e mais informal.
Esses métodos foram oficialmente propostos em fevereiro de 2001, nos Estados Unidos, por dezessete desenvolvedores de software experientes. Entre esses desenvolvedores estavam Jeff Sutherland, Ken Schwaber e Mike Beedle, propulsores do método Scrum na década de 90. Também estavam presentes os criadores do XP, do Dynamic Systems Development Method (DSDM), do Adaptive Software Development (ASD), do Crystal, do Feature-Driven Development (FDD) e do Pragmatic Programming (PP). Segundo Highsmith
(2001), o objetivo da reunião era identificar a base comum desses novos métodos, já que se fazia necessário buscar uma alternativa aos métodos tradicionais baseados em muita documentação.
Desse encontro surgiu o Manifesto Ágil, onde foram descritos os valores e os princípios dos métodos ágeis. Para melhor compreender o que isso significa é necessário conceituar e exemplificar os seguintes termos: valor, princípio, prática e método. Para Beck e Andres (2004), valor é o critério pelo qual julgamos o que vemos, pensamos e fazemos. Os valores são universais, não mudam ao longo da vida. Já as práticas são dependentes do contexto e devem ser claras, objetivas e evidenciar os valores (BECK; ANDRES, 2004). Para os autores, práticas sem valores, não passam de atividades sem propósito ou direção. Ainda, segundo Beck e Andres (2004), para estabelecer uma ligação entre valor e prática, se fazem necessários os princípios, que são diretrizes específicas para a vida, ou seja, “Os princípios são a ponte entre os valores e as práticas.” (BECK; ANDRES, 2004, p. 25). Em relação aos métodos, os autores os definem como um conjunto de práticas que produzem bons resultados (BECK; ANDRES, 2004).
Soares (2011), seguindo a conceituação de Beck e Andres (2004), exemplificou valor como respeito ao próximo. Um dos princípios derivado desse valor, seria o ritmo sustentável, ou seja, manter a produtividade e qualidade ao longo de todo o desenvolvimento. A prática a ser adotada para atingir esse princípio seria a limitação do trabalho semanal em 40 horas. Com essa prática estar-se-ia preservando o valor de respeito ao próximo não só em relação à equipe desenvolvedora, mas, também ao cliente, que teria a entrega sistemática de produto com qualidade ao longo do projeto. Para finalizar, Soares (2011) exemplificou método como o XP, uma vez que a prática de limitação de carga horária faz parte desse método ágil.
Retornando ao Manifesto Ágil, onde foram elencados os valores e princípios dos métodos ágeis, Beck et al. (2001, p. 1) definiram os seguintes valores:
Indivíduos e interações [são] mais [importantes] que processos e ferramentas. Software em funcionamento [é] mais [importante] que documentação abrangente. Colaboração com o cliente [é] mais [importante] que negociação de contratos. Responder a mudanças [é] mais [importante] que seguir um plano.
Os idealizadores dos métodos ágeis reconheceram que apesar dos processos, ferramentas, documentação, negociação de contratos e planejamento terem valor para o desenvolvimento de software, os indivíduos e suas interações, o software funcionando, a colaboração com o cliente e a resposta às mudanças eram mais importantes e, consequentemente, mais valorizados (BECK et al., 2001).
Em outras palavras, Beck et al. (2001) não concordam com o desperdício de esforço dos desenvolvedores e dos clientes na produção de documentação ou planejamento, a menos que sejam realmente necessários e não por se constituírem em produtos de processos estabelecidos na metodologia adotada.
Considerando-se que os valores são genéricos e que os princípios, com suas diretrizes, levam às práticas, Beck et al. (2001, p. 2) definiram os seguintes princípios para os métodos ágeis:
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade. 10. Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é
essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
É possível estabelecer uma ligação dos valores apresentados anteriormente com pelo menos um dos 12 princípios acima. Por exemplo, a preocupação com os indivíduos e suas interações está presente nos princípios de número 1, 4, 5, 6, 8, 11 e 12. Já as práticas, que devem ser claras e objetivas, vão variar de acordo com o método ágil.