O Google PageRank vinha sendo atualizado há alguns dias e finalmente dia 30/12 a atualização foi finalizada. O blog ADSystems agora é PageRank 2, graças a todos vocês que vem acompanhando nossos posts. Muito obrigado.

E o seu blog como ficou com a nova atualização do PageRank? Você ainda não sabe, então confira aqui.

Em Outubro de 2008, no congresso Global do PMI em Denver, o PMI (Project Management Institute) anunciou através do seu VCP (Virtual Communities Project), a intenção de lançar uma comunidade Agile. Este é o resultado do trabalho de um grupo de integrantes do PMI, interessados nas práticas ágeis, liderados por Jesse Fewell.

Segue o comunicado publicado no blog do Jesse Fewell:

PMI Agile is Official !

October 27th, 2008
To all PMI Agilists, it is official !

At last week’s PMI Global Congress in Denver, PMI’s Virtual Communities Project (VCP) announced their intent to launch an Agile community as the next new specific interest component. This is an exciting culmination of all our collected efforts. For over a year now, all of you have been expressing your enthusiasm to VCP and collaborating with local chapters on Agile practices. This combination of bottom-up and top-down engagement has gotten the attention of PMI leaders worldwide.

What exactly is this community going to be
Under the new component governance framework, VCP has defined two different tiers of specific interest communities: an entry-level “forum”, and a full-service “community of practice”. VCP is targeting Q2 of 2009 as the launch date for an Agile “forum” community. Once we have achieved that basic level of service to our members, we can then grow into the next tier (sounds rather close to iterative and incremental, wouldn’t you say?). For a more explanation of the VCP project, you can check out the latest issue of PMI Today here: http://www.pmitoday-digital.com/pmitoday/200810/ (note, you must first login to pmi.org before clicking the link)

What happens next?
Right now, our community steering committee is talking to VCP about what should go into a 2009 business plan. Once that plan begins to take shape, we’ll have a rather large backlog of requirements that need to be accomplished. So what we need now are volunteers to help build the community, and publicize its formation. Our most immediate need is to people to the SQE Agile Dev Practices conference in Orlando next month: http://www.sqe.com/go?ADP08APMI. PMI Agile has a booth there, and we need competent (that would be you) PMI members to volunteer an hour of their time to help spread the word. If you’re interested in helping in Orlando, or in any other facet, contact me directly at jesse.fewell@excella.com

Who were the real players in making this happen?
Finally, we have to do some recognition of those who have put us in this position:

Mike Griffiths was the first to issue this challenge to us, and paved the way with his Agile lectures at SeminarsWorld.
Dave Prior, Bob Tarne, and the IT&Telecom SIG have been collaborating with Jim Cundiff and the Scrum Alliance to raise Agile awareness within PMI.
Michele Sliger and Stacia Broderick who, after co-writing a mapping of Agile processes to the PMBOK, then co-wrote a draft community plan that we submitted to VCP.
Michele Sliger, Karen R.J. White, James Goebel, Bijan Nikravan, Douglas Melanson, and Peter Bennison who all spoke on Agile topics at last week’s Congress, providing ample validation that VCP’s support is well-founded.
All of you, too numerous to mention by name, who emailed, blogged, petitioned, and preached that Agile can make a difference to the PMI community.

Let’s keep the ball rolling!

O vídeo da entrevista com Jesse Fewell no PMI 2008 North American Global Congress, sobre a oficialização da comunidade:

Fonte: Jesse Fewell’s Blog

Thomas Wailgum – CIO (EUA)
Publicada em 07 de dezembro de 2007 às 11h57

Estudos mostram que as metodologias de desenvolvimento ágil geram resultados melhores. Então porque tão poucos CIOs já a adotaram?

A Farm Credit Services of America não parece ser uma organização do tipo que fomenta controvérsias. Esta cooperativa concede empréstimos a mais de 66.000 fazendeiros e pecuaristas da região centro-oeste dos Estados Unidos para a compra de bois, porcos, tratores, enxadas e outras coisas do gênero. Sua principal razão de existir — fornecer 11 bilhões de dólares em financiamento de capital operacional e imobiliário a quem alimenta a América — é tão acolhedora quanto as imagens de plantações de milho, pastagens verdejantes e fazendeiros rijos e determinados que adornam seu material de marketing.

A cooperativa está sediada em Omaha, Nebraska, região conhecida mais pelos filés do que pelo laboratório avançado de uma das metodologias de desenvolvimento mais comentadas em TI: a programação ágil. Mas agilidade foi exatamente o que a Farm Credit Services abraçou, e com força total.

A vantagem do ágil
O termo “programação ágil” significa coisas diferente para cada pessoa, mas todas as metodologias de desenvolvimento ágil têm os seguintes princípios básicos: os envolvidos da área de negócio são alocados em pequenas equipes autônomas de desenvolvimento; as equipes apóiam-se menos em requisitos e documentação e mais em conversas frente a frente; estas conversas resultam em um diálogo contínuo para design, teste e redesenho de software. O redesenho constante, dizem seus defensores, produz ferramentas de negócio mais oportunas e úteis. ( leia mais sobre o assunto em “O ABC da programação ágil”)

O surgimento do método de desenvolvimento ágil é uma resposta direta ao doloroso histórico de fracassos de projetos de software, custos superiores ao previsto e insatisfação do negócio com o modelo tradicional — a metodologia em cascata pela qual o desenvolvimento se desdobra lentamente em uma série de etapas, abrangendo análise de requisitos, design, implementação, teste, integração e manutenção. No entanto, apenas 17% das empresas norte-americanas e européias utilizam processos de desenvolvimento ágil, de acordo com a pesquisa “Enterprise Agile Adoption in 2006”, realizada pela Forrester Research.

Mas a Farm Credit Services recebeu bem a programação ágil. “Tínhamos os requisitos, criávamos as aplicações, mas ninguém ficava satisfeito no final”, diz Dave Martin, CIO da cooperativa. Um projeto em particular, a migração de um sistema de processamento de aplicações de clientes baseado em mainframe para uma versão Web chamada PinPoint, tinha mais de 200 páginas de requisitos e foi concluída em 2004, depois de transcorridos quase três anos. Neste ínterim, os requisitos e as necessidades de negócio mudaram e a maioria dos membros da equipe de negócio original já não estava mais lá. O sistema resultante, repleto de bugs, foi deixado de lado pouco depois de sua estréia questionável.

Isso nada tem de incomum. Segundo pesquisa sobre a situação do desenvolvimento ágil (“State of Agile Development”) realizada em 2006 pela Agile Alliance e pela Version¬One, apenas 29% dos projetos tradicionais foram ”razoavelmente bem sucedidos” ou “muito bem sucedidos”. Em comparação, 81% dos projetos ágeis alcançaram igual nível de sucesso.

O Standish Group, que compila o famoso relatório Chaos sobre fracassos de projetos de software, reportou na pesquisa de 2006 que somente 16% dos projetos feitos no modelo tradicional tiveram êxito, contra 41% dos projetos ágeis. Jim Johnson, chairman do Standish Group, estuda fracassos de projetos há anos e não entende por que as empresas ainda resistem ao desenvolvimento ágil. “Dizer que empresas ou CIOs estão relutantes em adotar o método ágil é o mesmo que dizer que eles não tomariam uma aspirina para dor de cabeça”, compara. “Além de não tomarem a aspirina, eles estão batendo a cabeça contra a parede e se perguntando por que dói.”

A adoção do ágil
Há dois anos, Martin, da Farm Credit Services, decidiu “dar uma sacudida”. Depois de receber uma leve cutucada de Lou Thomas e Beth Schmidt, diretores de desenvolvimento de aplicações, a equipe adotou o Scrum, que suporta repetições de instruções de duas semanas, reuniões diárias e análises e testes freqüentes. “Nossa premissa é ter produtos potencialmente prontos para liberação a cada duas semanas”, explica Thomas.

Na Farm Credit existem seis equipes de desenvolvimento compostas de um analista de negócio, um líder de projeto, um desenvolvedor-chefe, dois ou três desenvolvedores, um engenheiro de banco de dado, um a três “donos” do negócio e um engenheiro de QA. Em vez de requisitos, as equipes de desenvolvimento escrevem “histórias de usuários” à medida que o projeto avança, detalhando melhorias de funcionalidade e tecnologia, sucessos e desafios. “As histórias de usuários são o principal mecanismo para transmitir as necessidades do negócio”, diz Martin. Antes, os projetos apresentavam a média de 100 defeitos por lançamento. A média, agora, fica entre zero e dois. “Lançamos cinco produtos-chave com resultados fenomenais”, revela Martin. “Em todos os casos, os donos do negócio ficaram extasiados com o resultado final.”

Ágil em qualquer lugar? Nem tanto.
CIOs de empresas de todos os portes dizem que abandonaram totalmente ou estão descontinuando aos poucos as metodologias tradicionais de desenvolvimento. “Não sou do tipo que prometo tudo em 18 meses”, afirma Raymond Dury, CIO da Fifth Third Bancorp que adotou um método ágil chamado Extreme Programming.

Mas os processos cascata, na verdade, não ficaram para trás há tempos. Além do já mencionado estudo da Forrester (somente 17% usavam o ágil em 2006), uma pesquisa realizada em março de 2006 com leitores da revista Software Development e do Dr. Dobb’s Journal descobriu que 60% não estavam utilizando nenhuma metodologia ágil em suas organizações.

Não por coincidência, os CIOs estão buscando ajuda para gerenciamento de projeto ativamente. De acordo com a última pesquisa da CIO norte-americana, quase 75% dos leitores estão “extremamente interessados” ou “muito interessados” em descobrir como podem melhorar a disciplina de gerenciamento de projeto. Tudo isso leva a uma pergunta óbvia: se o desenvolvimento ágil é tão bom, por que não foi adotado universalmente?

O problema do modelo ágil
O ritual do desenvolvimento de software está profundamente impregnado em TI. Nos processos tradicionais, o negócio atira os requisitos para os desenvolvedores por cima do muro, os desenvolvedores se escondem e começam a codificar como lhes convém. Um prazo de 18 meses pode parecer décadas. Tardes perdidas são lugar comum. Quem liga para o que os “lusers” (termo pejorativo com o qual os codificadores se referem aos “usuários”) querem realmente?

“Muita gente na arena de TI achou que ágil era apenas a ‘onda’ do mês”, lembra Martin. “Alguns simplesmente disseram: não vou fazer isso.” (Estes programadores, segundo Martin, levaram uma rasteira do desenvolvimento ágil). Arquitetos corporativos, gerentes de projeto e profissionais de garantia de qualidade também fazem oposição ao métodos ágil. A preocupação dos arquitetos corporativos é que não haja design inicial suficiente e que a conseqüência disso seja código espaguete. Equipes de desenvolvimento ágil são auto-gerenciáveis e a função de líder de projeto muda drasticamente — das ordens à facilitação. E, visto que o teste de QA acontece ao longo de todo o processo, e não só no fim, o pessoal de teste costuma oferecer resistência.

Conceitos errôneos sobre o desenvolvimento ágil ainda existem nas organizações de TI. Eugene Nizker, ex-CIO de serviços financeiros e atualmente consultor, cita os mais deploráveis: as equipes ágeis não planejam; pulam a fase de design; não testam; ágil significa inexistência de documentação.

Além disso, os executivos podem se sentir distantes dos “scrums” e “sprints” diários da vida ágil, o que gera insegurança nos níveis mais altos. Tudo isso contribui para atrapalhar a aceitação do ágil, afirma John Scumniotales, um dos criadores do Scrum. “É fácil falar sobre o valor de criar software desta maneira, mas, se estou apostando minha empresa neste projeto, a gerência-sênior precisa ter alguns controles e visibilidade do processo”, observa. Scumniotales cita a necessidade de contar com uma ferramenta ágil específica que funcione como um gráfico de Gantt, ilustrando visualmente o progresso do projeto. “É onde precisamos chegar.”

Mas, dadas a magnitude dos fracassos das metodologias em cascata, os CIOs devem a si mesmos e às organizações tornarem-se ágeis. “O mundo não pára e espera 18 meses”, afirma Dury, da Fifth Third Bancorp.

Estudo de caso: chegada rápida no mercado
Dury não abandonou os processos tradicionais de desenvolvimento em sua empresa, que possui quase 100 bilhões de dólares em ativos. Alguns projetos de desenvolvimento, como os que afetam a infra-estrutura básica ou os projetos de SOA intensivos, simplesmente “não conseguem lidar com a forte mudança” que acompanha as metodologias ágeis. Mas ele está entusiasmado com a adoção de Extreme Programming.

O chefe da linha de produtos de varejo do banco conversou com o CIO sobre um novo produto que queria vender, uma ferramenta de investimento (batizada posteriormente de Stock Power CD) que oferecia aos clientes potenciais ganhos baseados no mercado de ações para seus certificados de depósito. Na realidade, o banco estava lutando para se recuperar. “Provavelmente estávamos para trás em relação ao mercado para este tipo de produto”, reconhece Dury, “e queríamos atuar no mercado”. Portanto, velocidade era fundamental.

Utilizando táticas baseadas em Extreme Programming, sua equipe debateu soluções que suprissem as necessidades do negócio rapidamente e fossem tecnicamente viáveis. Outras conversas ocorreram com o banco de varejo (muito tempo frente a frente, pouca documentação inicial). Duas equipes de desenvolvimento, trabalhando alinhadas entre si e com os departamentos de consumo e linha de varejo, foram formadas no âmbito de TI: a equipe de consultoria em investimento e a equipe de desenvolvimento do CD. As equipes trabalharam estreitamente ligadas às agências (que venderiam o Stock Power CD) e aos conselheiros de investimentos para satisfazer exigências legais e financeiras.

O Extreme Programming — reuniões diárias e input contínuo do negócio, bem como testes periódicos — “criou a urgência de fornecer este serviço para os clientes o mais rápido possível”, diz Dury. Apenas quatro semanas depois da primeira conversa, várias agências do Fifth Third começaram a oferecer o produto Stock Power CD. “Normalmente, a introdução de um novo produto de depósito levaria aproximadamente de 90 a 120 dias”, observa Dury, acrescentando que o produto gerou “depósitos adicionais significativos”.

Dury não podia imaginar nenhuma outra maneira de realizar este projeto. Além de acelerar o time to market, possibilitou “uma relação de trabalho mais estreita com o lado do negócio” e aumentou a confiança dos clientes internos “na capacidade da TI de estabelecer e cumprir expectativas”.

Maior alinhamento
Como as histórias de Martin e Dury demonstram, os métodos de programação ágil demandam diálogo contínuo entre o negócio e TI. O entrelaçamento dos membros das equipes de negócio e TI promove uma ligação que costuma estar ausente no desenvolvimento tradicional de software. “Eles estão junto com você”, diz Ajay Waghray, CIO da Verizon Wireless. “Se algo não está indo bem, partilham com você no ato.”

De acordo com os CIOs que adotaram métodos ágeis, as mudanças no relacionamento com a área de negócio podem ter resultados surpreendentes. Waghray se recorda de conversas recentes com executivos-chave de operações e marketing nas quais ele usou uma abordagem mais ágil. O executivo avisou-os que não queria nenhum requisito. Bastava dizerem o que queriam e eles conversariam sobre o assunto. “Os executivos perguntaram se deveriam anotar o que desejavam. Eu respondi que não, não me dêem requisitos.” Era uma abordagem estranha para as pessoas.

O produto VZ Navigator, da Verizon Wireless, que oferece direções passo a passo suportadas por voz em seus dispositivos móveis e se tornou um dos serviços móveis mais populares da empresa, foi extremamente influenciado pela metodologia ágil. A equipe de Waghray consistia de profissionais de TI, vendas, atendimento ao cliente, marketing, treinamento e finanças. O foco principal, observa Waghray, foi desenvolver a solução “completa, porém simples” imediatamente e depois expandi-la e melhorá-la. “A solução teve êxito porque a metodologia ágil incentivou a comunicação contínua e o alinhamento entre todos os envolvidos, levando ao desenvolvimento paralelo não só da solução de TI, mas também de documentação sobre treinamento, casos de teste, desenvolvimento e validação de interface externa e comunicação com os usuários para prepará-los para o lançamento.”

Parra muitos executivos da equipe, os resultados foram surpreendentes. Eles disseram a Waghray que o projeto deveria ter demorado três vezes mais do que levou, oito semanas do começo ao fim. De acordo com Waghray, o projeto VZ Navigator “teve um impacto significativo e imediato sobre os resultados financeiros e promoveu a capacidade organizacional de fazer o mesmo com produtos similares.”É uma mudança cultural e de timing”, diz Waghray sobre o processo, “mas nunca tinha recebido tantos elogios para um projeto de negócio”.

Gerenciando a mudança ágil
Tendo em vista que as equipes ágeis são grupos autônomos de agentes de rápida mudança que tomam decisões de negócio críticas “on the fly”, as leis antes imutáveis do gerenciamento de projeto passaram por uma transformação radical. Como o tempo de desenvolvimento de 18 a 24 meses, típico do modelo tradicional, é reduzido drasticamente para duas semanas, cada dia de desenvolvimento e cada conversa se torna crítica. No departamento de TI de Dury, as manhãs começam com uma reunião da equipe e uma lista do que cada um é responsável por fazer naquele dia. “Não queremos conversar sobre o que será feito daqui a três semanas, mas sobre o que queremos fazer hoje”, ensina Dury. “Não queremos perder dias.”

É obrigação dos CIOs estabelecer novas expectativas — trabalho em equipe, franqueza, colaboração — para todos do grupo. “Existe uma expectativa de colaboração. Você não pode se limitar a trabalhar em seu pequeno mundo”, diz Martin, da Farm Credit Services. “Existe também uma boa visibilidade do trabalho e, em alguns casos, do não-trabalho.”

Os membros da equipe que resistirem, porém, provavelmente ficarão desempregados. (Um antigo ditado persa parece bem apropriado para os CIOs: “O cão ladra e a caravana passa”.) Scott Ambler, especialista em desenvolvimento ágil que trabalha como líder de práticas na IBM, suspeita que muitos desenvolvedores, analistas de requisitos e profissionais de dados e teste estão preocupados com as conseqüências desta mudança na carreira. “Provavelmente participaram de um grande número de fracassos e, com freqüência, têm menos poder para mudar as coisas. Pior ainda, a ameaça do outsourcing paira sobre suas cabeças”, diz Ambler.

A função do CIO é administrar a ansiedade e garantir que sua equipe enfoque a produção de software de ótima qualidade de maneira oportuna e eficaz em termos de custos. “Na comunidade ágil, a única medida de progresso de um projeto de desenvolvimento de software é a entrega de software funcional”, enfatiza Ambler. “A comunidade de desenvolvimento tradicional perdeu isso de vista.”

Por que tantos CIOs são indiferentes ao desenvolvimento ágil de software?
Ceticismo é a palavra mais usada quando perguntam a CIOs e analistas por que tantos líderes de TI têm mostrado indiferença em relação ao desenvolvimento ágil de software. Eles se deparam com este termo em conferências ou artigos e ele soa bem, mas a pesquisa 2006 “State of Agile” mostra que apenas 5% dos entrevistados apontaram o CIO como o defensor inicial de processos de desenvolvimento ágil. Surpreendentemente, 11% disseram que o presidente ou CEO estava promovendo a aceitação do novo modelo.

Sem o apoio do CIO e de personagens influentes da área de negócio, não é possível usufruir as eficiências de tempo e custo do gerenciamento de projeto e desenvolvimento de software da metodologia ágil. “Quando as empresas não têm um executivo no nível do vice-presidente ou do CIO promovendo a adoção, elas enfrentam muitos obstáculos”, diz Schwaber, da Forrester. Na Farm Credit Services, a iniciativa ágil de Martin atraiu a atenção e o apoio do CEO. A mentalidade ágil proliferou no resto da organização. O CIO sabia que tinha tomado a atitude certa quando descobriu que as equipes de negócio estavam realizando reuniões diárias e espelhando as práticas de TI. “As unidades de negócio perguntavam como poderiam se tornar mais ágeis.”

A jornada ágil de Martin completou um círculo. De CIO que nada sabia sobre desenvolvimento ágil nem conhecia ninguém que estivesse adotando desenvolvimento ágil, Martin transformou-se em um evangelista, disseminando a mensagem em conferências, feiras e cafés da manhã com CIOs. “Eu não posso nem pensar em voltar para a metodologia antiga.”

Fonte: CIO

Outras Referências:
    InfoQ: Interview: Jim Johnson of the Standish Group

Google Tech Talks December 9, 2005
Elisabeth Hendrickson

A medida que mais times estão adotando práticas ágeis como XP e Scrum, times de teste de software estão sendo solicitados que se tornam “ágeis” também. Mas o que isso quer dizer? A palavra “Ágil” é uma nova “buzzword”? Ou as práticas ágeis estão mudando a forma como o software está sendo desenvolvido.

Nesta palestra, Elisabeth Hendrickson compartilha sua perspectiva sobre como times de teste podem ser mais ágeis, baseada em sua experiência como testadora em times ágeis. Por toda a palestra, ela fará um resumo de como paráticas ágeis diferem das práticas tradicionais e discute o que tais diferenças significam para times de teste independentes.

Ken Schwaber, além de ser um dos criadores do Scrum, é fundador da Agile Alliance e da Scrum Alliance, além de signatário do Manifesto Ágil. Ken desenvolve software há mais de trinta anos. Atualmente, promove ativamente processos ágeis de desenvolvimento de software.

Google Tech Talks September 5, 2006

Entenda como o Scrum funciona, em menos de 10 minutos. Ao final dessa vídeo aula em inglês, produzida por Hamid Shojaee, você vai conhecer termos como: burndown charts, team roles, product backlogs, sprints, daily scrums e muito mais.

Hamid Shojaee é fundador e CEO da Axosoft, uma empresa fabricante de ferramentas para desenvolvimento ágil.

Novembro 13, 2008

Já tratei sobre o assunto de CMMI e Agile em outro artigo, em que comentava minhas impressões sobre o tópico. Resumindo eu dizia que: Você pode fazer um processo ágil ficar aderente ao CMMI, porém terá um grande overhead (sobrecarga) de custo e prazo em cada um de seus projetos para conseguir isso. Escrevi isso baseado no excelente estudo do David Anderson sobre o tema, quando ele criou o MSF for CMMI.

Agora o SEI publicou um technical report sobre o assunto intitulado CMMI or Agile: Why not embrace both! E esse assunto deu o que falar nas comunidades e listas de discussão dos agilistas!

Uma das conclusões interessantes do relatório diz: “O Problema percebido entre Agile e CMMI não parte do Agile e CMMI serem inconsistentes inerentemente, mas de uma combinação de falsas percepções e experiências com algumas organizações que impõem processos padrões super pesados e restritivos em todos os projetos como parte do uso do CMMI”.

É citado também o grandioso livro Peopleware de Tom DeMarco e Timothy Lister. Os autores afirmam que muitas organizações que passaram pelo CMMI acabaram se tornando avessas a riscos e conservadoras.

Mas, o objetivo final do relatório é tentar minimizar os conflitos entre os dois campos, reconhecer o valor de cada paradigma, eliminar erros e preconceitos mútuos.

O artigo também comenta um ponto que considero crucial. Em todas as discussões sobre o modelo CMMI é inevitável falar sobre a questão da avaliação (erroneamente chamada no mercado de certificação). O artigo reforça que é possível usar práticas alternativas para se atingir um objetivo do modelo. O problema é que vemos que mesmo os auditores oficiais treinados pelo SEI no SCAMPI(o guia de avaliação do CMMI) possuem dificuldade em aceitar ainda esses conceitos. Por ser um modelo, pode existir uma gama de interpretações diferentes no momento de uma validação via auditoria, especialmente devido à necessidade que o SCAMPI impõe em relação à existência de evidências diretas e indiretas da realização de práticas.

Do meu ponto de vista, o problemas não é o modelo CMMI em si, mas o SCAMPI e como é feita a avaliação. Quando se entra na busca do “selinho” é que ocorrem grande parte dos problemas, conforme já descrito no excelente livro “Measuring and Managing Performance in Organizations”.

O método de avaliação SCAMPI tende a levar a uma busca frenética por evidências diretas e indiretas, já que os avaliadores oficiais do SEI possuem essa tendência (e sei disso por experiência própria, já que participei em SCAMPIs A e B). Se o SEI mudasse a forma como é feita a avaliação formal e como ela treina seus avaliadores (algo recomendado nesse novo technical report) talvez fosse útil uma organização agile tirar uma avaliação CMMI por motivos de negócio (entrar em licitações, etc). Agora, como está hoje definido o SCAMPI, se torna inevitavelmente necessário adaptar o processo ágil para que ele tenha chances de passar por uma avaliação. Pelo exemplo do próprio MSF for CMMI (discutido em meu artigo anterior) dá pra notar que é um overhead razoável para se adaptar e “passar” em um SCAMPI.

Acho que o primeiro passo concreto que o SEI poderia dar para se aproximar mais dos processos ágeis, seria adaptar o SCAMPI e definir melhor práticas alternativas no modelo CMMI.

Vamos ver o que o futuro reserva em relação a esse assunto!

Fonte: José Papo Weblog

Julho 28, 2008

Escrevo esse post movido por dois distintos eventos: o primeiro foi o excelente painel sobre metodologias ágeis que ocorreu no TDC 2008 e o segundo foi um posto na lista scrum-brasil sobre o assunto Scrum e CMMI.

A dúvida é: É possível fazer o Scrum ou outro processo ágil ficar aderente ao CMMI e ser avaliado oficialmente por um SCAMPI?

A resposta curta é: Você pode fazer um processo ágil ficar aderente ao CMMI, porém terá um grande overhead (sobrecarga) de custo e prazo em cada um de seus projetos para conseguir isso.

A resposta mais longa e com evidências(he, he!):

Para início de conversa, recomendo fortemente primeiro a leitura do artigo do David Anderson chamado Stretching Agile to fit CMMI Level 3. Anderson foi um dos criadores da nova versão do MSF (processo de desenvolvimento suportado pela Microsoft e mais conhecido por vir como padrão na ferramenta Visual Studio Team System) . Ele explica nesse artigo o que tiveram que fazer para conseguir adequar um processo ágil (o MSF for Agile) para atender o modelo do CMMI.

Fica claro no artigo que existiu um razoável overhead para isso acontecer. Anderson estudou só o overhead para atingir o CMMI nível 3. Se falássemos no nível 4 e no nível 5 o overhead seria ainda maior (teria que incluir controle estatístico de processos, análise causal, gerenciamento quantitativo de projetos, etc).

Segue a conclusão mais interessante de Anderson (negritos meus): “It was therefore necessary to enhance MSF for Agile Software Development with additional activities to cover these aspects of the CMMI. This was non-trivial. The footprint of the guidance material for MSF for CMMI Process Improvement is 150% larger than that of MSF for Agile Software Development. So some large amount of stretching was necessary. For example, MSF for Agile Software Development has 25 work product artifacts whilst the CMMI method has 59. There are 9 metric charts with the agile method whilst the CMMI method has 12. “

Portanto, você pode até atingir o CMMI usando um processo ágil e isso é legal. Porém, tenha em mente que não existe uma solução mágica para isso e avaliadores CMMI (que usam o SCAMPI) ainda determinam a necessidade de documentação explícita (chamados de artefatos diretos e indiretos) para cada uma das práticas específicas das áreas de processo do CMMI.

Tendo isso em mente, você e sua empresa devem estar cientes do grande overhead que será necessário para o processo ágil ficar aderente ao CMMI. Se a empresa realmente necessita do CMMI para governança, como estratégia de marketing ou outro fator qualquer ela antes deve ter consciência que um projeto feito com “Agile CMMI” terá mais custo e será mais lento que um projeto feito com “Agile Agile”.

O Adail Retamal da Heptagon respondeu à minha conclusão com um outro dado muito interessante que aqui transcrevo:

“É isso aí, Papo! Nos meus cursos e consultorias sempre saliento esses aspectos também. Minha proposição para um Agile CMMI é:

Nível 2: Scrum, parte da FDD, PSM
Nível 3: + FDD, parte da TOC, algo de Lean
Nível 4: + Six Sigma
Nível 5: + TOC

Claro que outras ajudas serão necessárias para atender certas PAs, mas essa receitinha já abrange uns 80%…”

Mais detalhes sobre esse assunto de Scrum, Agile e CMMI podem ser encontrados no meu artigo Scrum, OpenUP e CMMI.

Fonte: José Papo Weblog

Janeiro 11, 2007

Este artigo se originou de uma pergunta endereçada à lista de discussão OpenUP/Basic. A pergunta original questiona a possibilidade de conseguir ser avaliado como CMMI nível 2 utilizando o OpenUP.

O OpenUP/Basic segue a filosofia do manifesto ágil e prega que “Software executando é mais importante que documentação” e que “Pessoas são mais importantes que processos”. Isso não significa que não há documentação e processo, o que é provado pelos inúmeros artefatos existentes, pelas disciplinas e pela existência do planejamento em cinco níveis das metodologias ágeis. Apenas ilustra o fato que devemos nos focar fortemente nas pessoas e nas interações entre elas, especialmente na transferência de conhecimento tácito. E que também devemos lembrar que o processo iterativo é fundamental para gerar software executável em curtos períodos de tempo.

Eu, particularmente, considero que ele atende tranquilamente o CMMI 2 já que o OpenUP/Basic:

Possui disciplina de requisitos -> atende a PA de REQM
Possui disciplina de Gestão de Configuração e Mudança -> atende a PA de CM
Possui disciplina de Testes -> atende a PA de PPQA
Possui disciplina de Gestão de Projetos -> atende a PA de PP e PMC
Possui gestão e avaliação de resultados de iteração e de projetos (tem por padrão o Project Burndown e o Iteration Burndown. Permite definição de mais métricas ) -> atende a PA de MA (você poderia usar o Practical Software Measurement para detalhar ainda mais outras métricas que você tiver interesse em incluir).

Ficaria faltando a PA de SAM (sendo que gestão de fornecedores – SAM – também não é tratada pelo RUP 7.0 em sua versão base).

A diferença é que, dependendo do assessor que irá verificar suas práticas (talvez seja uma pessoa que goste de ter evidências mais explícitas em formas de documentos do que evidência tácitas em forma de entrevistas), talvez você precise gerar documentos adicionais (Por exemplo, um plano de gerência de configuração. Ele existe no RUP mas não existe no OpenUP/Basic). A vantagem é que você pode utilizar a ferramenta EPF Composer para customizar o OpenUP do jeito que você necessita.

Mas vale sempre lembrar um detalhe: o foco do OpenUP e de todos os processos ágeis é te dar um aumento radical de produtividade e qualidade (reduções em até 50% no prazo de entrega de projetos, mantendo alta a qualidade). Ele não tem como objetivo apenas demonstrar que você está aderente a um modelo ou não. Muitas empresas se focam no CMMI e não em realmente melhorar seu processo. O que ocorre muitas vezes é que acabam burocratizando demais seus processos, tornando seus projetos lentos e pesados.

Segundo o artigo da InfoQ, o uso de Scrum, quando bem implementado, pode trazer o processo de uma organização para o CMMI nível 3. O OpenUP/Basic utiliza muitas práticas e princípios do Scrum e, portanto, creio que essa afirmação também se adequa ao OpenUP. Recomendo a leitura dos seguintes endereços para apoiar no processo de ser avaliado em níveis do CMMI utilizando processos ágeis:

http://www.cmmifaq.info/

http://www.agilecmmi.com/

http://www.infoq.com/news/2006/11/case-for-agile-cmmi5

http://www.entinex.com/agilecmmi/

http://agile2005.org/XR14.pdf

http://jeffsutherland.com/scrum/2006/11/scrum-supports-cmmi-level-5.html

Fonte: José Papo Weblog

Tabu em algumas empresas, prática comum em outras, a competição interna pode ajudar a descobrir talentos e levar melhores resultados para a organização – desde que alguns fatores sejam observados

Revista Melhor
Rodolfo C. Bonventti

Faz parte da natureza humana o gosto pela disputa e não há como negar que as empresas são ambientes cada vez mais competitivos. Um estudo publicado recentemente pela psicóloga Betânia Tanure, da Fundação Dom Cabral (FDC), de Minas Gerais, aponta que os executivos paulistas são os mais individualistas, competitivos e menos preocupados com relacionamentos, ou seja, olham mais para suas próprias carreiras do que para as suas equipes.

As estatísticas mostram que quase um terço do tempo no trabalho é gasto com a administração de conflitos, mas, como bem disse o ex-presidente norte-americano John Kennedy, “é nos momentos de crise que eu tenho as minhas melhores idéias”. Estaria aí a solução para tornar a competição interna e a administração de conflitos entre colaboradores e equipes um dado positivo para o desenvolvimento profissional?

Para o mestre em Administração de Empresas da Fundação Getúlio Vargas (FGV) e autor do livro Ética na gestão de pessoas: uma visão prática, Flávio Farah, “os sistemas competitivos são incompatíveis com o trabalho em equipe, já que a competição interna destrói a cooperação e estimula os atos imorais como a sonegação de informações, a recusa de ajuda a colegas de trabalho e até a sabotagem do trabalho alheio”. Além disso, continua Farah, ela inibe a aprendizagem e a criatividade, já que as pessoas envolvidas em uma disputa concentram fortemente sua atenção nas concorrentes e em suas reações e, assim, não têm tempo para aprender nem para imaginar novas maneiras de fazer as coisas.

Um exemplo típico de uma competição interna predadora está no filme O Sucesso a Qualquer Preço, de 1992, no qual os atores Al Pacino, Jack Lemmon, Ed Harris e Alan Arkin vivem quatro corretores de uma imobiliária de Chicago, cujo gestor, interpretado por Alec Baldwin, estabelece um concurso de vendas em que o primeiro colocado ganha um prêmio dos sonhos: um automóvel Cadillac Eldorado. Já para o segundo colocado, o prêmio estabelecido é um simples jogo de facas de churrasco e, para os outros, a rua, porque como define o gestor, “nesta empresa não há lugar para fracassados”.

Guardadas as devidas proporções, as psicólogas e executivas Ângela Sardelli e Celina Beatriz Gazeti viveram uma situação parecida anos atrás quando, juntas com outra profissional, concorreram a uma vaga de gerente para uma divisão da empresa em que atuavam. “Eu e a Celina já éramos muito amigas e foi um processo muito sofrido na época porque o nosso gestor teve um papel totalmente errôneo. Eram feitas entrevistas individuais com as três e nelas havia um incitamento claro à competição e nós nos sentíamos manipuladas”, lembra. Segundo ela, o papel correto de um gestor em uma situação dessas é o de ter maturidade e valores éticos pessoais para saber articular situações e propiciar recursos para que os seus comandados busquem melhores resultados. “Mas sem nunca partir para a manipulação e estimular o individualismo”, explica Ângela, que hoje é sócia de Celina na Vox Solutions, uma das quatro empresas que faz parte da joint venture Cliv Solution Group.

Falando em ética, para o professor Flávio Farah, do ponto de vista ético, a fixação de metas para os colaboradores nas empresas torna-se questionável quando, para o seu cumprimento, aqueles que ocupam posições de liderança na empresa estimulam o vale-tudo com exortações do tipo: “Cumpra suas metas, não importa como”; “Consiga aquele contrato de qualquer maneira”; “Faça o que for preciso para manter esse projeto dentro do orçamento”. “Ordens como essas sinalizam aos colaboradores que, para atingir objetivos, quaisquer estratégias são válidas, inclusive as que incluem o uso de meios imorais ou ilegais”, diz.

“A partir das histórias isoladas de indivíduos que realizaram coisas que pareciam impossíveis, firmou-se a crença de que o ser humano tudo pode, de que não existem limites para o homem. Essa crença, porém, não passa de um mito, pois, até hoje, ninguém foi capaz de demonstrar logicamente que, para o ser humano, tudo é possível”, argumenta Farah, que acrescenta: “Como as empresas têm o costume de fixar metas novas e mais difíceis depois que as anteriores foram cumpridas, os colaboradores enfrentam a cada momento, e sob ameaça de demissão, novos desafios cuja superação é incerta.”

Leia o resto do artigo no link…

Fonte: Revista Melhor