Arquivo da categoria: Agile

SWX Labs 08 – Equipes de Alto Desempenho

capa02

No SWX Labs 08 Mike e Vinicius  conversam com Alércio Bressano sobre Equipes de Alto Desempenho.

Alércio nos mostra o caminho das pedras para criar uma equipe de alto desempenho usando metodologias ágeis, notadamente o Scrum. Dos fracassos iniciais à construção de um time de alto desempenho, passando pela conquista da confiança de sua equipe Alércio mostra que inovar em metodologias de trabalho é um caminho possível e real.

Ouça o podcast clicando no play, se preferir faça o download

Assine o feed do nosso podcast e não perca nenhum episódio: http://feeds.feedburner.com/SWXLabs

Se preferir, também estamos no Itunes Store

Gostou? Não gostou? Erramos algo? Sua opinião é muito importante para nós, por isso deixe seu comentário ou envie email para mike@swx.com.br

Imagem: O termo Scrum se origina de uma jogada de Rugby, por isso homenageamos a competente e divertida seleção neozelandeza de rugby.

Seja ágil ou seja esmagado!

agile-cloud

Desenvolvimento Ágil não é mais uma forma alternativa de desenvolver software. Com o ritmo de adoção de tecnologia acelerando em um ritmo frenético, desenvolvimento ágil está se tornando a única forma de desenvolver software. Isto é, se você quiser permanecer no, mercado.

Baixando a expectativa a cada release

Desenvolvimento ágil de software refere-se essencialmente a um processo incremental e iterativo de desenvolvimento de software, em oposição à velha escola do método “cascata”, que dependiam de um planejamento inicial de longa duração. Desenvolvimento Ágil pressupõe que os projetos de TI frequentemente falham, apesar de nossas melhores intenções. Ele é, consequentemente, uma forma de minimizar o custo de falhas fazendo com que o processo de desenvolvimento de software seja altamente sensível a alterações.

E, embora o desenvolvimento ágil possa ter sido exclusividade das empresas de tecnologia com pouca burocracia, notadamente as que desenvolvem de aplicações móveis ou web de ponta, ele tem ido agora para o mainstream. Como analista da Forrester Diego Lo Giudice observa:

Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. (Na era aplicações modernas, independentemente se novas aplicações de software estão sendo desenvolvidos e entregues para dispositivos móveis, tablets, ou para a Web, os desenvolvedores verdadeiramente bem sucedidos serão aqueles que se concentrarem em entregar valor constante e melhoria incremental para seus negócios.)

É importante ressaltar que as razões para abraçar o desenvolvimento ágil é tanto em razão do antigo método conservador e tedioso quanto o aumento de velocidade de desenvolvimento, como eu ouvi de um executivo da empresa de um (muito) grande serviços financeiros:

OH: “Product stability comes from releasing code more frequently, not less. You want each release to be a non-event, not a major launch.”

— Matt Asay (@mjasay) October 2, 2013

Os tempos estão mudando

Este tipo de abordagem iterativa para o desenvolvimento de software tem sido sempre uma boa ideia, mas está se tornando crítica com a mudança tecnológica e aumento de adoção, como Harvard Business Review mostra:

Tech Adoption Increasing

Tal aumento da adoção, por sua vez, é, sem dúvida conduzido por uma infraestrutura muito mais flexível, particularmente de software. Software de código aberto oferece um enorme conjunto de softwares de qualidade a partir do qual os desenvolvedores podem projetar os seus, uma vez que o hardware acessível por meio das nuvens (Infrastructure-as-a-Service -IaaS) torna trivial para escalar vertical e horizontalmente.

Com isto em mente, o mais novo de dados do Synergy Research Group sobre a adoção de IaaS é tão interessante tanto não porque demonstra que a Amazon domina completamente o mercado, o que nós sabíamos, mas porque mostra o crescimento em todos os principais provedores de nuvem:

iaas-paas-q313-release

Seja qual for o seu provedor, então, a infraestrutura existe para acelerar o desenvolvimento.

Big Data Exige uma abordagem ágil

Isto é particularmente importante em novas áreas de exploração, como Big Data. Como mostra a pesquisa da Gartner, as empresas estão obcecadas em começar com Big Data, mas muitas vezes não têm mais que de uma pista sobre como lidar com esses projetos.

Big Data é novo, e vamos enfrentá-lo: a maioria das empresas provavelmente irá falhar quando começarem seus projetos. Afinal, é quase garantido que as empresas não sabem quais dados capturar, ou a forma de aproveitá-lo, sem tentativa e erro. O desenvolvimento ágil, consequentemente, torna-se crítico para um projeto que venha a falhar, uma vez que tal abordagem reduz o custo de falhas, tanto em termos de tempo e dinheiro.

Isto poderia ser feito em uma abordagem em cascata tradicional? Claro. E muitas empresas quase certamente irão abordar o Big Data e outros projetos dessa maneira, porque eles simplesmente não conhecem nada melhor. Mas não seja essa empresa, ou esse desenvolvedor. O desenvolvimento ágil não é um Santo Graal que vai resolver todos os problemas de um desenvolvedor, mas é uma forma astuta de acompanhar a inovação tecnológica (como o Big Data) e para resolver projetos de desenvolvimento em larga escala.

Fonte: ReadWrite

Precisamos de uma metodologia mais ágil

Fonte: Fabio Camera/IMasters


Desde o princípio, em qualquer relação humana, o indivíduo organizado serve de exemplo, estimula e ensina ao indivíduo menos organizado. É assim com as crianças em relação aos adultos. É assim nas corporações quando inicia um novo funcionário inexperiente. Quem está aberto para crescer sempre busca aprender um método mais eficiente com alguém qualificado.

Dessa afirmação já se justifica a utilidade funcional de uma metodologia. De forma simplista, podemos traduzir metodologia como uma proposta particular de organização de métodos úteis e funcionais a mais de um indivíduo para uma determinada situação.

Nesse contexto, qualquer metodologia é perfeita. Se já funcionou para uma situação específica, depois foi documentada e agora pode ser utilizada por mais pessoas – é uma metodologia perfeita. É uma experiência similar ao princípio do método científico em sua finalidade.

Porém, muitas corporações, muitas equipes falham em atingir resultados satisfatórios com a utilização de uma metodologia. Onde está o problema? Nas pessoas? Na corporação? Na cultura? Muitas iniciativas frustradas têm uma explicação muito simples para o insucesso: quando não se tem a menor ideia daquilo que se está procurando, fica difícil encontrar.

Por que precisamos de um método ágil?

Recentemente, abordei esse assunto com um competente gestor de projetos que veio trabalhar em nossa empresa. Eu sabia que ele havia implantado na empresa anterior e eu precisava descobrir a motivação e os problemas para os quais ele buscava soluções.

Ele citou que o maior problema é que todos faziam a mesma coisa todos os dias, e o problema se tornava maior, ao invés de diminuir. Imagine uma rotina diária: cansativa – aquela ferramenta, aquela linguagem para o mesmo sistema, quase sempre entediante, certamente monótona pela ausência de oportunidades. O mesmo trabalho, as mesmas pessoas, e o que era antes uma vocação tornou-se somente um trabalho como outro qualquer.

Antes de tentar um método ágil, esse gestor acreditava que o problema estava no controle – ou melhor – na falta de controle. Com isso, aumentava a “pressão” por resultados no time, de vez em quando aumentava o time, frequentemente aumentava a quantidade de horas de trabalho diária, entretanto os resultados não se mostravam muito diferentes do que já eram.

Eu o questionei a respeito desta compreensão: se ele entendia que precisava fazer algo diferente, se esperava por resultados diferentes, por que havia resistência à proposta da metodologia ágil?

Resposta do gestor:

Nas iniciativas de implantação de Agile que presenciei ou das quais participei, a maior resistência era o medo de “perder o controle” sobre a qualidade do resultado do projeto. De alguma forma, alguns envolvidos acreditavam que o uso de metodologias ágeis resulta em um produto de baixa qualidade ou que não atende às expectativas.

Por fim, essa falsa crença foi justamente um dos motivadores para encarar o desafio na empresa que implantei. Ter a oportunidade de mostrar que o resultado seria justamente o oposto fazia o esforço mais compensador.

Ao analisar um ambiente que adotou uma metodologia ágil, após longos períodos de utilização de uma metodologia convencional, é possível observar diversos ganhos, dentre os quais destaco:

  • Maior produtividade: Entregar mais em menos tempo. Evitar desperdiçar o tempo com o que não é importante. Em ambientes mais engessados, perdemos muito tempo com um processo burocrático e por vezes ineficiente;
  • Entregas constantes: Proporcionar feedback de todos, dos clientes, dos usuários, dos contratantes e etc., com frequência;
  • Mais qualidade: Menor número de retrabalho e defeitos. Código com melhor “manutenibilidade” e escalabilidade;
  • Maior envolvimento do time: As reuniões diárias e as outras interações sugeridas pela metodologia ágil fizeram o time funcionar como time. Todos se conheciam, sabiam aonde podiam chegar.

Fazendo o mesmo comparativo com um ambiente que antes não seguia metodologia alguma, os ganhos também são expressivos: maior visibilidade, melhor comunicação e enorme incremento de qualidade.

Dessa forma, encontrei a resposta para a minha intenção com esse gestor. Com essas informações, concluí que sem novidade de meios (ferramenta ou linguagem), somente ordenando de uma forma diferente o “como” você faz diariamente, somente utilizando uma técnica diversa ao seu cotidiano, possivelmente podemos alcançar um fim novo.

O hábito que o sujeito carrega dentro de si para o trabalho, com o tempo, torna-se o seu maior algoz, o seu maior limitante. Impede-o de verificar novas opções, alternativas diversas. Implantar mais controle para mudar os resultados é automatizar um ser humano. É como se transformássemos um desenvolvedor em um robô. E como se medíssemos um programador como um atleta, buscando fazer cada vez mais rápido a mesma coisa.

A proposta de uma metodologia deve melhorar a comunicação, a interação entre os partícipes, a sinergia entre expectativas e os resultados. Afinal, processos fabris no universo da informática não deveriam ser “uma linha de montagem” em que pessoas ficam isoladas em suas mesas e computadores conectadas à internet, e ao mesmo tempo desconectadas com o projeto.

Infelizmente, nossos desenvolvedores são formados à margem dessa proposta de comunicação e interação. Um desenvolvedor nunca é estimulado a ser comunicativo ou a trabalhar em equipe de verdade. Na escola superior de ciência da computação, recebe uma educação matemática robótica que o estimula a se tornar um introspectivo cientista lógico.

O que esperar de uma metodologia ágil?

Um critério, válido, que podemos utilizar para definir se uma metodologia nos ajuda ou nos atrapalha em nosso dia-a-dia é a visibilidade que os problemas alcançam. Se somente o time do trabalho sabe/soube dos problemas e para os clientes ficou imperceptível, certamente a metodologia usada está sendo funcional.

Outro critério é a versatilidade das técnicas. Se há baixa aderência com a cultura existente e não há espaço para adaptações, a imposição da disciplina rígida nos proporcionará resultados comportamentais indesejados, como a resistência a mudanças pelas pessoas. O segredo nesse ponto é nunca perder de vista a razão de ser do trabalho, da empresa e de sua cultura. A metodologia deve propor técnicas para incrementar isso, não trazer razões contrárias. Numa metodologia inflexível, com restrições em excesso, você para de pensar no que pode fazer para se preocupar com o que não pode fazer. Se há uma imposição de seguir tudo o que está em manuais para o seu projeto, muita coisa escapará do que está escrito e ninguém saberá o que fazer.

Mais um critério que considero muito válido é o da análise do resultado. Os métodos sugeridos pela proposta metodológica devem trazer uma compreensão real sobre a capacidade de realizar e a capacidade de coordenar um grupo a um único escopo. É conduzir um projeto através de técnicas que não permitam dúvidas sobre o valor, o mérito e a expectativa de sucesso. No fim, sucesso é uma convenção social do grupo que definiu o escopo. O que é inicialmente pensado como sucesso para o time pode não ser sucesso para os contratantes ou para os clientes. A metodologia ágil ensina técnicas para se obter o critério de sucesso de um projeto.

Para não alongar demais com sugestões de critérios, concluindo de forma mais generalista, entretanto muito completa, podemos nos utilizar dos valores do Manifesto Ágil. Ele foi escrito por Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie Van Bennekun, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunninghan, John Kern, Dave Thomas, Martin Fowler e Brian Marick

O Manifesto Agil contém quatro valores fundamentais:

  • Os indivíduos e as suas interações acima de procedimentos e ferramentas;
  • O funcionamento do software acima de documentação abrangente;
  • A colaboração dos clientes acima da negociação de contratos;
  • A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

Referência Bibliográfica:

  • MENEGHETTI, A. A Psicologia do Líder. 4ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2008.
  • MENEGHETTI, A. Sistema e Personalidade. 3ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2004
  • HEWARD, L. Cirque Du Soleil – A Reinvenção do Espetáculo. 8ª. Edição. São Paulo, SP: Elsevier Editora, 2006
  • ANDERSON, D. Agile Management for Software Engineering. 2ª. Edição. New York, NY: Prentice Hall Editora, 2004

Gerentes em Agile: Nocivos ou apenas despreparados?

Fonte: Rafael Buzon

Segundo Joe Little, muitos da comunidade ágil acreditam que os gerentes são nocivos às equipes, mas o problema, ele defende, está mais no despreparo:

É fato que há muitos gerentes que não gerenciam bem… Mas acredito que a principal razão para isso é que não foram bem treinados. Ou ninguém os ensinou, ou foram ensinados de forma errada, ou mesmo aprenderam errado.

Dave McNulla, em comentário no post de Little, reforça o argumento do despreparo dos gerentes para o Agile, sugerindo que este desconforto da comunidade venha da maneira desconexa com que os gerentes tomam decisões no dia a dia:

Decisões gerenciais geralmente não levam em conta o ambiente ágil, pois muitos gerentes não fazem ideia do que seja Agile.

McNulla afirma ainda que muitos gerentes nem sequer conhecem o Manifesto Ágil ou os princípios que norteiam as práticas ágeis, e acrescenta:

Enquanto os gerentes não pararem de pensar no Agile somente como uma técnica, este cenário não mudará.

Joe Little contesta também o sentimento equivocado, tanto dos próprios gerentes, quanto de seus subordinados, de que ninguém deve corrigir os gerentes. Entretanto, ele destaca que a hierarquia e o poder não contribuem tanto em uma indústria de profissionais que trabalham com conhecimento e criatividade.

Para os desenvolvedores, segundo comentário deixado por Sannette Coetzze, muitas vezes o gerente é visto como um impedimento e em outros casos o gerente não se envolve com o trabalho das equipes:

Alguns gerentes não querem “sujar as mãos” ou se comprometer com a equipe e com o produto. Um bom gerente tem que liderar e possuir energia e entusiasmo ao conduzir a equipe.

Sobre a relação entre liderança e gerenciamento, Little cita outra impressão da comunidade ágil: a de que líderes são necessários, mas não gerentes. Mas ele reafirma que os gerentes também são importantes, dentro de um novo contexto:

Estamos em meio a uma mudança na cultura de gerenciamento em todo o mundo. Este será um longo diálogo e há muitas dimensões a serem discutidas. Precisamos argumentar sobre como gerenciar melhor.

Esta discussão ainda será longa, como finaliza Little, pois o modo como gerenciamos hoje ainda está enraizado em antigos conceitos que precisam ser revistos – principalmente dentro do contexto ágil e da indústria do conhecimento.

Rotação do papel do ScrumMaster: se puder, evite

Fonte: Rafael Buzon/InfoQ


Algumas equipes ágeis têm tido a iniciativa equivocada, segundo Mike Cohn, de rotacionar o papel do ScrumMaster entre os integrantes da equipe. Em post publicado recentemente em seu blog, Cohn argumenta que está sendo subestimado o papel do ScrumMaster quando se afirma que qualquer um pode exercê-lo e acrescenta:

Não defendo esta abordagem, pois não acho que demonstra o respeito apropriado aos desafios e ao significado do papel de ScrumMaster.

Cohn revela, entretanto, que há situações nas quais se deseja criar oportunidades de aprendizado, e que nesses casos rotacionar o ScrumMaster aumentaria o entendimento na equipe sobre como é estar neste papel.

Outra situação, para Cohn, que permitiria a rotação do ScrumMaster, surge quando se deseja evitar a imagem de um “gerente da equipe”. Com a rotação das responsabilidades, o “poder” fica mais balanceado e a equipe se torna mais autogerenciável.

Cohn não recomenda que o papel do ScrumMaster seja rotacionado sistematicamente, e aponta alguns problemas decorrentes de rotações frequentes:

  • Aqueles que assumiram o papel de ScrumMaster, devido a uma rotação, geralmente têm outras atribuições que terminam ganhando prioridade durante o sprint;
  • É difícil treinar pessoas em número suficiente para fazer bem o papel do ScrumMaster;
  • Algumas pessoas usarão seu tempo como ScrumMaster para forçar mudanças nos processos;
  • Designar alguém como ScrumMaster durante alguns sprints não garante que esta pessoa irá valorizar esse trabalho. Isso pode levar à impressão, da parte de ScrumMasters, de que o Scrum seria um erro.

Rotacionar o papel do ScrumMaster, portanto, não deve ser uma prática permanente. É aceita por Mike Cohn somente por tempo determinado e em situações específicas, que contribuam para o aprendizado da equipe e para a sua capacidade de autogerenciamento.

Quais são suas experiências em rotacionar o papel do ScrumMaster em sua organização?

7 opções para lidar com interrupções em Scrum e outras práticas ágeis

Fonte: Rafael Buzon/InfoQ

Mishkin Berteig, consultor e coach Agile, publicou recentemente no blog Agile Advice uma revisão de um antigo artigo de sua autoria, acrescentando sete opções para lidar com interrupções nas empresas que utilizam práticas ágeis. Aqui resumimos essas alternativas.

1. Seguir rigorosamente o Scrum

As regras do Scrum são claras, defende Berteig:

Se não faz parte do trabalho planejado para o sprint, então não deve ser feito. Do momento em que a equipe se compromete com o trabalho no início do sprint, na reunião de planejamento, até o final do sprint, na reunião de revisão, é necessário que a equipe seja protegida contra interrupções.

Berteig comenta que ao se rejeitar as interrupções, como resultado de seguir fielmente o Scrum, os obstáculos que impedem as equipes são evidenciados dentro da organização. Desse modo é possível identificar as causas-raiz dos problemas e tratá-las de forma apropriada.

2. Reservar um tempo para interrupções

De acordo com Berteig, em determinadas condições do ambiente de trabalho é possível estimar o tempo médio gasto com interrupções no passado e reservá-lo no sprint para tais ocorrências. A alocação deste tempo poderia acontecer de duas maneiras:

Na reserva de tempo para interrupções, diz Berteig, há duas possibilidades para alocação do tempo:

Todos na equipe dispõem de certa quantidade de tempo diária para lidar com interrupções, OU um ou dois membros da equipe ficam dedicados exclusivamente a lidar com as interrupções durante o sprint.

O autor lembra ainda que o tempo planejado para as interrupções nunca deve ser excedido, pois comprometerá as entregas do sprint. Ele recomenda que o tempo economizado seja sempre usado para analisar as causas-raiz dos problemas.

3. Negociar mudanças de forma visível

Outra abordagem é formalizar o processo de interrupções e mudanças, permitindo às partes interessadas (stakeholders) negociar e conhecer os impactos de suas solicitações imediatamente. Para isso, Berteig recomenda o uso de cartões coloridos para representar a solicitação de cada stakeholder, e que sejam diferentes dos cartões planejados para o sprint.

Após avaliação e estimativa da equipe, os envolvidos podem negociar prioridades e determinar qual trabalho poderia ser deixado de lado para a entrada da nova demanda.

Para que esta abordagem seja bem sucedida, Berteig defende que três condições devem ser verdadeiras:

  • Ter um quadro de tarefas visível de forma constante (e não através de ferramentas eletrônicas);
  • Ter uma equipe que seja boa em estimar rapidamente e com bom grau de acurácia;
  • Deixar muito claro, com todos os envolvidos, as mudanças realizadas e seus impactos na iteração atual.

4. Ter uma equipe separada, dedicada a interrupções

Outra abordagem apontada pelo artigo é dedicar uma equipe exclusiva para tratar as interrupções, liberando as demais equipes para a construção dos produtos.

Sobre o perfil desta equipe dedicada a interrupções, diz Berteig:

Quanto mais capacidade técnica tiver esta equipe, e autonomia para que possa realizar mudanças no código, banco de dados etc, mais efetiva será em proteger das interrupções as equipes de produto.

Esta abordagem pode ser especialmente interessante, por tornar mais visíveis os custos associados às interrupções. Funciona, assim, como um indicador da qualidade do código entregue pelas equipes.

Berteig recomenda, ainda dentro desta abordagem, que as equipes não tenham seus integrantes rotacionados, pois isso pode trazer problemas de sinergia entre eles.


5. Realizar iterações extremamente curtas

Realizar iterações extremamente curtas é outra abordagem apontada pelo artigo, que possibilita a realização das interrupções em um tempo médio aceitável, sem contudo comprometer a iteração já planejada e em andamento.

Para tanto, é necessário conhecer historicamente o prazo médio com que as interrupções (novas demandas) precisam ser entregues e realizar iterações menores que este prazo. Berteig cita um exemplo:

Uma equipe na qual trabalhei recebia interrupções que precisavam ser resolvidas dentro de até três dias (interrupções mais urgentes eram raras). Decidiram, então, realizar iterações de dois dias para que na média conseguissem terminar de lidar com uma interrupção em três dias.

A lógica é a seguinte, utilizando o exemplo dado por Berteig: usando iterações de 2 dias a interrupção geralmente ocorrerá entre os dias 1 e 2 da iteração. A equipe, então, ao invés de já iniciar os trabalhos da nova demanda gerada pela interrupção, apenas a prioriza para o próximo ciclo de 2 dias. Dessa forma, a interrupção não atrapalha o ciclo atual e é resolvida dentro de um prazo médio aceitável.


6. Manter o Status Quo

Berteig considera também que as empresas podem optar em manter o status quo e continuar lidando com as interrupções da forma como fazem atualmente. Destaca que em algumas indústrias, a forma atual pode ser estratégica e pode permanecer, mas faz uma ressalva:

Se você escolher manter o status quo é importante que o faça de forma transparente e deixe claro o que está sendo sacrificado. Diga a todos das equipes exatamente porque está optando por essas escolhas e quais os benefícios esperados de se fazer dessa maneira.

7. Estimar com a velocidade de comprometimento

A velocidade de comprometimento (commitment velocity), segundo o autor, é a menor quantidade de pontos entregues em um sprint, medida ao longo do projeto. Utiliza-se essa velocidade como sendo o limite possível para o planejamento dos próximos sprints, permitindo com isso que a equipe se comprometa tanto com as entregas do projeto como com as interrupções.

A equipe pode se sentir tentada a calcular a média das velocidades realizadas e utilizá-la como medida para o planejamento dos sprints, mas Berteig alerta que a média não representa a velocidade de comprometimento e acrescenta:

Com base na lei dos grandes números e no teorema do limite central, usando esta ferramenta da Velocidade de Comprometimento por muitos sprints, sua capacidade de manter compromissos, mesmo com interrupções, se aproximará cada vez mais de 100% de certeza.

Escolhendo a melhor abordagem

Para que a abordagem escolhida seja bem experimentada, Berteig recomenda que seja feita uma decisão consciente e que seja exercitada por tempo suficiente a fim de entender se funciona ou não para você. E acrescenta algumas considerações:

  • Se você está tentando realizar uma melhoria radical em sua organização, eu recomendaria escolher a opção 1 ( Seguir rigorosamente o Scrum) ou a opção ou 7 (Estimar com a velocidade de compromisso). Ambas as opções colocam pressão na equipe e na organização, em busca de melhoria;
  • Se você não tem um forte apoio executivo para o Agile, então as opções 2 (Reservar um tempo para interrupções), 4 (Ter uma equipe separada, dedicada para interrupções) e 5 (Realizar iterações extremamente curtas), serão as melhores;
  • Se você tem um forte apoio executivo, mas não está desesperado em melhorar sua organização, considere a opção 3 (Negociar mudanças de forma visível);
  • E claro, a opção 6 (Manter o Status Quo) é a mais fácil… Mas não recomendo! A agilidade requer mudanças sistemáticas para encorajar a melhoria contínua, e todas as demais opções ajudam nesse aspecto.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Para os gerentes de projetos de TI seguindo a linha tradicional, não resta muito tempo até que ouçam algo como “Lembra-se daquele projeto? Decidimos usar nele método ágeis”, e na semana seguinte chegar à empresa uma consultoria em Agile e começar a explicar Scrum, XP, User Stories, Sprints, TDD e uma série de outras técnicas e conceitos. Enquanto isso, o gerente provavelmente irá começar a revirar a internet tentando entender o que fazer, e pode se surpreender ao descobrir que gerentes de projetos aparentemente não são indispensáveis nessas metodologias.

Tenho presenciado muitos gerentes nesta situação, alguns chegando a temer seriamente os métodos ágeis. Por isso a inspiração de escrever um artigo que apresente o Agile para os gerentes de projetos que estão usando práticas mais tradicionais.

Benefícios das metodologias ágeis

Metodologias ágeis, nunca é demais lembrar, são um conjunto de práticas baseados em princípios e valores descritos no Manifesto Ágil. Em 2001 um grupo de experientes líderes de TI, insatisfeitos com o gerenciamento tradicional de projetos de software, reuniu-se e compartilhou novas maneiras para se fazer bom software. Entre as várias metodologias consideradas ágeis, o Scrum e o Extreme Programming (XP) são as mais utilizadas.

O Agile pode resolver alguns dos principais problemas encontrados por um gerente de projetos e trazer diversas vantagens; por exemplo:

  • Identificar, com facilidade e clareza, as funcionalidades do software sendo construído e o que ainda falta fazer;
  • Mostrar de forma efetiva os resultados e o progresso real do projeto;
  • Entregar versões funcionais do sistema, ao invés de somente anunciar atrasos e problemas;
  • Lançar o software antes da data final e mostrar aos usuários que podem contar com novas funcionalidades poucas semanas após a requisição, ao invés de meses ou até anos depois.

O objetivo das metodologias ágeis, portanto, é simples mas ao mesmo tempo desafiador: satisfazer o cliente por meio de entregas contínuas e antecipadas de software, com valor agregado. Entre os benefícios podemos citar:

  • Disponibilizar uma nova versão do software regularmente, a cada duas ou quatro semanas;
  • Poder lidar com pedidos de mudanças e replanejar o projeto em poucas horas;
  • Descobrir os principais riscos e problemas de integração durante as primeiras semanas do projeto, enquanto ainda há tempo de lidar com eles;
  • Visualizar o progresso e o resultado efetivo do projeto a partir de versões intermediárias do software;
  • Manter um alto comprometimento da equipe de TI durante todo o projeto;
  • Conseguir um maior grau de satisfação e de comprometimento da equipe do projeto em sua execução;
  • Reduzir a necessidade de microgerenciamento das atividades.

Para potencializar esses benefícios, é preciso uma grande mudança na forma de pensar e de agir, por parte de todos os envolvidos no projeto e na organização.

O escopo do projeto vai mudar

Tradicionalmente, para garantir um bom projeto o gerente gasta muito tempo reunindo todos os possíveis requisitos que os usuários possam ter em suas mentes. Com o intuito de evitar surpresas, é feito um grande esforço para se construir o plano perfeito. O trabalho é planejado para que tudo possa ser controlado rigorosamente, sem mudanças.

Mas isso quase sempre é impossível. No entanto, este tipo de pensamento tem se tornado comum em grandes empresas, onde planejar, especialmente em conjunto com outras equipes e áreas, é algo muito difícil.

Em um projeto ágil, por outro lado, podemos:

  • Lançar o software regularmente e em datas marcadas (pelo menos em um ambiente de testes), para que os usuários possam verificar rapidamente o trabalho realizado;
  • Permitir aos usuários finais que solicitem mudanças e novas funcionalidades, desde que deixem as menos importantes para depois;
  • Disponibilizar versões intermediárias com frequência, para que os usuários possam utilizar antecipadamente as primeiras funcionalidades do sistema.

Além disso, surpresas são bem-vindas, pois podem criar ideias e favorecer a inovação.

Em projetos ágeis, para controlar o projeto e comunicar o progresso, são contabilizadas as funcionalidades implementadas e não a porcentagem de realização das tarefas, o que é muito mais fácil de entender. Em um projeto tradicional o gerente de projetos diria algo como, “consumimos 45% do orçamento e estamos duas semanas atrasados”. Em um projeto ágil, poderia dizer: “com 45% do orçamento temos hoje uma aplicação capaz de executar estas 12 funcionalidades das 20 previstas”.


A adoção de uma metodologia ágil é um verdadeiro projeto de mudanças

Os métodos ágeis, entretanto, podem ser difíceis de implementar em grandes empresas. Normalmente a gestão de TI acredita que os métodos ágeis dizem respeito apenas aos desenvolvedores e à equipe técnica. Isto é um grande erro, pois elas também envolvem as equipes de gestão e de negócios.

O uso de práticas ágeis apenas no âmbito dos desenvolvedores não vai necessariamente reduzir os prazos globais dos projetos. Os ganhos de produtividade podem ser desperdiçados por outras equipes em outras funções. Se as atividades de testes de integração, por exemplo, durarem muito tempo, os desenvolvedores terão que fazer vários merges das diferentes versões de testes realizadas.

Em muitos casos, o primeiro projeto na adoção de uma metodologia ágil falha devido à falta de envolvimento do patrocinador, à falta de capacitação e treinamento, ou a uma má atuação de alguns “falsas consultorias” em Agile. (Existem consultores que simplesmente rotulam suas ofertas de serviços com a palavra “ágil” sem ter o conhecimento apropriado.)

Negociação do escopo

A negociação de um contrato em Agile é talvez o ponto mais complexo na adoção de práticas ágeis em uma empresa. Isso porque em Agile as mudanças no escopo são bem vindas e constantes. Mas os gerentes de projetos têm muitas dúvidas e resistência ao trabalhar com um escopo variável, principalmente quando não existe uma relação de confiança com o fornecedor.

Há no entanto novos modelos de contratos que procuram criar uma relação de confiança. Entre os pontos abordados nesses contratos, podem estar a definição de escopo fechado por iteração; medidas precisas para controlar a qualidade das entregas; e a possibilidade de o cliente cancelar o projeto ao final de qualquer iteração, sem multas ou penalidades.

A adoção de uma metodologia ágil é na verdade um “projeto de gestão de mudanças”, que requer um forte comprometimento dos patrocinadores e gestores. Esse processo de mudanças pode ser feito gradualmente, implementando-se primeiro as práticas ágeis para desenvolvimento de software, e depois seguindo com práticas mais avançadas e focadas em planejamento, organização e gestão.

O papel do gerente de projetos

O gerente de projetos ganha novas atribuições em um contexto ágil, pois a filosofia do time e os novos papéis exigem uma nova postura e uma nova forma de lidar com as atividades do dia a dia.

Para ganhar em rapidez, as metodologias ágeis dão grande importância à equipe de projetos e à forma como ela pode colaborar de modo eficiente para a resposta às mudanças. Busca-se desenvolver equipes autônomas, capazes de lidar com todas as questões sob sua alçada. Além disso, as equipes têm a liberdade de tratar diretamente com os usuários e alguns patrocinadores.

Outro papel que cresce e ganha importância, a medida que cresce o Scrum, é o de Product Owner (PO), que é responsável pelo produto sendo construído e pelos benefícios e o valor que serão proporcionados ao negócio e aos usuários finais. O Product Owner pode complementar o trabalho do gerente de projetos focando nas funcionalidades já entregues e analisando os benefícios do lançamento do produto em cada iteração.

Mas com equipes autônomas e a presença do Product Owner, quais seriam as responsabilidades de um gerente de projetos? O gerente de projetos continua responsável por várias áreas da gestão, como integração, gestão do tempo, orçamento, qualidade, recursos humanos, comunicação, risco e contratos. E aparecem outras atividades importantes em um contexto ágil; por exemplo:

  • Integrar o projeto ágil com outros projetos da empresa: Em empresas grandes e complexas como bancos e operadoras de telecomunicações, projetos ágeis terão sempre alguma dependência com projetos ditos mais tradicionais.Se você precisa que uma equipe “não-ágil” crie um novo serviço na web, terá que entregar a especificação do projeto com meses de antecedência. O gerente de projetos ágil precisa buscar, nesse contexto, envolver e “evangelizar” outros gerentes, buscando disseminar a filosofia e o funcionamento das equipes ágeis, além de coordenar atividades entre diversas áreas.
  • Proteger a equipe na empresa: Departamentos externos e outros funcionários certamente demandarão suporte e manutenção de sua equipe em outros projetos. Muitas vezes questões urgentes podem levar dias, e gerar atrasos e quebras no ritmo da equipe. Conseguir “blindar” o time de interferências externas e criar mecanismos para tratar estas questões é outro papel importante do gerente de projetos.
  • Aperfeiçoar o processo e as práticas: Metodologias ágeis estimulam o aperfeiçoamento das práticas, técnicas e ferramentas de forma continuada. O gerente de projetos é convidado a criar iniciativas que aprimorem os processos que vão além da sua equipe, e podem buscar otimizar até práticas e processos mais estratégicos. (Em Scrum, o Scrum Master assume esta última responsabilidade.)

Voltando ao Scrum, um gerente de projetos pode assumir o papel do Scrum Master desde que esteja disposto a trabalhar perto da equipe, e a auxiliá-la a aperfeiçoar processos e práticas e a desenvolver suas habilidades. (Veja definições em português de Product Owner e Scrum Master)

Em grandes projetos, um gerente pode assumir o papel de Scrum Master, mas atuando em nível mais estratégico. Em um projeto simples (por exemplo, com uma equipe interna de quatro a oito pessoas), o gerente pode até assumir o papel do Product Owner também. Mas isso somente se conseguir ao mesmo tempo pensar no projeto e no produto em construção.

Comece com um projeto piloto

Como todo projeto de mudanças, a adoção das metodologias ágeis deve ser planejada e ter patrocinadores importantes dentro da organização. É recomendável que o primeiro passo seja um projeto piloto, que permita aos patrocinadores entender melhor as metodologias envolvidas, e identificar possíveis benefícios e dificuldades na sua implementação em larga escala na empresa.

A seguir é apresentada uma lista de ações que podem ajudar o gerente de projetos a organizar um primeiro projeto piloto com metodologias ágeis. São incluídas também algumas dicas gerais que podem ajudar os projetos ágeis a serem bem-sucedidos.

  • Defina o projeto piloto com o objetivo de testar o uso de métodos ágeis. Deixe claro que um dos objetivos é experimentar uma nova metodologia. Custos, cronogramas e riscos devem ser avaliados neste contexto.
  • Explicite os motivos para utilizar o Agile. Evite metodologias ágeis, se não houver um real motivo no momento. As dificuldades em adotá-las podem desencorajar a equipe e a gestão. Documente os motivos e analise, junto aos usuários finais e patrocinadores, quais benefícios são possíveis com a entrega do projeto, meses antes.
  • Garanta o comprometimento dos patrocinadores. Envolva-os em revisões regulares do projeto e em reuniões de duas a quatro horas por semana. Com esse grau de envolvimento, os patrocinadores poderão ajudar a obter apoio de outros departamentos mais rapidamente, entre outras vantagens. Também é importante que os patrocinadores avaliem junto com você os passos seguintes ao projeto piloto.
  • Faça treinamentos em Agile, com empresas com experiência comprovada. O Agile parece simples, mas leva algum tempo para dominar práticas reais. Uma opção complementar é o Coaching: existem empresas com profissionais experientes que podem ajudar na condução de projetos seguindo práticas ágeis. Verifique a experiência destas empresas e considere adquirir seus serviços para um primeiro projeto piloto.
  • Avalie a experiência em métodos ágeis reais dos fornecedores que contratar. Algumas empresas de serviços de TI utilizam o termo Agile com propósitos comerciais, mas suas equipes não possuem conhecimento ou capacidade para trabalhar efetivamente com as práticas ágeis. Para reduzir o risco de cair nessas armadilhas, é importante entender os principais conceitos e acompanhar as decisões sobre a metodologia ágil a ser utilizada, além de ter uma noção geral das práticas de planejamento, desenvolvimento e testes mais adequados à realidade da empresa.
  • Construa uma equipe com pessoas orientadas a resultados e dispostas a tentar coisas novas.

Conclusões

As metodologias ágeis continuam ganhando popularidade e aceitação. A pergunta não é mais se funcionam ou não, e sim se podem ajudar sua empresa a realizar mais e melhores projetos de TI. A melhor maneira de testar estas metodologias é realizando um projeto piloto para identificar os potencias benefícios e as prováveis dificuldades na sua implementação.

A adoção do Agile é um verdadeiro projeto de mudanças para o departamento de TI e para as áreas de negócio. Nesse processo, o gerente de projetos pode cumprir um papel fundamental, assumindo a liderança das mudanças e ajudando as equipes técnicas a entregar software de maior qualidade em menor tempo, e com funcionalidades de maior valor para a empresa.

Fonte: Ignacio Lizarralde/InfoQ

SCRUM, KANBAN e XP – Indo além de Projetos de TI

Três Metodologias Ágeis e como usá-las em Projetos que não sejam de TI

Muitos gerentes de projeto que trabalham com desenvolvimento de software estão bem familiarizados com as entregas rápidas e iterações constantes do desenvolvimento ágil. Mas agora, ágil está ganhando terreno em outras indústrias. Aqui estão três populares metodologias ágeis, e como elas podem trabalhar em projetos que não sejam de desenvolvimento de software.

1. Scrum

Scrum tem encontrado seu caminho dentro de uma variedade de organizações que trabalham com projetos, incluindo escritórios de advocacia e universidades.

Veja como ele funciona, de acordo com a Scrum Alliance:

  • Uma lista de desejos priorizados chamada product backlog é criada.
  • Durante a fase de planejamento, a equipe seleciona um pequeno pedaço do topo da lista de desejos, e chama de sprint backlog, e decide como implementar essas tarefas.
  • A equipe recebe um certo período de tempo, chamado de sprint, para completar o trabalho especificado no sprint backlog e avalia a cada dia o seu progresso.
  • No final do sprint, geralmente de duas a quatro semanas, o trabalho deve estar pronto para entregar a um cliente.
  • O sprint termina com uma revisão de sprint e uma retrospectiva.
  • O próximo sprint, então, começa.

Para Scrum atingir outras indústrias, você teria que: “quebrar os requisitos para um discreto conjunto de itens que poderiam ser trabalhados em um conjunto de iterações”, diz Bob Tarne, PMP, engagement manager para IBM Software Group em Lenexa , Kansas, EUA.

Ele usou o exemplo de trabalhar com um editor e ilustrador em um projeto de publicação.”Nós quebramos o livro em capítulos e começamos a primeira iteração com o capítulo um”, diz ele.”Nós escrevemos, ilustramos e realizamos a edição dentro de um [Sprint]. Nós revisamos no final do [Sprint] e, em seguida, planejamos a iteração dois com o segundo capítulo. ”

2. Kanban

Com raízes na indústria automobilística, Kanban é adaptável a projetos que não sejam de desenvolvimento de software, especialmente de recursos humanos e legal, porque os seus princípios não estão associadas a qualquer prática específica, afirma Abdiel Ledesma, PMP, proprietário do Grupo Equation no Panamá e presidente da PMI Capítulo Panamá.Esses princípios são:

  • Visualize o fluxo de trabalho: Isto pode ser feito usando um cartão de parede, com as colunas representando os estados ou etapas do fluxo de trabalho e as cartas que representam os itens de trabalho
  • Limite o andamento do projeto: “Se a sua equipe estava trabalhando em cinco itens de uma vez e não a fez progressos, reduza esse número para dois ou três”, diz Sliger. “Selecione o mais importante, os itens de trabalho mais valiosos. Trabalhe sempre na próxima coisa mais importante.”
  • Gerencie o fluxo: O fluxo de trabalho através de cada estado ou etapa deve ser ativamente monitorado, medido e relatado, a fim de avaliar os efeitos positivos ou negativos de mudanças incrementais e evolutiva.
  • Tornar explícito as políticas dos processos: Garantir uma compreensão explícita do mecanismo de um processo para alcançar uma discussão racional e objetiva dos problemas e facilitar o consenso em torno de sugestões de melhoria.
  • Melhore de forma colaborativa: Kanban para realmente funcionar, as equipes devem colaborar. “Kanban é bom como qualquer outro método ágil, em que a equipe tem que se reunir para planejar, diariamente preferencialmente em pé, e pode optar por fazer retrospectivas para inspecionar e adaptar o seu processo”, diz a Sra. Sliger. “Todos esses itens, e mais envolver a colaboração e melhoria contínua.”

Para se adaptar a um projeto de recursos humanos, por exemplo, visualizar o processo de contratação através de uma placa de Kanban. Categorias na placa seriam incluir uma coluna para os candidatos que enviaram currículos, uma coluna para os candidatos que estão qualificados para a posição e uma coluna para os candidatos que se mudaram após o processo de entrevista por telefone. Apoio que fluxo de trabalho com um documento que define quem é responsável por esses diferentes papéis e processo de kickoff o com uma pequena reunião com a participação de todas as partes interessadas.

O nome por si só pode desligar-se muitas equipes de projetos trabalhando em projetos fora desenvolvimento de software e eles podem estar certos.

3. Extreme Programming

XP se concentra em desenvolvimento orientado a testes, lançamentos de pequenas “releases”, e uma estrutura de equipe que inclui o cliente, enquanto que as abordagens tradicionais de gerenciamento de projeto, geralmente adotam, diz Mr. Tarne.

Muitas das regras para esta metodologia ágil são projetadas especificamente para tratar de codificação, projetar e testar. Ter planejamento, por exemplo: Um projeto tradicional faz planejamento na frente; XP diz para planejar o lançamento a um nível elevado, mas o plano de cada iteração em seu início (ou a cada duas semanas).

Mas XP oferece algumas lições aprendidas para projetos além de TI.

“O mais poderoso das práticas ágeis é o reconhecimento das pessoas como o ativo mais valioso de projeto e a liderança como catalisador”, disse Ledesma diz.

“XP tem cinco valores que podem ser enfatizado em muitos tipos de projetos (além desenvolvimento de software) : Simplicidade, comunicação, feedback, respeito e coragem”. Esses valores podem, e devem ser aplicados a todos os projetos em todos os setores, o Sr. Tarne diz. “Comunicação é um grande exemplo”, diz ele. “Eu vi uma série de projetos que descarrilou por causa das comunicações pobres”.

Traduzido de http://www.pmi.org/passport/dec11/agile-non-it-projects.htm

Fonte: PMI.org

Scrum o que realmente é

O Scrum é um processo de gestão e desenvolvimento ágil que se desenvolveu como uma abordagem iterativa e incremental para otimizar a previsibilidade e controle de riscos, fortemente sustentado por três pilares:

  • Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
  • Inspeção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
  • Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras. Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

  • o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
  • o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
  • o Time: são os desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

  • Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
  • Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
  • Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
  • Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis a partir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
  • Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
  • Daily Scrum: o Time se encontra diariamente para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
    • O que ele realizou desde a última reunião;
    • O que ele vai fazer antes da próxima reunião;
    • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint. Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

  • Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
  • Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente integrável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Fonte: Elton Kuzniewski

Programação em Pares: Lado a lado ou frente a frente?

A programação em pares é uma técnica de desenvolvimento ágil em que dois programadores trabalham juntos em apenas uma estação de trabalho. Seus benefícios são bem conhecidos e a técnica é amplamente praticada. Entretanto, qual é o melhor posicionamento das pessoas quando se trabalha em pares?

Uma maneira comum é sentar-se lado a lado, mas este modelo traz alguns inconvenientes, como sugere Josh Susser:

Embora sentar-se lado a lado seja um bom modelo em vários aspectos, o mesmo se mostra pouco ergonômico. Primeiro, os programadores acabam ficando de lado para o monitor, o que requer inclinação e torção para se sentarem em uma posição em que ambos possam tanto ver quanto digitar. Também é difícil olhar para o parceiro sem contorcer o pescoço.

Uma maneira alternativa de se programar em pares é sentar-se frente a frente. A organização alternativa se parece com o desenho abaixo, onde as áreas destacadas representam os pares.

Diz Susser sobre esse layout:

É muito mais confortável, pois ambos temos uma visão melhor da tela e se pode ver um ao outro com facilidade. Ficamos sentados próximos o suficiente para que seja possível se comunicar, sem que seja necessário levantar a voz. Facilitou muito nossa interação.

Brian e Corey experimentaram este modelo e o acharam bastante efetivo. De acordo com Brian, ele acabou preferindo esta forma de parear ao modelo convencional:

Acabei preferindo este estilo ao pareamento lado a lado, de frente a uma única tela. E ainda prefiro este modelo, no lugar de sentar-se em frente a dois monitores com dois teclados. O trabalho tem um fluxo mais livre e é mais fácil perceber a linguagem corporal da outra pessoa. Também fica mais natural parar de codificar, levantar a cabeça e conversar. A troca entre os pares também melhorou; houve poucas situações em que se tentou mexer no cursor ao mesmo tempo.

Tim Ottinger tentou este arranjo mas não ficou tão impressionado. De acordo com Tim,

Não foi tão ruim assim, mas nos sentimos menos conectados um ao outro neste modelo e era necessário apontar com o mouse ao invés das mãos. Funciona, mas parece mais com a experiência de se programar em pares remotamente.

Será que este arranjo tem desvantagens?

Josh Susser diz que é um pouco difícil perceber sinais sutis, como quando a outra pessoa está pronta para assumir o controle do teclado ou pequenos movimentos das mãos, que são mais visíveis quando se está sentado lado a lado. O layout também aumenta o custo, pois requer mais equipamentos e espaço físico.

Postado por Vikas Hazrati, traduzido por Rafael Buzon

Fonte: InfoQ

Kent Beck: “Pare de pensar durante a refatoração”

Em primeira análise, a refatoração exige uma boa dose de pensamento, mas a realidade é que pensar demais também pode ser prejudicial. Esta é opinião de Kent Beck e J.B. Rainsberger.

Kent Beck sugere que um dos desafios da refatoração é o sequenciamento, ou seja, como dividir o trabalho em passos seguros e ordenar esses passos. Avançar rápido demais nas refatorações pode resultar em código instável. Por outro lado, pensar demais pode tornar o processo mais lento que o aceitável.

Meus colegas de programação são testemunhas do meu hábito irritante de dizer “pare de pensar” durante a refatoração. Eu sempre soube que isso não é exatamente o que eu quero dizer, porque afinal não se pode parar de pensar literalmente. Mas até agora eu não tinha uma explicação melhor.

Kent explica o conceito de “refatoração horizontal e vertical”. A refatoração vertical envolve ações como mover o método ou atributo para cima ou para baixo numa pilha de invocações; na refatoração horizontal se faz algo similar entre itens no mesmo nível. Para Beck, ao refatorar não se deve misturar os dois tipos de refatoração.

Quando se tem várias invocações para refatorar, ou várias implementações, é o momento de ter cuidado para evitar a alternância entre a refatoração vertical e a horizontal. Deve-se manter os dois tipos separados e ficar atento à profundidade das refatorações verticais.

Mas fazer isso não é fácil. Algo que pode se particularmente útil, diz Beck, são os cartões indexados.

Manter um cartão perto do meu computador me ajuda a manter o foco. Quando vejo uma oportunidade de refatoração vertical no meio de uma fase horizontal (ou vice-versa), anoto a ideia e volto para o que estava fazendo. Isso me permite terminar uma tarefa antes de partir para a próxima, sem perder nenhuma boa ideia. É um processo que lembra a meditação, em que você se concentra na respiração e não se deixa levar pela espiral dos próprios pensamentos.

Nos comentários, J. B. Rainsberger concorda e acrescenta:

Não importa no que você está trabalhando: se quer ter foco, tenha uma caneta e um cartão por perto. Quando surgir algo na sua cabeça que não for necessário fazer imediatamente, anote a ideia em cinco palavras ou menos e volte para o que estava fazendo. Funciona muito bem.

Em princípio, isto é bem semelhante à abordagem de “mudanças estreitas” (narrow changes) sugerida por Joshua Kerievsky. Nela, o foco é restrito a um pequeno número de pontos de mudança de cada vez; em seguida usa-se essa informação para selecionar a próxima mudança (estreita ou paralela) para a refatoração.

Portanto, refatorar envolve (claro) o pensamento, mas manter o foco é essencial para refatorações saudáveis. Nas palavras de Beck:

Na metade do caminho, meu colega começou a ter boas ideias de como mover parte da funcionalidade. Neste ponto disse a ele para parar de pensar. Na verdade, só queria que focasse no que estávamos fazendo. Não faz sentido começar a fixar uma estaca (no alpinismo) e parar na metade para verificar onde colocar a próxima estaca.

Fonte: Postado por Vikas Hazrati , traduzido por Giovanni Abner/InfoQ

Desenvolvimento de software não é construção civil

Ao longo dos últimos anos, uma das áreas que mais cresceu foi justamente a de tecnologia voltada para o desenvolvimento de software e, com esse grande impulso, vieram junto enormes problemas que vão desde qualidade, prazos e, principalmente, expectativas de todos os envolvidos no processo, levando grande parte dos projetos a algum tipo de fracasso, conforme podemos observar nos principais estudos relacionados, como o “Chaos report”, promovido pelo The Standish Group.

A arte de desenvolver software é baseada em um modelo completamente criativo e dinâmico, sujeito a mudanças em cada passo, sejam oriundas de uma amplificação no entendimento do valor de negócio por parte do cliente ou em atividades emergentes que surgem logo nos primeiros minutos de codificação em qualquer projeto de desenvolvimento de software.

As disciplinas tradicionais de gestão baseiam-se em muitas ideias aplicadas na própria construção civil e tentam, usando esses princípios, determinar os mesmos fundamentos para projetos de desenvolvimento de software desconsiderando que são modelos completamente diferentes e conduzidos por pessoas criativas. Eu costumo dizer que, ao projetar um prédio nós costumamos ver a evolução da construção, desde a fundação e paredes que vão aparecendo aos nossos olhos. Rapidamente você consegue pegar e medir quanto é necessário de investimento e esforço para atingir o objetivo. Já no software a realidade é completamente diferente, pois é emergente e adaptável em cada passo dado.

É hora de mudar e adotar atitudes mais ágeis que provoquem a colaboração e comprometimento entre todos os envolvidos no ciclo produtivo do software. Estamos falando de pessoas altamente criativas e não de máquinas ou “recursos”.

Em meados de 2001 os principais pensadores da época deram um grande passo reunindo-se para formação do “Manifesto para Desenvolvimento Ágil de Software” que representou um grande marco de mudança contra os modelos tradicionais de desenvolvimento de software com 4 pilares importantes:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

A base principal disso tudo são pessoas felizes colaborando com o processo produtivo que requer adaptação frequente e muita atenção para atender a expectativa do cliente dentro dos objetivos do projeto. No modelo ágil, direcionamos todas as energias em criar um software funcionando orientado aos desejos do cliente que, sabemos, nunca são iguais aos pensamentos originais. Eles emergem e amadurecem junto com as entregas frequentes de software que são apresentadas em cada final de Sprint.

Ao questionar diversos desenvolvedores sobre documentação de software durante a manutenção, nenhum deles confirmou que abre qualquer documentação e sim vai direto ao código fonte resolver o problema. Imagina agora um cenário onde precisa fazer uma mudança, seja qualquer for o tamanho, como terá certeza que não gerou nenhum tipo de impacto no projeto? Não encontrará nenhum documento word que lhe dará essa garantia no código.

Para isso nós usamos outras abordagens no desenvolvimento ágil como TDD (Test Driven Development), orientando o desenvolvimento a testes unitários, gerando uma documentação de negócio no formato de testes que são executados automaticamente, garantindo que aquele código coberto pelos testes não sofreu impacto com a mudança de negócio. Na prática nós desenvolvemos primeiro os testes e depois as regras de negócios, já validando as mesmas com os testes, diminuindo inclusive o tempo de desenvolvimento.

Para alinhar a visão do cliente com as implementações realizadas, temos uma abordagem em desenvolvimento ágil conhecida como BDD (Behavior Driven Development) que permite orientar o desenvolvimento baseando-se no comportamento de negócio desejado escrito em histórias pelo cliente, fortalecendo mais ainda um dos princípios em desenvolvimento ágil que é o valor de negócio.

Para integrar o código fonte desenvolvido usamos a abordagem de CI (Continuous integration), tendo um mecanismo automático para geração de versão e entrega do software funcionando, permitindo uma visibilidade do produto que está sendo entregue e indo além, usando os testes unitários produzidos e outras abordagens para garantir a integridade do código fonte e sua fidelidade aos valores de negócio garantidos dentro dos testes e outros padrões de projeto, como arquitetura em camadas favorecendo a reutilização de software.

A informação mais importante que devemos passar ao nosso cliente é que estamos aptos a fazer mudanças no software e adaptar ao final de cada ciclo para juntos atingirmos os valores de negócio do projeto. Ter o cliente próximo esclarecendo as dúvidas faz a diferença e reduz todo o ruído de diferenças de entendimento, permitindo esclarecer o mais breve possível sempre que aparecer qualquer impedimento ou mudança de rumo.

As pessoas tratadas como pessoas e incentivadas a colaborar produzem cerca de 10 vezes mais, pois são desafiadas a dar o melhor de si e valorizadas pelos resultados proporcionados à equipe de uma maneira rápida, pois com ciclos curtos de projetos conseguirmos alinhar rapidamente qual o resultado de cada equipe de projeto. É muito importante que todos se sintam importantes no processo. Por isso incentivar a participação e compartilhamento de informações resulta em comprometimento.

O desenvolvimento de software como um trabalho criativo e intelectual requer uma atenção dobrada na equipe, motivando e alinhando expectativas, além de iniciativas que valorizem cada entrega de projeto com sucesso, mesmo que seja tirando uma foto da equipe e uma Coca-Cola gelada para cada. Na maioria das vezes a intensão vale mais que a força empregada e, ter um ambiente de trabalho feliz é o maior impulsionador de qualquer projeto.

Compartilhe, escute e provoque criando desafios animadores nas pessoas para que juntas formem uma grande força em prol de uma causa e não de uma regra. Conquiste liderando e multiplique a visão por todos do projeto removendo impedimentos e burocracia que não contribuem em nada com o resultado.

Para ter a melhor estratégia de desenvolvimento em um projeto de software inicie pela formação da equipe e crie mecanismos de qualificação e demais incentivos para manter um grupo forte e orientado a resultados. Acabo por acompanhar muita gente preocupada com quanto tempo uma pessoa está parada na frente do computador e não com o resultado que essa pessoa proporciona ao projeto.

Até hoje venho observando em projetos de “software civis tradicionais” gerentes e analistas estimando atividades para outras pessoas assumirem o compromisso de programar. É logico que sabemos de antemão que os desenvolveres vão concordar e que você já vai dar o prazo sabendo que não será entregue, criando o que eu batizei de mundo “Alice do Software”, onde todos sabem que não vai dar certo, mas continuam vivendo até não aguentarem viver mais dentro do caos e darem o grito de mudança.

De uma vez por todas vamos entender que resultado em um projeto de software se dá pela energia criativa para construir uma solução simples e rápida e não pela quantidade de força empregada ao longo do tempo. Para ter comprometimento é fundamental compartilhar com todos do projeto as informações e objetivos e abrir espaço para escutar e colaborar.

O dia que descobrirem, finalmente, que desenvolvimento de software é empírico, mutável e não pode ser encarado como um projeto de uma obra civil, teremos atitudes diferentes com pessoas felizes desenvolvendo com qualidade desde o início e entregas rápidas alinhando a expectativa de negócio.

Para saber mais:

Fonte: Ramon Durães/IMasters