Como Criar Um Processo Agil

CRIANDO UM PROCESSO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE
CRIANDO UM PROCESSO ÁGIL

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

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.
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 http://agilemanifesto.org/.
É 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.
1.1 METODOLOGIAS
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
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
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, recomenda-
se 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
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
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
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
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
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
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: http://www.standishgroup.com/sample_research/chaos_1994_1.php
10
 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
 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 Á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
É 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
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 (www.infoq.com/br), da Revista Visão Ágil (www.visaoagil.com)
ou através de artigos na página de comunidade da Fratech
(www.fratech.net/comunidade).
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 email comercial@fratech.net ou pelo telefone
(19) 3454-8335 que ficaremos felizes em lhe atender.
Você pode encontrar mais informações sobre a Fratech em nosso site no

endereço www.fratech.net
14

Como Criar Um Processo Agil

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Como Criar Um Processo Agil

Uploaded by

Copyright:

Available Formats

CRIANDO UM PROCESSO ÁGIL PARA DESENVOLVIMENTO DE SOFTWARE

CRIANDO UM PROCESSO ÁGIL

Autor: Felipe Rodrigues de Almeida 1

O Manifesto Ágil é um documento criado com o intuito de

A Gestão Ágil envolve um profundo processo de melhoria

As metodologias mais conhecidas são:

 Lean Software Development

1.2 COMEÇANDO UM PROJETO

Estas fases normalmente são divididas em dois momentos importantes no projeto:

Veremos abaixo, essas etapas.

Todo software possui usuários. Uma ou mais pessoas irão utilizá-lo

Entendemos que há casos em que é impossível ouvir diretamente o cliente

Com o product owner presente, o software resultado do desenvolvimento

Então nos perguntamos: "E quanto aos outros 20% de benefícios?".

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

O cliente também deve listar algumas das

O backlog pode ser utilizado para criar uma estimativa

Isso não é ágil!

As práticas mais citadas e interessantes são:

 Desenvolvimento Orientado a Testes

Vale a pena citar como um dos benefícios do trabalho

Para que um projeto seja ágil, é preciso garantir

BURN DOWN CHART

MELHORIA CONTÍNUA - RETROSPECTIVAS

Normalmente na retrospectiva acontecem ajustes às práticas, cria-se um costume de autogerenciamento na equipe,

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

 O contrato prevê alteração de valores no caso de mudanças no escopo do projeto.

A má notícia é que isso não funciona por que:

Em um projeto ágil, as estimativas estão

A FRATECH PODE AJUDAR!

Entender os conceitos e princípios do agile é o que faz com que uma

Além disso, oferecemos serviços de consultoria e treinamento em agile. Se

Você pode encontrar mais informações sobre a Fratech em nosso site no

You might also like