Por Lygia de Luca, repórter do IDG Now!
Publicada em 29 de junho de 2009 às 07h00
Atualizada em 29 de junho de 2009 às 09h47

São Paulo – Seus horários não coincidem com as ofertas de cursos ou pós-graduações tradicionais? Veja opções 100% online na área de tecnologia.

Muitos profissionais querem se atualizar ou especializar, mas não encontram tempo para fazer cursos presenciais e mesmo os cursos online exigem que o aluno compareça pessoalmente a uma aula comum ao menos semanalmente. Felizmente, algumas instituições oferecem cursos 100% online. Basta abrir um espaço na agenda e se conectar ao conhecimento.

Leia também:
> Mercado valoriza graduação ou curso tecnológico?

No mercado, há ofertas que vão de cursos livres ou de extensão até graduações, pós-graduações e MBAs no Brasil ou exterior. O IDG Now! selecionou 12 opções para que você aprenda temas relacionados à tecnologia direto de sua casa, da praia, do campo e onde mais seu raciocínio funcionar melhor.

Data Center University
Os cursos da Data Center University e da Energy University são voltados a bancos de dados e eficiência energética – em várias áreas -, respectivamente. Os usuários podem acessar todos os cursos por meio de um cadastro em cada site e assisti-los em vídeo. O acesso é gratuito. Em inglês.

FGV Online
A Fundação Getúlio Vargas oferece, aos interessados, o curso de extensão em Gestão da Tecnologia da Informação. Com carga horária de 30 horas, o treinamento aborda a criação de estratégias e planejamento na área de TI. O valor é de 680 reais.

Harvard University
A instituição norte-americana mundialmente reconhecida também possui opções de cursos online, da introdução à Ciência da Computação a design de software e computação paralela. Os preços variam. Em inglês.

Linux Online
Gratuitamente, o site Linux Online ensina os interessados no sistema operacional de código aberto do nível básico ao avançado, em inglês. Para quem não fala o idioma, o Linux Brasil também criou cursos online em português que custam entre 15 e 25 reais para incentivar o uso de software livre no Brasil.

MIT
O Massachusetts Institute of Technology oferece gratuitamente diversos cursos com temas de tecnologia. As áreas incluem Ciência da Computação, Engenharia Elétrica e mistos de tecnologia com sociedade e saúde. Os materiais para download incluem textos, áudios e vídeos. Em inglês.

News University
A Universidade online voltada a jornalistas possui cursos, gratuitos e pagos, que também podem interessar aos profissionais de tecnologia. Temas como web semântica e arquitetura de redes sociais estão entre as ofertas da News University. Em inglês.

Postado por Abel Avram, traduzido por André Dourado em 24 Jun 2009 02:26 PM

Muitos se perguntam por que a Microsoft está dando um tratamento diferenciado para o VB.NET comparado ao C#, por que desenvolvedores VB.NET recebem menos que desenvolvedores C# e se eles devem se preocupar com seu futuro ou não. Em um podcast, Lisa Feigenbaum, gerente de projetos no grupo de linguagens gerenciadas .NET, garante à comunidade VB.NET que o VB definitivamente tem futuro.

Lisa explicou porque VB.NET e C# tem tido uma percepção diferenciada: foi uma decisão estratégica da Microsoft em primeiro lugar. Microsoft não apenas quer duas linguagens com duas sintaxes diferentes rodando no CLR, mas eles quiseram que fossem diferentes em seus recursos, então as duas linguagens seguiram em diferentes caminhos no mundo .NET. Desde que a maioria da documentação relacionada saída da Microsoft contém exemplos em C# e menos exemplos em VB.NET, todos concluíram que o VB.NET é menos favorecido e possivelmente morrerá com o tempo, não tendo suporte suficiente.

De acordo com Lisa, no início a Microsoft tentou diferenciar as duas linguagens, implementando diferentes recursos em cada uma delas, mas muitas vezes clientes VB.NET solicitaram tem recursos disponíveis para o C#, enquanto clientes C# desejaram recursos disponíveis no VB.NET, portanto no final uma decisão foi tomada para manter ambas em sincronismo. Também, o número de desenvolvedores VB.NET é um poucco maior que os desenvolvedores C# e a Microsoft não matará o VB.NET porque não é do interesse deles fazer isso. Esse comprometimento foi reforçado quando dois times de arquitetos foram reunidos por 18 meses com o objetivo de co-desenvolver as linguagens.

Anders Hejlsberg, Arquiteto Chefe para o C#, supervisiona o desenvolvimento de ambas linguagens para garantir seu progresso. Após a decisão sobre alguns recursos a serem implementados para C# e VB.NET, os respectivos times de desenvolvimento são separados em ambientes distintos, para que possam desenhar a implementação dos recursos, de acordo com a sintaxe e regras gerais de cada linguagem. Este processo apresenta dois resultados: as linguagens mantém a adição dos mesmos conjuntos de recursos e as linguagens mantém sua personalidade e não necessariamente tentam copiar o modo que a outra é implementada. Isto garante que o VB.NET não será eventualmente absorvido pelo C#.

As linguagens estão rapidamente convergindo. No momento, as únicas aplicações que podem ser feitas em C# e não podem ser feitas em VB.NET são jogos XNA, porque não há templates de projetos para o VB.NET. Mas a Microsoft deseja encerrar completamente esse gap, de forma que as duas linguagens se tornem completamente iguais.

Os resultados do esforço conjunto serão vistos mais claramente na próxima versão do Visual Studio. VS foi inciado inicialmente em C, C++, mas o editor e compilador do VS 2010 conterá mais código gerenciado que antes, isto significa mais código C# e VB.NET. Nem o VS ou Office iniciaram tendo tanto código gerenciado do dia para a noite porque existe uma imensa quantidade de código valioso já escrito, mas códigos novos geralmente são códigos gerenciados.

O fato que alguns estudos mostram que desenvolvedores VB.NET são pagos de 10-15% menos que seus colegas desenvolvedores C#, pode ser decorrente do fato que a percepção sobre VB.NET ainda não mudou o bastante e mais tempo ainda é necessário para que se perceba que estas linguagens são iguais e são tratadas da mesma forma pela Microsoft.

Fonte: InfoQ

Postado por André Pantalião em 23 Jun 2009 03:17 PM para o InfoQ

Este post é um relato da apresentação feita no Scrum Gathering Brasil.Esta apresentação foi feita por Boris Gloger, alemão muito famoso na cena do Scrum e responsável pela formação de muitos CSMs no Brasil. Ele dispensa apresentações, excelente conteúdo, algumas tiradas engraçadas e com ótimos slides, vale a palestra!

Mais do que 6 segredos, ele passou por diversos aspectos importantes em uma retrospectiva. Foi uma apresentação que explorou bem este assunto importante para que a equipe evolua, mas um assunto nem sempre valorizado.

O que é retrospectiva?

Retrospectiva é o processo de aprender com o passado para o futuro. As retrospectivas não eram parte do Scrum em seu início, mas em 2004 virou uma prática. Diversos profissionais fazem este tipo de procedimento após uma ação: bombeiros fazem a "Ater Action Review", militares fazem o "debriefing", só para citar alguns exemplos.

Quando não se está usando o Scrum corretamente ou quando não se tem tempo suficiente, a primeira coisa que param de fazer é a retrospectiva. Mas esta sessão é fundamental para a melhoria. Na palestra anterior, Rodrigo de Toledo também concorda com isto, afirmou que se fosse para escolher o mínimo que um processo de desenvolvimento deveria ter, seria o fato de ser iterativo e fazer retrospectivas.

Uma objeção comum a estas sessões de retrospectiva é a de que estamos muito bem, não precisamos melhorar. Mas na verdade, nas retrospectivas devemos achar o que fazer para não deixar chato, para que não parem de continuar fazendo bem as coisas. É uma boa oportunidade para pensarmos em qual é o nosso próximo passo importante, para onde vamos.

O que é aprendizado?

Antes de continuar, Boris conceituou o que é aprendizado. E levantou as seguintes questões:

Porque os adultos param de aprender? Crianças ainda aprendem, é engraçado para elas. Um bom exemplo disso é o segredo da gravidade. Quando a criança fica jogando insistentemente uma colher ao chão, ela está aprendendo o que é gravidade. Primeiramente, a criança aprende com a repetição.

Depois, ela aprende com o desapontamento da expectativa. E isto acontece com os balões de gás. A criança solta o balão achando que vai acontecer a mesma coisa que aconteceu com a colher, mas não! O balão vai para o alto! Quando ficamos desapontados, aprendemos. Quando somos adultos, ao invés de nos desapontarmos, culpamos o ambiente, os outros e paramos de aprender.

É importante que as pessoas tenham segurança psicológica para termos uma boa retrospectiva. É preciso que as pessoas certas estejam presentes, sem inimigos, para criarmos um ambiente de segurança psicológica. Quando as pessoas tem metas altas e segurança psicológica elas estão em uma zona de aprendizado. Se tiverem metas altas e baixa segurança psicológica ficam ansiosas. E com alta segurança e baixas metas temos uma zona de conforto.

Chame o médico!

A retrospectiva é como um diagnóstico. Você usa uma ferramenta para examinar o que o paciente tem. Uma mãe ao ver que um filho está gripado, muitas vezes além do diagnóstico dá uma bronca no filho por ter andando descalço, ter tomado coisas geladas e não ter ouvido ela. Ela faz o diagnóstico e a bronca. Na retrospectiva, devemos nos comportar como o médico, imparcial, fazendo o diagnóstico e querendo saber o que acontece. A melhor ferramenta para a retrospectiva é o próprio time conversando, sentando junto e vendo como pode melhorar.

Como executar uma retrospectiva?

Conte histórias. Use histórias para transmitir acontecimentos do passado para o futuro. O time deve contar histórias para o próprio time. Contando "causos" do passado para garantir que a mensagem seja transmitida.

Tome cuidado. Os adultos começam a culpar as pessoas. O facilitador da retrospectiva deve garantir que o time entende que não é para procurar culpado. Um excelente livro sobre o assunto é Project Retrospectives. Independente do que seja descoberto, nós devemos entender e realmente acreditar que todos fizeram o melhor trabalho que podiam, dado o que sabiam no momento, de acordo com seus conhecimentos e habilidades.

Conte Histórias Observe e colete fatos do passado:

• Faça o timeline do que aconteceu no sprint, enumere fatos importantes.
• Colete artefatos do passado.
• Ou faça algum tipo de jogo, que toque no assunto do que aconteceu.

What Went Well? (O que foi bem?)

Não é só para vermos o que estava errado no passado, mas sim, levantar o que queremos manter. Enquanto facilitadores, devemos fazer com que o grupo olhe para o passado e enxergar o que queremos manter.

O que queremos mudar para o futuro?

Após o que foi bom, vamos focar no futuro. Pegue todas as idéias que o time tenha para melhorar. Então, divida as idéias entre responsabilidades do time/scrum master e prodruct owner / empresa. Ordene estas idéias do mais importante para o menos importante. É recomendada a criação de um plano de ação.

O sprint planning é um bom ponto de partida para as idéias de melhoria do time. Mas as melhorias então vão sempre para o backlog? Não! O Time decide! O time vai fazer aquilo que achar correto.

Mas o que será melhorado? Quem define? O time melhora o que eles queiram melhorar.

Mas e se a melhoria que eu criei impacta mais alguém? o que eu faço? Converse!

Resumindo o que deve ter em uma retrospectiva

• Crie segurança para o time
• Conte uma história sobre o que aconteceu
• O que foi bem?
• O que foi ruim? Divida entre empresa e time.
• Priorize o que será feito.

Muitos fazem a retrospectiva fora da empresa, não é fundamental isto, mas não faça no local de trabalho do time. E não deixe a retrospectiva durar muito, deve durar menos de 90 minutos. Se quiser sessões maiores, é importante que ela seja bem preparada.

E quem participa da retrospectiva? Quem o time quiser. Se ver que uma retrospectiva não vai bem, veja se não tem que é de fora do projeto.

E por fim, o Scrum Master precisa agir, tem que fazer isso acontecer. O Scrum Master deve agir se ver que algo não dá certo.

Concluindo…

Uma retrospectiva deve ser divertida. Mude, inove, troque o local. Tem que ser algo divertido! Fique atento porque muitas vezes as pessoas estão assustadas de culturas que não as deixam aprender .

Fonte: InfoQ

Para quem ainda não viu o viral do N96 com a lenda Bruce Lee.

O motivo do vídeo é a edição especial do aparelho que foi lançada na China. Para chamar a atenção do público, gigantesco, diga-se de passagem, nada melhor que um ídolo do povo chinês e do mundo. O viral já teve milhares de visualizações desde o seu lançamento em Novembro/2008.

Postado por Amr Elssamadisy, traduzido por Samuel Carrijo em 19 Jun 2009 11:46 AM

Joshua Kerievsky iniciou uma discussão no grupo Refactoring do Yahoo! com o seguinte post:

Nos últimos anos tenho ouvido algumas pessoas dizerem que só se deve refatorar quando se está trabalhando em uma história com esse propósito. Eu nunca concordei com essa noção, pois penso que há momentos em que você simplesmente precisa pagar parte do débito técnico. Durante vários dias, eu e os meus colegas temos refatorado nosso código de eLearning. Não há nenhum história associada a essa atividade. Nós simplesmente estávamos com um débito técnico maior do que gostaríamos, e consideramos agora como uma boa hora para pagá-lo. Havia um Singleton pernicioso que desempenhava um papel central no nosso código e agora estamos eliminando-o, porque isso irá permitir muito mais melhorias de design no nosso código. Nos sentimos bem fazendo esse trabalho. Ele irá nos deixar numa posição muito mais fácil para trabalhar nas novas histórias.

Entretanto, nós continuamos entregando algo toda semana – poucas correções e muitas refatorações. Como sempre, os nossos microtestes automatizados e testes de história nos ajudam a ter bastante confiança e coragem.

Enfim, eu gostaria de compartilhar isso, uma vez que pode levar a uma discussão interessante.

Dale Emery tentou se esclarecer sobre o contexto em que Josh estava inserido:

Dale: Eu suspeito que os conselhos gerais existem para desencorajar o pessoal técnico a tomar decisões de negócio. A decisão de pagar débito técnico exige uma sólida compreensão dos impactos técnicos e no negócio. Se os tomadores de decisão não tem um conhecimento sólido de ambos, a decisão torna-se pouco confiável. O seu é um caso especial em que esse perigo é reduzido.

Josh: Sim, o nosso caso é especial. No entanto, eu diria que geralmente é uma coisa muito boa que o pessoal técnico e de negócios trabalhem em estreita colaboração, de tal forma que este tipo de decisão relacionada a débito técnico seja comum a todos. E sim, nós não queremos incentivar os desenvolvedores a simplesmente decidir gastar várias semanas refatorando sem nenhuma que haja uma decisão conjunta dentro da comunidade relacionada ao projeto.

Dale: Parece-me (corrija-me se as minhas hipóteses estiverem erradas) que seu cliente é altamente técnico, e muitos, se não a totalidade, do seu pessoal técnico compreende o seu negócio a fundo. Além disso, o seu cliente é você. Quando você toma a decisão de pagar o débito técnico, você está fazendo isso com pleno conhecimento do impacto no negócio e, provavelmente, devido ao seu pleno conhecimento do impacto no negócio.

Josh: Sim, a decisão de pagar o débito técnico agora, é impulsionada por

• timing – acabamos de entregar um release muito importante para o nosso maior cliente, e é hora de sair um pouco do "trem das funcionalidades".
• futuro – temos mais funcionalidades por vir e uma experiência prática com este código diz que o débito técnico só nos deixará mais lento.
• linguagem ubíqua – nós temos uma metáfora musical maravilhosa no nosso código e … ainda há alguns remanescentes da nossa metáfora anterior (livros) espalhadas pelo código.

Com esse entendimento do contexto de Josh (e, mais ainda, ao longo de toda essa longa discussão) Adam Sokra sugeriu:

Então. Você não está trabalhando com iterações fixas. Você desenvolve incrementalmente e lança com a maior frequência possível. Às vezes você tem um conjunto de histórias nas quais você está trabalhando, e tenta entregá-las rapidamente aos clientes. Outras vezes você está apenas tentando melhorar o design do que você tem. Você é tanto o cliente quanto um programador.

Isto parece muito com os bons projetos open source que já encontrei, e muito pouco com qualquer projeto Scrum ou XP. Eu não acho que haja algo de errado com o que você está fazendo, mas não sei se é muito útil para as pessoas que estão tentando entender como fazer refatoração em um contexto ágil.

Um dos principais conceitos de Scrum e XP é que estamos num jogo das necessidades de pessoal de negócios (não-técnicas) contra as necessidades da time (técnicas). Queremos ter certeza de que as coisas técnicas são feitas de forma proficiente, mas também queremos maximizar o controle que o negócio tem sobre o que é produzido, e quando é produzido.

O que você está descrevendo é um ambiente em que esta dicotomia não existe. Você é livre para decidir quais funcionalidades você deseja adicionar, quando você deseja adicioná-las, e quando fazer uma pausa na entrega de funcionalidades para concentrar-se em questões puramente técnicas.

Então, Adam sugeriu que o contexto de Josh é bem diferente da maioria dos projetos; sendo a diferença mais importante a ausência da disputa de comunicação, compreensão, e prioridades nos aspectos técnicos e não técnicos.

Ron Jeffries sugeriu que a quantidade de refatoração que devemos fazer é uma decisão de negócios. Refatoração é um investimento que não tem valor de imediato. Ele também discorda de que seja uma decisão binária: "não refatorar nada" ou "parar e refatorar":

Há uma hipótese aqui que precisa ser explicitada: a de que, de alguma forma, às vezes é melhor parar ou "avançar lentamente" para limpeza.

Parece óbvio para várias pessoas que tal coisa pode acontecer, que o código pode ficar tão ruim que a única opção que se tem é limpá-lo, após interromper ou reduzir o progresso na criação de funcionalidades.

Isso não é óbvio para mim. Os números não batem. Quando limpamos o código, o retorno disso só vai ser visto no futuro. Alguns podem ver esse retorno amanhã, e alguns podem não ver esse retorno por semanas ou meses. Em nenhum caso, o retorno é visto de imediato.

Toda refatoração que atrasa a evolução das funcionalidades é um investimento no futuro. O que precisa ser descoberto é se, como e quando, esse investimento vale a pena.

Ron então sugere uma maneira de determinar quando a refatoração é um investimento que vale a pena:

Quando é melhor [refatorar], e por quê? Existem muitos caminhos possíveis para o futuro, que levam ao aumento do valor das funcionalidades ao longo do tempo. Podemos descrever dois deles:

1. Não refatorar. O valor das funcionalidades cresce cada vez mais lentamente, talvez até mesmo comece a diminuir quando a injeção de erros superar a injeção de funcionalidades.

2. Parar o desenvolvimento de funcionalidades e refatorar. O valor das funcionalidades PARA DE CRESCER, por um tempo. Depois, ele começa a crescer novamente. Assumimos que, uma vez que agora o código está melhor, vai crescer mais rapidamente do que antes. No entanto, a necessidade de funcionalidades aumenta, e haverá um intervalo antes de compensar o tempo gasto na refatoração. Depois disso, assumimos que vamos começar a desenvolver mais rapidamente do que se não tivéssemos feito nenhuma refatoração.

Então o que podemos concluir, comparando esses dois casos? Em primeiro lugar, a decisão de não refatorar resulta no lançamento de mais funcionalidades por algum tempo, mas em menos funcionalidades no longo prazo. Em segundo lugar, para saber quando começa a valer a pena refatorar, precisamos saber alguns números: quanto tempo vai levar a refatoração, e qual será o seu impacto na velocidade? E, quanto tempo levará até que o código fique ruim novamente, o que por sua vez resultará na redução da velocidade?

É inteiramente possível parar, refatorar, atrasar algumas funcionalidades, e acabar piorando o código, ficando em um loop eterno, sem nunca perceber nenhum benefício. Esperamos que isso seja improvável … e é, se as pessoas forem suficientemente qualificadas … o que faz parte do meu ponto acima, que o seu conselho é bom para os experts.

No entanto, estes dois pontos finais mostram que a própria estratégia de parar e refatorar pode falhar. Existe outra estratégia que pode funcionar melhor? Existe.

Vamos imaginar uma espécie de "acelerador de refatoração", AR. No caso 1, foi de AR=0, não refatorar. No caso 2, foi setado para AR=1. O que acontece com as configurações entre esses dois valores?

Antes de tudo, como o valor das funcionalidades se dá em função do AR? Existe algum número x, com 0 < x <1 tal que, se AR < x, o aumento do valor das funcionalidades sempre diminui. Nós não estamos refatorando suficientemente, o código se deteriora, perdemos cada vez mais. Com AR = x, o aumento do valor das funcionalidades permanece constante. Nós não aumentamos, nem diminuímos a velocidade.

Agora, se estabelecermos o acelerador de refatoração acima de x, RA> x, o que acontece? Podemos ir mais rápido, ou será que sempre ficaremos mais lentos? Sabemos que em um ponto, RA = 1, a velocidade vai para zero (mas podemos acelerar mais tarde).

A resposta depende do formato da curva da velocidade em função da limpeza do código. Sabemos que uma limpeza conduz a uma maior velocidade, e (eu acho) sabemos que os primeiros esforços para limpeza tem um bom efeito proporcional, enquanto os esforços nos "detalhes de polimento" não acrescentam muito.

O que eu acredito que pode acontecer … e não há absolutamente nenhuma prova de que não pode acontecer … é que, deixando o AR apenas um pouco acima de x, aumentamos cada vez mais a criação de novas funcionalidades. Se isso for verdade, então esta estratégia vai entregar valor uniformemente mais rápido do que a estratégia de parar para refatorar.

Portanto, se isto for verdade – e eu tenho convicção de que seja – a estratégia de parar para refatorar nunca é o melhor um para um time experiente em refatoração.

O ponto-chave que Ron coloca aqui é que a estratégia de "parar e refatorar" NUNCA é a melhor escolha para um time competente em refatoração.

Este longo relatório é apenas um vislumbre de um debate muito envolvente. Esta não é uma nova questão, como Josh explica no início da conversa. Na realidade, este repórter escreveu um editorial sobre o assunto chamado Refatoração é um desperdício necessário dois anos atrás, e o tema de refatoração foi coberto pela InfoQ em múltiplas ocasiões. A comunidade não chegou a um consenso sobre este tema.

Fonte: InfoQ

Já devem estar disponíveis há algum tempo, mas descobri somente hoje. A LocaWeb disponibilizou na web edições antigas e atuais da Revista LocaWeb.

As edições podem ser encontradas em: http://locaweb.digitalpages.com.br/home.aspx

Daniela Moreira, de INFO Online
15 de junho de 2009

Jogo da Intel simula os desafios do dia-a-dia de um gestor de TI em terceira dimensão

Como é estar na pele de um gerente de TI, tendo que lidar com orçamentos, investir em inovação, combater ataques virtuais, contratar e demitir e garantir treinamento e suporte adequados aos funcionários de uma companhia?

Agora você já pode viver essa experiência no simulador em terceira dimensão IT Manager Game 3.0, desenvolvido pela Intel.

O jogador tem como meta tornar a empresa virtual lucrativa e bem sucedida, decidindo quais são as tecnologias que cada funcionário deve utilizar e como elas vão ajudá-los a desempenhar melhor suas funções.

Desafios como ataques de vírus e incidentes que exigem a gestão de equipes podem aparecer no meio do caminho e o grau de dificuldade vai aumentando conforme o jogo evolui e empresa cresce.

O jogo já está disponível em 14 países e 12 idiomas diferentes, incluindo português. Desde a estreia da versão beta, em novembro de 2008, o simulador já atingiu aproximadamente 1 bilhão de pageviews.

Segundo a Intel, são mais de 20 mil jogadores registrados, na maioria profissionais e estudantes de TI, que jogam em média 38 minutos cada um. Estados Unidos, Inglaterra, Turquia e Rússia são os países com o maior número de jogadores.

É possível acompanhar, em tempo real, o ranking dos líderes do jogo e a lista das empresas virtuais mais lucrativas.

O IT Manager Game 3.0 é gratuito e para jogar basta cadastrar-se neste endereço: http://www.nextgenerationcenter.com/email/2404-itmangIII/port/itmgr3.html

Fonte: Info Professional

Postado por Mike Bria, traduzido por Marcus Rehm em 12 Jun 2009 01:25 PM

As vagas estão quase encerradas para os próximos cursos dos respeitados mentores do movimento Ágil Jim Shore e Diana Larsen , e a InfoQ conseguiu a oportunidade de conversar com Jim enquanto ele se preparava. Em uma entrevista casual, Jim falou sobre alguns tópicos como seu livro Art Of Agile, implementações erroneas de agilidade e como o Kanban não deve ser encarado como o ponto principal.

Primeiramente InfoQ perguntou sobre seu livro Art Of Agile, de co-autoria com Shane Warden, qual a sua importância e o que os leitores devem esperar ao lê-lo. Jim explicou que muitas das matérias introdutórias, como as relacionadas a Extreme Programming, focavam mais em "inovação e novos adeptos", enquanto seu livro foca em uma abordagem mais pragmática para a grande maioria que busca ingressar na agilidade. Jim descreve como o conteúdo do livro surgiu:

Esse livro é realmente uma síntese de minhas experiências com equipes, as quais apliquei XP no início e então partes do Scrum, porque muitas destas equipes já conheciam estas práticas. Além disso, introduzi também alguns conceitos de Lean. Tudo isso culminou em um modelo semelhante a Teoria das Restrições de Eli Goldratt que assemelha-se ao Lean. Finalizando, nós falamos sobre a série Agile Testing Directions de Brian Marick.

Mais informações sobre o livro podem ser encontradas nesta entrevista filmada na conferência Agile 2007.

InfoQ conversou com Jim sobre sua percepção de que a adoção de métodos ágeis estã crescendo de forma errada, como visto nos seus artigos Stumbling Through Mediocrity (Tropeçando na Mediocridade) e Decline and Fall Of Agile (Declínio e Queda da Agilidade). Resumindo sua observação, ele diz:

As pessoas estão dizendo, "Queremos ser ágeis", e então buscam a forma mais barata e rápida, e como resultado, esta transformação não estão tornando a vida delas nada fácil. Em muitos casos, estão tornando a vida pior.
…
O que eu vejo é que a palavra ágil se tornou um jargão, e agora "ser ágil", tornou-se o objetivo. Porém, se "ser ágil" é o objetivo, você pode simplesmente fazer qualquer coisa, por mais anormal que seja, colocar a palavra "ágil" e declarar sucesso, mas sem realmente ter feito nada que melhorasse a forma de trabalho. O objetivo do movimento ágil não é "se tornar ágil", mas sim produzir sistemas que tenham valor e que façam o que se propõem de maneira eficaz, flexível e humana.

Quando nós perguntamos o que a comunidade ágil pode fazer para melhorar a situação e Jim respondeu:

Precisamos parar de dizer que "ser ágil" é fácil. Precisamos dizer que "ser ágil" é ser eficaz, é ser poderoso e assim, poderemos ter valor, porém isso não é necessariamente fácil. Na verdade, é difícil. Éuma mudança organizacional e qualquer mudança organizacional é difícil.

Durante a conversa sobre a tendência na qual a metodologia ágil estão sendo aplicada sem realmente ser entendida ou utilizada em todo seu potencial, o tópico sobre Kanban apareceu. Jim explicou que acha o Kanban uma ótima ferramenta, mas se preocupa demais com o foco excessivo dado a tal ferramenta e pensa que desse jeito podemos estar perdendo a ideia principal proposta no Lean:

Eu acho o Kanban uma ideia interessante, e uma ferramenta excelente… porém, As Ideias de Desenvolvimento de Softwares baseadas no Lean  trazidas do Sistema de Produção Toyota para o mundo ágil [inicialmente por Mary e Tom Poppendieck], propõem muito mais do que apenas uma maneira de se planejar o trabalho, o que é, a grosso modo, a ideia do Kanban. Coisas como "Fluxo Contínuo" e a filosofia de melhoria [uma "Cultura de Aprendizado"], e eliminação de desperdício são outros conceitos. Penso que o Kanban é apenas uma das ferramentas usadas para criar o ambiente de Fluxo Contínuo. Este cenário seria similar a adotar XP e Scrum, porém se preocupando apenas com o planejamento.

Muitos dos defensores do Kanban dirão "Não, o Kanban é uma filosofia" e para estes eu pergunto "Por que não falar sobre Lean então"? Porque nós já possuí­mos uma filosofia no Lean e ela se ajusta perfeitamente na metodologia ágil.

Se vamos usar o Kanban, então não usemos apenas o Kanban, Vamos usar toda a filosofia Lean, pois esta se ajusta perfeitamente a metodologia ágil.

Quando questionado sobre o que mais ele acha interessante no Lean, Jim encerra nossa conversa dizendo:

Quando li pela primeira vez o livro do Poppendieck pensei: "Finalmente, aqui estão algo que explica o porque de estarmos fazendo tudo isso focado em agilidade". Claro que o Manifesto ágil possui principios importantes, mas ao meu ver, Lean traduz estes conceitos de uma forma melhor. Coisas como porque nos preocupamos em manter nosso leque de opções em aberto e cuidado em entregar frequentemente algum pacote. Lean provê uma otima explicação para isso.

Se você está interessado nas ideias de Jim sobre agilidade, considere algum dos cursos Art of Agile Planning & Delivery que ele e Diana Larsen estão oferecendo entre 8 e 12 de Junho.

Fonte: InfoQ

Postado por Juan Bernabó para o Blog teamware blog
em Maio 27, 2009

Depois de ouvir o podcast de Ricardo Vargas, Chairman do PMI, sobre Agile Project Management ficou claro que será necessario um trabalho grande para continuar desmistificando Scrum e Agile, agora não porque não exista interesse ou demanda para adoção, o que acontecia há muitos anos quando tivemos a coragem de começar fazer os primeiros treinamentos de scrum no país, justamente pelo contrário.

Como o interesse esta crescendo, um dos aspectos que podem ser banalizados mais rapidamente, é de que para poder usufruir dos benefícios de Scrum e Agile, é necessário uma mudança de paradigma, e é esse nosso principal desafio.

Eu vejo com muito bons olhos que aqueles que de alguma forma tem pautado suas carreiras a gestão de projetos (os gestores de projetos) e são associados do PMI, e tem um objetivo de avançar a ciência da gestão de projetos, possam começar a ser expostos a métodos inovadores de gestão como Scrum, que tenho certeza vai aumentar muito o valor da sua caixa de ferramentas, porem minha experiencia me diz que temos que tomar cuidado com um aspecto fundamental.

Alguns desafios pela frente

Gestores de projetos sobre tudo que passam numa certificação onde existem perguntas extremamentes claras sobre qual deveria ser a forma de pensar correta sobre um assunto, vão provavelmente manifestar uma elevada taxa de concordância sobre algumas premissas fundamentais, certamente entre elas existirá diferente capacidade ou habilidade porem algumas crenças, verdades e premissas fundamentais serão similares.

Muitos dos gestores que tenho feito coaching, e tinham recebido treinamento formal em gestão tradicional de projetos, apresentavam mais o menos a mesma forma de pensar sobre ser possível ou não detalhar todas as atividades de um plano de projeto para desenvolvimento de software.

O que tenho visto, é que existe um gap entre o discurso e a prática, ou seja as teorias esboçadas e as teorias em uso tem divergencias muito grandes e isso pode ser a causa de muitos problemas, como a falta de reflexão sobre alguma premissa fundamental, e assim a falta de aprendizado.

Peter Senge, autor do livro A Quinta Disciplina, fala que o problema das organizações não é que não conseguem resolver os seus problemas, o problema é não conseguir “enxergar” seus problemas, o seu paradigma os cega.

Como as teorias aprendidas acabam sendo reforçadas, já que são as respostas certas para exames de certificação, elas passam a ser tratadas como “verdades” e como Scrum e Agile partem de premissas em alguns casos opostas da gestão tradicional, é necessário quebrar a ilusão que foi criada, para permitir o aprendizado de uma ferramenta que tem como premissa outras “verdades” que conflitam com aquelas adquiridas anteriormente.

O nosso trabalho tem sido basicamente nos últimos anos, criar duvida suficiente das “verdades” aprendidas, porém que estão criando problemas não deixando as pessoas conseguirem olhar para a realidade e refletir sobre os problemas que estão tendo realmente.

Conceitos para complementar o podcast do Ricardo

Aqui vão alguns comentários sobre o podcast que creio que podem ajudar a entender melhor e complementar o que Ricardo disse.

Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja, imaginem algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção rapidamente sem muito esforço.

Então a rapidez na verdade não é o objetivo de Scrum e sim reduzir a massa.

Para poder ser ágil e flexível será necessário reduzir a massa, ficar mais enxuto, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento até o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean – Toyota – Just in Time) para poder responder a mudanças sem stresse.

O desafio para quem passou por treinamento formal em gestão tradicional de projetos será poder re-avaliar as premissas e crenças fundamentais, digo isto depois de ter reciclado centenas de pessoas formalmente treinadas em gestão de projetos tradicionais, não como uma hipótese e sim como um fato, nosso maior desafio é como o que tive com orientação a objetos há uns 22 anos atrás, mudar o meu paradigma (o sistema de verdades, crenças e premissas) que lamentavelmente nós humanos não fomos projetados para mudar muito frequentemente na nossa vida.

Existem milhares de implementações meia boca de Lean, existem milhões de analistas e desenvolvedores OO que programam em linguagens OO porem continuam pensando de forma estruturada, como eu já vi esta historia varias vezes o desafio maior é que não tenhamos milhares de PMPs usando Scrum sem mudar o seu paradigma, sem realmente conseguir retirar todo o valor da ferramenta já que para poder retirar a maior quantidade de valor é necessário pensar diferente.

Uma pergunta para develar uma premissa

No Scrum Gathering apos a palestra do Ricardo Vargas, eu Juan Bernabó, acabei fazendo uma pergunta chave, conhecendo as premissas dos gestores tradicionais eu fiz só uma pergunta para tentar entender melhor se o discurso era um discurso de quem tinha passado por um entendimento profundo, mudança de paradigma, ou simplesmente de quem ainda so conhece os artefatos mais não as premissas fundamentais de Scrum.

A pergunta foi “O PMI parece ser muito centrado no papel do gestor de projetos, certo? Porem o PMI esta preparado para um mundo de equipes auto-geridas?”

O Ricardo contesto de forma totalmente transparente uma “verdade” que ele tem “experimentado” e que se eu não tivesse tido tanta experiencias reais com Scrum também teria, ele disse que a idéia de equipes auto-geridas é romântica, mais nunca viu uma funcionando direito, logico sem Scrum e Ágil eu vi uma porem era uma raridade.

Eu já transicionei mais de 80 equipes auto-geridas, por isso tenho plena convicção, porem sem essa experiencia seria difícil ter tanta certeza, sobre todo quando usamos processos que não estão ajustados para a auto-gestão, e que os ciclos de controle são muito grandes.

Pela primeira vez com Scrum tenho a oportunidade de criar em larga escala equipes auto geridas, que se comportam relativamente dentro de parâmetros, e que tem um resultado muito superior a qualquer outra forma de organização que eu já tinha visto.

Pela resposta do Ricardo deu para entender que ainda não foi exposto e ainda precisara passar por uma mudança de paradigma.

Por exemplo da para entender claramente o que um gestor tradicional acredita sobre times auto gerenciados, como ele nunca viu funcionando de forma eficaz então deve ser porque é necessário um time extremamente maduro.

Porem a auto gestão só é possível não porque as pessoas são muito maduras, mais porque usamos de alguns mecanismos que permitem que um grupo de pessoas normais (na media) tenham comportamentos emergentes (do sistema) inteligentes, isso se chamam gestão empírica com ciclos curtos (2 a 4 semanas), equipe holística sem papeis que permite que os pares possam se auto-regular, e feedback binário e concreto através da demonstração de produto pronto que é facilmente verificável, que passa nos testes de aceitação automatizados por exemplo.

Scrum nada mais é do que o nosso velho amigo o PDCA levado extremamente a serio por exemplo, 1 dia de Sprint “Planning” (Plan), 8 dias de “Sprint” (DO), 4 hrs. de Sprint “Review” (Check), e 2 hrs. de Sprint “Retrospective” (ACT).

O controle na gestão empírica não esta no processo e sim em definir claramente a entrada (item do backlog) e verificar rigorosamente a saída (features prontas testadas), e não mexer no processo durante o momento onde o processo esta executando (Sprint), só ajustar o processo depois de verificar a saída (ou seja no Sprint Retrospective).

A outra diferencia é que o papel das equipes mudou de co-adjudantes para papeis principais, elas planejam taticamente no Sprint Planning, e melhoram seu processo no Sprint Retrospective ao invés de simplesmente executar planos planejados por algum gestor, e ver seus processos melhorados por alguma área ou responsável por processos.

Como vemos Scrum esta sendo bem aceito inclusive na comunidade de gestão de projetos tradicional, logico não sem algumas preocupações, o papel do gestor de projetos como o conhecemos em Scrum muda de forma radical, PM irão precisar adquirir novos skills, novas formas de pensar, é muito mais legal e interessante do que assustador, porem precisa se ter consciência que para termos resultados no mundo ágil uma transição será necessária.

Já hoje e mais no futuro o que ira agregar valor é ser aquele facilitador que saberá criar o ambiente certo e os processos certos para que equipes possam se auto-gerir, um profissional com estas habilidades nunca deixara de ter valor no mercado.

Boa noticia

Donella Meadows fala em seus 12 pontos de alavanca para intervir num sistema
que o paradigma é um dos mais fortes, porem mais forte do que o paradigma é o poder de transcender a paradigmas, como a física clássica não deixou de ser útil nem perdeu validade com o advento da física quântica, a gestão tradicional e muito do seu corpo de conhecimento não perdeu relevância o problema é tentar usar uma única ferramenta (paradigma) para tentar resolver todos os problemas.

Fonte: teamware blog

Por Marco Mendes para o Blog do Marco Mendes
em 10 de Junho de 2009

A maioria de nós já ouviu falar da eficência da Toyota, que já assumiu o posto de primeira montadora de carros do mundo. Entretanto, é ainda mais interessante estudar os princípios que norteiam esta eficiência, chamados de manufatura enxuta. São sete os seus princípios, que focam na redução do desperdício:

• Superprodução: a maior fonte de desperdício.
• Tempo de espera: refere-se a materiais que aguardam em filas para serem processados.
• Transporte: nunca geram valor agregado no produto.
• Processamento: algumas operações de um processo poderiam nem existir.
• Estoque: sua redução ocorrerá através de sua causa raiz.
• Movimentação
• Defeitos, produzir produtos defeituosos significa desperdiçar materiais, mão-de-obra, movimentação de materiais defeituosos e outros.

Em 2004, dois computatas (Mary e Tom Poppendieck) adaptaram este processo para o contexto da engenharia de software, criando um conjunto de 22 “ferramentas” que promovem o aumento da eficiência de projetos em TI. Estes princípios foram batizados como “Desenvolvimento Enxuto de Software”.

Eliminação de Desperdícios

Comento aqui sobre o princípio da eliminação de desperdício através da remoção de atividades e produtos que não geram valor para o cliente. Alguns exemplos incluem:

• Requisitos folheados a ouro. A XP Conference de 2002 mostrou que quase metade das funcionalidades de um sistema não é usada. Funcionalidades não usadas implicam em desperdício. Uma forma de combater este mal é fazer perguntas e estudar a causa raiz das necessidades dos usuários.
• Requisitos ambíguos e voláteis. Requisitos voláteis provocam retrabalho. Retrabalho é desperdício. Devemos simplificar requisitos e criar sessões intensivas de coletas e acomodação de requisitos junto a todos os usuários chave.
• Burocracia. Reuniões gerenciais sem foco, sistemas de apontamento de horas que controlam até a ida de um funcionário ao banheiro e excesso de controle gerenciais são exemplos de burocracia.
• Comunicação interna ineficiente. Afastar os usuários dos analistas desenvolvedores, trocar a comunicação face a face por documentações frias e trancar desenvolvedores em baias (cubículos com paredes) são excelentes exemplos de como reduzir a comunicação em times e aumentar a ineficiência.
• Defeitos. Defeito é retrabalho. Devemos evitar defeitos realizado um processo contínuo de testes de unidade e refatorações desde o primeiro dia do projeto. Devemos procurar reduzir ao mínimo a densidade de defeitos no código de um sistema.
• Atrasos no processo de desenvolvimento de software. Testes que somente começam no meio do projeto, processos “mastodontes” e foco em documentos que não geram valor reduzem o valor de processos e aumentam o desperdício.

Alguns recursos complementares sobre o desenvolvimento enxuto de software são listados abaixo:

• Instituto para o desenvolvimento enxuto de software.
• Entrevista com Mary Poppendieck
• O livro que originou o tema na Engenharia de Software: Lean Software Development – An Agile Toolkit.

Fonte: Blog do Marco Mendes