Rafa Nascimento

O futuro da Agilidade não é bonito

Posted in futuro by Rafa Nascimento on 30/10/2012

Concordo com o que Jurgen Appelo diz em seu post I don’t care about “Agile”.

Muitos fatos e experiências levam-me a crer que o Agile não tem um futuro necessariamente bonito. Embora a vontade, obviamente, seja oposta, é inegável o momento controverso pelo qual a filosofia passa. Compartilho abaixo alguns fatores que chamam a minha atenção e convido-os a uma reflexão.

  1. A figura mais emblemática rumo à adoção da agilidade e à mudança cultural necessária à agilidade, o Scrum Master, é um papel cada vez menos requisitado nas empresas. No ano de 2011, uma média de 8 a 10 anúncios de emprego buscando um Scrum Master eram encontrados para a cidade do Rio de Janeiro. Hoje, nenhum é encontrado. Muitos Scrum Masters que emergiram, emergiram de vontade de ver um novo ambiente de trabalho. Poucos têm o preparo necessário para exercer o papel, que, hoje, é mesclado por muitas empresas ao cargo de desenvolvedor, ao papel de líder técnico ou até mesmo ao papel do gerente de projetos. “Mas o Scrum Master é um papel!”, muitos dirão. Sim. Segundo o PMBoK, o Gerente de Projetos também.
  2. Não houve e nem está havendo uma mudança substancial na disciplina de gerenciamento de projetos, documentada hoje em dia pelo PMI. Muitos anúncios buscando gerentes de projetos que citam os métodos ágeis passam a impressão de que o conhecimento requerido é um “backup” para o caso de aparecerem projetos que fujam aos tradicionais, guiados pelo RUP. Resta a esperança de que gerentes de projetos tradicionais incorporem os princípios ágeis e que os líderes ágeis compreendam que o conhecimento sobre gerenciamento de projetos só tem a acrescentar ao trabalho. E resta a esperança de que a nova versão do PMBoK traga uma mudança substancial na disciplina considerando-se a gestão ágil, e não apenas citações.
  3. Uma sensação de final de “oba-oba” paira no ar. O Scrum foi inegavelmente o framework ágil de maior sucesso que apareceu, o método Kanban, até então, não tem mostrado grandes resultados e nenhum dos frameworks ágeis, nem mesmo o XP, pelas experiências que tive até hoje, conseguem manter as pessoas imbuídas em manter o processo funcionando minimamente bem. No mínimo respeitando os princípios do Agile e do Lean. Isso se deve a uma adoção mecanizada dos processos e a ausência de um trabalho de mudança cultural, que é muito mais complexo e demorado. Fica a impressão de modismo. A impressão de que a agilidade não vai ultrapassar a barreira da novidade. Vale lembrar que, apesar de a filosofia ágil ter mais de 10 anos, somente entre 2006 e 2008 ela começou a adentrar grandes empresas.
  4. Muitas empresas que adotaram a agilidade, hoje, estão tendo uma “recaída”de comando-controle, basicamente, por expectativas de produtividade não atendidas. Mais uma vez, fruto da falta de mudança profunda na cultura, que faz aferir a produtividade da mesma forma como aferia-se antes da “mudança” e da subestimação do fator humano no ambiente de trabalho. Além disso, empresas famosas por seus ambientes favoráveis aos profissionais da informação e criação, como a Google e o Facebook, evitam afirmar que utilizam métodos ágeis.
  5. A crença de que a filosofia ágil é algum método milagroso que transforma todas as pessoas que são tocadas em pessoas altamente comprometidas. É fato que a atenção ao fator humano na agilidade é imensamente maior, mas pessoas que não são comprometidas com as metas da empresa estão por toda a parte. Apesar da agilidade tratar essas pessoas de forma diferenciada, com compaixão e buscando encontrar a melhor equipe e projeto para elas, em certos casos não há solução que não a dispensa do profissional. Nem sempre há final feliz. E profissionais “espertos” e imaturos existem em qualquer lugar.
  6. Foco exagerado no processo e baixo na gestão do ambiente de trabalho. Uma das formas mais efetivas de provocar uma mudança cultural é mudar o próprio ambiente de trabalho e fazê-lo fluir “no sangue”. E exemplos não faltam: Google, Microsoft, Facebook, Philips. Na minha opinião, a parte mais efetiva de uma mudança concreta rumo aos princípios do Agile e do Lean é a mudança do ambiente de trabalho e a sua adequação ao trabalho com a informação e criatividade. E mais do que fazer a transformação: garantir que as novidades são úteis e são utilizadas pelos profissionais. Cansei de ver videogames e salas de descompressão “espetaculares” disponíveis aos profissionais que são vigiadas ou só podem ser usadas fora do horário do expediente. Acreditar que as mudanças podem gerar aumento de produtividade e incentivar o funcionamento de todas as iniciativas de ambiente. Se o foco estiver todo no processo, há grandes chances de ser só mais um processo que foi experimentado pela empresa.
  7. Negligência ao histórico dos times. A filosofia ágil é baseada em experimentação. E não há experimentação se não há estado anterior e estado atual. Métricas de performance são importantes para que as ações de melhoria contínua possam ter chance de ser efetivas. Métricas de satisfação do cliente são importantes para garantir que o planejamento dos esforços está apontando para a melhor direção possível.

Enfim, se continuarmos ignorando estes e outros fatores que, talvez, nem eu perceba, definitivamente há grandes chances de a filosofia ágil ser só mais uma moda. Assim como a Qualidade Total e a mais recente Re-Engenharia.

Como medir a produtividade de times ágeis

Posted in métricas by Rafa Nascimento on 22/10/2012

Um dos mantras mais repetidos em uma cultura ágil é “melhoria contínua”. Porém, pouco se faz de fato para facilitar o surgimento de um verdadeiro fluxo de melhoria contínua em um time ágil. Na maioria das vezes, apenas retrospectivas lúdicas com dinâmicas que visam diminuir o tormento de mais uma reunião e que, com o passar do tempo, por conta de resultados superficiais, perdem o efeito “suavizante” que deveriam ter para que a reunião gere um bom plano de ação. Então, como podemos tornar nossas retrospectivas mais produtivas e factuais? Como podemos ajudar nossos times na árdua tarefa de aferir a sua própria performance? Eis a maneira que encontrei de endereçar estes problemas.

Segundo Patrick Lencioni, em seu livro The 5 Dysfunctions of a Team, um time não pode ser considerado um time de verdade se o mesmo não é capaz de aferir os seus próprios resultados e reagir conforme a informação conhecida. Isso porque não é possível melhorar o seu processo se não há um histórico no qual se basear. A melhoria contínua, enfim, só se torna realidade quando é possível concluir que aspectos do processo são passíveis de melhoria, através de métricas.

Em muitas empresas, métricas são vistas como vilãs pelos times de desenvolvimento de software. Isso porque, durante muito tempo, as métricas foram utilizadas, em grande parte, para promover verdadeiras “caças às bruxas” em times que não vinham colhendo bons resultados. Ou seja, as métricas eram utilizadas, tardiamente, para buscar culpados por falhas e insucessos em projetos. Algumas vezes, métricas eram utilizadas sem um propósito claro, e sim pelo simples fato de que elas deveriam existir, perdendo-se excelentes oportunidades de descobrir problemas antes que eles acontecessem.

Para facilitar o processo de melhoria contínua no meu time, me fiz a seguinte pergunta: o que é interessante como métrica para o meu time, e ao mesmo tempo enxuto? Que métricas deveriam estar presentes em seu dashboard? E para responder a estas perguntas, recorri ao livro Agile Project Management, de Jim Highsmith, e ao triângulo da agilidade proposto por ele.

Segundo Highsmith, projetos ágeis devem buscar o equilíbrio entre valor agregado ao negócio, qualidade técnica e as restrições tradicionais de um projeto (tempo, custo e escopo). Tendo em vista estes prismas, criei um dashboard que oferece métricas para aferir os dados de cada um deles. O dashboard, então, fica dividido em 3 partes: o quão efetivo o time está sendo em trazer valor para a empresa que comprou o projeto, o quão efetivo o time está sendo em desenvolver um produto de alta qualidade e o quão efetivo o time está sendo em entregar valor e qualidade dentro das restrições de tempo, escopo e custo do projeto.

Para o prisma de valor agregado, por exemplo, utilizo-me de métricas como velocidade (quantidade de story points que um time á capaz de entregar por iteração), lead time (tempo decorrido entre o pedido de uma feature e a disponibilização da mesma em produção) categorizado por story points, tail (tempo decorrido entre a conclusão de uma feature e a utilização da mesma pelo usuário final) e cumulative flow (representando o tempo que cada passo do processo consome durante o desenvolvimento das features).

Para o prisma de qualidade interna, realizo, por exemplo, medições como a quantidade de pares distintos que estão sendo formados por iteração, a quantidade de releases com features e com bug fixes e a quantidade de quebras do CI por iteração.


Por fim, utilizo, por exemplo, um burndown por story points do trimestre e um gráfico de alocação de horas do time categorizado por tipo de atividade para o prisma das restrições de projeto (um empréstimo da galera da Globo.com!).

Desta forma, deixo visível para o meu time a performance de cada iteração e podemos discutir de uma forma mais factual as possíveis melhorias no nosso processo. Retrospectivas lúdicas são úteis em determinadas ocasiões e momentos do time, mas há momentos em que a melhor opção é vasculhar os dados históricos para encontrarmos possíveis pontos de melhoria que talvez não seriam vistos a “olho nu”.

#soudev

Posted in time by Rafa Nascimento on 02/07/2011

O que é desenvolver software?

 

Desenvolver um software envolve muito mais processos e pessoas do que o ato de escrever instruções que programem o comportamento de um computador. Todos os passos, artefatos, ferramentas e pessoas envolvidas em um projeto de construção de um software têm igual importância. Desenvolver um software é o ato milenar de desenvolver um produto. Quando trabalhamos em um processo como tal, não basta contarmos como “sucesso” somente o cumprimento da nossa parte. Durante o desenvolvimento de um software, somos uma comunidade de profissionais com objetivos em comum. Objetivos tecnológicos em comum e objetivos de negócio também em comum. Em um time de futebol, não basta a defesa defender. Isso não configura sucesso. O ataque precisar marcar gols.

 

Um projeto de desenvolvimento de software nada mais é do que uma ferramenta que nos ajuda na organização dos nossos esforços rumo à entrega de um produto de qualidade. Um equívoco comum na área é o fato de o projeto de desenvolvimento de um software tornar-se mais importante que o próprio software sendo desenvolvido. O produto deve ser o centro das atenções. Suas funcionalidades, qualidade e satisfação do cliente. Não as datas e previsões descritas em um cronograma. Deve-se pensar em gestão de produto, e não na gestão de projeto. Deve-se buscar excelência em qualidade de produto, não excelência em cumprimento de prazos.

 

Em um ambiente ágil, colaboração é a palavra-chave para que uma comunidade de profissionais conclua a construção de um produto. Aliás, colaboração é a palavra-chave em qualquer comunidade que possui um objetivo comum. Quando mães buscam seus filhos nas escolas e conversam entre si ponderando sobre a escola, vez ou outra surge um esforço colaborativo para viabilizar reuniões com professores e diretoria que visam buscar melhorias na qualidade de ensino e tratamento de seus filhos. Estas mães formam uma comunidade. Um grupo de pessoas com um objetivo em comum: dar a melhor educação e ambiente possíveis a seus filhos. Em um projeto de desenvolvimento de software, todos, do cliente ao desenvolvedor, devem formar uma comunidade de profissionais que colaboram em prol de um único objetivo: a entrega de um software de qualidade que atenda às expectativas do cliente e de seus usuários. Meu objetivo não é ser um excelente Scrum Master. Mas, sim, ser o melhor Scrum Master para a comunidade onde me encontro. A comunidade que desenvolve o mesmo produto que estou desenvolvendo.

 

Em um ambiente ágil, todos os esforços têm igual importância. Como em uma comunidade. O usuário desenvolve software, o patrocinador desenvolve software, o gerente de projetos desenvolve software, o scrum master desenvolve software, o testador desenvolve software, o designer desenvolve software, o desenvolvedor desenvolve software, o arquiteto desenvolve software. Embora trabalhemos como profissionais especializados, fazemos parte de times. E quando isso acontece, não basta que o nosso trabalho de codificação esteja excelente e o trabalho do designer esteja muito ruim. Se estamos desenvolvendo um produto como uma equipe, precisamos ajudar nossos companheiros designers ou testers a realizarem o seu trabalho também com a mesma qualidade que realizamos o nosso trabalho, e vice-versa. Então, em vez de afirmarmos “a minha parte eu fiz direito”, por que não questionar: como posso ajudar meu companheiro de jornada? O que mais posso fazer para ajudar a construir um produto de qualidade? Não uma tela de qualidade, um código de qualidade ou um planejamento de qualidade.

Tagged with: , ,

Fibonacci com Pimenta, Parte 2

Posted in ágil, estimativa by Rafa Nascimento on 22/04/2011

No post anterior sobre estimativa de projetos de desenvolvimento de software utilizando os números de Fibonacci, conhecemos a origem dos números, o motivo que cria a sequência como ela é e por que é mais fácil para nós, seres humanos, estimar por relativismo e não por absolutismo. Neste novo post, veremos como estimar projetos de desenvolvimento de software utilizando Story Points, como monitorar o andamento do projeto com eles (e motivar seu time) e, enfim, como responder as perguntas capitais: quando o software estará pronto e quanto irá custar.

Quando falamos em estimativa, buscamos informações de experiências prévias sobre o que queremos estimar que nos embase o suficiente para sermos satisfatoriamente assertivos. Porém, no mundo do software, é extremamente difícil haver experiências suficientemente parecidas que nos permitam ser assertivos ao ponto de não termos um prejuízo considerável ou perdermos um prazo. Sim, é possível acertar estimativas sob estas condições e ter, assim, projetos de sucesso. Mas as estatísticas mostram que o percentual destes projetos não passa de 50%. Um índice perigoso quando se trata, por exemplo, de um projeto de desenvolvimento de um software que objetiva melhorar um processo de densitometria óssea. Um projeto de construção civil; um prédio residencial, altamente previsível, por sua vez, beira os 100% de assertividade. Ou seja, para que sejamos capazes de ser assertivos em nossas estimativas de projetos de desenvolvimento de software, precisamos de projetos previsíveis. Projetos que se repetem, que têm muito em comum. Como isso é quase impossível na nossa área, precisamos monitorar o nosso caminho. Literalmente, andar pisando em ovos. As condições que precisam ser criadas em prol da previsibilidade de um projeto de desenvolvimento de software (um mesmo time que já passou por diversos projetos junto e adquiriu experiência suficiente como um time em sua existência) são poucos, insuficientes para tornar nossas estimativas assertivas, e nos obrigando a monitorar a saúde de nossos projetos e estarmos preparados para tormarmos decisões rápidas sobre o destino do mesmo. Em comparação ao futebol, há quanto tempo não se vê um time supercampeão no Brasil? A rotatividade, o “não conseguir manter a base do time” não permite mais que isso aconteça. Bem como nos times de software. Então? É ou não é ser previsível, por mais matemáticos que sejamos?

Usando Story Points para estimar trabalho

Já sabemos que somos melhores estimando por relação entre objetos do que usando números exatos. Então, como podemos usufruir de nossa natureza em prol de nossos objetivos na construção de software? Simples: Usando Story Points, que se baseiam nos números de Fibonacci. Para isso, basta atribuirmos “pesos” aos requisitos de nossos projetos baseando-nos nos Story Points (0,1,2,3,5,8,13,20,40,100). Esta sequência está presente em muitos decks comercializados de Planning Poker, um jogo para intermediar a estimativa de construção dos requisitos de um software que visa facilitar a colaboração em um time. Porém, em seu último post, Ken Schwaber defende que a estimativa use a real natureza dos números de Fibonacci. Ou seja, não teríamos 20 na sequência de Story Points, e sim 21. E o próximo número não seria 40, mas sim 34. E concordo com ele, pois a natureza dos números de Fibonacci já é suficiente para deixar claro o peso de cada requisito. Não há necessidade de adaptação.

Para testarmos a estimativa com Story Points, imaginemos o seguinte projeto: um time precisa ler 4 publicações, conforme abaixo:

Se as publicações são completamente desconhecidas pelo time, a probabilidade de haver falhas na estimativa deste projeto é bem alta. Se alguns membros do time conhecem algumas das publicações, as chances de o time acertar a estimativa aumenta. Se todos conhecem as publicações, as chances de sucesso do projeto são altíssimas, pois o método para atingir o objetivo já é bem conhecido por todos: ler. Se um membro do time não sabe ler, isso ficará evidente em uma rodada de Planning Poker. E como funciona uma rodada?

O Planning Poker é um jogo colaborativo que favorece a criação de consenso dentro de um time sobre a estimativa de tamanho de um determinado trabalho e ajudar a descobrir riscos no projeto. Todos os membros do time escolhem, individualmente, sua estimativa para cada requisito que lhe é apresentado em uma reunião de detalhamento e planejamento para a construção de requisitos. Suas escolhas são mantidas em segredo, para que um membro não influencie o outro. E, por fim, as estimativas são apresentadas, todas de uma só vez. Diferenças entre as estimativas fatalmente aparecerão, o que leva à necessidade de um melhor entendimento, pelo time, do requisito, e a rodada é repetida até que o entendimento pelo time sobre o requisito esteja homogêneo. Isso ajuda, no caso do nosso projeto, a descobrir quem já tem experiência em ler determinada publicação e pode ajudar o time e que membro do time não sabe ler, o que pode ser um risco para o projeto e precisa ser tratado.

Para mim, ler o livro sobre CMMI teria uma pontuação de 20. Já para um companheiro, seria 8, pois ele já leu algumas partes e eu nunca peguei no livro. Então, entramos em um consenso de que a estimativa para lermos o livro sobre CMMI pode ser 13, porque os membros do time que conhecem o livro terão a carga extra de ajudar os que desconhecem. E, os que desconhecem, terão a carga extra de chegar ao mesmo nivel dos demais.

Ora, se o livro sobre CMMI tem 13 pontos de peso, ler a revista Caras não pode ser um esforço do mesmo tamanho. Porém, dependendo da experiência prévia do time, o livro sobre Orientação a Objetos pode chegar ao mesmo nível de esforço do livro sobre CMMI. Como podemos concluir, estimar depende muito da experiência prévia do time que executará as tarefas. Este projeto pode ter uma pontuação total de 30 para o meu time. Mas, para o seu, pode ser 20. Quanto tempo um time leva para atingir 30 ou 20 pontos? Mais uma vez, depende da experiência prévia destes times. Meu time pode levar 1 semana para atingir 30 pontos. Seu time pode levar o mesmo tempo para atingir 20 pontos. Então, devemos aprender a montar supertimes? Não. Temos que aprender a promover o crescimento individual de cada membro dos nossos times e reter, assim, os talentos necessários para o sucesso de nossos projetos.

Navegando por mares bravios: Se vigiamos os marinheiros, o mar nos surpreende

O sextante é uma ferramenta de navegação que permite saber o quão próxima uma embarcação está de seu destino. Se o capitão desta embarcação se preocupasse em saber se todos os seus marinheiros estão trabalhando como deveriam e se o estão fazendo da forma “correta”, esta embarcação teria grandes probabilidades de nunca chegar ao seu destino. Afinal, quem estaria no encargo de manter a embarcação na sua devida rota e motivar seus marinheiros informando-os do resultado de seu trabalho em prol do cumprimento do objetivo, que é a sua chegada a um local pre-determinado? Ainda há a enorme possibilidade de uma tempestade surpreender o capitão controlador, pois não estaria engajado em cumprir com seu objetivo, que não é manter seus marinheiros ocupados, mas guiar a todos de forma segura e competente ao seu destino. Portanto, em nossos projetos de desenvolvimento de software, nossa única preocupação é medir o quanto de software produzido com qualidade tem em mãos, para que, dentro do prazo acordado com nosso cliente, lhe entreguemos seu produto.

Progresso = Software funcionando. Foco no valor do software para o negócio, não no cronograma
Responder às questões “quanto custará”

e “quando ficará pronto” em um projeto de desenvolvimento de software é análogo a navegar uma embarcação. É necessário progredir, ou seja, ter software funcionando com qualidade, para que consigamos saber em que data conseguirá entregar o software a cada momento do ciclo de vida de um projeto e quanto isso custará. Diante de uma data previamente definida por nossos clientes, precisamos ajustar o escopo do projeto para que os requisitos de maior valor de negócio para o nosso cliente sejam priorizados, e, assim, consigamos satisfazer suas expectativas. Por isso, é de suma importância a participação ativa do cliente no projeto. Concluimos que tentar responder a estas perguntas no início de um projeto (certas vezes, até antes do início) é impossível. É um chute, qualquer que seja o método utilizado, em se tratando de software. Fatalmente, esta estimativa será atualizada durante o andamento do projeto. E os métodos ágeis de desenvolvimento de software prevêem este fato. E focam todo o esforço dedicado a um projeto na entrega o mais breve possível de valor para o cliente em forma de software, e não nos ajustes do cronograma e do tamanho do time em um projeto focando um plano criado no início do mesmo.

Manifesto Ágil, explicado

Posted in ágil, manifesto by Rafa Nascimento on 14/03/2011

Os Valores Ágeis

O importante de compreender sobre os quatro valores ágeis é que enquanto você deve valorizar os conceitos sobre o lado direito, você deve valorizar as coisas do lado esquerdo ainda mais. A boa maneira de pensar sobre o manifesto é que o mesmo define preferências, não alternativas, estimulando um foco em determinadas áreas, mas não eliminando 
em outras. Os valores do Manifesto Ágil são:

Indivíduos e interações sobre processos e ferramentas
Times de pessoas desenvolvem software, e para isso eles precisam trabalhar de forma eficaz – incluindo, mas não limitado, a programadores, testadores, gerentes de projetos, modeladores, e seus clientes. Quem você acha que desenvolveria um sistema melhor: cinco desenvolvedores de software com suas próprias ferramentas de trabalho juntos em uma sala ou cinco pessoas com poucas qualificações, com um processo bem definido, as ferramentas mais sofisticadas, e os melhores escritórios que o dinheiro poderia comprar? Se o projeto for razoavelmente complexo meu dinheiro seria sobre os desenvolvedores de software, e o seu? O ponto é que os fatores mais importantes que você precisa considerar são as pessoas e como elas funcionam juntas, porque se não acertar nisso, as melhores ferramentas e processos serão desnecessários. Ferramentas e processos são importantes, não me interpretem mal, só que eles não são tão importantes quanto trabalhar em conjunto de forma eficaz. Basta lembrar o velho ditado: um tolo com uma ferramenta ainda é um tolo. Como Fred Brooks pontua em “O mítico homem-mês”, isso pode ser difícil para a gestão de aceitar porque eles muitas vezes querem crer que as pessoas e o tempo, ou os homens e os meses, são intercambiáveis.

Software funcionando sobre documentação abrangente
Quando você pergunta a um usuário se ele gostaria de ter um documento de cinquenta páginas descrevendo o que você pretende construir ou o software em si, o que você acha que ele escolheria? Meu palpite é que 99 vezes entre 100 ele vai escolher software funcionando. Se for esse o caso, não faz mais sentido trabalhar de forma que você produza software de forma rápida e, muitas vezes, dando aos usuários o que eles preferem? Além disso, eu suspeito que os usuários teriam uma facilidade maior de compreender qualquer software que você produz no lugar de diagramas técnicos complexos descrevendo o seu funcionamento interno ou descrevendo uma abstração de sua utilização, não é? Documentação tem o seu lugar, por escrito corretamente é um guia valioso para a compreensão das pessoas de como e porque um sistema é construído e como trabalhar com o sistema. No entanto, nunca esquecer que o principal objetivo do desenvolvimento de software é criar o software, e não documentos – caso contrário, seria chamado desenvolvimento de documentação, não seria?

Colaboração do cliente sobre negociação de contrato
Apenas o seu cliente pode dizer o que ele quer. Sim, ele provavelmente não tem habilidades para especificar exatamente o sistema. Sim, ele provavelmente não sabe o que quer de primeira. Sim, ele provavelmente vai mudar de ideia. Trabalhar juntamente com seu cliente é difícil, mas essa é a realidade do trabalho. Ter um contrato com seu cliente é importante, ter uma compreensão dos direitos e responsabilidades de cada um pode formar a fundação do referido contrato, mas um contrato não é um substituto para a comunicação. Desenvolvedores de sucesso trabalham em estreita colaboração com seus clientes. Eles investem o esforço para descobrir o que seus clientes necessitam, e eles educam os seus clientes ao longo do caminho.

Responder a mudanças sobre seguir um plano
As pessoas mudam de prioridades por uma variedade de razões. Conforme o trabalho progride em seu sistema, a compreensão do dono do projeto sobre o domínio do problema e do que você está construindo muda. O ambiente de negócios muda. A tecnologia muda ao longo do tempo, embora nem sempre para melhor. Alterar é uma realidade de desenvolvimento de software, uma realidade que o seu processo deve refletir. Não há nada de errado em ter um plano de projeto, na verdade, eu estaria preocupado com qualquer projeto que não tenha um. 
No entanto, um plano de projeto deve ser maleável, deve haver espaço para mudar conforme a sua situação muda. Do contrário, seu plano torna-se irrelevante rapidamente.

Os Princípios Ágeis

Para ajudar as pessoas a obter uma melhor compreensão do que é o desenvolvimento ágil de software, os membros da Agile Alliance refinaram as filosofias capturadas em seu manifesto em uma coleção de 12 princípios. Estes princípios são:
Nossa maior prioridade é satisfazer o cliente através entrega breve e contínua de software de valor
Por alguma razão, muitas pessoas em TI parecem ter esquecido que o objetivo do desenvolvimento de software deve ser o desenvolvimento de software. Ou, talvez, o problema é que eles pensam que eles precisam definir tudo na frente antes que eles possam iniciar a construção do software, ao passo que uma abordagem evolutiva para o desenvolvimento parece funcionar muito melhor.

Mudanças nos requisitos são bem-vindas, mesmo que tarde. Processos ágeis absorvem mudanças em prol da vantagem competitiva do cliente
Goste ou não, os requisitos vão mudar durante um projeto de desenvolvimento de software. Desenvolvedores de software tradicionais, muitas vezes, adotam processos de gestão de mudanças que se destinam a evitar ou reduzir aumento de escopo, mas quando você pensa sobre isso, estes são realmente processos de prevenção de mudanças, e não processos de gestão de mudanças. Agilistas abraçam as mudanças e, ao invés, seguem uma abordagem de gestão ágil de mudanças que trata requisitos como priorizados em uma pilha, que pode variar ao longo do tempo.

Entregar software funcionando frequentemente, de um par de semanas a um 
par de meses, com preferência para o período de tempo mais curto
Entregas frequentes de software funcionando fornecem aos donos do projeto um feedback concreto, tornando o estado atual de seu projeto transparente e permitindo que eles forneçam um melhor direcionamento ao time de desenvolvimento.

Especialistas de negócio e desenvolvedores devem trabalhar juntos diariamente durante 
todo o projeto
Seu projeto está em sérios apuros se você não tem acesso regular aos interessados. Os desenvolvedores ágeis adotam práticas como manter o cliente no local do desenvolvimento e incentivar a participação ativa do mesmo, além de adotar ferramentas inclusivas e técnicas que permitem que os interessados se envolvam ativamente com o desenvolvimento do software.

Construir projetos em torno de indivíduos motivados. Dê-lhes um bom ambiente e o suporte que precisam, e confie neles para realizar o trabalho
Muitas organizações têm uma visão de que eles podem contratar hordas de 
pessoas relativamente não-qualificadas, dar-lhes uma descrição de processo compatível com CMMI / ISSO que eles vão desenvolver com sucesso o software. Isso não parece funcionar muito bem na prática. As equipes ágeis, por outro lado, percebem que você precisa criar equipes de pessoas que estão dispostas a trabalhar de forma colaborativa e aprender uns com os outros. Eles têm a humildade para respeitar um ao outro e perceber que as pessoas são um fator primário de sucesso no desenvolvimento de software.

O método mais eficiente e eficaz de transmitir informação para um time e dentro de um time é a conversa cara-a-cara
Para um time de desenvolvimento de software ser bem-sucedido seus membros devem se comunicar e colaborar de forma eficaz. Há muitas maneiras de as pessoas se comunicarem em conjunto, e como você já deve ter percebido, a comunicação cara-a-cara em um ambiente de desenho compartilhado (como papel ou um quadro branco) é a maneira mais eficaz de fazê-lo.

Software funcionando é a medida primária de progresso
A principal medida progresso no desenvolvimento de software deve ser a entrega software funcionando que atenda as necessidades mutáveis de seus donos, não alguma forma de mensuração de “valor agregado” com base na entrega de documentação ou na realização de reuniões.

Processos ágeis promovem o desenvolvimento sustentável. Os clientes, 
desenvolvedores e usuários devem ser capazes de manter um ritmo constante 
indefinidamente
Assim como você não pode dar um sprint por uma maratona inteira, você não pode desenvolver software com sucesso forçando as pessoas a trabalhar horas extras durante meses em um determinado momento. Minha experiência é que você só pode realizar trabalho intelectual de alta qualidade intelectual por 5-6 horas durante um dia antes de começar a se cansar. Sim, o resto do dia pode ser preenchido com e-mails, reuniões, discussões informais, e assim por diante, mas a capacidade das pessoas para fazer “trabalho real” é limitada. Sim, você pode ser capaz de fazer um trabalho de alta qualidade a 12 horas por dia, e fazê-lo por alguns dias seguidos, mas depois de algum tempo você esgota-se e tudo o que você tem são 12 horas de um trabalho medíocre por dia.

Atenção contínua à excelência técnica e bom projeto melhoram a agilidade
É muito mais fácil de compreender, manter e evoluir código-fonte de alta qualidade do que é trabalhar com código de baixa qualidade. Portanto, agilistas sabem que precisam começar com um bom código, mantê-lo bom via refatoração, e adotar uma abordagem orientada a testes de forma que eles saibam a qualquer momento que seu software funciona. Nós também adotamos e seguimos diretrizes de desenvolvimento, particularmente orientações de codificação e até mesmo diretrizes de modelagem.

Simplicidade – a arte de maximizar a quantidade de trabalho não feito – 
é essencial
Os desenvolvedores ágeis focam em atividades de alto valor. Nós nos esforçamos em maximizar o retorno sobre os investimentos em TI de nossos clientes, e cortamos ou automatizamos o trabalho pesado.

As melhores arquiteturas, requisitos, e projetos emergem de times auto-organizáveis
Este é um dos princípios mais radicais do manifesto. O Modelo de Desenvolvimento Ágil de Software (AMDD) e o test-driven design (TDD) são os enfoques principais dentro da 
comunidade ágil para garantir o surgimento de arquiteturas, requisitos e projetos eficazes.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, e ajusta seu comportamento em conformidade
Melhoria do processo de software (SPI) é um esforço contínuo, e técnicas como 
retrospectivas devem ser adotadas para permitir a melhoraria da sua abordagem 
ao desenvolvimento de software.

Escrito por Scott W. Ambler

Referência: http://www.ambysoft.com/essays/agileManifesto.html

Tagged with: ,
%d blogueiros gostam disto: