Dia 18/08, vai acontecer mais uma edição do Caipira Ágil, o maior evento sobre princípios e métodos e ágeis da região de Campinas. Inspirado pelo Encontro Ágil, o Caipira Ágil nasceu para ser uma forma de troca de experiências e conhecimento entre estudantes e profissionais, praticantes ou não de Agilidade.
O evento tem seu foco na troca de experiência e conhecimento de forma ativa, mão na massa. Composto por Workshops, Open Spaces, Coding Dojos e Lightning Talks o Caipira Ágil é muito mais do que um evento com apresentações. É um momento de união e atuação conjunta entre seus participantes, proporcionando uma ótima oportunidade de aprendizado.
O Evento terá bastante Dojos, Workshops e diversos temas para botar a mão na massa. Estarei com sessão prática sobre Coaching para times estressados. Confira essa e outras palestras na programação completa do evento: www.caipiraagil.com/programacao.
Parte do material que uso em meus treinamentos sobre Scrum. Nesse material mostro algumas visões pessoais e minhas experiências na adoção/adaptação do framework Scrum.
Through Agile approaches, we’ve uncovered different ways to help teams improve a whole organizational ecosystem. With the results of these experiments, we’ve concluded that, to create systemically healthy solutions, one should understand that:
1) The behavior of people varies with context.
2) Different contexts require different solutions.
3) The perception of the value of a solution depends on the point of view.
4) The effectiveness of a solution depends on how the root cause is perceived.
5) The dynamics of a system makes the today’s solution cause the tomorrow’s restriction.
6) Every solution must be sufficiently incomplete.
7) Sufficiently incomplete solutions make the continuous improvement possible.
8 ) A good solution allows identify and break its own restrictions.
9) And all the above statements also apply to this manifesto.
Through these guidelines, we, the creators of organizational solutions, recognize that no solution is better than another. We also affirm that the effectiveness of any solution depends on its ability to promote the solution beyond itself. Therefore if you believe in this brief manifesto, put it into practice and make your comment below.
Por meio de abordagens Ágeis, descobrimos diferentes formas para ajudar times na melhoria de todo um ecossistema organizacional. Com os resultados dessas experiências, concluímos que para criar soluções sistemicamente saudáveis, é necessário entender que:
1) O comportamento das pessoas varia de acordo com o contexto.
2) Contextos diferentes precisam de soluções diferentes.
3) A percepção de valor acerca de uma solução é relativa ao ponto de vista.
4) A eficácia de uma solução depende da maneira como é percebido o problema de origem.
5) A dinâmica de um sistema faz com que a solução de hoje cause a restrição de amanhã.
6) Toda solução precisa ser suficientemente incompleta.
7) Soluções suficientemente incompletas tornam possível a melhoria contínua.
8 ) Uma boa solução permite a identificação e a quebra de suas próprias restrições.
9) E todas as afirmações acima se aplicam também para esse próprio manifesto.
Por meio dessas diretrizes, nós, criadores de soluções organizacionais, reconhecemos que nenhuma solução é melhor que a outra. Afirmamos também que a efetividade de qualquer solução depende da sua capacidade de promover a solução além dela mesma. Sendo assim, se você acredita nesse breve manifesto, coloque-o em prática e faça o seu comentário logo abaixo.
Visando ter um canal mais simples, direto e mais ágil (com entregas constantes), criamos um novo formato de disponibilização de notícias e conhecimentos para nossa comunidade de agilistas. Portanto, gostaria de apresentar a todos: o Visão Ágil Community Journal, que nessa primeira edição oferece aos nossos leitores as seguintes matérias:
Agile Brazil 2010
Experiência Sicoob Brasil
Testes Unitários
Por que usar “story points”?
Coaching para Auto-Organizacão
Essência Ágil
Notícias
Portanto meu amigo agilista, faça aqui o download dessa primeira edição e fique por dentro do que está acontecendo na comunidade ágil brasileira.
Veja nesse vídeo, uma rápida entrevista feita durante o Ágiles2009 com Gerson Barrey (Gerente Executivo da EBC – Empresa Brasil de Comunicação) sobre algumas experiências ágeis no governo federal.
Em tempos de agile, tem algumas coisas que são um pouco difíceis de algumas pessoas/times adorarem como prática. Por exemplo: como fazer com que desenvolvedores façam testes automatizados, de preferência usando a abordagem TDD? Pode parecer fácil, mas só quem já tentou sabe como é difícil e como existe resistência na quebra do paradigma.
Pra resolver o problema temos basicamente 2 opções: (1) Alguém obriga todos do time a fazer os testes automatizados e ponto final, ou (2) utilizar-se de algum método que os convença que essa prática trás ganhos significativos.
Se existem duas coisas que não combinam em um projeto de software são prazo e escopo. Quando comecei a estudar sobre metodologias ágeis, um dos primeiros aprendizados que me chamou a atenção foi sobre esse problema: O cliente pode querer fixar o prazo ou o escopo, nunca ambos.
Desde o advento da era industrial, nos descobrimos uma palavra incrível para tudo: “mais”. Realmente sempre funcionou. Quando nossas ruas ficaram cheias, nós contruímos mais ruas. Quando nossas cidades ficaram inseguras, nós contratamos mais policiais e compramos mais carros de polícia.
Esse é a introdução de um dos capítulos do livro que eu estou lendo atualmente, Information Anxiety, que fala sobre como viver em um mundo onde não temos tempo para absorver todos os dados que são atirados contra nós.
Seguindo essa ótima idéia do Agile FAQ, acho que essa é realmente a segunda pergunta que mais recebemos em apresentações. Na verdade ela aparece em diversos formatos:
Trabalhar com desenvolvimento ágil de software tem sido um grande desafio para muitas pessoas. Geralmente, acontecem mudanças de estrutura hierárquica, na organização geográfica de pessoas, nas mesas para comportar todo time, e por ai vai.
Desse conjunto de mudanças que uma equipe/empresa sofre, vou destacar uma neste artigo: Escopo negociável e o Sprint Goal.
Partindo do princípio que você conhece o básico de SCRUM (Caso contrário existem tutorias na internet, aqui mesmo no blog ou na revista Visão Ágil), esse artigo foca basicamente no como e não muito nos conceitos. Só irei abrir uma exceção para o Sprint Goal, já que é o tema central do artigo e muitas vezes mau interpretado.
Já que todo mundo está dando opinião, acho que posso dar a minha também 🙂 .
Caso você não tenha acompanhado a discussão, pode se atualizar no post original do Jim Shore, ou então também nos comentários do Manoel ou do Guilherme, para citar alguns entre muitos.
Acho que o ponto em que vale a pena tocar é que ninguém tem problema com Scrum, FDD, XP ou qualquer outra metodologia da salada de fruta que sao os métodos ágeis hoje em dia. Todas elas são muito boas e tem seu valor em abordar um ou mais lados do desafio que é desenvolver software.
O problema acontece quando tudo isso se torna muito na moda e popular, o que leva um monte de gente a adotar metodologias ágeis sem ter muita noção do que está fazendo, ou não vendo a realidade que adotá-las de fácil não tem nada…
Quando eu e o Danilo fomos falamos no Falando em Agile esse ano, a idéia era justamente mostrar que não existem solucoes prontas (ou receitas para o sucesso), e que nenhuma alternativa é rápida e fácil quando o assunto eh criar software, e que existem diversas maneiras de falhar. O desafio é justamente alertar todo mundo sobre isso, sob a pena de vermos muitas pessoas desistindo dos métodos ágeis porque falharam na sua adoção.
E é claro que metodologias mais comerciais acabam sendo a vidraça da vez, já que elas acabam vendendo mais facil (sendo por desatenção de quem está “comprando”, seja pela falta de profissionalismo de consultores que as colocam como balas de prata) , e sendo encaradas como uma solução pronta, o que so prejudica a todos.
Um abraço
Sobre o autor:
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui diversos anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
A atividade de desenvolvimento de software, é uma coisa interessante e muito intrigante, pois como é uma atividade relativamente nova, ainda está cheia de indefinições e transformações sobre seus conceitos e práticas. Essa constante metamorfose é grandemente potencializada na área de metodologias, pois é aqui, que as questões humanas são mais evidentes nessa atividade.
Mas meu foco nesse texto é abordar as diferentes (e várias) visões que a agilidade (ou seus praticantes), têm acerca da atividade de software.
A primeira vista, podemos até achar que dentro da agilidade, seus praticantes e evangelizadores se dividem nos diferentes rótulos de metodologias existentes, como XP(Extreme Programming), FDD(Feature Driven Development), Scrum, Lean, OpenUP, MSF, etc. Essa primeira visão é em função dos grandes debates “sobre qual dessas metodologias é a melhor?” que incidem sobre a comunidade e o mercado.
Outra possível leitura, que devido ao conteúdo dos debates, podemos imaginar que a principal diferença é que talvez haja os agilistas mais ligados às questões técnicas e os agilistas mais ligados em questões gerenciais e como o mercado nos acostumou a tratar isso como duas coisas diferentes, criamos (pelo menos em nossas mentes) dois mundos totalmente antagônicos e passamos a chamar esses mundos de: operacional,tático e estratégico, e como temos algumas das metodologias acima que tratam de formas distintas essas questões, criamos então o cenário propício para a existência imaginária da “metodologia para osgerentes” e a “metodologia apenas para os programadores”.
Mas essa segregação apenas por rótulos ou por nível hierárquico, são na verdade apenas os efeitos visíveis, que ainda têm algumas outras causas que precisam ser mitigadas. Por exemplo: Será que uma das causas dessas segregações, é que algumas das metodologias citadas acima, oferecem uma visão mais artística, poética e um tanto artesanal e outras metodologias oferecem uma visão mais mercadológica, corporativa e industrial?
Observe que não estou sugerindo que um desses dois grupos é melhor que o outro, apenas mostrando algumas diferenças, que ultimamente estão ficando muito latentes na comunidade, inclusive, talvez essas diferenças não existam na prática, apenas é algo que as próprias pessoas da comunidade, estão criando entre si mesmas, pois como existem pessoas com tendências mais artísticas e outras com tendências mais industriais/corporativas, elas acabam “construindo muros” ao seu redor, para proteger suas idéias e suas crenças.
Na verdade, essa discussão entre o industrial e o artesanal, é algo muito antigo em nossa sociedade, pois a história mostra por exemplo, o movimento do Luddismo contra a Revolução Industrial que em meados do século XVIII, trouxe profundas questões sobre a relação do homem com as atividades produtivas que estavam surgindo.
Mas, conforme disse Domenico De Masi, em seu livro O Ócio Criativo, para esses antagonismos produzidos em nossa sociedade, devemos “Nem Rir nem Chorar mas Entender”, ou seja, dentro da comunidade de software, conforme já falei no artigo Os Moinhos de Vento dos processos ágeis, publicado no Blog Visão Ágil, não é saudável levar esse tipo de debate a nível da intolerância intelectual nos posicionamentos de euforia ou temor e sim entender de uma vez que: Não existe uma só forma de agilidade, que atenda a todos os contextos, por isso devemos estar dispostos a aprender continuamente sobre essas formas possíveis em cada contexto, mesmo que muitas vezes, elas ainda não estejam descobertas.
Veja que recentemente essas segregações ganharam muito fôlego, pois algumas antigas discussões como CMMI e Agile e o tipo de atuação da Scrum Alliance, voltaram ao cenário em nossas comunidades através do relatório do SEI sobre CMMI e Agile e através do contundente artigo “The Decline and Fall of Agile” do James Shore.
Porém, termino esse meu breve texto, lembrando que não estou aqui querendo dizer quem está certo ou errado, mas sim, para complementar o pensamento do meu amigo Alisson Vale em seu texto sobre O Dilema Ágil, quero propor uma reflexão:
Será que não há espaço para todas essas vertentes da agilidade?
Será que não podemos sair do Luddismo para o Lúdico? E reconhecer que para alguns contextos, o industrial é melhor que artesanal?
E será também que os industriais, não podem reconhecer que para muitos casos, o artesanal é mais aconselhável que o industrial?
Enfim, está lançado um desafio que talvez somente com o tempo, quando nossa área estiver mais madura, poderemos responder com mais clareza e acurácia.
Sobre o autor:
É Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com como Coach em metodologias para importantes empresas do segmento de serviços, indústrias e bancário. É Diretor Editorial da Revista Visão Ágil, Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Contatos: manoel@visaoagil.com
Normalmente eu nao gosto de criar posts apenas para citar outros, mas achei que valeria a pena divulgar essa discussao, especialmente no Brasil, onde Scrum esta se tornando o padrao de facto para Agile, com muita gente embarcando sem saber exatamente do que se trata…
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui diversos anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
No próximo dia 01 de Novembro a Fratech realizará o evento de Lançamento do portal InfoQ Brasil. A idéia é oferecer ao público uma prévia do conteúdo do portal através de apresentações de novidades e opinião dos editores.
Buscamos nomes muito interessantes para cara Queue, como Fabio Akita para falar de Ruby, Yara Senger para falar de Java, Alexandre Gomes em SOA, Wagner Santos em Architecture e Manoel Pimentel e Victor Hugo em Agile.
Além dos editores brasileiros, contaremos ainda com a presença do Floyd Marinescu, criador e fundador do InfoQ.com (e antes disso do portal The Server Side) e de Heather Van Cura, gerente no JCP (Java Community Proccess) que falar sobre como o JCP funciona e como ele pode influenciar o mundo open source com padrões.
O evento acontecerá no auditório da Faculdade Anhembi Morumbi, parceira da Fratech já faz algum tempo, localizado na Rua Casa do Ator, 275.
Contamos com a presença de todos aqueles que como eu, esperam que a infoQ Brasil venha para contribuir para a comunidade brasileira de desenvolvimento de software.
Compareça e saiba mais sobre como funciona a InfoQ Brasil e quais são as possibilidades desta nova iniciativa.
Arquiteto de Sistemas com experiência de 5 anos em desenvolvimento de sistemas distribuídos. Atualmente trabalha em projetos pela Fratech, atuando na arquitetura de aplicações críticas. Participa atvamente do desenvolvimento do framework Struts2 e mantém o projeto open-source BoxSQL. Palestrante no QCon em Londres.
Semana passada estive presente no Rails Summit Latin America, que foi realizado em SP (por sinal, ótimo evento 😀 ), e uma das coisas que chamaram a minha atenção foi o que o Chad Fowler falou em sua palestra:
Experiência real é igual à mudança. Para a maioria das pessoas, 9 anos de experiência equivalem a 9 anos fazendo o seu trabalho do mesmo jeito, mas experiência conta somente se você está aprendendo continuamente como trabalhar melhor
Isso me chamou a atenção porque frequentemente se vê pessoas tentando utilizar metodologias ágeis como se fossem receitas prescritivas, como “eu utilizo Scrum, ou XP, ou FDD, etc..”.
Não me canso de repetir isso, mas como o Manifesto Ágil já dizia:
We are uncovering better ways of developing software by doing it and helping others do it.
Então não tenha medo de mudar e tentar coisas novas, nem de adaptar as práticas ágeis para o contexto que você se encontra. A melhor maneira de desenvolver software é a que funciona para você. Mude!
Um abraço,
Francisco
Sobre o autor:
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
Nossa história com o projeto começou quando eu e o Bruno fomos chamados pelo Fábio Petrillo, Coordenador Geral de Sistemas de Informação do INEP para ajudarmos o pessoal a trabalhar com Metodologias Ágeis. Não houve esforço nenhum para o Petrillo comprar a idéia, pois ele já acreditava em Agile e já tinha trabalhado com isso antes. Já leu os livros que eu li, os que você já leu e mais um monte que a gente nem ouviu falar ainda. É um cara que sabe das coisas.
O desafio pra gente era com a equipe, pois não seria legal chegar com “pose” de consultor pedindo pra eles fazerem as coisas de uma forma completamente diferente e depois ir embora deixando eles com o pepino na mão. Eles tinham que ver muito rápido benefícios nas práticas adotadas, e ver que estávamos do lado deles, senão a consultoria e o projeto iam afundar. Não sabíamos por qual prática começar, nem como abordar o pessoal.
Restavam 11 semanas de projeto e o prazo não era negociável por força de lei. A equipe começou com Danielzim, Cláudio Alberto e Sandro. Depois entraram Robert (JBoi Seam), Vitor e Kelly.
O desafio inicial era enorme. O projeto já tinha um módulo administrativo funcionando, com algumas fraquezas, e tínhamos que migrar o banco, desenvolver a inscrição web e refazer o módulo administrativo. Ao longo do projeto, a idéia da migração do banco e do redesenvolvimento do módulo administrativo foram abandonados. Ainda bem! A inscrição web já tinha por si suficientes desafios. Tinha que resolver diversos problemas legados de outras inscrições.
Cláudio Alberto pilotando o sistema apresentado pela equipe, para dar feedback ao cliente. Atrás: Bruno, Vitor, Petrillo, Robert e Daniel
Começamos levantando tudo em estórias e planejando iterativamente. A equipe tem muito mérito pois absorveu as práticas de forma surpreendentemente rápida. Também são muito habilidosos e desenvolveram as coisas bem rápido. No começo eu e o Bruno achamos as estimativas otimistas demais, que acabariam se frustrando, mas eles conseguiam cumpri-las muito bem. Havia receios por parte deles em relação à não utilização de casos de uso com toda descrição do sistema. Acredito que há até hoje! :o)
O Kanban começou numa porta de armário. Falta de espaço não pode servir de desculpa pra não começarmos a utilizá-lo. Depois foi pra um quadro chique, com product burndown e tudo mais.
Ao longo do projeto, o Cláudio foi fazendo a interface com o cliente a cada versão gerada e também levantava casos de teste, pois o cliente tinha restrições em estar presente. O feedback gerou diversas alterações que melhoraram bastante o sistema e também permitiram que escopo fosse cortado dessa release. Foi bom pra todos. O pessoal desenvolveu testes automatizados e também se ajudou em pares. Inclusive, pra eles isso foi um ponto forte destacado: a integração da equipe de desenvolvimento.
Par que nada, esta foi uma triple do pessoal, pra resolver problemas na automação de testes.
Uma das últimas stand-up meetings do projeto, falando dos testes e ajustes finais.
Após o sistema entrar em produção, a equipe já estava gerando versões com naturalidade e confiança pra ir corrigindo detalhes e disponibilizando versões a cada dia – graças às builds semanais. Na última visita que fizemos a eles, dia 8, já havia cerca de 20 mil inscritos (Rodando no JBoss – cha chim!!$$$), e consideramos o projeto um grande case de sucesso com agile.
Claro que ainda há muito o que aprender, aliás, essa é a moral da história: sempre há! Agora o desafio é espalhar a cultura no resto do departamento. Já sabemos que outro projeto vai começar a adotar metodologias ágeis, o Enem. Em breve, de um jeito ou de outro, todos acompanharemos os resultados – acredito que seja com muita alegria, como no case do Encceja.
Abraço a todos, parabéns ao INEP pela coragem e parabéns à equipe pelo ótimo trabalho!!! Willi
Nas minhas leituras recentes sobre Lean, eu encontrei uma tabela bastante informativa, que tenta clarificar os mitos sobre o que é e o que não é Lean, e continha as seguintes informações (livre tradução):
Mito – O que não é TPS
Uma receita tangível para o sucesso
Um programa de gerência
Uma série de ferramentas para implementação
Realidade – O que é TPS
Uma maneira consistente de pensar
Uma filosofia de gerenciamento
Um ambiente de trabalho em equipe e melhoria
Uma busca sem fim por uma forma melhor
Apesar de Lean não ser um conjunto de ferramentas, tudo que se fala sobre o assunto na industria de TI é sobre uma série de … ferramentas. Tempo de ciclo, kanban, sistemas pull, flow, qualquer um desses conceitos já foi anunciado como a última solução para projetos de software.
Não quero dizer aqui que essas ferramentas não vão nos ajudar a desenvolver software, mas com certeza estaremos perdendo a principal parte do que Lean tem para nos ensinar se não começarmos a pensar sobre seus princípios, isto é, a segunda parte daquela lista, a filosofia e o pensamento.
E se você começar a pensar nos princípios Lean, verá que eles não são muito diferentes dos que norteiam o desenvolvimento ágil ( ao menos o que eu penso sobre agile:-) ). Se você le sobre um um ambiente de trabalho em equipe e melhoria, você pode dizer se estão falando sobre Lean ou Agile?
Mas o problema é que quando a a maioria das pessoas pensa sobre Agile, elas pensam sobre práticas e não príncipios. Ao invés de ser colaboração e comunicação, Agile para eles é programação em pares, iterações e retrospectivas. E é nesse ponto que eu acho que está a solução. Parar de pensar em qual é o próximo conjunto de práticas que nos farão melhorar e começar a pensar em quais são os princípios que estamos seguindo e como fazer para aplicá-los melhor no nosso contexto.
Um abraço.
Francisco
Ps: Esse post é uma tradução de um post originalmente publicado no meu blog: What is Lean? And Agile?
Sobre o autor:
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.
Nos dias 21 e 22 de Outubro de 2008, das 09:00 às 18:00, através da Heptagon Tecnologia (Parabéns Adail!) aconterá em São Paulo, oCurso Zen of Agile Management com David Anderson (Reconhecido líder na comunidade Ágil e autor do livro “Agile Management for Software Engineering).
Essa é uma grande oportunidade para que a comunidade ágil aqui no Brasil, possa interagir com um grande pensador internacional e criador de várias das técnicas ágeis que usamos.
Alguns tópicos que serão abordados:
Como criar ou destruir confiança
Minha receita para o sucesso
Métricas, medição, rastreamento e indicadores para a Gestão Ágil
Identificação de gargalos e Gestão por Restrições (TOC)
Identificação de perdas
Gestão de problemas e riscos
Planejamento simples de iterações
Planejamento avançado e previsível de iterações, baseado em processos de baixa variação
Sistemas puxados e “Kanban”
Seleção do mix de produtos e priorização
Teoria das Opções Reais e o suporte à decisão
Combinação de Agile e CMMI
Como alcançar uma organização ágil de alta maturidade (cultura “Kaizen”)
Esses dias estava assistindo o vídeo do debate sobre metodologias ágeis na TDC, onde o principal tópico foi a já conhecida discussão sobre metodologias ágeis X CMMi.
Não quero entrar em detalhes aqui sobre o debate, até porque quem estiver curiosidade pode ver o vídeo, que foi bem interessante, mas sim queria dar minho opinião sobre um ponto de vista que é pouco abordado nessas discussões, que é a utilização de certificaçoes em geral.
O principal ponto em qualquer processo ou metodologia , na minha opinião, é a capacidade que é dada para a equipe de constantemente melhorar o seu desempenho, e isso é um aspecto extremamente importante nas metodologias ágeis, já que um ambiente de melhoria constante é possibilitado devido ao constante feedback recebido (do cliente, da própria equipe, etc.. ).
E o que isso tem a ver com certificações?
Bom, certificações, como o próprio nome diz, certificam que uma equipe segue algum padrão. Elas requerem evidências de que o time está constantemente seguindo certas práticas, e com essa exigência, elas acabam com as possibilidades de inovação de qualquer equipe.
Quero deixar claro que não estou falando só de CMMi ou qualquer outra certificação tradicional, mas sim de qualquer certificação, inclusive idéias de certificações ágeis que vem surgindo. E se a equipe não quiser estimar mais? E se não quiser escrever estórias em cartões?
Um exemplo prático disso está acontecendo em um projeto da ThoughtWorks UK, onde o cliente decidiu que algumas funcionalidades sendo desenvolvidas deveriam ser colocadas em produção sem testes de aceitação, para se obter um feedback rápido do público e depois então testá-las caso fossem aceitas.
Como ficaria essa situação se a equipe fosse certificada em “Agile nível 5” :D, onde 100% do código deve ser testado? Certamente o cliente seria prejudicado por regras impostas por alguma organização que quer especificar como desenvolvemos software.
Finalizando, eu também entendo o outro lado da moeda, onde certificações são exigidas por empresas e governos para se poder vender projetos. Acho que nesse caso, a opção é de cada equipe, mas deve-se saber que aceitando-se isso, se estará comprometendo a capacidade de se entregar software.
Um abraco,
Francisco
Sobre o autor:
Francisco Trindade é desenvolvedor e consultor da ThoughtWorks UK. Engenheiro de Computação e mestre em Engenharia de Software pela UFRGS, Francisco possui 5 anos de experiencia em desenvolvimento de software, alem de ser um entusiasta e praticante de metodologias ágeis.