Qual fator deve ser considerado ao estabelecer a duração da Sprint?

Nesse artigo vamos apresentar uma pequena introdu��o sobre as tecnologias aqui comparadas e, em seguida, veremos qual melhor se encaixa nas diversas modalidades de um projeto de software.

Se voc� quer se aprofundar mais nesse tema, voc� n�o pode deixar de conferir os cursos de Engenharia de Software da DevMedia.

Scrum

O SCRUM � uma metodologia �gil de trabalho onde � usada para estabelecer conjuntos de regras e pr�ticas de gest�o para conseguir o sucesso de um projeto. Com o foco no trabalho em equipe, ocorre uma melhora na comunica��o e maximiza o apoio de todos, fazendo com que todos do time se esforcem e se sintam bem com que est�o fazendo e isso acaba gerando mais para frente um aumento de produtividade.

Jeff Sutherland colocou em pr�tica a primeira concep��o do SCRUM na Easel Corporation em 1993 e em 1995, Ken Schwaber pegou essa metodologia e refinou baseando-se com sua experi�ncia em desenvolvimento de sistemas e processos.

As principais caracter�sticas do SCRUM s�o:

• � um processo �gil para gerenciar e controlar o desenvolvimento de projetos;
• � um wrapper para outras pr�ticas de engenharia de software;
• � um processo que controla o caos resultante de necessidades e interesses conflitantes;
• � uma forma de aumentar a comunica��o e maximizar a coopera��o;
• � uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto;
• � escal�vel desde projetos pequenos at� grandes projetos em toda empresa.

O modo de organiza��o no SCRUM � feito da seguinte forma (Figura 1):

1. Cria-se o backlog onde tem a lista de todas as funcionalidades que precisam ser desenvolvidas durante todo o projeto, junto com o stakeholder, onde precisa ser bem definido e detalhado no come�o, listado e ordenado por prioridade do que � mais importante;
2. Com o backlog pronto, cria-se o sprint backlog, onde se decide o tempo necess�rio (dentro dos 30 dias) para criar a funcionalidade requisitada;
3. Depois de todo o planejamento, os itens do backlog s�o divididos nas equipes e entra no sprint que pode durar de 2 a 4 semanas.
4. A cada 24 horas tem uma reuni�o com os membros de equipes e quest�es devem ser respondias como:
   - O que voc� fez desde a �ltima reuni�o?
   - O que te impede de continuar?
   - O que vai fazer at� a pr�xima reuni�o?
   
5. Ao termino do sprint as funcionalidades requisitadas s�o demonstradas.

O SCRUM, como � um m�todo �gil, e os m�todos �geis acabam tendo v�rias semelhan�as, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles t�m a raiz fundamentada em um manifesto �gil.

XP - eXtreme Programming

XP foi criado por Kent Beck quando trabalhava na Chrysler Comprehensive Sistema de Compensa��o (C3) no projeto da folha de pagamento. Quando Beck tornou-se C3 l�der do projeto em mar�o de 1996, ele come�ou a refinar o m�todo de desenvolvimento usado no projeto e logo em seguida ele escreveu um livro. E em outubro de 1999, a Extreme Programming foi publicada. Em fevereiro de 2000, a Daimler-Benz adquiriu a Chrysler e acabou cancelando o projeto C3.

O XP � uma metodologia �gil de desenvolvimento de softwares focada na agilidade de equipes e na qualidade dos projetos e tem como seus valores a simplicidade, o feedback, a comunica��o, a coragem, o respeito.

O XP tem como seus princ�pios b�sicos o feedback r�pido, a simplicidade, a ideia de abra�ar mudan�as, fazer um trabalho de qualidade e aceitar mudan�as incrementais.

Uma frase onde Vin�cius Teles fala na TDC 2008 � muito interessante onde ele demonstra claramente que a simplicidade � fundamental no projeto, e a frase que ele diz �:

"Na hora do desenvolvimento do software, para aplicar os princ�pios e valores, o XP sugere uma s�rie pr�ticas porque h� uma grande confian�a na uni�o entre elas pois os pontos fracos de cada uma s�o cobertos pelo ponto forte das outras."

Segundo Kent Beck, as pr�ticas s�o as seguintes (Figura 2):

• Jogos de Planejamento(Planning Game): O desenvolvimento � feito em itera��es semanais. No in�cio da semana, desenvolvedores e cliente re�nem-se para priorizar as funcionalidades. Essa reuni�o recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente � essencial neste processo e assim ele fica sabendo o que est� acontecendo e o que vai acontecer no projeto. Como o escopo � reavaliado semanalmente, o projeto � regido por um contrato de escopo negoci�vel, que difere significativamente das formas tradicionais de contrata��o de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produ��o.
• Pequenas Vers�es (Small Releases): A libera��o de pequenas vers�es funcionais do projeto auxilia muito no processo de aceita��o por parte do cliente, que j� pode testar uma parte do sistema que est� comprando. As vers�es chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.
• Met�foras (Metaphor): Procura facilitar a comunica��o com o cliente, entendendo a realidade dele. O conceito de r�pido para um cliente de um sistema jur�dico � diferente para um programador experiente em controlar comunica��o em sistemas em tempo real, como controle de tr�fego a�reo. � preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
• Projetos Simples (Simple Design): Simplicidade � um princ�pio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira vers�o apenas o usu�rio "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, voc� vai fazer o c�digo exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autentica��o e restri��es de acesso. Um erro comum ao adotar essa pr�tica � a confus�o por parte dos programadores de c�digo simples e c�digo f�cil. Nem sempre o c�digo mais f�cil de ser desenvolvido levar� a solu��o mais simples por parte de projeto. Esse entendimento � fundamental para o bom andamento do XP. C�digo f�cil deve ser identificado e substitu�do por c�digo simples.
• Time Coeso (Whole Team): A equipe de desenvolvimento � formada pelo cliente e pela equipe de desenvolvimento.
• Testes de Aceita��o (Customer Tests): S�o testes constru�dos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.
• Ritmos Sustent�veis (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saud�vel (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras s�o permitidas quando trouxerem produtividade para a execu��o do projeto. Outra pr�tica que se verifica neste processo � a pr�tica de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motiva��o da equipe devem estar sempre em harmonia.
• Reuni�es em p� (Stand-up Meeting): Reuni�es em p� para n�o se perder o foco nos assuntos, produzindo reuni�es r�pidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
• Posses Coletivas (Collective Ownership): O c�digo fonte n�o tem dono e ningu�m precisa solicitar permiss�o para poder modificar o mesmo. O objetivo com isto � fazer a equipe conhecer todas as partes do sistema.
• Programa��es em Pares (Pair Programming): � a programa��o em par/dupla num �nico computador. Geralmente a dupla � formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como � apenas um computador, o novato � que fica � frente fazendo a codifica��o, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre � revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolu��o da equipe, melhorando a qualidade do c�digo fonte gerado.
• Codifica��o (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecer� que todo o c�digo fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
• Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unit�rios (unit tests) e depois crie o c�digo para que os testes funcionem. Esta abordagem � complexa no in�cio, pois vai contra o processo de desenvolvimento de muitos anos. S� que os testes unit�rios s�o essenciais para que a qualidade do projeto seja mantida.
• Refatora��o (Refactoring): � um processo que permite a melhoria continua da programa��o, com o m�nimo de introdu��o de erros e mantendo a compatibilidade com o c�digo j� existente. Refabricar melhora a clareza (leitura) do c�digo, divide-o em m�dulos mais coesos e de maior reaproveitamento, evitando a duplica��o de c�digo-fonte;
• Integra��o Cont�nua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar � vers�o atual do sistema. Isto s� aumenta a possibilidade de conflitos e a possibilidade de erros no c�digo fonte. Integrar de forma cont�nua permite saber o status real da programa��o.

Compara��o entre scrum e eXtreme programming

O SCRUM, como � um m�todo �gil, e os m�todos �geis acabam tendo v�rias semelhan�as, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles tem a raiz fundamentada em um manifesto �gil.

O SCRUM � uma forma de gest�o ampla para projetos que n�o depende da �rea de conhecimento. J� o XP tem sua aplica��o mais restrita, focada basicamente no mundo de desenvolvimento de sistemas de softwares.

Entretanto, quando usamos o SCRUM como forma de gest�o e para cria��o de sistemas de software, muitas das pr�ticas contidas no XP s�o de grande compet�ncia, como por exemplo a cria��o de testes automatizados ou o uso de refatora��o de c�digo para que um trecho de c�digo funcional seja alterado buscando um ganho de qualidade e garantindo que a manuten��o futura seja simplificada.

Execu��o de um Projeto com Scrum

A empresa em que foi aplicado o estudo de caso se enquadra no ramo de desenvolvimento de software. � uma entidade civil sem fins lucrativos que se orgulha por ser uma das refer�ncias nacionais em qualidade e efici�ncia na �rea de tecnologia da informa��o e comunica��o. Possui ISO 9001:2008 e CMMI n�vel 5 e busca a melhoria cont�nua dos seus processos. O projeto na qual foi desenvolvido era para a plataforma de hardware Windows XP profissional, a ferramenta de desenvolvimento era o Microsoft Visual Studio 2008, a ferramenta de banco de dados SQL Server 2005, a ferramenta de an�lise e projeto o Enterprise Architect, ferramenta de acompanhamento de bugs JIRA, sedo o mesmo produzido para a plataforma desktop. O projeto possu�a 221 pontos de caso de uso t�cnicos (TUCP) e era enquadrado na modalidade de F�brica de Solu��o, na qual s�o projetos em que a equipe do projeto trabalha com a equipe do cliente desde a etapa inicial de avalia��o de necessidades e concep��o de requisitos, ajudando o cliente a gerar uma solu��o de alto valor agregado para seu neg�cio.

Visando a necessidade da melhoria no gerenciamento dos projetos resolveu-se aplicar Scrum em um projeto e analisar o desempenho de produtividade do projeto com o emprego desta metodologia.

Aplicar Scrum traz v�rias mudan�as, principalmente culturais na empresa. Para o in�cio da utiliza��o do Scrum, como primeiro passo aplicou-se um treinamento para todos os colaboradores para que todos pudessem conhecer as atividades a serem desempenhadas na nova metodologia de ger�ncia de projeto e assim nivelar o conhecimento adquirido.

No treinamento foram repassados os conhecimentos acerca do ciclo do Scrum e mostrado em detalhes cada evento a ser executado com o emprego da metodologia �gil, assim como as vantagens e facilidades proporcionadas pelo Scrum.

O segundo passo foi realizar o planejamento inicial do projeto. Cada Sprint teve sua dura��o definida em tr�s semanas, assim a cada rodada tinha que ser entregue uma parte incremental do produto testado e funcionando. No total, foram definidas cinco Sprints para a conclus�o do projeto.

A princ�pio, foram definidas as seguintes atividades a serem realizados no projeto e estas foram enquadradas no Backlog:

• Levantamento dos requisitos.
• Especifica��o dos requisitos.
• An�lise e Projeto.
• Especifica��o de testes.
• Revis�o t�cnica.
• Implementa��o.
• Testes.
• Corre��o.
• Entrega.

Em seguida, o plano do projeto foi montado e apresentado ao cliente. O cliente foi envolvido inicialmente com participa��o ativa de forma remota para a defini��o das prioridades das atividades. Para cada Sprint realizou-se um Sprint Planning Meeting, ou seja, uma reuni�o para planejamento da Sprint, de modo que pudesse definir dentre as atividades do Backlog aqueles que seriam executadas na Sprint. Al�m disso, a cada in�cio do dia o gerente do projeto realizava a Daily Meeting, ou seja, a reuni�o di�ria para acompanhamento das atividades do projeto (atividades a fazer, atividades finalizadas, atividades em andamento), assim como para a identifica��o dos impedimentos ocorridos no dia anterior para que fossem resolvidos o mais r�pido poss�vel. Estas reuni�es tinham dura��o de no m�ximo 15 minutos.

O pr�ximo passo foi executar cada Sprint. A cada entrega, ou seja, decorridos tr�s semanas, o time realizou a reuni�o de revis�o (Sprint Review) para apresenta��o do produto realizado na Sprint. Ap�s esta reuni�o fazia-se uma reuni�o de retrospectiva (Sprint Retrospective) para demonstrar as li��es aprendidas. Nestas reuni�es, foi poss�vel identificar os principais desafios enfrentados pela equipe. Al�m disso, ao final de cada Sprint, o gerente realizou as medi��es dos indicadores de desempenho de produtividade do projeto.

Resultados Pr�ticos do Uso do Scrum

DESEMPENHO DOS INTEGRANTES

Os resultados form satisfat�rios, obteve um satisfa��o por todos os integrantes do projeto na aplicabilidade do Scrum. O projeto foi entregue dentro do prazo e do or�amento melhor do que os previstos.

Constatou-se uma maior participa��o do cliente no processo de desenvolvimento do software proporcionando um acompanhamento em alto n�vel do andamento das atividades realizadas. Al�m disso, observou-se a satisfa��o do cliente na solicita��o das modifica��es dentro de prazo h�bil para realiz�-las, al�m do recebimento de funcionalidades totalmente implementadas no final das Sprints. Um fator caracter�stico do Scrum que apresentou-se satisfat�rio para o cliente trata-se do tempo fixo estimado para as Sprints.

A equipe evoluiu profissionalmente se tornando mais segura com rela��o � capacidade de estimativa e autogerenciamento, descartando a necessidade de atribui��o de tarefas pelo gerente. Esse crescimento foi gradativo no decorrer das Sprints.

Aumentou tamb�m a seguran�a no que estava desenvolvendo e no conhecimento dos requisitos. Isto proporcionou um menor retrabalho por n�o desperdi�ar tempo no desenvolvimento de requisito confuso. O aumento da seguran�a aumentou o comprometimento e o foco com o projeto. Al�m do mais, a equipe, depois de experimentar o Scrum, quer sempre que poss�vel, seguir esta pr�tica nos novos projetos.

O gerente apontou a facilidade em solucionar os impedimentos do projeto, haja vista que os mesmos eram identificados precocemente e n�o apresentava impactos nas demais atividades. Todos os integrantes tinham conhecimento do impedimento e atrav�s de uma a��o em conjunto o impedimento era solucionado o mais r�pido poss�vel. Al�m disso, o gerente relatou a facilidade de extrair informa��es gerenciais do projeto atrav�s dos quadros adotados pela metodologia �gil, pois conforme � relatado por Schawber (2004) o Scrum oferece um framework e um conjunto de pr�ticas que guardam tudo vis�vel. Isto permite aos participantes do Scrum saber exatamente o que est� acontecendo e fazer no local os ajustes para manter o projeto na dire��o dos objetivos desejados.

INDICADORES DE DESEMPENHO DE PRODUTIVIDADE DO PROJETO

Como mencionado anteriormente, o gerente realizou o acompanhamento do desempenho da produtividade do projeto. A Figura 3 a seguir apresenta a tabela de produtividade da equipe no projeto.

A figura ilustra os principais processos de engenharia executados no desenvolvimento do software e a produtividade planejada e realizada para cada um desses processos. Al�m disso, s�o expressos valores de produtividade para �Produtividade dos processos com retrabalho� que retrata a produtividade do projeto contando o esfor�o gasto com o retrabalho de alguma atividade; �Produtividade dos processos sem retrabalho� que representa a produtividade do projeto sem considerar o esfor�o gasto com o retrabalho das atividades; e �Produtividade geral� que significa a produtividade do projeto expressa em um �nico valor.

Por normas de sigilo, a forma como � calculada a produtividade n�o foi divulgada pela empresa. No entanto, alguns fatores nos permitem a an�lise destes dados.

A produtividade planejada representa o n�vel de produtividade planejado pelo gerente de acordo com as caracter�sticas do projeto e representa o limite m�ximo a ser atingido.

Quando a produtividade realizada � expressa abaixo da produtividade planejada, significa dizer que a equipe apresenta boa produtividade e que est� realizando suas atividades com um esfor�o inferior ao planejado. Deste modo, quando menor a produtividade realizada, melhor est� sendo a produtividade da equipe.

Como se pode constatar pela an�lise da Tabela 1 acima representada, em todos os processos a equipe apresenta uma boa produtividade, haja vista que todos os valores expressos na �Produtividade realizada� s�o inferiores aos valores da �Produtividade planejada�. Uma an�lise a respeito da diferen�a entre �Produtividade planejada� e �Produtividade realizada� � apresentada na Figura 4.

No gr�fico acima representada, � poss�vel verificar que al�m da produtividade realizada apresentar-se inferior a produtividade planejada em todos os processos, o processo de �An�lise e Projeto� apresenta uma melhor produtividade se comparado o valor aos demais processos. Em contrapartida, o processo de �Testes� apresenta uma boa produtividade, no entanto, bem pr�xima a produtividade planejada.

Com o aumento da produtividade da equipe, ou seja, a execu��o das atividades em menor tempo que o estimado, o projeto foi entregue em tempo menor que o planejado. No geral, foram planejados 5 meses para a execu��o total do projeto e o projeto foi realizado em 4 meses. Isto proporcionou uma maior satisfa��o do cliente assim como o aumento do lucro da empresa.

Na Figura 5 temos o ciclo de vida dentro do XP.

Atrav�s desta pesquisa e an�lise podemos concluir a import�ncia da utiliza��o destas ferramentas que auxiliam no desenvolvimento de projetos garantindo sua efic�cia e alta qualidade.

Podemos notar que devido a evolu��o da tecnologia esses processos se tornaram complemento um do outro tornando-se �timas ferramentas de trabalho, sendo que o XP � utilizado para desenvolvimento e o SCRUM para um framework.

Scrum � um processo de desenvolvimento iterativo para gerenciamento de projetos, usando para trabalhos complexos nos quais � imposs�vel predizer tudo o que ir� ocorrer.

� um processo eficaz pois pode ser aplicado em qualquer projeto no qual um grupo de pessoas necessita trabalhar em grupo para atingir um objetivo em comum, al�m disso, permite a cria��o de equipes auto organizadas, encorajando a comunica��o verbal entre todos os membros da equipe e entre todas as disciplinas que estar�o envolvidas no projeto.

Para garantir o sucesso na realiza��o do processo e projeto deve haver um planejamento de sprint onde o Product Owner, o Scrum Master e a Equipe ir� decidir no que ir� trabalhar, planejando a arquitetura e o design de como backlog dever� ser implementado. � importante que ocorram todas as etapas do processo como todas as reuni�es de planejamentos di�rios, as de revis�o, as retrospectivas momento em que todos refletem sobre a sprint passada.

J� a metodologia de desenvolvimento XP consiste em usar m�todos simples, onde o trabalho � feito em duplas utilizando aplica��es simples, design simples focando apenas no que o cliente necessita neste momento, n�o havendo import�ncia com futuras modifica��es do sistema, as mudan�as tem que ser feitas por partes , quando o aplicativo se torna obsoleto n�o se refaz o mesmo, simplesmente desenvolve-se um novo sistema. Existe tamb�m um respeito entre a equipe onde todos s�o valorizados da mesma forma, sendo assim um incentivo para o desenvolvimento de alta qualidade.

Cada parte do c�digo � testada antes de passar para o pr�ximo recurso, verifica-se que o requisito � realmente o que o cliente deseja. A comunica��o entre o cliente e o programador no planejamento, o feedback onde a cada parte do desenvolvimento � testado e se o cliente desejar fazer alguma modifica��o, os programadores adicionam tempo extra para concluir o projeto.

S�o atrav�s destes processos que � poss�vel entregas frequentes e intermedi�rias de funcionalidade 100% desenvolvidas, diminui��o de riscos desenvolvidos pelas equipes, transpar�ncia no planejamento e desenvolvimento, garantindo efici�ncia e evolu��o na realiza��o do projeto.

Qual fator deve ser considerado ao determinar a duração de uma Sprint?

Como definir o tempo de cada Sprint?

Quanto tempo dura uma Sprint Review?

Que critérios normalmente são utilizados para decisão sobre o tamanho de Sprints?