Desenvolvimento ágil com Scrum: uma visão geral

Considerando o cotidiano da maioria das organizações na atualidade, é inegável a importância desempenhada por sistemas computacionais dos mais variados tipos na condução de operações rotineiras. Esse suporte não apenas contribui para uma maior eficácia na execução de atividades do dia a dia, como também foi um fator determinante para um incremento substancial na produtividade de diversos processos de negócio.

A evolução da área de sistemas foi acompanhada pelo surgimento de diversas metodologias, com estas últimas normalmente englobando um conjunto de diretrizes e conceitos criados com o intuito de nortear o processo de construção de um software. Como de praxe, não há uma fórmula mágica para se chegar ao resultado final, ou seja, uma aplicação que atenda às expectativas dos usuários e seja capaz de funcionar dentro de uma série de parâmetros considerados como aceitáveis. Partindo de um conjunto de técnicas e diretrizes com eficácia já comprovada, os profissionais envolvidos empreendem esforços no sentido de adaptar um modelo para a realidade na qual se encontram inseridos.

É importante frisar sempre que desenvolver softwares não é uma tarefa das mais simples. Uma ampla gama de variáveis influencia no modo como uma aplicação será construída, somando-se ainda a isto influências como a pressão pela entrega do produto em um prazo muito curto, mudanças motivadas por alterações na legislação vigente, dificuldades dos usuários que solicitam um sistema em descrever de forma clara e concisa aquilo que realmente necessitam (com prováveis pedidos de modificações ao longo do projeto), dentre outros aspectos.

A noção de mudança também representa um elemento central na elaboração de aplicações. Por mais que todo um esforço procurando contemplar um número extenso de situações seja levado a cabo, é praticamente impossível construir um software que em determinado momento não precise passar por alterações. Aliás, é bastante comum que exista a necessidade de modificações durante a construção da aplicação, comprometendo assim uma parcela do tempo e de recursos que já haviam sido alocados para a implementação daquela solução.

Em um cenário de transformações constantes, a escolha pelo paradigma de desenvolvimento mais adequado a um determinado contexto é, sem sombra de dúvidas, um fator crucial para o sucesso do projeto. As primeiras técnicas formais voltadas à construção de sistemas possuíam um enfoque direcionado à elaboração de soluções com uma estrutura mais rígida e, portanto, eram menos suscetíveis a mudanças. A necessidade de uma rápida adaptação diante de situações imprevistas é um dos aspectos que caracteriza o mundo corporativo atual; procurando atender a este tipo de demanda, surgiriam práticas mais flexíveis para a criação de aplicações, com diversas destas sendo conhecidas como “metodologias ágeis”.

O objetivo deste artigo é abordar, em linhas gerais, como métodos ágeis podem ser empregados em atividades relacionadas com o desenvolvimento de sistemas. Isto será feito, basicamente, através de um estudo mais detalhado de um conjunto de práticas com uma grande aceitação na área de software atualmente: trata-se da metodologia Scrum.

Metodologias de desenvolvimento de software: uma visão geral

O modelo em cascata (em inglês “waterfall”) foi, ainda na década de 1970, um dos primeiros padrões a fornecer diretrizes para processos voltados ao desenvolvimento de software. Esta metodologia é caracterizada por fases que ocorrem dentro de uma sequência rígida, com o início das atividades de uma etapa acontecendo imediatamente após o término daquela que a precedeu. A implementação de um projeto que segue este modelo é geralmente dividida nas seguintes fases: análise de requisitos, projeto da aplicação, implementação, testes de validação, implantação e manutenção.

De certa forma, esta abordagem é bastante semelhante à da linha de montagem clássica do mundo fabril. Considerando o cenário atual, em que muitas organizações se veem às voltas de transformações profundas e muitas vezes repentinas, a maneira linear que este modelo impõe à atuação dentro de um projeto de software revela-se como um fator deveras limitante.

Após uma fase inicial em que se apresentam as expectativas e em que se estabelece o escopo da aplicação a ser gerada, a área que solicitou um sistema apenas terá uma visão do resultado ao término do projeto. Mudanças eventuais em requisitos ou, mesmo, em regras que definem o comportamento destes podem prejudicar todo um esforço de meses. Tais alterações podem ainda comprometer um orçamento previamente acordado, além de não ser raro que o produto resultante sequer chegue a ser utilizado (por estar distante daquilo que se aguardava).

Conforme já frisado neste artigo, o cotidiano dinâmico de muitas organizações acabaria impondo o surgimento de um novo enfoque para a construção de softwares. Com base em uma série de parâmetros pré estipulados, mas que também se encontram sujeitos a mudanças ao longo de um projeto, outras abordagens foram desenvolvidas de forma a tornar o desenvolvimento de aplicações mais flexível e produzindo resultados mais próximos do esperado.

Procurando fazer um contraponto às deficiências do modelo cascata, a metodologia RUP (Rational Unified Process) foi criada para permitir um desenvolvimento incremental e com entregas sucessivas de partes do software combinado. Amparando-se em conceitos da Orientação a Objetos, além de representação de estruturas de sistemas por meio da linguagem UML.

RUP é uma boa alternativa para projetos de grande porte que exigem um processo bem estruturado e que prime por uma documentação rica em detalhes. Esta é uma demanda bastante comum em organizações sujeitas a rigorosos procedimentos de auditoria. Este modelo está dividido em fases de análise (Concepção), modelagem e arquitetura do sistema a ser entregue (Elaboração), implementação (Construção) e Transição (implantação), sendo possível ainda que as diferentes atividades destas etapas possam vir a acontecer de maneira paralela em determinados momentos.

Ainda sobre o RUP, esta metodologia é, na verdade, uma implementação de um processo conhecido como Unified Process, representando uma solução específica da IBM para a condução de atividades voltadas ao desenvolvimento de software. É importante destacar também que existe uma série de ferramentas disponibilizadas para a geração dos diversos artefatos previstos por este modelo.

Nem sempre um processo trabalhoso e extremamente detalhado como o RUP pode ser a melhor alternativa em projetos de software. Equipes de tamanho reduzido, projetos que não são extensos e requisitos mudando constantemente motivariam a busca por novas formas de se controlar o processo de desenvolvimento de uma aplicação. Essas necessidades levariam, consequentemente, ao desenvolvimento de uma série de padrões que compõem um agrupamento de técnicas conhecidas como metodologias ágeis.

Em 2001 seria publicado, a partir do trabalho conjunto de diversos especialistas da área de sistemas, o Manifesto para Desenvolvimento Ágil de Software. Tal declaração enfatiza a entrega de software operável, atuando em conjunto com o solicitante do mesmo, além de frisar a necessidade de uma interação adequada entre os diversos envolvidos num projeto e a flexibilidade diante de mudanças. São doze os princípios que norteiam o Manifesto Ágil (ou em inglês “Agile Manifesto”):

• Satisfação das expectativas da área solicitante/cliente;
• Uma postura mais positiva diante da necessidade de mudanças, procurando inclusive obter benefícios e explorar oportunidades não vislumbradas antes;
• Entregas mais frequentes, a fim de possibilitar que o cliente possa acompanhar melhor a evolução do projeto, visando assegurar que os requisitos esperados realmente têm sido atendidos;
• A colaboração entre todos aqueles que participam do projeto, quer sejam pessoas da área que solicitou a aplicação ou, mesmo, desenvolvedores focados em atividades de implementação, de forma a se agir como um time coeso;
• Assegurar que existam condições para que todos possam trabalhar motivados;
• Transmissão de informações através de conversas face a face;
• Garantir que o software é entregue funcionando;
• Manter um ritmo constante de trabalho, de forma que o processo como um todo continue de um modo sustentável, sem grandes percalços;
• Forte ênfase na qualidade do que é produzido;
• Foco na simplicidade;
• Equipes auto-organizáveis, capazes de tomar decisões técnicas que viabilizem a evolução contínua do processo em que se encontram inseridas;
• Uma reflexão constante dos rumos que estão sendo trilhados, a fim de se aumentar a eficácia da equipe, bem como ajustar o comportamento da mesma para com metas estabelecidas previamente.

Além do Scrum que será descrito em maiores detalhes nas próximas seções, outras modelos ágeis que desfrutam de uma boa aceitação na área de desenvolvimento de software são as metodologias XP e Lean IT.

XP (abreviação do inglês “Extreme Programming”) é uma metodologia de desenvolvimento de software que se caracteriza por uma forte ênfase na elaboração e execução contínua de testes unitários, bem como pela codificação em pares: uma dupla de desenvolvedores participa da implementação de uma ou mais funcionalidades, sendo que isto acontece em torno de um único computador, com a pessoa responsável por escrever o código sendo auxiliada pelo parceiro que a observa e a orienta conforme a evolução das atividades. Esta abordagem em que dois profissionais interagem em conjunto procura diminuir a incidência de falhas, assim como possibilitar uma melhor qualidade do código resultante.

Lean IT é uma metodologia ágil baseada no modelo de gestão de produção da montadora japonesa Toyota. Este método prioriza a organização das atividades em uma maneira na qual se elimine ou reduza a perda de recursos (sobretudo tempo), de forma a tornar a aumentar a eficiência dos processos e atender mais rapidamente às necessidades das áreas que solicitaram um projeto.

Independentemente da opção escolhida para gerenciar projetos dentro da área de Tecnologia, é necessário sempre ter em mente que cada padrão pode ser adaptado ou, até mesmo, combinado a outra abordagem, de maneira a se adaptar melhor às necessidades da organização.

Métodos ágeis não estão restritos a uma tecnologia (.NET, Delphi, Java etc.); na verdade, as diversas técnicas existentes procuram ser a base para uma mudança de postura rumo a um melhor gerenciamento das atividades cotidianas.

Desenvolvimento ágil com Scrum

Scrum é uma metodologia ágil voltada ao desenvolvimento de software. Surgido ainda na década de 1990, este modelo é resultado dos esforços conjuntos de especialistas da área de sistemas, com destaque especial para Ken Schwaber e Jeff Sutherland. O termo “scrum” é originário do meio esportivo: no jogo de rugby esta palavra de língua inglesa refere-se ao reinício de uma partida logo após uma infração leve. Na Figura 1 é apresentada a representação esquemática de um processo baseado nesta metodologia, com os diferentes itens citados sendo descritos nas próximas seções.

Assim como outros métodos com um enfoque similar, a proposta do Scrum é fornecer subsídios para o gerenciamento de atividades muitas vezes complexas, porém de uma forma flexível e que facilite a adaptação do projeto diante das inevitáveis mudanças. São três as ideias principais em que a metodologia Scrum se ampara:

• Transparência;
• Inspeção;
• Adaptação.

A noção de transparência deve ser compreendida como a existência de um consenso mútuo entre todos os participantes de um projeto, considerando para isto termos específicos de negócio, regras que caracterizam processos e outros aspectos. Inclusive o significado de "pronto", algo tão controverso em projetos de software que apresentam deficiências, está contemplado dentro do conceito de transparência.

Outro ponto importante da metodologia Scrum é a atividade de inspeção. A verificação contínua do que é produzido é fator determinante para que se tenha a certeza de que o projeto caminha dentro do estipulado, bem como para diagnosticar desvios indesejáveis e atuar de forma corretiva sobre estes últimos.

Já o conceito de adaptação vai de encontro a uma dos principais objetivos dos métodos ágeis: a flexibilidade diante de mudanças. Não serão raras as ocasiões em que alterações em demandas de clientes ou ainda, regulamentações governamentais e de ordem setorial, acarretarão desvios de rotas preestabelecidas. Diante disto, ajustes se fazem necessários, atenuando desse modo outros efeitos indesejáveis em momentos posteriores.

Os diferentes papéis de atuação na metodologia Scrum

Um conjunto de papéis bem definidos determina, através de atribuições, como será a atuação dos diversos profissionais que participarão de um projeto baseado na metodologia Scrum:

• Product Owner: representante da área cliente/solicitante;
• Scrum Master: o líder que gerenciará o projeto;
• Equipe de Desenvolvimento/Time: os profissionais responsáveis pela criação do produto esperado.

O Product Owner é o ponto que centraliza a interação com a área/grupo de usuários que solicitou a execução de um projeto. A partir do mesmo são definidas prioridades, o que deverá ou não ser implementado e a validação dos diferentes resultados ao longo do processo de desenvolvimento.

Já o Scrum Master corresponde ao papel do Gerente de Projetos tradicional. Além de ser um facilitador removendo impedimentos e um mediador em prováveis conflitos, este profissional garante que a equipe sob sua supervisão siga de maneira adequada as práticas de Scrum.

Por fim a Equipe de Desenvolvimento (ou Time) elabora estimativas, estipula tarefas, implementa o produto dentro de níveis de qualidade preestipulados e cuida da apresentação do mesmo ao cliente/solicitante. Conforme já mencionado anteriormente, espera-se que tal equipe conte com um caráter auto gerenciável, com o comprometimento e uma postura multifuncional dos membros representando um fator crucial para o sucesso do projeto.

Além dos três papéis já descritos, certamente também existirão envolvidos com o projeto, mas que não desempenham um papel direto na sua execução. Estes elementos podem englobar usuários, gerentes, diretores ou departamentos que possuem interesses (neste caso são conhecidos dentro da Gerência de Projetos como “stakeholders”) ou ainda, são afetados pelos resultados do produto final.

Considerando tudo isto, criou-se uma forma lúdica de representar o grau de comprometimento de uma pessoa em um projeto que segue as práticas do Scrum; para isto, foi utilizada uma sequência de histórias em que interagem um porco e um frango (Figura 2). Porcos representariam profissionais realmente engajados/comprometidos com o sucesso do projeto (Product Owner, Scrum Master, Time), ao passo que frangos seriam pessoas relacionadas indiretamente e sem uma maior disposição para com o mesmo (usuários comuns, gerentes ou áreas afetadas).

Eventos possíveis em Scrum

Como outros métodos ágeis, Scrum é uma metodologia que prima pelo desenvolvimento iterativo e incremental de software. Em termos práticos, isto significa que ciclos contendo um conjunto de específico de atividades são repetidos continuamente ao longo de um projeto; por incremental, deve-se ter em mente a ideia de sucessivas entregas de funcionalidade, acrescentando aquilo que se espera do software em intervalos constantes de tempo.

Antes de prosseguir com a descrição dos diferentes eventos de Scrum, faz-se necessário conceituar as idéias de Time-Box e Sprint. Uma Time-Box nada mais é do que a quantidade de tempo estipulado para a realização de uma iteração. Esta última recebe o nome de Sprint, sendo que essa estimativa de tempo não pode ser alterada, a fim de com isto garantir a entrega sem atrasos e facilitar o planejamento. Diante da possibilidade de erros na estimativa, deve-se proceder com uma redução do escopo, sem contudo afetar substancialmente as metas da Sprint ou obrigar a um aumento na quantidade de horas ou dias planejados. O comum é que uma Sprint dure de duas a quatro semanas.

A partir destas explanações, são possíveis dentro de Scrum os seguintes eventos:

• Reunião de Planejamento da Sprint;
• Reunião Diária;
• Revisão da Sprint;
• Retrospectiva da Sprint.

A Reunião de Planejamento da Sprint é uma atividade com duração de 8 horas e da qual participam todos os profissionais comprometidos com o projeto (Product Owner, Scrum Master, Equipe de Desenvolvimento). Esta reunião é formada por duas etapas: num primeiro momento o Product Owner define a prioridade de funcionalidades a serem implementadas (a partir do Backlog); posteriormente, a Equipe montará sua própria lista de trabalho (Sprint Backlog) com base no que foi exposto pelo Product Owner.

Já a Reunião Diária é uma curta sessão de 15 minutos, em que membros da Equipe e o Scrum Master comentam a situação atual (muitas vezes em pé dentro de um recinto). Isto normalmente envolve uma rápida explanação do que foi feito no dia anterior, o que será realizado na data atual e uma discussão de prováveis impedimentos que foram encontrados.

A Revisão da Sprint é uma reunião de normalmente 4 horas, em que estão presentes o Product Owner, o Scrum Master e a Equipe (pode acontecer ainda de outras pessoas serem convidadas para participar). As atividades desempenhadas durante a Sprint são apresentadas, procedendo-se com a entrega do software funcionando (conforme pregado pela metodologia).

Por fim, há ainda a Retrospectiva da Sprint. Trata-se de uma reunião de geralmente 3 horas entre Equipe e Scrum Master. Nesta discussão aborda-se o que deu certo e aquilo que falhou, além de se estudarem formas para se melhorar num próximo ciclo (Sprint).

Artefatos de Scrum

Por mais que como uma metodologia ágil Scrum priorize a entrega do software em detrimento de uma extensa e trabalhosa documentação, a elaboração e a consequente manipulação de alguns artefatos neste modelo é de fundamental importância para o controle das atividades rotineiras. A seguir estão listados tais documentos:

• Backlog do Produto (ou em inglês “Product Backlog”);
• User Story;
• Sprint Backlog;
• Gráfico de Burn Down.

O Product Backlog é uma listagem que contempla todas as funcionalidades desejadas para o software que se está implementando. Além disso, as informações contidas neste tipo de controle podem conter ainda uma ordem de prioridade, sendo incumbência do Product Owner criar e controlar o status dos diferentes elementos do Backlog.

Uma User History é uma pequena história que descreve as características esperadas para uma funcionalidade constante no Backlog do Produto. Constam no documento que representa tal história um título, uma descrição clara do que se necessita, bem como é possível se indicar ainda uma prioridade para execução da tarefa.

A Sprint Backlog é uma relação de tarefas elaborada pelo Time de Desenvolvimento durante a segunda etapa da Reunião de Planejamento da Sprint. Trata-se de algo que está em conformidade com o conceito de equipes auto-gerenciáveis, uma vez que os profissionais responsáveis por isto planejam como será o dia a dia de desenvolvimento a partir das prioridades apontadas pelo Product Owner.

O Gráfico de Burn Down é uma ferramenta de gerenciamento. Este artefato costuma ser atualizado diariamente, servindo de base para a comparação entre o que foi planejado e aquilo que realmente se realizou. Pode ser considerado um instrumento para tomada de decisão, uma vez que fornece embasamento para ações em prol de uma maior produtividade ou ainda, a fim de atenuar riscos iminentes.

Conclusão

Mudanças são algo praticamente certo durante a construção de uma aplicação de software. O grande dinamismo do mundo atual força as organizações a se adequarem de maneira rápida a transformações repentinas, a fim de com isto assegurar a continuidade da operação das mesmas dentro do mercado em que estão inseridas. A possibilidade de alterações nas “regras do jogo” a qualquer instante foram os grandes motivadores para o surgimento das metodologias ágeis.

Scrum é mais um método ágil, representando uma alternativa flexível para orientar equipes na entrega de sistemas com qualidade. Diversas ferramentas de software (gratuitas ou proprietárias) já foram desenvolvidas, auxiliando assim o dia a dia de profissionais envolvidos em projetos que adotaram esta metodologia.

Conforme discutido aqui, não existe um truque que facilite a condução de atividades voltadas ao desenvolvimento de software. Diversos métodos foram propostos por pesquisadores da área, sendo que nenhum destes modelos representa uma verdade. A maturidade dos profissionais de um projeto sempre terá seu peso no sucesso ou fracasso deste.

Além disso, um padrão adequado ao gerenciamento de um determinado contexto pode-se revelar como um entrave num outro tipo de situação. Em certos casos é possível até que um conjunto de técnicas precise ser modificado, com ajustes tornando a metodologia em questão melhor adaptada às demandas da equipe de projetos considerada.

Espero que o conteúdo aqui apresentado possa ter sido útil. Até uma próxima oportunidade!