CRIANDO UM PROCESSO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE

Transcrição

1 CRIANDO UM PROCESSO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE CONTEÚDO 1.Introdução Gestão Ágil Metodologias Começando um projeto...3 Planejamento Inicial...3 Desenvolvimento...6 Motivação da Equipe...9 Melhoria Contínua - retrospectivas Requisitos...10 User Stories...10 Estimativas Conclusão...14 A Fratech pode ajudar!...14 Autor: Felipe Rodrigues de Almeida 1

2 1. INTRODUÇÃO Neste documento, procuramos sintetizar o raciocínio por trás da criação de um processo de desenvolvimento de software que seja ágil, flexível e confiável ao mesmo tempo. Para isso, vamos caminhar por alguns tópicos, descrevendo o nosso entendimento sobre cada um desses tópicos. Fica claro que nossa intenção não é criar um tutorial passo a passo sobre como implantar agile em sua empresa, mas destacar algumas considerações importantes que devem ser lembradas. 2. GESTÃO ÁGIL A Fratech tem investido uma quantidade significativa de tempo em explorar o uso de métodos mais ágeis para gestão de processos e projetos de desenvolvimento de software. Por isso, na Fratech, todos os projetos são geridos segundo os princípios estabelecidos no Manifesto Ágil. 1.1 METODOLOGIAS O Manifesto Ágil é um documento criado com o intuito de determinar qual a visão de uma equipe de desenvolvimento de software e, foi assinado por desenvolvedores e gestores de projetos do software respeitados no mundo todo. Ele pode ser encontrado no site É importante observar que ser Ágil não quer dizer ser radical e nem quer dizer que existe uma única solução para projetos de desenvolvimento de software. Ser Ágil quer dizer identificar e focar em objetivos bem estabelecidos, cuidar para que haja conscientização dos membros da equipe, unir a equipe e permitir pró-atividade e autogerenciamento, garantir feedback continuamente, utilizar soluções simples para problemas simples e, por fim, inspecionar e adaptar. A Gestão Ágil envolve um profundo processo de melhoria contínua do próprio processo de gestão e da equipe. Dentro dos princípios do manifesto ágil, existem diversas abordagens possíveis que podem dar certo. Não existe uma única abordagem que atenda a todos os casos. Por isso é fundamental inspecionar e adaptar frequentemente o processo. Com isso em mente, também sabemos que existem diversas abordagens que servem como ponto de partida. Essas abordagens são conhecidas como metodologias ágeis e, foram concebidas por profissionais respeitados no mundo todo, sendo que muitos deles estiveram presentes na concepção do manifesto ágil. De nossa experiência, 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, não detalhando profundamente todos os 2

3 casos. Isso deixa muitas questões em aberto, dificultando o entendimento e a implementação por profissionais inexperientes. Esse é também o grande motivo pelo qual essas metodologias funcionam. Essas "brechas" deixadas foram deixadas de propósito, com o intuito de promover a inspeção e adaptação dentro de cada equipe. Isso permite que sua equipe desenvolva um processo de gestão altamente customizado e simples ao mesmo tempo. Isso é o que torna o processo realmente ágil e aplicável nas mais diversas situações. As metodologias mais conhecidas são: Extreme Programming Scrum FDD Lean Software Development 1.2 COMEÇANDO UM PROJETO As metodologias ágeis tem algumas coisas em comum, que muitas vezes compõe a base e promove os princípios do manifesto ágil. Essa base influencia de maneira muito forte as fases do projeto e pontos importantes que devem ser considerados sempre. Estas fases normalmente são divididas em dois momentos importantes no projeto: Planejamento Inicial Desenvolvimento Veremos abaixo, essas etapas. PLANEJAMENTO INICIAL Projetos Ágeis tem um período de planejamento inicial. Claro que conta com algumas diferenças em relação ao modelo tradicional. A primeira grande diferença é que o planejamento inicial demora alguns dias, uma semana ou duas no máximo. Esse é o tempo necessário para contextualizar todos os envolvidos e definir o objetivo comum do projeto. Comparado aos meses de levantamento de requisitos e preparação de documentos e diagramas do modelo waterfall, esse é um tempo bem pequeno. A segunda grande diferença é que os documentos resultantes do planejamento não são muito importantes. Servem mais como um guia, mas alguns até dizem que podem ser descartados. O fato é que acreditamos que o ato de 3

4 planejar é mais importante do que o plano em si. Isso ressalta a importância de todos os envolvidos no projeto participarem ativamente do planejamento. É nesta fase que se definem os objetivos, metas, declaração de visão, plataforma tecnológica, restrições tecnológicas e padrões a serem seguidos. Em outras palavras, é nesta fase que se definem as diretrizes técnicas e de negócio do projeto. Aqui, define-se também 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 envolvidas tomem conhecimento do que deve ser feito e quando deve ser feito. É fundamental para que todos possam ser próativos e caminhe na mesma direção, além de permitir que todos saibam quando estão chegando perto do objetivo. Mas para que isso aconteça, é fundamental que todos participem do planejamento, pois somente através da participação é que existe o comprometimento. É impossível alguém se comprometer a buscar um objetivo se ele não tiver participado da definição deste objetivo. Devido a natureza dinâmica dos projetos de desenvolvimento de software, faz-se necessário um plano flexível e abrangente. Como veremos no capítulo sobre requisitos, os projetos estão em constante mudança e, cabe a nós, criarmos um plano que permita a mudança constante. Por isso, não deve especificar detalhadamente o resultado do projeto, mas deve se limitar a descrever como o projeto será realizado. O plano deve determinar os papéis de cada um dentro do projeto, deve determinar como serão levantados os requisitos e quais as subfases do projeto. Como todos participam desse planejamento, o comprometimento em relação ao que foi definido neste momento será muito grande. Todo este planejamento não deve demorar muito mais do que 2 semanas, dependendo do tamanho do projeto e dos recursos disponíveis. PRODUCT OWNER Todo software possui usuários. Uma ou mais pessoas irão utilizá-lo constantemente e o desenvolvedor, na maioria dos casos, não utilizará o software que desenvolveu. Por isso, acreditamos que não é justo e nem produtivo que os desenvolvedores ou analistas de negócio decidam como o software deve ser, mas sim o cliente. A pessoa que irá consumir este software e passar seus dias de trabalho olhando para ele. Entendemos que há casos em que é impossível ouvir diretamente o cliente final que irá comprar o produto. São comuns os casos onde uma equipe desenvolve software para vários clientes reais. Para estes casos, recomendase a utilização de alguém que represente e centralize a opinião de todos os outros clientes. Alguém que pense sempre no que é importante para quem está pagando. Gostamos de chamar essa pessoa de Product Owner (Dono do Produto). O Product Owner é quem decide o que deve ser incluído ou não no software, em termos de funcionalidades, aparência e layout. Ele também define a prioridade e ordem em que cada uma dessas coisas será implementada. Com o product owner presente, o software resultado do desenvolvimento será muito mais adaptado e adequado ao dia-a-dia do usuário real. Isso significa mais qualidade e menos complicação desnecessária. 4

5 ROI Como dito acima, o Product Owner é responsável 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 operação de desenvolvimento. A equipe de desenvolvimento deve acompanhar e alertar ao product owner quando algo for muito custoso ou precisar de esforço extra para ser alcançado, 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 esforço do desenvolvimento, resulta em 80% dos benefícios. Para o Product Owner isso quer dizer que com 20% dos custos, resolveremos 80% dos nossos problemas. Então nos perguntamos: "E quanto aos outros 20% de benefícios?". Bom, segundo Pareto, esses 20% restantes de benefícios custarão 80% do esforço no desenvolvimento. Isso quer dizer que se demora 4 vezes mais para desenvolver esses últimos 20%. O ROI dos 80% iniciais é muito alto. O ROI dos 20% 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 esforço desproporcional em troca de uma diferença tão pequena. Nesse caso, recomendamos aplicar o princípio da simplicidade. Quanto mais simples, melhor. Focar no que é importante e, fazê-lo de forma simples é um jeito ágil de pensar no ROI. DECLARAÇÃO DE VISÃO É bom que se determine os objetivos e metas do projeto, de forma que todos saibam, em alto nível, qual o resultado esperado do projeto. É importante determinar restrições de ambiente e expectativas gerais. É bom descrever, em 1 ou 2 folhas A4, qual é o software desejado. Chamamos este documento de visão geral. Ele deve ser escrito pelo 5

6 cliente que, dentro do limite de 1 ou 2 folhas, deve descrever de forma abrangente, as partes mais importantes do software. Também é interessante criar um modelo inicial do fluxo das informações dentro do sistema. Nós o chamamos de fluxo de negócio, que deve mostrar as principais operações de negócio realizadas pelo usuário do sistema, quando operando o mesmo. Tudo isso serve para guiar a equipe e o cliente ao longo do desenvolvimento. ESTIMATIVA INICIAL O cliente também deve listar algumas das funcionalidades que ele espera ter no software, sem o compromisso de limitar o escopo, mas apenas para garantir que ele não esqueça o que deve ser implementado. Essas funcionalidades compõem uma lista conhecida como Backlog e podem ser ordenadas por prioridade, tamanho ou complexidade das funcionalidades. O backlog pode ser utilizado para criar uma estimativa inicial de esforço e complexidade para o projeto. Essa estimativa serve como parâmetro para definir viabilidade, custo estimado e pode até mesmo ajudar no contrato, porém é de extrema importância lembrar que são apenas estimativas e que, apesar de aproximadas, não são os números reais. DESENVOLVIMENTO Para que um projeto de desenvolvimento de software seja um sucesso, é preciso que o desenvolvimento em si seja um sucesso. Isso é óbvio! O que não é óbvio neste caso, é que a tarefa de desenvolvimento não é apenas uma tarefa mecânica de transcrição de diagramas em formato de código. O desenvolvimento é uma tarefa criativa de resolução de problemas, onde os desenvolvedores precisam saber exatamente o que deve ser resolvido. 6

7 No modelo waterfall, o preparo para a implementação extrapola o tamanho da implementação, de forma que se gasta mais tempo especificando o que deve ser desenvolvido do que desenvolvendo efetivamente. Além disso, toda a especificação gerada é uma abstração incompleta do entendimento que um analista de negócio teve do problema. O problema foi explicado às pressas por um usuário ou cliente que mal teve tempo para refletir sobre suas reais necessidades. Na verdade, o cliente confia que o analista de negócio saiba orientá-lo e saiba transformar todas as solicitações em algo real, já que suas solicitações são abstratas. Como se não bastasse, essa especificação chega ao desenvolvedor por partes e não toda de uma vez. São pedaços de documentação, sem contexto e muitas vezes com o design e modelagem técnica já definidos. Diante disso, espera-se que o desenvolvedor seja capaz, de alguma forma mágica, de em 1/3 do tempo gasto para o levantamento, implementar todo o código necessário para o software funcionar. Isso não é ágil! Manter um processo ágil implica oferecer condições apropriadas para que todos desempenhem seu papel. Isso significa permitir acesso à informação com contexto, para que assim, consigam executar seu trabalho de forma rápida e eficaz, além de poderem dessa forma contribuir além de suas funções, participando da melhoria contínua do processo. Isso se aplica principalmente aos desenvolvedores, que tem um dos papéis mais importantes em todo o processo. Estes são 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 são conhecidos como iterações ou sprints e tem duração de 2 semanas, podendo ser adaptados dependendo do caso. Antes de iniciar cada um destes ciclos, há um período de planejamento, para que o plano original seja revisto, estendido e para que as expectativas citada anteriormente sejam reavaliadas, agora considerando o ciclo anterior. No planejamento da iteração, definem-se quais das funcionalidades listadas no backlog criado no planejamento inicial, devem ser implementadas no ciclo atual. Para esta escolha, leva-se em conta a priorização feita pelo cliente, implementando as funcionalidades de maior prioridade. É necessário limitar a quantidade de funcionalidades para que seja possível entregar até o final do ciclo. Toda essa seleção de funcionalidades acontece em algumas horas antes do início da iteração. Alguns times consomem 4 horas para isso. 7

8 Para que a seleção das funcionalidades seja possível, é necessário estimar o tempo de cada funcionalidade, calculando assim, se o total de horas estimadas para implementar as funcionalidades selecionadas é menor ou igual ao total de horas disponível para a equipe. As estimativas são realizadas pelos desenvolvedores, que participam do processo desde o início. Obviamente, nem todos os planos de cada ciclo serão cumpridos, mas com o acompanhamento constante e com a participação dos desenvolvedores no planejamento, é fácil perceber que todos se esforçam e ficam motivados para trabalhar o mais rápido possível. IMPLEMENTAÇÃO Após iniciado o ciclo de desenvolvimento, a cada dia do ciclo é interessante que aconteça uma reunião, onde cada membro exponha suas dificuldades e conquistas, atualizando a equipe sobre o status atual de suas atividades. Isso permite criar uma rede de relacionamento na equipe, permitindo que uns ajudem os outros, aumentando ainda mais a produtividade da equipe. Essa reunião é conhecida como Stand Up Meeting, pois não deve demorar mais do que 15 minutos. Durante o desenvolvimento em si, é importante levar em consideração diversas práticas de engenharia de software, que ajudam aos desenvolvedores criarem e manter um código confiável mesmo diante de toda essa dinâmica. Essas práticas determinam como testar, como evoluir o código e como compartilhar o código, uns com os outros. As práticas mais citadas e interessantes são: Desenvolvimento Orientado a Testes Integração Contínua Design Evolutivo Refactoring Também é muito útil utilizar conceitos de arquitetura técnica e processos de modelagem como o Domain Driven Design e o conceito de modelagem ágil. O Domain Driven Design tem por objetivo aproximar o mundo técnico do desenvolvedor dos conceitos de negócio, específicos daquela situação, permitindo uma melhor comunicação entre o cliente e o desenvolvedor. A modelagem ágil por sua vez determina alguns passos básicos para serem executados ao longo do desenvolvimento, com o objetivo de ajudar na definição de componentes técnicos de alto e baixo nível dentro do sistema. ENTREGA Após o término 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 cliente avalie o que foi feito e, se necessário, solicite alterações. Essas alterações devem ser incluídas na lista do backlog para que sejam priorizadas e estimadas no início do próximo ciclo. 8

9 As funcionalidades que não foram implementadas, por falta de tempo ou outro motivo qualquer, devem ser apresentadas ao cliente, que irá retorná-la ao backlog para que seja mais uma vez priorizada, estimada e alocada em outro ciclo. MOTIVAÇÃO DA EQUIPE Vale a pena citar como um dos benefícios do trabalho em ciclos a motivação da equipe. Em um projeto tradicional é comum notar que a equipe de desenvolvedores não recebe feedback sobre seu trabalho até que o cliente finalmente veja o resultado no fim do projeto. Para que um projeto seja ágil, é preciso garantir feedback constante e, o fato do cliente "brincar" com o software a cada 2 semanas faz com que o feedback aconteça naturalmente. Isso permitirá ao desenvolvedor criar de forma livre, porém ir acostumando- se com o jeito do cliente, com o gosto do cliente. Em um curto espaço de tempo, a equipe já entende qual o estilo do software. A cada entrega acontece uma pequena vitória para o desenvolvedor, pois ele desenvolveu e apresentou sua criação. 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 é através de um gráfico conhecido como Burn Down. O conceito é simples, soma-se o total de funcionalidades listadas no backlog e diminui deste total a quantidade de funcionalidades implementadas a cada ciclo. Desta forma, a cada ciclo, o gráfico tende a se aproximar cada vez mais do zero no eixo X e, assim é possível visualizar a evolução em ciclo. Muitos optam por complicar um pouquinho mais o gráfico, adicionando o esforço estimado, o esforço gasto na realidade e o quanto falta para o fim das funcionalidades. Dessa forma o gráfico fica com 3 ou mais séries. MELHORIA CONTÍNUA - RETROSPECTIVAS Após realizar a entrega referente ao ciclo que acabou, a equipe se reúne e realiza uma reunião de auto avaliação, conhecida como reunião de retrospectiva. Nesta reunião cada membro é convidado e estimulado a citar o que ele achou que funcionou bem e o que ele achou que não funcionou bem neste ciclo. A equipe então debate ligeiramente sobre o tema, em atitude construtiva e delibera-se em busca de uma solução. 9

10 Normalmente na retrospectiva acontecem ajustes às práticas, cria-se um costume de autogerenciamento na equipe, pois dessa forma, todos são responsáveis pelo bom funcionamento da equipe, facilitando assim o convívio e a produtividade. 1.3 REQUISITOS A gestão de requisitos é um tópico muito importante e intimamente relacionado às outras áreas de um projeto de desenvolvimento de software. É um ponto importante a ser considerado quando se busca uma abordagem mais flexível e ágil. A gestão de requisitos por si só, quando mal feita, pode comprometer todo o andamento do projeto. Através dos tópicos abaixo, veremos como isso acontece e quais são as alternativas. USER STORIES User Stories são estórias que o usuário conta para descrever uma pequena funcionalidade do sistema. A idéia é passar para o desenvolvedor uma descrição de qual a operação deve ser implementada no sistema. Uma User Story deve ser pequena e específica, diminuindo assim as possibilidades de mal- entendidos em relação ao que deve ser implementado. Obviamente, os detalhes adicionais que não podem ser descritos em um pequeno texto devem ser disponibilizados de outra forma. Normalmente, a opção de conversar com o cliente sobre uma estória é a melhor solução para este caso. As user stories normalmente são descritas em pequenos cartões de papel, post-its ou até em software especializados. Cada cartão deve ser priorizado pelo cliente e estimado pela equipe de desenvolvimento. Apesar de ser recomendado o uso dos pequenos cartões, é possível, utilizar modelos alternativos, que se adequem melhor ao estilo 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 que aproximadamente 64% das funcionalidades desenvolvidas nos softwares não são utilizadas. 1 Isso ressalta alguns pontos: 1 Para mais detalhes, veja: 10

11 Isso é um fato que reflete quão precária é a idéia de levantar os requisitos todos de uma só vez. Muitas vezes, pelo fato do cliente só poder pedir uma vez, ele acaba pedindo coisas que não tem certeza de que precisa. Ele pede antes, porque sabe que depois, qualquer alteração no escopo pode custar muito caro. Essas funcionalidades fazem parte dos 64% que ele nem repara que estão lá, quando o software é entregue. Os softwares mais famosos e utilizados no mundo são os mais simples. Os usuários não gostam de coisas complexas e normalmente a complexidade de um software é refletida em sua interface de usuário. Mais uma vez, o princípio de Pareto se aplica, porém de forma mais forte. Estudos da Microsoft identificaram que 70% dos usuários utilizam as funcionalidades básicas de um software. 20% utilizam as funcionalidades intermediarias e finalmente 10% utilizam as funcionalidades avançadas. Como se pode imaginar, o esforço para desenvolver as funcionalidades avançadas e intermediarias são 80% do esforço total dos projetos. ESTIMATIVAS Outro fator importante a se levar em consideração é como o tempo de desenvolvimento total do projeto é estimado. É comum nos projetos tradicionais que as estimativas sejam feitas no início do projeto. Isso se deve basicamente por motivos de contrato: É preciso definir tudo o que será feito, pois isso normalmente é colocado no contrato para garantir que o cliente receberá pelo que está pagando. O contrato contém prazos e em alguns casos prevê multas, caso o produto não seja entregue no prazo correto. O contrato prevê alteração de valores no caso de mudanças no escopo do projeto. Apesar de parecer a única forma de se negociar software, esses tópicos do contrato trazem mais problemas do que soluções. A questão dos contratos foge ao assunto deste documento, por isso vamos nos restringir a pensar no que eles significam em relação às estimativas. Devido ao modelo do contrato, é preciso estimar e definir o preço total antes de assinar o contrato. O fornecedor dos serviços neste caso tem uma preocupação em estimar menos tempo e esforço que o necessário. Como solução ele se baseia em projetos "similares" que já acompanhou, além de iniciar uma corrida contra o tempo para entender e levantar "todos" os pontos importantes do sistema a ser estimado. Com esse esforço ele imagina que conseguirá chegar á um número aproximado de esforço e prazo. Em alguns casos utiliza até mesmo fórmulas como o caso dos Pontos de Função. A má notícia é que isso não funciona por que: O levantamento inicial nunca se aprofunda, por falta de tempo e recursos, nos detalhes da aplicação. Isso conduz a diversas suposições equivocadas a respeito do software, que só são descobertas no momento do desenvolvimento. Projetos de software que demoram mais que alguns meses estão sujeitos à mudanças drásticas. Algo que era útil para o cliente a 1 ano atrás pode não ser útil para ele hoje. 11

12 Sabidos de que as estimativas são falhas, os profissionais envolvidos costumam colocar uma "gordurinha". Super estimam o prazo como forma de garantir que terão tempo suficiente. Como provado pela teoria da Corrente Crítica, essa "gordurinha" é desperdiçada na hora de desenvolver, pois todos fielmente acreditam que 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 Visão Ágil

13 É fácil de perceber o quão falhas e prejudiciais são as estimativas quando feitas no momento errado. Por isso, o que propomos é que, de forma incremental, os desenvolvedores estimem o esforço e tempo gradualmente. Possibilitando assim, uma grande flexibilidade, facilitando a priorização e se bem trabalhado, até mesmo a utilização de versões parciais do sistema. Em um projeto ágil, as estimativas estão intimamente ligadas ao sistema de levantamento de requisitos através de user stories, onde cada user story é estimada individualmente pouco antes de ser implementada. Essas estimativas são mais precisas, pois são realizadas pelos desenvolvedores, em uma reunião e num momento em que a equipe já conhece melhor a complexidade e as implicações do projeto, pois já estão trabalhando no mesmo. 13

14 3. CONCLUSÃO Na Fratech, acreditamos seriamente que ser ágil não significa adotar uma metodologia ou um conjunto de práticas específicas. Não acreditamos que ser ágil significa abandonar tudo que já foi feito em uma empresa e, do dia para a noite, modificar o modo de agir e pensar de todos na empresa. Acreditamos que para ser ágil é necessária uma grande mudança cultural, mas sabemos que essa mudança é gradual. Essa mudança é aplicada através de um fluxo de melhoria contínua, baseado nas práticas de inspeção e adaptação. Ser ágil é focar no que realmente precisa ser feito, abandonando tudo o que não é necessário. O interessante desta declaração é que o necessário é específico para cada situação. O que é necessário para minha empresa, pode não ser necessário para a sua e vice-versa. Dessa forma, saiba que não há um processo pronto que lhe sirva bem. É necessário adaptar as práticas ao dia-a-dia de sua equipe, dentro da cultura e visão de sua empresa. Por fim, levando em consideração esses princípios, fica claro que é possível ser ágil dentro de qualquer contexto. E possível criar um ambiente mais maduro e adaptado ao desenvolvimento de software, sem perturbar as fundações de sua empresa. Para ser ágil não precisa ser intrusivo e nem informal. Apenas prático. A FRATECH PODE AJUDAR! Entender os conceitos e princípios do agile é o que faz com que uma implementação seja bem sucedida. A Fratech oferece ajuda para que sua evolução dentro dos conceitos do agile seja a mais fácil possível. Temos publicado materiais sobre esse e outros temas pertinentes, seja através do portal InfoQ ( da Revista Visão Ágil ( ou através de artigos na página de comunidade da Fratech ( Além disso, oferecemos serviços de consultoria e treinamento em agile. Se você achar que precisa de ajuda para aumentar a agilidade de seu processo atual, contate-nos através do comercial@fratech.net ou pelo telefone (19) que ficaremos felizes em lhe atender. Você pode encontrar mais informações sobre a Fratech em nosso site no endereço 14