30 novembro 2007

Tornando-se um líder Ágil - parte 3




Entenda como funciona a Liderança sob a ótica do Lean thinking.
Palestra ministrada por Mary Poppendieck - excepcional. Um pouco demorada, mais muito produtiva.

Assista na íntegra (com os slides da apresentação)
http://www.infoq.com/presentations/poppendieck-agile-leadership



29 novembro 2007

Mais trágico que engraçado


Gosto muito do Dilbert, e esta semana recebi a tirinha acima numa lista de amigos da faculdade. E me deixou um pouco chateado...
Não pela tirinha em si, mas pela representatividade que ainda não temos no Brasil. É mais comum do que se possa imaginar o fato de profissionais de TI nunca terem ouvido falar em Desenvolvimento Ágil, mesmo já sendo algo completamente batido, com menções já publicadas na MundoPM, CNN, MundoJava, JavaMagazine entre outras tantas. Mesmo com um termo já no Mainstream mundial, empresas ainda se recusam a dar crétido ao que as empresas mais promissoras estão utilizando.
Seria isto culpa de nós, agilistas? Estaríamos realmente transmitindo os valores corretos às pessoas que abordamos com essa história de Desenvolvimento Ágil? Ou seria mais a nossa incapacidade de transformar o manifesto em algo realmente aplicável?

Talvez falte divulgação concreta e de qualidade. (Um dos motivos que me prontifiquei a ajudar a revista Visão Ágil - para fazer parte da disseminação de conhecimento e esclarescimento que precisa ser feito). Faça você tb!!
Mês passado dei uma palestra na empresa Way2 com o título: O Desafio da Mudança. E foi muito importante esclarescer o que realmente está por trás do Manifesto Ágil: princípios acima de técnicas!!. Técnicas são apenas a consequência da aplicação dos princípios, e é isso que a minha apresentação tenta cobrir. Mesmo que você saiba de cór e salteado o ciclo Scrum, ou as práticas XP, você somente atingirá um pequeno grau de produtividade, qualidade e satisfação. Para ultrapassar isso é necessário buscar os princípios. Bem, no fundo apenas espero que eles tenham gostado da apresentação... =)

Enquanto estivermos apenas pensando em técnicas, ferramentas e procedimentos, não haverá o sucesso real do desenvolvimento Ágil, apenas o aumento da produtividade. E trasmitir isto às empresas é o principal... Como o Yugo sempre diz:"É descobrir o que está por trás dos conceitos e das práticas".

27 novembro 2007

Performing transformation

HBR IdeaCast 69: Rapid Transformation

Rapid Transformation: Harvard Business Digital's Paul Michelman talks with Stanford University's Behnam Tabrizi, author of Rapid Transformation: A 90-Day Plan for Fast and Effective Change.

Entrevista muito boa... impressionante... e bastante alinhado com o modelo Ágil de desenvolvimento...

aliás, vc deveria acompanhar estes podcasts... =) Business language....






File .mp3

26 novembro 2007

Como tratamos nosso departamento de TI



Saudações!
O conto abaixo foi apresentado a mim na especialização que fiz... e traduz muito fielmente experiências que passei em algumas empresas...



A FÁBULA DOS PORCOS ASSADOS
DESCONHEÇO O AUTOR
CONTOS E LENDAS



Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir daí, toda vez que queriam comer porco assado, incendiavam um bosque... Até que descobriram um novo método.

Mas o que quero contar é o que aconteceu quando tentaram mudar o SISTEMA para implantar um novo. Fazia tempo que as coisas não iam lá muito bem: às vezes, os animais ficavam queimados demais ou parcialmente crus. O processo preocupava muito a todos, porque se o SISTEMA falhava, as perdas ocasionadas eram muito grandes - milhões eram os que se alimentavam de carne assada e também milhões os que se ocupavam com a tarefa de assá-los. Portanto, o SISTEMA simplesmente não podia falhar. Mas, curiosamente, quanto mais crescia a escala do processo, mais parecia falhar e maiores eram as perdas causadas.

Em razão das inúmeras deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de reformar profundamente o SISTEMA. Congressos, seminários e conferências passaram a ser realizados anualmente para buscar uma solução. Mas parece que não acertavam o melhoramento do mecanismo. Assim, no ano seguinte, repetiam-se os congressos, seminários e conferências.

As causas do fracasso do SISTEMA, segundo os especialistas, eram atribuídas à indisciplina dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou ainda às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar - na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: maquinário diversificado, indivíduos dedicados exclusivamente a acender o fogo - incendiadores que eram também especializados (incediadores da Zona Norte, da Zona Oeste, etc, incendiadores noturnos e diurnos - com especialização matutina e vespertina - incendiador de verão, de inverno etc). Havia especialista também em ventos - os anemotécnicos. Havia um diretor geral de assamento e alimentação assada, um diretor de técnicas ígneas (com seu Conselho Geral de Assessores), um administrador geral de reflorestamento, uma comissão de treinamento profissional em Porcologia, um instituto superior de cultura e técnicas alimentícias (ISCUTA) e o bureau orientador de reforma igneooperativas.

Havia sido projetada e encontrava-se em plena atividade a formação de bosques e selvas, de acordo com as mais recentes técnicas de implantação - utilizando-se regiões de baixa umidade e onde os ventos não soprariam mais que três horas seguidas.

Eram milhões de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, o fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Foram formados professores especializados na construção dessas instalações. Pesquisadores trabalhavam para as universidades para que os professores fossem especializados na construção das instalações para porcos. Fundações apoiavam os pesquisadores que trabalhavam para as universidades que preparavam os professores especializados na construção das instalações para porcos etc.

As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo depois de atingida determinada velocidade do vento, soltar os porcos 15 minutos antes que o incêndio médio da floresta atingisse 47 graus e posicionar ventiladores gigantes em direção oposta à do vento, de forma a direcionar o fogo. Não é preciso dizer que os poucos especialistas estavam de acordo entre si, e que cada um embasava suas idéias em dados e pesquisas específicos.

Um dia, um incendiador categoria AB/SODM-VCH (ou seja, um acendedor de bosques especializado em sudoeste diurno, matutino, com bacharelado em verão chuvoso) chamado João Bom-Senso resolveu dizer que o problema era muito fácil de ser resolvido - bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então numa armação metálica sobre brasas, até que o efeito do calor - e não as chamas - assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor geral de assamento mandou chamá-lo ao seu gabinete, e depois de ouví-lo pacientemente, disse-lhe: "Tudo o que o senhor disse está muito bem, mas não funciona na prática. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? Onde seria empregado todo o conhecimento dos acendedores de diversas especialidades?". "Não sei", disse João. "E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadores automáticas de ar?". "Não sei". "E os anemotécnicos que levaram anos especializando-se no exterior, e cuja formação custou tanto dinheiro ao país? Vou mandá-los limpar porquinhos? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Heim?". "Não sei", repetiu João, encabulado. "O senhor percebe, agora, que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo atrás? O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas! O que o senhor espera que eu faça com os quilômetros e quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? Vamos, diga-me?". "Não sei, não, senhor". "Diga-me, nossos três engenheiros em Porcopirotecnia, o senhor não considera que sejam personalidades científicas do mais extraordinário valor?". "Sim, parece que sim". "Pois então. O simples fato de possuirmos valiosos engenheiros em Porcopirotecnia indica que nosso sistema é muito bom. O que eu faria com indivíduos tão importantes para o país?" "Não sei". "Viu? O senhor tem que trazer soluções para certos problemas específicos - por exemplo, como melhorar as anemotécnicas atualmente utilizadas, como obter mais rapidamente acendedores de Oeste (nossa maior carência) ou como construir instalações para porcos com mais de sete andares. Temos que melhorar o sistema, e não transformá-lo radicalmente, o senhor, entende? Ao senhor, falta-lhe sensatez!". "Realmente, eu estou perplexo!", respondeu João. "Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério e complexo do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia - isso poderia trazer problemas para o senhor no seu cargo. Não por mim, o senhor entende. Eu falo isso para o seu próprio bem, porque eu o compreendo, entendo perfeitamente o seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo, não é mesmo?".

João Bom-Senso, coitado, não falou mais um a. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.

24 novembro 2007

The Enterprise Scrum



Saudações! Eis a minha mais nova aquisição, o novo livro do Ken - The Enterprise Scrum. Seguindo a indicação do próprio Ken Schwaber, na lista scrumDevelopment (sim, ele respondeu um email meu!!! hahahahah que merda).
Os questionamentos que me fizeram comprar o livros estão relacionados à formas de extrapolar a utilização do movimento Ágil, deixando o ambiente de software e TI para uma visão mais ampla e estratégica da empresa. Talvez tenha encontrado uma pequena introdução neste livro...

Estou no início do livro, mas algumas coisas são interessantes:
- Afirmação clara: Scrum não resolverá seus problemas. Pelo contrário, ele os tornará mais explícitos e será difícil não encará-los. Portanto, se você não está pronto para resolver seus problemas, utilizando o scrum, você apenas vai deixá-los mais expostos.
E tenho visto esta a afirmação realmente ocorrer em nossa utilização do Scrum na Audaces. Conflitos sempre ocorrerão. E realmente, este é o maior sinal de que a mudança que propomos com o Desenvolvimento Ágil está acontecendo...
- O livro é mais uma tentativa de vender inúmeros livros e cursos para formação ScrumMasters... como não poderia deixar de ser...


Está sendo interessante a leitura...

[]s

21 novembro 2007

Implantando Scrum em 10 passos



Saudações!!

Bem, aqueles que acessam o site já devem ter percebido que eu disponibilizo uma seleção de posts direto dos feeds que assino (GoogleReader Shared Links)...
E tenho acompanhado muito de perto os escritos de Kelly Waters, do All About Agile. Ultimamente Kelly tem escrito um série de posts sobre como implantar Scrum de forma simples (será mesmo??? )... valeu MUITO a pena a leitura...
Infelizmente não estou com muito tempo para traduzir, e provavelmente o farei em breve... então lá vai o texto em inglês:

How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

16 novembro 2007

Errata

Corrigido post anterior (mea culpa mea maxima culpa)

Enterremos o termo "Engenharia de Software"

Enterremos o termo "Engenharia de Software"

Saudações!

Desculpem a demora em escrever... estou um pouco ocupado escrevendo o novo artigo para a revista Visão Ágil...
Mas vamos lá...

Dica quente: Agile Journal de novembro

Sou muito fã das publicações desta revista, e desta vez devo admitir que eles foram muito bem na escolha dos temas, recomendo imensamente...
Me chamou atenção um texto entitulado:
Let's Bury the Term Software Engineering, que gostaria de dividir com vocês, fazendo uma pequena introdução em português.
Continuo não acreditando que Desenvolvimento de software não deve ser comparado em engenharia (na verdade gosto mais do termo criado dave Thomas: Jardinagem de software), e o texto me trouxe maiores embasamento sobre minha convicção. E vale muito a pena ser comentado.

"In software, if we discourage changes, we can expect failure. Our constraints come packaged with change. Our constraints are the expectations, needs, wants, and feelings of people."


O texto inicia com uma comparação bastante interessante:

Engenheiros ao trabalharem possuem as restrições principais relacionadas às leis da física, bastante conhecidas, documentadas e estáticas (em termos gerais: leis de newton, mecânica dos sólidos, leis da aceleração, peso, momento, etc). Obviamente que espectativas de clientes são restrições a serem consideradas... entretanto a base do pensamento na construção de uma ponte está focada em axiomas matemáticos e físicos...
Em desenvolvimento de software isso não ocorre!! As maiores restrições que possuimos estão relacionadas a expectativas de stakeholders, mal documentadas, mal compreendidas (se é que um stakeholder sabe realmente o que quer). E como o resultado de nosso trabalho é um produto intengível, leis da física não são prioridade... e pior, as "leis" que regem o desenvolvimento podem mudar a qualquer momento! Inclusive na leitura deste blog...

A principal forma de trabalhar de forma eficiente e produtiva num ambiente mutável como o de criação de software é estar preparado para a mudança, não tentando evitar que ela ocorra, mas incorporando-a. E como resolvemos este problema? Criatividade! Não processos de engenharia...

Daryl Kulak propõe inclusive a abolição do termo Engenharia de Software, na tentativa de mudar nossas convicções que nos prendem a um modelo estático e mecanizado, que não corresponde a nossa realidade. Vou apoiar a iniciativa e não falarei mais em engenharia de software! =)

Leia o artigo completo

10 novembro 2007

Ampliando o blog

Iniciando no Technorati

Technorati Profile

Tipping Point - Guinness



Assista abaixo, a super produção “Tipping Point”, o comercial mais caro dos 80 anos de história da Guinness e dirigido por Nicolai Fugslig, o mesmo responsável por “Balls” da Sony Bravia.







09 novembro 2007

Scrum at Yahoo and Google AdWords.



O vídeo abaixo foi retirado do site AgileSoftwareDevelopment, e conta a história de como Yahoo! e o projeto Google Adwords passaram a utilizar Desenvolvimento Ágil apresentada por Jeff Sutherland (pai da criança)...

Uma aula excepcional... ASSISTAM!

Resumão PIV (pra inglês ver):

Yahoo
1. Yahoo já foi uma empresa "organica". Existiam vários pequenos grupos com a capacidade de realizar qualquer coisa com o mínimo de disciplina.
2. Houve a necessidade melhorar a estrutura da empresa. Assim, os consultores entregaram 300 páginas de um processo Pesado e complexo. Todos odiaram a iniciativa, e não trouxe reais benefícios para aempresa
3. Viram scrum como a possibilidade de retornar às origens, enquanto ainda teriam alguma estrutura. Atualmente o desenvolvimento de produtos é realizado utilizando Scrum (Mais informações: aqui )


Google AdWords
1. Em 2001 existiam inúmeros gerentes no Google. Eles costumavam a dizer a pessoas inteligentes o que elas deveriam ou não fazer. Então a empresa livrou-se deles.
2. Então tornou-se comum inúmeras equipes orgânicas de três pessoas com liderança rotativa. Em torno de 160 equipes se reportavam para uma única pessoa - sem problemas uma vez que os times não necessitavam instruções. Ainda assim aplicações b2b precisavam de muitos retornos do cliente.
3. Scrum tornou-se uma opção bastante promissora. Sua hierarquia é bastante próxima do que eles já possuiam, mas ainda assim possui alguma estrutura e permite facilmente a apresentação de prioridades de forma mais clara.

Com vocês, o vídeo:

Fonte

08 novembro 2007

Bellatorus


Saudações a todos!

É com grande satisfação que anuncio o lançamento do Jogo Bellatorus pela Manifesto Games esta semana! Melhor ainda por ter acompanhado de perto o desenvolvimento e os desafios que o criador, O Petrucio da Pangas Entertainment, enfrentou ao largar o belo emprego que possuia para se arriscar num sonho...

Muito Sucesso Pangaré!!
Segue a descrição do jogo:
Bellatorus is a card battle game, where you'll struggle to destroy your opponent's tower and protect your own. If your are not too fond of wanton destruction, you can focus on building and protecting your tower, and should consider siding with the good guys. If you are a destructive kind of fella, the bad guys are your choice of allies.

Bellatorus is multiplayer, and you will be able to play with your friends over the internet and show them who's boss... You can even create your own decks and new cards with the integrated Bellatorus Deck Editor, and use them to play, and maybe even share them with the rest of the Bellatorus comunity at this site!

Add to that the gorgeous 3D look & feel of Bellatorus, and you've got a card battle experience unlike any you've known before.


Alguns Screenshots
[]s

06 novembro 2007

Mobile Comédia!!


Saudações!!
Seguindo a linha de grandes sites como o UnderGoogle, eu tb criei a versão mobile para A Maldita Comédia!! Muito bom!

Através do site MoFuse, você também pode gerar a sua versão simplificada e acessível por qualquer celular... =) Web 2.0 meu amigos! Chame do que quiser: wikinomics, convergência, web 2.0, futuro, brincadeira de nerd... mas ficou muito bom!!!

http://malditacomedia.mofuse.mobi

Imagens do site:


Caia na Real!!



Fonte: Getting Real (versao pt_BR)

Alguns pensamentos que deveriam nortear todo nosso desenvolvimento (leitura obrigatória se você quiser trabalhar com web):

Execução

Qualquer um pode ler um livro. Qualquer um pode chegar com uma idéia. Qualquer um tem um primo que é um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar alguém para grudar algum código.

A diferença entre você e qualquer um será quão bem você executa. Sucesso tem tudo a ver com uma grande execução.

Para software, isso significa fazer um monte de coisas certas. Você não pode somente ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de interface não vai dar certo se seu código é cheio de gambiarras. Uma grande aplicação não vale nada se promoção pobre significa que ninguém saberá sobre ela. Para pontuar grande, precisa combinar todos esses elementos.

A chave é balanço. Se for longe demais em uma direção, está caminhando para o fracasso. Constantemente procure seus pontos fracos e foque neles até estar nivelado.

Pessoas

Vale a pena enfatizar a coisa que achamos que é o ingrediente mais importante quando falamos em construir uma aplicação web de sucesso: as pessoas envolvidas. Mantras, designs de epicentro, menos software e todas essas idéias maravilhosas não vão realmente importar se não tiver as pessoas certas a bordo para implementá-las.

Você precisa de pessoas que são apaixonadas pelo que fazem. Pessoas que se importam pela seu artesanato – e que realmente acham que é um artesanato. Pessoas que se orgulham do seu trabalho, independentemente da recompensa monetária envolvida. Pessoas que suam nos detalhes mesmo que 95% das pessoas nem saibam distinguir as diferenças. Pessoas que querem construir alguma coisa grande e não se conformam com menos. Pessoas que precisam de pessoas. Ok, não necessariamente essa última coisa mas não iríamos resistir não jogar um pouco de Streisand na mistura. De qualquer forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua equipe farão ou quebrarão seu projeto – e sua empresa.

Mais Que Apenas Software

Também vale a pena notar que o conceito de Caindo na Real não se aplica apenas a construir aplicações web. Uma vez que você começa a tocar nas idéias envolvidas, as encontrará em todos os lugares. Alguns exemplos:

  • Forças de Operações Especiais, como os Boinas Verdes ou Navy Seals usam equipes pequenas e entrega rápida para atingir tarefas onde outras unidades são grandes demais ou lentas demais para cumprir.

  • Os White Stripes abraçam restrições seguindo uma fórmula simples: duas pessoas, músicas enxutas, baterias infantis, manter o tempo de estúdio ao mínimo, etc.

  • O iPod da Apple se diferencia da concorrência não oferecendo funcionalidades como rádio FM embutido ou gravador de voz.

  • No futebol americano, jogadas rápidas ajudam a ganhar terreno rapidamente, eliminando a “burocracia” das jogadas ensaiadas.

  • Ernest Hemingway e Raymond Carver usavam linguagem simples e limpa e ainda assim entregavam impacto máximo.

  • Shakespeare revelou, nas limitações dos sonetos, poemas líricos de catorze linhas em pentâmetro iâmbico.

  • E assim por diante …


Claro, Caindo na Real é sobre construir grandes softwares. Mas não há razão para parar por aí. Pegue essas idéias e tente aplicá-las em diferentes aspectos de sua vida. Você pode acabar atingindo resultados interessantes.

05 novembro 2007

Em busca de uma Empresa Ágil


Success, particularly today, is a function of a team's ability to react to change, not its ability to plan and follow that plan. How teams are measured affects their adaptiveness. Adaptation—rather than adherence—brings success.

Fonte:The Measure Of A Management System


Tenho pensado muito sobre métricas e formas de mensurar progresso em equipes ágeis, e a forma que estas informações se alinham às informações necessárias para a tomada de decisão dos diretores de uma empresa Ágil.
Num post anterior, trabalhei a questão mundana deste tema, isto é, apresentando ferramentas de medição condizentes com o Processo Ágil. Danilo Sato, em sua teste de mestrado, apresenta de forma detalhada outras ferramentas. Vale a pena a leitura!

Mas gostaria de ir além...

A revista Better Software Magazine, apresenta um artigo mostrando de que maneira métricas de progresso devem ser aplicadas para garantir a real avaliação de desempenho para equipe de Desenvolvimento Ágil. Leia o artigo completo.


Fonte: Wikipedia


Dentro Balanced Score Card(BSC), existem 4 perspectivas bem definidas: Financeira, Cliente, Processos Internos e Aprendizado/Crescimento. A figura apresentada inlustra bem a forma como tais perspectivas se comunicam, numa relação de causa-efeito. Empresas privadas que visam o lucro que somos, é natural imaginar que a perspectiva financeira venha à frente de decisões estratégicas. Gostaria de tratar sobre a perspectiva do cliente.

Cliente
Medidas claras focadas a segmentos específicos devem ser apresentadas a toda a organização. Compartilhar a informação em todos os níveis da empresa, e garantir que indicadores de progresso estejam disponíveis é uma forma bastante clara de alinhamento entre decisões estratégicas e iniciativas.
O Feedback contínuo dos representantes destes segmentos é uma maneira de garantir alinhamento e progresso. Como nos Princípios do Desenvolvimento Ágil, software em funcionamento é a primeira medida de progresso. E sendo assim, transformar a satisfação do cliente em um indicador é um grande passo.
Na lista xpRio, Clavius Tales, da Fortes Informática, apresentou os resultados obtidos utilizando XP. Uma ótima medida de progresso utilizada pela equipe do Clavius foi "satisfação do cliente". Os resultados:


Alguns números que podem não dizer muito, mas que me impressionaram: amanhã finalizamos, com vinte dias de adiantamento, um projeto daqui da empresa, que tinha originalmente um prazo previsto de quatro meses e meio. A equipe era formada por onze colaboradores. Monitoramos a satisfação do cliente através de uma nota semanal entre 0 e 10. Na última semana, a nota ficou em 9,88 - chegou a estar em 7,8. Também monitoramos com uma nota entre 0 e 10, só que diariamente, o moral da equipe. A nota atual está em 9,8 - chegou a estar em 7,9. Estamos trabalhando com um nível de 75% de todas as práticas de XP (versão 2).

Um abraço.

Clavius Tales


Para tomar proveito da ligação entre cliente e desenvolvimento, gerando informações válidas para a empresa, é necessário uma intervenção branda através de medidas de desempenho que alimentarão indicadores do BSC.
Uma forma de se fazer isto é através da Análise de Valor Agregado (do inglês EVA), que pode ser adaptado para auxiliar analistas de negócio e diretores a garantir o ROI mais adequado na utilização do Desenvolvimento Ágil.
Nota Importante:Não estou tratando o ponto de vista do patrocinador de um projeto (o cliente), mas da empresa que utiliza o desenvolvimento Ágil como forma de garantir Qualidade, flexibilidade e menor custo.
Definição: "Earned Value Management (EVM) is a method for integrating scope, schedule and resources, and measuring project performance.” Fonte: APM with Scrum
Um artigo muito interessante (e complexo) que trata desta informação foi publicado pelas empresas SolutionIQ e InfoTech: acesse o artigo.
No documento, os autores concluem que a adaptação da técnica de EVM para o Scrum pode trazer resultados semelhantes à análise do Burndown, e deve ser utilizado em conjunto com as ferramentas do scrum, gerando informações importantes sobre releases e adequação orçamental.

Trabalhar com valor de negócio e agregação de valor ao cliente é uma postura bastante diferente do que estamos acostumados em nossos projetos. Para a maior parte das empresas, um projeto no prazo e debtri di orçamento é mais importante do que garantir que os clientes estejam realmente satisfeitos com as soluções promovidas. Isto é preciso ser alterado para que se possa atingir maiores benefícios relacionados ao Desenvolvimento Ágil.

Measurement systems are crucial to creating an agile enterprise, particularly for those projects that implement new products, services, or processes that will create your future company. If you are creating the future, an extra month or a few extra dollars will be insignificant. If you don't deliver value or you don't deliver innovation, that will be significant. We cannot continue to ask teams to be innovative, flexible, and adapt to changing competitive conditions and then measure their performance by forcing them into narrow expectation alleys. We have to be as innovative with our measurement systems as we are with our methodologies.