O Centro de Tecnologia de Informação Aplicada da Escola de Administração de Empresas de São Paulo da Fundação Getulio Vargas – FGV-EAESP, o GVcia, divulga anualmente um amplo retrato do mercado de Tecnologia de Informação (TI), com resultados de pesquisas do uso nas empresas e do comércio eletrônico no Brasil.

O levantamento atual é uma ampliação da amostra do estudo para sua 20ª edição. A pesquisa foi realizada em 5.000 empresas com 2.000 respostas válidas de grandes e médias empresas.

Segundo o estudo, nos servidores corporativos o Linux representa hoje 19% do uso no ambiente operacional.

O sumário dos resultados da pesquisa pode ser encontrado em: http://www.eaesp.fgvsp.br/subportais/interna/relacionad/gvciapesq2009.pdf

Postado por Carlos Henrique Vilela
para o blog CHMKT em 30/06/2009

Enquanto o futuro da conferência anual de planejamento vai sendo definido, decidi resgatar algo muito interessante que foi dito na edição de San Diego, em 2007.

Na ocasião, o Gareth Kay, da Modernista! e o Mark Lewis, da DDB San Francisco, apresentaram um material fantástico, chamado Os 7 pecados mortais, no qual falaram sobre os erros que cometemos todos os dias e que acabam nos impedindo de criar novas possibilidades. Abaixo, seguem os 7 pontos listados e um breve comentário sobre cada um. Concordando ou não com as colocações, é uma leitura que vale a pena.

1) Viver com base em suposições antigas e incontestadas. Na busca por um discurso consistente para marcas, ficamos presos em fórmulas, guidelines, brand books e isso acaba nos limitando. Deixamos de explorar novos discursos. Não levamos em conta que, assim como pessoas, as marcas também podem mudar radicalmente se a cultura popular inspirar essa nova atitude. Portanto, desafie as (velhas) suposições.

2) Nos importamos com os assuntos errados. Nossa busca eterna pelo insight perfeito – capaz de gerar conhecimento, atitude e imagem – é desnecessária. Nosso objetivo deve ser criar energia para que as marcas contagiem as pessoas – mais ou menos da maneira que uma banda de rock faz todo mundo sair do chão.

3) Nosso desejo por simplicidade. Segundo Kay e Lewis, é um pecado a idéia é que, com a evolução do papel do planejador, fomos reduzindo tudo a um só problema, um só consumidor, um só conceito para uma marca, uma só forma simples de escrever um brief, uma coisa só para contar para a criação, só mundo a explorar. Isso nos faz muito simplistas e rasos. Eles fizeram, inclusive, uma analogia com a estrutura molecular. Quando você faz um experimento desses, vai surgindo um sistema cada vez mais complexo, maior e muito mais interessante. Ou seja, a complexidade no trabalho de planejamento (e não na forma como apresentamos) pode criar muito mais possibilidades.

4) Qual a mensagem principal? Passamos o tempo todo tentando escrever a mensagem principal no brief – de forma criativa, clara, límpida, para a criação nos achar inteligentes quando o que mais importa é o território que queremos explorar, o porquê de explorar este território e o problema que originou o caminho que estamos definindo. A teoria do caos, afirmaram, é a inspiração para criar um processo mais criativo.

5) Auto-importância. O que fazemos pouco importa para as pessoas. Ninguém fica louco para ver um comercial ou cai de amores pela sua marca. Há coisa muito mais importantes nas suas vidas. Portanto, para ter alguma chance, desenvolva uma missão social, mais do que uma simples proposta comercial. Seja humilde.

6) Achar que as coisas grandes é que importam. Ficamos o tempo todo buscando inspiração em grandes coisas: macro tendências, exemplos de grandes marcas, grandes mudanças de categoria e consumo, entre outras. Isso nos faz esquecer que, no final, estamos falando com pessoas, que tem suas vidas, que fazem pequenas coisas que realmente são muito mais importantes – buscar o filho na escola, almoçar com a família, comer pipoca e dar risada de uma boa comédia, etc.

7) Aprender e depois fazer. Eles dizem que devemos aprender e construir as idéias enquanto estamos fazendo as coisas, enquanto estamos junto com a criação avaliando a execução. Podemos ter uma idéia durante o processo de produção de um filme, por exemplo, e não necessariamente antes de todo mundo. O processo criativo sempre é orgânico e deve ser feito sem processos formatados.

Fonte: Blog CHMKT

Postado por Mark Levison, traduzido por Wagner R. Santos em 02 Jul 2009 12:44 PM

Kent Beck , autor de “ Extreme Programming Explained” e “ Test Driven Development: By Example” sugere que um projeto de software, assim como golf, pode ser um jogo longo ou curto. JUnit é um exemplo de projeto longo, muitos usuários, rentabilidade estável (a $0 é triste para qualquer envolvido), onde o objetivo principal é proporcionar funcionalidades além das necessidades dos usuários.

Quando iniciei o JUnit Max, vagarosamente foi ficando claro para mim que as regras haviam mudado. A questão fundamental era (é), “Quais funcionalidades irão atrair clientes pagantes?” Por definição, esta é uma questão sem resposta. Se o JUnit (ou qualquer outro pacote livre) implementasse a funcionalidade, ninguém irá pagar pelo Max.

O sucesso no JUnit Max é definido por uma receita sustentável: quanto mais usuários pagantes, maior a receita, e/ou um grande coeficiente viral. Uma vez que, por definição, os meios de se alcançar o sucesso são desconhecidos, o que maximiza a chance de sucesso é tentar diversos experimentos e incorporar o feedback do uso atual e a adoção.

JUnit Max reporta todos os erros internos para um servidor central de modo que Kent pode ser alertado dos problemas conforme eles surgem. Estes logs de erro ajudaram a solucionar dois problemas. Para o primeiro problema ele foi capaz de reproduzir escrevendo um teste simples, e assim analisar e resolver o problema. O segundo problema foi facilmente solucionado, mas Kent estimou que ele pudesse tomar diversas horas para escrever um caso de teste para o problema. Neste caso ele somente corrigiu e atualizou a aplicação.

Kent continuou dizendo:

Quando iniciei o Max ao fim do primeiro mês eu não tinha qualquer teste automatizado. Eu fiz todos os meus testes manualmente. Após ter os primeiros usuários e voltei atrás e escrevi testes para as funcionalidades existentes. Novamente, eu acho que esta seqüência maximizou o número de experimentos válidos. Eu poderia fazer por unidade de tempo. Com pouco ou nenhum código, sem testes eu consigo iniciar mais rápido (o primeiro teste que escrevi me tomou quase uma semana). Uma vez que o primeiro bit de código se provou valoroso(de forma que poucos amigos meus pagariam por ele), testes me permitem fazer experiências com esse código com mais confiança.

Queira ou não, escrever testes automatizados requer um balanceamento de uma série de fatores. Mesmo para o Max eu escrevi um número grande de testes. Se eu posso pensar em um modo mais barato de se fazer testes, eu desenvolvo para cada funcionalidade um teste de aceite primeiro. Especialmente se não tenho certeza de como implementar a funcionalidade, escrever testes me traz boas idéias. Enquanto estou trabalhando no Max, a questão sobre se escrevo ou não um teste se resume ao fato do teste me ajudar a fazer e validar mais experimentos por unidade de tempo. Se sim, eu escrevo. Se não, deixo para lá. Estou tentando maximizar a chance de alcançar a maior receita possível com o Max. A razão em torno do investimento em design é tão complicado quanto, mas este é um tópico para um post futuro.

Ron Jeffries, autor de Extreme Programming Installed, responde: “Eu confio em você, e a respeito das outras três pessoas, para tomar boas decisões em pequenas iterações. Minha longa experiência sugere que existe uma resposta automática na curva de impacto para decisões focadas em pequenas iterações. O que faz com que a confiabilidade e a habilidade de progredir de muitos caia substancialmente.

Johannes Link, Agile Software Coach, disse: “Eu tenho visto alguns desenvolvedores que foram capazes de tomar decisões razoáveis de curto/longo prazo. Ainda estou para ver um único time, portanto; deixe a empresa tomar a decisão.”

Michael O’Brien em contraste comentou: “Um grande artigo e a decisão correta, Eu acho. É muito fácil ser pego escrevendo um código bonito e consistente, e esquecer para o que você esta escrevendo o código. Eu escrevo testes porque ele torna a escrita de código mais fácil e me dá confiança de que o código faz o que eu acho que ele deve fazer. Se escrever um teste não irá me ajudar alcançar o que quero, então eu simplesmente não faço.”

Olog Bjarnason acha que: “uma idéia relevante que Kent nos trás é o fluxo de feedback. Se nós focarmos em buscar um fluxo-por-unidade-tempo alto, nós estaremos indo na direção correta. Por exemplo, ele mencionou que adicionar funcionalidades sem testes em projetos de curto prazo maximizou o fluxo de feedback no inicio do projeto JUnitMax, uma vez que era muito complicado escrever o primeiro teste (tomou dele cerca de uma semana de trabalho). Ele teve um fluxo de feedback maior somente codificando e liberando; seus “testes vermelho” eram os seus primeiros poucos usuários e seus feedbacks.”

Guilherme Chapiewski, alertou sobre o problema de que às vezes podemos pensar que é um projeto de curto prazo mas não é. No caso de Guilherme ele decidiu iniciar um projeto sem testes como uma prova de conceito. O projeto foi para o ar e as pessoas começaram a utilizar, e rapidamente aparecem alguns bugs que não podiam ser corrigidos. No final ele concluiu que o código estava horrível e intestável. Ele jogou tudo fora e começou a fazer tudo de novo do inicio.

Kent respondeu a muitos que comentaram dizendo: “Eu concordo que confundir as práticas e os princípios levam a problemas. E que os testes levam a um design melhor. É por isto que tenho ~30 testes funcionais e ~25 testes unitários (um balanceamento esquisito porque as aplicações no Eclipse são difíceis de se testar). Eu faço para a maioria das minhas novas funcionalidades testes de aceite primeiro. Isto me ajuda a reduzir os ciclos de tempo.”

Esta idéia escala seguramente além de uma ou duas pessoas? Além de Kent Beck, existem muitas pessoas que tem o julgamento correto de deixar os testes de fora?

Fonte: InfoQ

Essas tirinhas foram postadas pelo Henrik Kniberg, autor do livro “Scrum e XP direto das Trincheiras“, em seu blog.

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners.

Tentei fazer uma tradução livre para o português. O post original pode ser visto em: One day in Kanban land

Daniela Moreira, de INFO Online
Terça-feira, 30 de junho de 2009 – 07h33

SÃO PAULO – No mundo do desenvolvimento de software, metodologias ágeis como scrum e extreme programming são a onda do momento. Mas será que elas funcionam mesmo?

Para tentar responder a pergunta, conversamos com Fabio Akita, um especialista no tema. Gerente de produtos da Locaweb e autor do blog Akita on Rails, ele trabalhou como desenvolvedor, integrador e gerente em diversos projetos de software.

Confira a seguir algumas das ideias que ele defende e tenta colocar em prática no seu dia-a-dia como gestor de projetos:

De onde surgiu a ideia de desenvolvimento ágil?

A crise do software vem desde a década de 70, não é recente. Desde os projetos militares da década de 60 todo mundo já sofria com os mesmo problemas. Mas a gente sempre vem fazendo do mesmo jeito desde então. Nos anos 90 diversos pensadores da área de engenharia de software se juntaram para tentar encontrar a metodologia correta para lidar com software e não chegaram a uma conclusão. Mas chegaram a um conjunto de valores importantes, que deram origem ao que chamamos de manifesto ágil.

Scrum e extreme programming são algumas metodologias ágeis que estão em voga no momento. Elas refletem o espírito deste manifesto ágil?

Com a nossa cultura de fast food, de querer achar uma receita mágica para tudo, o mundo ágil ganhou força dentro de um certo nicho de desenvolvimento. A gente ouve falar muito hoje de scrum, de extreme programming, mas se usam essas ferramentas apenas como ferramentas. Isso não funciona. Tem gente que até discute se o pico recente de scrum não foi mais negativo que positivo, porque muita gente está aplicando e não atinge os resultados, simplesmente porque usa o raciocínio antigo com ferramentas novas. Os valores não foram entendidos. Scrum é um template. Ele te diz que você tem esse papel chamado product owner, você tem este tempo chamado sprint, tem essa atividade chamada scrum diário, e essas coisas chamadas retrospectiva e backlog. Ele te dá nomes e elementos que você aplica. Mas não é só aplicar e ponto. Isso é só o começo. A grande mensagem da forma ágil de pensar é que o procedimento não é importante. É irrelevante se eu chamo o meu tempo de trabalho de sprint ou o dono do projeto de product owner. É absolutamente irrelevante, se eu não entendi os valores que são entregar valor ao cliente, criar uma organização de aprendizado, acreditar nas pessoas e dar suporte a elas. Esses princípios é que são importantes, mas não são explícitos. Em vez disso eu tenho papéis, cargos e atividades. Não se explicam os porquês e não entendendo os porquês você vai fazer exatamente a mesma coisa, mas em vez de chamar o sujeito de gerente de projeto você vai chamá-lo de product owner. Mas nada mudou.

Existe aquela figura de um gerente que tem embaixo dele uma série de recursos – como pessoas e tecnologias – um escopo, um orçamento, prazos e parte-se do princípio que, havendo um bom gerente que coordene e dê ordens de cima para baixo, o projeto vai correr da forma como classicamente se espera e o projeto vai ser entregue com sucesso. Passando por vários projetos e observando tantos outros, é bastante claro para mim que a maioria não acaba exatamente com sucesso. Alguns são entregues pela metade, outros saem mais caro outros acabam atrasando. Se todos acabam de forma errada, qual é a vantagem de partir da premissa de que se eu fizer tudo como foi planejado passo a passo vai dar certo no final?

Porque as ferramentas tradicionais de gestão e controle não funcionam para software?

Instrumentos de controle como forecasting, cronogramas e business plan são ilusórios. Eles dão a ilusão de que eu tenho um controle que realmente não tenho. Software não é colocar um tijolo em cima do outro. É impossível ter dois programadores que vão fazer exatamente a mesma coisa, ao mesmo tempo, mesmo partindo dos mesmos princípios. Produzir software é uma atividade criativa. Você não pode pedir a um compositor: eu quero exatamente esta música neste dia. Ele vai trazer alguma coisa, mas a gente não sabe exatamente o que. Eu tenho uma noção de que quero uma música mais para rock do que para blues, mas exatamente com que notas eu não tenho como saber. Software segue um pouco este caminho. Por isso é difícil gerir software usando premissas que não foram feitas para isso.

O que pode funcionar então?

Em primeiro lugar, a empresa assumir que não sabe o que quer. Eu sei que tenho alguns pontos problemáticos no meu negócio que eu quero corrigir, um certo orçamento e um certo prazo a partir do qual não é viável mais esperar. Diante disso, vamos trazer o desenvolvedor e o cliente que tem o problema, que sabe onde o calo dele aperta, e fazer ambos trabalharem juntos. Em vez de gastar os próximos seis meses descrevendo o que se quer, vamos definir um prazo curto. Eu não consigo prever o futuro em longo prazo, mas talvez eu consiga controlar o curto prazo. Duas, três semas, E entender dentre os problemas que o cliente tem quais são os prioritários. Porque se eu atacar esse problema primeiro, vou ter muito valor. Começamos a desenvolver e no fim desse período curto, o cliente vai ter alguma coisa, mesmo que seja um pedaço de software, mas que funciona, que não está completo, mas que o cliente pode testar, usar e dizer se está no caminho que ele deseja, de tal forma que se não estiver, eu não perdi seis meses. Isso é minimizar o risco. Ninguém sabe qual é o jeito certo, mas dá para discutir o que não funciona desde o começo. É como fazer uma escultura. Primeira se faz cortes grosseiros e depois é que vem o acabamento. O código é dinâmico, não é estável e tudo que é entregue continua sendo mexido.

Qual é o papel do gerente em uma equipe que trabalha desta forma?

O gerente não controla se o João trabalha duas horas nesta tarefa ou Maria vai passar três horas naquela. Ele não vai fazer cronogramas. Vai controlar as expectativas e a comunicação. Vai garantir que o cliente esteja disponível para tirar as dúvidas do desenvolvedor, vai garantir que o desenvolvedor tenha os subsídios para desenvolver. Ele tem que retirar de si poderes e delegar a quem realmente tem capacidade de tomar decisão. Afinal, é o desenvolvedor que vai colocar a mão no código. A tomada de decisão vem de baixo. Scrum e extreme progaming prevêem tudo isso, mas se eu jogar de cima para baixo não funciona, porque até ontem os desenvolvedores recebiam ordens. É um processo que começa com a quebra de algumas premissas, com algumas discussões, que devem ser aplicadas uma de cada vez até que a equipe entenda a dinâmica e sinta a necessidade de puxar outras práticas.

Como funciona a aplicação prática desses valores no dia-a-dia?

Em empresas grandes, é como mover um elefante, porque elas estão em equilíbrio. É como um copo de água. Sozinho, ele não entra ebulição. É preciso entropia. Os gerentes do meio não têm nenhuma motivação para melhorar algo porque a sua carreira não depende disso, e ele não é o dono do dinheiro. Quando surge algo novo ele não vai ser o primeiro a tentar. Mesmo que o que ele faça está errado, ele acredita que não vai ser condenado por ter seguido a maioria. Em empresas menores onde tem o dono e mais cinco pessoas, o dinheiro que sai do bolso do dono é valioso. Ele não vai aplicar burocracia porque é bonito ter papel na mesa. Nos Estados Unidos, tem um mercado enorme de startups que são os primeiros a adotar essas novas tecnologias e novos jeitos de trabalhar. Elas dão o start para que chegue às grandes. Aqui tem muitas empresas que desenvolvem para outras empresas, portanto têm pouca liberdade. Lá, elas desenvolvem produtos próprios e é aí que está a diferença.

Fonte: Info

A empresa Bluesoft acaba de colocar no ar o site do software “Pronto”. Software livre desenvolvido para gestão de projetos que utilizam Scrum.

No site dá pra ver alguns screenshots, fazer o download do projeto e até acessar uma demonstração online do produto.

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.