Rafa Nascimento

A importância do RH em uma transição cultural

Posted in ágil, cultura by Rafa Nascimento on 06/11/2012

Tenho visitado algumas empresas de desenvolvimento de software durante as últimas semanas, e vivenciando uma excelente experiência sobre o ambiente de trabalho e os processos dessas empresas. Estas visitas e a hospitalidade dessas empresas têm sido uma excelente fonte de informação e aprendizado sobre o que está funcionando, o que não está funcionando e o que está sendo adaptado em um contexto agile/lean. Mas, em uma dessas empresas, uma coisa me chamou muito a atenção. E foi algo inclusive já vivenciado por mim e que trouxe lembranças úteis: o apoio do RH para o desenvolvimento de um ambiente de trabalho leve, descontraído e, ao mesmo tempo, produtivo.

Em muitas empresas percebemos uma mescla entre o Departamento de Recursos Humanos e o Departamento Pessoal, muitas das vezes havendo somente 1 departamento, com separação interna entre RH e DP. Mas, afinal, qual a diferença? Basicamente, um Departamento de RH tem como objetivo maior cuidar do bem-estar e desenvolvimento do capital humano da empresa. Este é o real responsável pelas pessoas e seu bem-estar. Normalmente é administrado por administradores e psicólogos. O Departamento Pessoal cuida de toda a burocracia que envolve folha de pagamento, admissão, demissão, férias, etc. Normalmente é administrado por contadores. Um documento de graduandos da Inesul explica mais detalhadamente as diferenças. E daí?

Daí que por muitos anos o “bem-estar das pessoas” ficou firmemente ligado ao cumprimento de leis trabalhistas e às burocracias relacionadas a pessoas. Poucas são as empresas (em sua maioria, as grandes empresas) que executam de fato a diferenciação entre RH e DP. E as consultorias de desenvolvimento de software? Conto nos dedos de 1 das mãos, e ainda sobra dedo, as consultorias que possuem um departamento ativo de RH. Felizmente, não é o caso dessa consultoria que visitei. Embora ainda existam vergonhosos casos de subordinação do RH ao DP. Enfim, por muitos anos, o Departamento de RH da grande maioria das empresas ficou, também, mergulhado nas burocracias que cabem única e exclusivamente ao Departamento Pessoal.

Com a adoção dos métodos ágeis para desenvolvimento de software, emerge uma preocupação humana muito forte, que se relaciona diretamente com motivação e, consequentemente, com produtividade. Uma preocupação psicológica, sociológica e antropológica, que está ligada única e exclusivamente ao RH das empresas, mas não ao DP. Mas, como o RH pode cuidar de tantas pessoas e observar de perto suas necessidades como seres humanos e profissionais? Surge, então, a figura do coach de equipes. O profissional que está ligado a cada equipe da empresa, assim como gerentes de projetos ou coordenadores, e que está única e exclusivamente focado na performance dos times do ponto de vista da motivação e do bem-estar. Enquanto gerentes de projetos e coordenadores têm por objetivo realizar a entrega de projetos ou produtos, ou seja, a execução do trabalho propriamente dito, e fazem a “ponte” com outros departamentos para que o trabalho seja coerente, o coach tem por objetivo garantir que a suas equipe tem as melhores condições possíveis, sob diversos pontos de vista (processos, clareza de requisitos, engajamento entre as pessoas do time, ambiente de trabalho, desenvolvimento profissional) para executar o trabalho que lhes é solicitado, mais importante ainda, como uma equipe de fato. Este é o profissional que vai fazer a “ponte” com o RH e atuar como um “braço” do RH em cada equipe. Não como um regulador um cumpridor de normas do RH, mas como um verdadeiro porta-voz das equipes para o RH, em busca da melhoria contínua da gestão e do ambiente de trabalho.

Fica claro, então, a importância do apoio do RH em um processo de transição para métodos ágeis ou lean para desenvolvimento de software. Mais do que apoiar, é preciso que o RH também acredite na nova cultura. Dessa transição surge um papel estritamente ligado às pessoas e ao seu bem-estar, que precisa de apoio, e mais do que apoio, de parceria com o RH (não o DP), ou seja, com os psicólogos da empresa, para que o seu trabalho seja bem-sucedido e a transformação dos processos e do ambiente de trabalho aconteça de fato e, mais do que isso, transforme-se em uma mudança cultural, firme e duradoura.

Arrisco dizer que sem o apoio dos psicólogos da empresa, a transição para a agilidade pode transformar-se em mais uma mera mudança nos processos. E é preciso muito mais do que video-games expostos ou budgets exclusivos para treinamentos. É preciso que os valores da empresa sejam identificados, expostos e celebrados todos os dias, e que eles sejam a base de todas as ações corporativas. Assim como fez essa empresa que visitei, hoje, uma das “100 Melhores Empresas para Trabalhar” do Rio de Janeiro.

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.

Fibonacci com Pimenta, Parte 1

Posted in ágil, estimativa by Rafa Nascimento on 16/03/2011

Planejamento de projetos de software buscam responder a 2 simples questões:

  • Quanto vai custar?
  • Quando estará pronto?

Não somente projetos de software, mas qualquer projeto de prestação de serviço, têm dificuldades para responder a estas questões. Isso por conta do grau de empirismo envolvido nestes projetos. Na construção de um prédio, de um carro ou na fabricação de um pacote de biscoitos, o grau de empirismo é muito baixo. Por estes projetos clássicos terem uma visão muito clara de seus objetivos finais, sua previsibilidade, incluindo margem de erro, é extremamente apurada. Em projetos de prestação de serviço, onde geralmente precisamos conhecer o ambiente, cotidiano, cultura ou negócio do nosso cliente, ou seja, fatores um tanto quanto fora de nosso controle, a previsibilidade decresce consideravelmente. Além da vertical “objetivo”, projetos de software trazem consigo outra vertical que acabam por criar o nível de insucesso mostrado no gráfico do StandishGroup abaixo, chamado Chaos Report: tecnologia. Sua evolução extremamente rápida neste mercado traz mais um dificultador para fazer previsões.

Sendo assim, podemos afirmar que projetos de software nada mais são do que gestão de conhecimento: conhecimento sobre o negócio de nossos clientes, ou do que vamos desenvolver, e conhecimento tecnológico, sobre como vamos desenvolver. Gerir estas 2 vertentes perante inúmeras possibilidades de aplicação de tecnologias que não cessam sua evolução e a constante evolução do próprio negócio de nossos clientes tornam o grau de previsibilidade de um projeto de software extremamente baixo.

Existem diversos métodos, científicos ou não, para estimar a duração e o custo de um projeto de software. Nenhum é exato. E a prática comum, e por si só equivocada, de transformar estimativas, que segundo o dicionário são cálculos aproximados, em compromissos se torna uma prática ainda mais equivocada no mundo do software, onde há empirismo por todos os lados. E as cobranças sobre este pseudo-compromisso acabam por minar, em muitos projetos, qualquer possibilidade de prever seu andamento futuro, ou até mesmo a possibilidade de conclusão. E o pior: desmotiva os times de desenvolvimento, que, normal e erroneamente, nada tem a ver com as estimativas.

Projetos ágeis de desenvolvimento de software costumam tratar estimativas simplesmente como estimativas, e criam mecanismos que permitem monitorar seu custo e duração durante todo o seu andamento, tornando estas informações visíveis e frequentemente atualizadas, desde o início do projeto, para os clientes. Para que seja possível ser previsível sem ser exato, estimativas ágeis utilizam-se de 2 ferramentas: o conhecimento prévio de negócio e tecnologia de um time que já trabalhou junto em, pelo menos, 1 projeto, e um método de pontuação de requisitos famoso por não se preocupar com a exatidão, e sim com o consenso conseguido através da experiência de um grupo de profissionais: Story Points, baseados nos números de Fibonacci.

Por que Fibonacci?
Segundo Mike Cohn, em seu livro Agile Estimating and Planning, estudos mostram que somos melhores estimando coisas dentro de uma determinada ordem de magnitude (Miranda 2001; Saaty 1996). No seu bairro, provavelmente você é capaz de estimar razoavelmente bem a distância relativa de coisas como a padaria mais próxima, a banca de jornais mais próxima ou a escola mais próxima. A escola pode estar duas vezes mais longe do que a padaria, por exemplo. Suas estimativas serão muito menos assertivas se você tiver que estimar a distância relativa para a lua ou para a capital de outro país. Porque somos melhores dentro de uma determinada ordem de magnitude, seria melhor se pudéssemos basear nossas estimativas sempre desta forma.

Os números de Fibonacci (0,1,1,2,3,5,8,13,21…) são muito úteis neste tipo de estimativa. Os intervalos entre os números se tornam apropriadamente longos à medida que os números crescem. Por conta desta interessante caracterísctica, inclusive, há quem veja relações dos números de Fibonacci com a Proporção Divina. O intervalo entre 1 e 2, bem como o intervalo entre 5 e 8, parecem respectivamente apropriados. Traduzindo para o mundo do software, quanto maior a pontuação de um requisito, maior o intervalo entre a pontuação do requisito e o número anterior. Este intervalo sugere o grau de imprevisibilidade do esforço envolvido no desenvolvimento do requisito. Ora, prever o quão custoso e arriscado deve ser desenvolver um requisito é tudo o que um gestor precisa saber para que possa tomar as medidas cabíveis contra os riscos envolvidos e garantir que o time tenha condições de desenvolver aquele requisito com sucesso.

Respondendo às perguntas
Em suma, mais importante do que acertar, no início de um projeto de software, o quanto ele deve custar ou quando terminará, é prover nossos clientes de transparência e informações suficientes sobre o projeto para que eles possam reagir adequadamente às novidades que costumam surgir durante este tipo de projeto. Na próxima parte deste artigo, veremos como estimar com Story Points e o que é necessário para transformar estas estimativas em um horizonte para nossos clientes.

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: