Como Criar Um Processo Agil

8/8/2019 Como Criar Um Processo Agil

1/14

CRIANDO UM PROCESSO GIL PARA DESENVOLVIMENTO DE SOFTWARE

CRIANDO UM PROCESSO GILPARA DESENVOLVIMENTO DESOFTWARE

CONTEDO

1.Introduo................................................................................................................................................2

2.Gesto gil...............................................................................................................................................2

1.1 Metodologias.....................................................................................................................................2

1.2 Comeando um projeto.....................................................................................................................3

Planejamento Inicial..........................................................................................................................3

Desenvolvimento...............................................................................................................................6

Motivao da Equipe.........................................................................................................................9

Melhoria Contnua - retrospectivas...................................................................................................9

1.3 Requisitos........................................................................................................................................10

User Stories......................................................................................................................................10

Estimativas........................................................................................................................................11

3.Concluso...............................................................................................................................................14

A Fratech pode ajudar!.............................................................................................................................14

Autor: Felipe Rodrigues de Almeida 1


2/14


1. INTRODUO

Neste documento, procuramos sintetizar o raciocnio por trs da criao de um processo de desenvolvimento de

software que seja gil, flexvel e confivel ao mesmo tempo. Para isso, vamos caminhar por alguns tpicos,descrevendo o nosso entendimento sobre cada um desses tpicos. Fica claro que nossa inteno no criar umtutorial passo a passo sobre como implantar agile em sua empresa, mas destacar algumas consideraes importantesque devem ser lembradas.

2. GESTO GIL

A Fratech tem investido uma quantidade significativa de tempo em explorar o uso de mtodos mais geis para gestode processos e projetos de desenvolvimento de software. Por isso, na Fratech, todos os projetos so geridos segundoos princpios estabelecidos no Manifesto gil.

O Manifesto gil um documento criado com o intuito dedeterminar qual a viso de uma equipe de desenvolvimentode software e, foi assinado por desenvolvedores e gestores deprojetos do software respeitados no mundo todo. Ele podeser encontrado no site http://agilemanifesto.org/.

importante observar que ser gil no quer dizer ser radicale nem quer dizer que existe uma nica soluo para projetosde desenvolvimento de software. Ser gil quer dizer

identificar e focar em objetivos bem estabelecidos, cuidarpara que haja conscientizao dos membros da equipe, unir aequipe e permitir pr-atividade e autogerenciamento,garantir feedback continuamente, utilizar solues simplespara problemas simples e, por fim, inspecionar e adaptar.

A Gesto gil envolve um profundo processo de melhoriacontnua do prprio processo de gesto e da equipe.

1.1 METODOLOGIAS

Dentro dos princpios do manifesto gil, existem diversas abordagens possveis que podem dar certo. No existe umanica abordagem que atenda a todos os casos. Por isso fundamental inspecionar e adaptar frequentemente oprocesso.

Com isso em mente, tambm sabemos que existem diversas abordagens que servem como ponto de partida. Essasabordagens so conhecidas como metodologias geis e, foram concebidas por profissionais respeitados no mundotodo, sendo que muitos deles estiveram presentes na concepo do manifesto gil.

De nossa experincia, a maior dificuldade que as pessoas tem para aplicar ou mesmo entender estas metodologias,se deve ao fato de que elas apenas sugerem como as coisas deve ser feitas, no detalhando profundamente todos os

2


3/14


casos. Isso deixa muitas questes em aberto, dificultando o entendimento e a implementao por profissionaisinexperientes.

Esse tambm o grande motivo pelo qual essas metodologias funcionam. Essas "brechas" deixadas foram deixadasde propsito, com o intuito de promover a inspeo e adaptao dentro de cada equipe. Isso permite que sua equipedesenvolva um processo de gesto altamente customizado e simples ao mesmo tempo. Isso o que torna o processorealmente gil e aplicvel nas mais diversas situaes.

As metodologias mais conhecidas so:

Extreme Programming

Scrum

FDD

Lean Software Development

1.2 COMEANDO UM PROJETO

As metodologias geis tem algumas coisas em comum, que muitas vezes compe a base e promove os princpios domanifesto gil. Essa base influencia de maneira muito forte as fases do projeto e pontos importantes que devem ser

considerados sempre.

Estas fases normalmente so divididas em dois momentos importantes no projeto:

Planejamento Inicial

Desenvolvimento

Veremos abaixo, essas etapas.

PLANEJAMENTO INICIAL

Projetos geis tem um perodo de planejamento inicial. Claro que conta com algumas diferenas em relao aomodelo tradicional.

A primeira grande diferena que o planejamento inicial demora alguns dias, uma semana ou duas no mximo. Esse o tempo necessrio para contextualizar todos os envolvidos e definir o objetivo comum do projeto. Comparado aosmeses de levantamento de requisitos e preparao de documentos e diagramas do modelo waterfall, esse umtempo bem pequeno.

A segunda grande diferena que os documentos resultantes do planejamento no so muito importantes. Servemmais como um guia, mas alguns at dizem que podem ser descartados. O fato que acreditamos que o ato de

3


4/14


planejar mais importante do que o plano em si. Isso ressalta a importncia de todos os envolvidos no projetoparticiparem ativamente do planejamento.

nesta fase que se definem os objetivos, metas, declarao de viso, plataforma tecnolgica, restries tecnolgicase padres a serem seguidos. Em outras palavras, nesta fase que se definem as diretrizes tcnicas e de negcio doprojeto. Aqui, define-se tambm a equipe e o papel de cada um dentro do projeto.

Para conseguir realizar um bom planejamento. O planejamento gera contexto e permite que as pessoas envolvidastomem conhecimento do que deve ser feito e quando deve ser feito. fundamental para que todos possam ser pr-ativos e caminhe na mesma direo, alm de permitir que todos saibam quando esto chegando perto do objetivo.Mas para que isso acontea, fundamental que todos participem do planejamento, pois somente atravs daparticipao que existe o comprometimento. impossvel algum se comprometer a buscar um objetivo se ele notiver participado da definio deste objetivo.

Devido a natureza dinmica dos projetos de desenvolvimento de software, faz-se necessrio um plano flexvel eabrangente. Como veremos no captulo sobre requisitos, os projetos esto em constante mudana e, cabe a ns,criarmos um plano que permita a mudana constante. Por isso, no deve especificar detalhadamente o resultado doprojeto, mas deve se limitar a descrever como o projeto ser realizado. O plano deve determinar os papis de cadaum dentro do projeto, deve determinar como sero levantados os requisitos e quais as subfases do projeto.

Como todos participam desse planejamento, o comprometimento em relao ao que foi definido neste momentoser muito grande. Todo este planejamento no deve demorar muito mais do que 2 semanas, dependendo dotamanho do projeto e dos recursos disponveis.

PRODUCT OWNER

Todo software possui usurios. Uma ou mais pessoas iro utiliz-loconstantemente e o desenvolvedor, na maioria dos casos, no utilizar osoftware que desenvolveu. Por isso, acreditamos que no justo e nemprodutivo que os desenvolvedores ou analistas de negcio decidam como osoftware deve ser, mas sim o cliente. A pessoa que ir consumir este softwaree passar seus dias de trabalho olhando para ele.

Entendemos que h casos em que impossvel ouvir diretamente o clientefinal que ir comprar o produto. So comuns os casos onde uma equipedesenvolve software para vrios clientes reais. Para estes casos, recomenda-se a utilizao de algum que represente e centralize a opinio de todos osoutros clientes. Algum que pense sempre no que importante para quemest pagando. Gostamos de chamar essa pessoa de Product Owner (Dono doProduto).

O Product Owner quem decide o que deve ser includo ou no no software,em termos de funcionalidades, aparncia e layout. Ele tambm define aprioridade e ordem em que cada uma dessas coisas ser implementada.

Com o product owner presente, o software resultado do desenvolvimentoser muito mais adaptado e adequado ao dia-a-dia do usurio real. Issosignifica mais qualidade e menos complicao desnecessria.

4


5/14


ROI

Como dito acima, o Product Owner responsvel por representar os clientes perante a equipe de desenvolvimento,pensando sempre no retorno e nas prioridades das funcionalidades (user stories).

Em outras palavras, o Product Owner deve pensar sempre no Return on Investiment (ROI) de toda a operao dedesenvolvimento. A equipe de desenvolvimento deve acompanhar e alertar ao product owner quando algo for muitocustoso ou precisar de esforo extra para ser alcanado, de forma que o Product Owner poder decidir pelo que melhor.

Acreditamos que a lei de Pareto se aplica ao desenvolvimento de software. Isso quer dizer que 20% do esforo dodesenvolvimento, resulta em 80% dos benefcios. Para o Product Owner isso quer dizer que com 20% dos custos,resolveremos 80% dos nossos problemas.

Ento nos perguntamos: "E quanto aos outros 20% de benefcios?".

Bom, segundo Pareto, esses 20% restantes de benefcios custaro 80% do esforo no desenvolvimento. Isso querdizer que se demora 4 vezes mais para desenvolver esses ltimos 20%. O ROI dos 80% iniciais muito alto. O ROI dos20% finais muito baixo.

Diante disso o Product Owner deve decidir se realmente precisa de todas as funcionalidades que ele realmente achou

que precisava. Decidir se vale a pena aplicar um esforo desproporcional em troca de uma diferena to pequena.

Nesse caso, recomendamos aplicar o princpio da simplicidade. Quanto mais simples, melhor. Focar no que importante e, faz-lo de forma simples um jeito gil de pensar no ROI.

DECLARAO DE VISO

bom que se determine os objetivos e metas do projeto, de forma que todos saibam, em alto nvel, qual o resultadoesperado do projeto. importante determinar restries de ambiente e expectativas gerais. bom descrever, em 1ou 2 folhas A4, qual o software desejado. Chamamos este documento de viso geral. Ele deve ser escrito pelo

5


6/14


cliente que, dentro do limite de 1 ou 2 folhas, deve descrever de forma abrangente, as partes mais importantes dosoftware.

Tambm interessante criar um modelo inicial do fluxo das informaes dentro do sistema. Ns o chamamos defluxo de negcio, que deve mostrar as principais operaes de negcio realizadas pelo usurio do sistema, quandooperando o mesmo.

Tudo isso serve para guiar a equipe e o cliente ao longo do desenvolvimento.

ESTIMATIVA INICIAL

O cliente tambm deve listar algumas dasfuncionalidades que ele espera ter no software, sem ocompromisso de limitar o escopo, mas apenas paragarantir que ele no esquea o que deve serimplementado. Essas funcionalidades compem umalista conhecida como Backlog e podem ser ordenadas porprioridade, tamanho ou complexidade dasfuncionalidades.

O backlog pode ser utilizado para criar uma estimativainicial de esforo e complexidade para o projeto. Essaestimativa serve como parmetro para definir viabilidade, custo estimado e pode at mesmo ajudar no contrato,porm de extrema importncia lembrar que so apenas estimativas e que, apesar de aproximadas, no so osnmeros reais.

DESENVOLVIMENTO

Para que um projeto de desenvolvimento de software seja um sucesso, preciso que o desenvolvimento em si sejaum sucesso. Isso bvio!

O que no bvio neste caso, que a tarefa de desenvolvimento no apenas uma tarefa mecnica de transcriode diagramas em formato de cdigo. O desenvolvimento uma tarefa criativa de resoluo de problemas, onde osdesenvolvedores precisam saber exatamente o que deve ser resolvido.

6


7/14


No modelo waterfall, o preparo para a implementao extrapola o tamanho da implementao, de forma que segasta mais tempo especificando o que deve ser desenvolvido do que desenvolvendo efetivamente.

Alm disso, toda a especificao gerada uma abstrao incompleta do entendimento que um analista de negcioteve do problema. O problema foi explicado s pressas por um usurio ou cliente que mal teve tempo para refletirsobre suas reais necessidades. Na verdade, o cliente confia que o analista de negcio saiba orient-lo e saibatransformar todas as solicitaes em algo real, j que suas solicitaes so abstratas.

Como se no bastasse, essa especificao chega ao desenvolvedor por partes e no toda de uma vez. So pedaos dedocumentao, sem contexto e muitas vezes com o design e modelagem tcnica j definidos. Diante disso, espera-seque o desenvolvedor seja capaz, de alguma forma mgica, de em 1/3 do tempo gasto para o levantamento,implementar todo o cdigo necessrio para o software funcionar.

Isso no gil!

Manter um processo gil implica oferecer condies apropriadas para que todos desempenhem seu papel. Isso

significa permitir acesso informao com contexto, para que assim, consigam executar seu trabalho de formarpida e eficaz, alm de poderem dessa forma contribuir alm de suas funes, participando da melhoria contnua doprocesso.

Isso se aplica principalmente aos desenvolvedores, que tem um dos papis mais importantes em todo o processo.Estes so trabalhadores do conhecimento e devem ser tratados como tal.

PLANEJAMENTO

A fase de desenvolvimento realizada em ciclos do tipo PDCA (Plan, Do, Check and Act). Estes ciclos so conhecidoscomo iteraes ou sprints e tem durao de 2 semanas, podendo ser adaptados dependendo do caso. Antes de

iniciar cada um destes ciclos, h um perodo de planejamento, para que o plano original seja revisto, estendido e paraque as expectativas citada anteriormente sejam reavaliadas, agora considerando o ciclo anterior.

No planejamento da iterao, definem-se quais das funcionalidades listadas no backlog criado no planejamentoinicial, devem ser implementadas no ciclo atual. Para esta escolha, leva-se em conta a priorizao feita pelo cliente,implementando as funcionalidades de maior prioridade. necessrio limitar a quantidade de funcionalidades paraque seja possvel entregar at o final do ciclo. Toda essa seleo de funcionalidades acontece em algumas horas antesdo incio da iterao. Alguns times consomem 4 horas para isso.

7


8/14


Para que a seleo das funcionalidades seja possvel, necessrio estimar o tempo de cada funcionalidade,calculando assim, se o total de horas estimadas para implementar as funcionalidades selecionadas menor ou igualao total de horas disponvel para a equipe. As estimativas so realizadas pelos desenvolvedores, que participam doprocesso desde o incio.

Obviamente, nem todos os planos de cada ciclo sero cumpridos, mas com o acompanhamento constante e com aparticipao dos desenvolvedores no planejamento, fcil perceber que todos se esforam e ficam motivados paratrabalhar o mais rpido possvel.

IMPLEMENTAO

Aps iniciado o ciclo de desenvolvimento, a cada dia do ciclo interessante que acontea uma reunio, onde cadamembro exponha suas dificuldades e conquistas, atualizando a equipe sobre o status atual de suas atividades. Issopermite criar uma rede de relacionamento na equipe, permitindo que uns ajudem os outros, aumentando ainda maisa produtividade da equipe. Essa reunio conhecida como Stand Up Meeting, pois no deve demorar mais do que 15

minutos.

Durante o desenvolvimento em si, importante levar em considerao diversas prticas de engenharia de software,que ajudam aos desenvolvedores criarem e manter um cdigo confivel mesmo diante de toda essa dinmica. Essasprticas determinam como testar, como evoluir o cdigo e como compartilhar o cdigo, uns com os outros.

As prticas mais citadas e interessantes so:

Desenvolvimento Orientado a Testes

Integrao Contnua

Design Evolutivo

Refactoring

Tambm muito til utilizar conceitos de arquitetura tcnica e processos de modelagem como o Domain DrivenDesign e o conceito de modelagem gil.

O Domain Driven Design tem por objetivo aproximar o mundo tcnico do desenvolvedor dos conceitos de negcio,especficos daquela situao, permitindo uma melhor comunicao entre o cliente e o desenvolvedor.

A modelagem gil por sua vez determina alguns passos bsicos para serem executados ao longo do desenvolvimento,com o objetivo de ajudar na definio de componentes tcnicos de alto e baixo nvel dentro do sistema.

ENTREGA

Aps o trmino de cada ciclo de desenvolvimento, a equipe deve entregar um incremento do software para o cliente.Cada funcionalidade implementada naquele ciclo deve ser mostrada para o cliente, permitindo assim que o clienteavalie o que foi feito e, se necessrio, solicite alteraes. Essas alteraes devem ser includas na lista do backlog paraque sejam priorizadas e estimadas no incio do prximo ciclo.

8


9/14


As funcionalidades que no foram implementadas, por falta de tempo ou outro motivo qualquer, devem serapresentadas ao cliente, que ir retorn-la ao backlog para que seja mais uma vez priorizada, estimada e alocada emoutro ciclo.

MOTIVAO DA EQUIPE

Vale a pena citar como um dos benefcios do trabalhoem ciclos a motivao da equipe. Em um projetotradicional comum notar que a equipe dedesenvolvedores no recebe feedback sobre seutrabalho at que o cliente finalmente veja o resultadono fim do projeto.

Para que um projeto seja gil, preciso garantirfeedback constante e, o fato do cliente "brincar" com

o software a cada 2 semanas faz com que o feedbackacontea naturalmente. Isso permitir aodesenvolvedor criar de forma livre, porm iracostumando- se com o jeito do cliente, com o gostodo cliente. Em um curto espao de tempo, a equipe jentende qual o estilo do software.

A cada entrega acontece uma pequena vitria para o desenvolvedor, pois ele desenvolveu e apresentou sua criao.Isso o motiva para criar cada vez mais, buscando sempre agradar ao dono do software, o cliente.

BURN DOWN CHART

Uma forma interessante de acompanhar o andamento do projeto atravs de um grfico conhecido como BurnDown.

O conceito simples, soma-se o total de funcionalidades listadas no backlog e diminui deste total a quantidade defuncionalidades implementadas a cada ciclo. Desta forma, a cada ciclo, o grfico tende a se aproximar cada vez maisdo zero no eixo X e, assim possvel visualizar a evoluo em ciclo.

Muitos optam por complicar um pouquinho mais o grfico, adicionando o esforo estimado, o esforo gasto narealidade e o quanto falta para o fim das funcionalidades. Dessa forma o grfico fica com 3 ou mais sries.

MELHORIA CONTNUA - RETROSPECTIVAS

Aps realizar a entrega referente ao ciclo que acabou, a equipe se rene e realiza uma reunio de auto avaliao,conhecida como reunio de retrospectiva.

Nesta reunio cada membro convidado e estimulado a citar o que ele achou que funcionou bem e o que ele achouque no funcionou bem neste ciclo. A equipe ento debate ligeiramente sobre o tema, em atitude construtiva edelibera-se em busca de uma soluo.

9


10/14


Normalmente na retrospectiva acontecem ajustes s prticas, cria-se um costume de autogerenciamento na equipe,pois dessa forma, todos so responsveis pelo bom funcionamento da equipe, facilitando assim o convvio e aprodutividade.

1.3 REQUISITOS

A gesto de requisitos um tpico muito importante e intimamente relacionado s outras reas de um projeto dedesenvolvimento de software. um ponto importante a ser considerado quando se busca uma abordagem maisflexvel e gil. A gesto de requisitos por si s, quando mal feita, pode comprometer todo o andamento do projeto.

Atravs dos tpicos abaixo, veremos como isso acontece e quais so as alternativas.

USER STORIES

User Stories so estrias que o usurio conta para descrever uma pequena funcionalidade do sistema. A idia

passar para o desenvolvedor uma descrio de qual a operao deve ser implementada no sistema.

Uma User Story deve ser pequena e especfica, diminuindo assim as possibilidades de mal- entendidos em relao aoque deve ser implementado. Obviamente, os detalhes adicionais que no podem ser descritos em um pequeno textodevem ser disponibilizados de outra forma. Normalmente, a opo de conversar com o cliente sobre uma estria amelhor soluo para este caso.

As user stories normalmente so descritas em pequenos cartes de papel, post-its ou at em softwareespecializados. Cada carto deve ser priorizado pelo cliente e estimado pela equipe de desenvolvimento. Apesar deser recomendado o uso dos pequenos cartes, possvel, utilizar modelos alternativos, que se adequem melhor aoestilo da empresa.

MENOS MAIS

Normalmente, achamos que quanto mais funcionalidades um software tiver, melhor ser. Isso nem sempre verdade.

O Standish Group, entidade que realiza pesquisas sobre a rea de TI, relatou em suas pesquisas queaproximadamente 64% das funcionalidades desenvolvidas nos softwares no so utilizadas. 1 Isso ressalta algunspontos:

1 Para mais detalhes, veja: http://www.standishgroup.com/sample_research/chaos_1994_1.php

10


11/14


12/14


Sabidos de que as estimativas so falhas, os profissionais envolvidos costumam colocar uma "gordurinha".Super estimam o prazo como forma de garantir que tero tempo suficiente. Como provado pela teoria daCorrente Crtica, essa "gordurinha" desperdiada na hora de desenvolver, pois todos fielmente acreditamque h tempo sobrando e consequentemente, deixa para fazer as coisas em cima da hora. H relatos de que

esta gordura chega a 200% do tempo total do projeto.Abaixo, veja um diagrama de causa e efeito, criado por Manoel Pimentel para o artigo no blog da revista Viso gil2.

2 http://visaoagil.wordpress.com/2009/06/17/agile-faq-3-o-que-voce-prefere-uma-mentira-ou-software-funcionando-no-inicio-de-um-projeto/

12


13/14


fcil de perceber o quo falhas e prejudiciais so as estimativas quando feitas no momento errado. Por isso, o quepropomos que, de forma incremental, os desenvolvedores estimem o esforo e tempo gradualmente.Possibilitando assim, uma grande flexibilidade, facilitando a priorizao e se bem trabalhado, at mesmo a utilizaode verses parciais do sistema.

Em um projeto gil, as estimativas estointimamente ligadas ao sistema de levantamentode requisitos atravs de user stories, onde cadauser story estimada individualmente poucoantes de ser implementada. Essas estimativas somais precisas, pois so realizadas pelosdesenvolvedores, em uma reunio e nummomento em que a equipe j conhece melhor acomplexidade e as implicaes do projeto, pois jesto trabalhando no mesmo.

13


14/14


3 . C ONC LU S O

Na Fratech, acreditamos seriamente que ser gil no significa adotar uma metodologia ou um conjunto de prticasespecficas. No acreditamos que ser gil significa abandonar tudo que j foi feito em uma empresa e, do dia para anoite, modificar o modo de agir e pensar de todos na empresa. Acreditamos que para ser gil necessria umagrande mudana cultural, mas sabemos que essa mudana gradual. Essa mudana aplicada atravs de um fluxode melhoria contnua, baseado nas prticas de inspeo e adaptao.

Ser gil focar no que realmente precisa ser feito, abandonando tudo o que no necessrio. O interessante destadeclarao que o necessrio especfico para cada situao. O que necessrio para minha empresa, pode noser necessrio para a sua e vice-versa. Dessa forma, saiba que no h um processo pronto que lhe sirva bem. necessrio adaptar as prticas ao dia-a-dia de sua equipe, dentro da cultura e viso de sua empresa.

Por fim, levando em considerao esses princpios, fica claro que possvel ser gil dentro de qualquer contexto. Epossvel criar um ambiente mais maduro e adaptado ao desenvolvimento de software, sem perturbar as fundaes

de sua empresa. Para ser gil no precisa ser intrusivo e nem informal. Apenas prtico.

14

A FRATECH PODE AJUDAR!

Entender os conceitos e princpios do agile o que faz com que uma

implementao seja bem sucedida. A Fratech oferece ajuda para que suaevoluo dentro dos conceitos do agile seja a mais fcil possvel. Temospublicado materiais sobre esse e outros temas pertinentes, seja atravs doportal InfoQ (www.infoq.com/br), da Revista Viso gil (www.visaoagil.com)ou atravs de artigos na pgina de comunidade da Fratech(www.fratech.net/comunidade).

Alm disso, oferecemos servios de consultoria e treinamento em agile. Sevoc achar que precisa de ajuda para aumentar a agilidade de seu processoatual, contate-nos atravs do email [email protected] ou pelo telefone(19) 3454-8335 que ficaremos felizes em lhe atender.

Voc pode encontrar mais informaes sobre a Fratech em nosso site noendereo www.fratech.net
mailto:[email protected]:[email protected]:[email protected]://www.fratech.net/http://www.fratech.net/http://www.fratech.net/mailto:[email protected]

Documents

Como Criar Um Processo Agil