Atualização: Scrum and XP from the Trenches

Eu havia postado aqui a dica do documento Scrum and XP from the Trenches. Esse novo post é para avisar que há 2 dias atrás foi lançado uma nova versão do documento, que agora se transformou em um livro. Eu ainda não li esta versão, mas a versão anterior possuia 104 páginas, esta nova possui 170, deve ter mais coisa boa por lá!

A versão em pdf continua gratuita, mas agora é necessário fazer o registro na InfoQ para fazer o download. Então, o link é esse aqui para acessar o site da InfoQ, fazer o registro, caso não tenha, e baixar a nova versão do livro!

Read Full Post »

An Introduction to Agile Leadership – Tim Lister

An Introduction to Agile Leadership é uma palestra apresentada por Tim Lister.

Pra quem não conhece, Tim Lister é co- autor de dois livros, Managing Software Project Risk e Peopleware: Productive Projects and Teams. Este segundo livro está na fila dos livros que pretendo comprar e ler em breve, já ouvi falar muito bem deste livro 😉

O player de vídeo da infoQ não é dos melhores (neste momento a internet não está permitindo que eu assita de uma forma contínua o videocast, e se eu aperto o pause o player para de fazer o buffer…), mas a idéia de apresentar o videocast e a apresentação juntos, eu acho sensacional!

É isso, daqui alguns minutos estarei saindo para a reunião do coding dojo floripa.

Read Full Post »

Agile Methods and Other Fairy Tales!

Esta rolando uma discussão legal, e por algumas vezes engraçada na lista de XP. Alguns membros da lista, convidaram David Longstreet para participar da lista. A questão é: Quem é David Longstreet ?

Realmente não posso dizer muita coisa, mas o que interessa aqui foi o artigo que ele escreveu: Agile Methods & Other Fairy Tales (eu não li o artigo).

Na opinião deste cidadão, deveria haver uma especialização dos desenvolvedores do mesmo modo que ocorre em outras áreas, como na medicina. Ele acredita que deveríamos ter desenvolvedores de software especialistas para cada área de negócio. Eu não concordo com isso, quem precisa ser especialista na área de negócio é o cliente, não o desenvolvedor,
embora é óbvio que algum conhecimento do desenvolvedor é necessário (e é essa possibilidade de navegar por várias áreas, um dos atrativos da nossa profissão).

Bem, vou citar agora algumas frases que ele enviou pra lista de XP

• my intent it to bring a level of professionalism to software development.
• The more time you spend up front the higher the productivity rate, less defects and faster time to market.
• It is common for companies not to understand what they are capable of doing in the alloted timeframe/budget. This is why thy spend too much time pounding out requirements. They create a set of requirements they are not capable of implementing.
• Those companies where their software developers know the business domain are the most profitable and are market leaders.
• Software organizations with the least amount of domain knowledge have the most difficult time communicating with customers.
• The most productive, market leaders and profitable are those companies who are able to define all their requirements in advance. They take a traditional waterfall approach. The data is conclusive.
• Do I see productivity improvements when companies try to adopt Agile the answer is NO.
• I have seen Agile tried in companies that were chaotic at best and they had a lot of problems unrelated to Agile. Agile made no difference and did not solve their problems.
• Let me tell you this time with numbers, those companies that have developers who specialize in the business drop their productivity rates from an average of 40 hrs/fp to less than 4 hrs/fp. They increase their profit margins 2 to 3 times. They reduce their time to market from an average of 12 months to less than 3 months.
• I can say one thing with absolute certainty you can’t rely on verbal
  communication with 1,000 developers on a project and you sure can rely on verbal communication with 10,000 individuals in development.
• I know one thing for sure. Agile, of any flavor or color, is not going to work on large software projects. The next question does it work on small projects.

As respostas para essas colocações foram as mais variadas, desde muito inteligentes até as mais engraçadas, e a discusão está grande (mais de 250 emails em 2 dias, e aumentando).

Bem, fica aí a dica, vale a pena acompanhar a discussão. Quem não participa do grupo pode acessar as discussões por este site e fazer uma busca por “Fairy Tales”

Read Full Post »

Popularização do SCRUM

Na última sexta-feira estava no II ECETI (Encontro Catarinense das Empresas de Tecnologia da Informação) e dentre as palestras havia: “METODOLOGIA SCRUM. Apresentará os princípios fundamentais e as boas práticas de projetos através da filosofia do processo ágil definido pelo SCRUM, bem como pode ser usado conjuntamente com outras metodologias.”

Acredito que a forte expansão do SCRUM tem gerado algumas pequenas anomalias, como algumas que percebi nessa palestra e vou citar aqui.

Primeiramente o palestrante deixou claro que daily meeting tinha a função dos participantes do time prestarem conta ao Scrum Master. Concordo este pode ser um dos objetivos do daily meeting, mas acredito que este não é o principal (um bom exemplo do que é, e para que serve o daily meeting pode ser encontrado aqui).

Acredito que a utilização de termos como product owner, product backlog, burn down chart sem explicar corretamente o significado de cada um deles foi outro problema. Em um dos slides o palestrante estava falando e falando sobre burn down chart quando alguém perguntou “O que é um burn down chart?!?!“. A resposta foi “Explico logo em seguida, em um próximo slide“, o problema foi que esse slide demorou pelo menos 10 minutos…

“A seleção dos itens no product backlog para o sprint backlog, é feita de forma que os itens de maior risco (onde risco é uma complexidade desconhecida, uma nova tecnologia, entre outros) são desenvolvidos primeiramente”. Isso eu achei bem complicado, acredito que é um dos pontos importantes do SCRUM o fato do cliente priorizar os itens permitindo que seja desenvolvido primeiramente o que agrega mais valor para o cliente.

O palestrante também citou que o RUP pode ser utilizado junto com o SCRUM. Isto realmente pode acontecer, mas eu prefiro utilizar o princípio do Lean: eliminate waste. Em uma palestra anterior, um palestrante de uma empresa filiada a IBM (um braço da IBM que prega o uso do RUP) mencionou que atualmente utiliza-se 80% do tempo de desenvolvimento no design do software, então ocorre a _transformação_ dos diagramas em código. Eu acredito que 80% do tempo criando diagramas é desperdício.

No geral, a palestra foi interessante 😉

Read Full Post »

SCRUM Reference

Acabei de ler um documento (embora não esteja completo) que é um dos melhores documentos que eu já li a respeito do SCRUM. Por exemplo o documento inicia citando 3 frases de Bruce Lee 😉

O documento faz (e faz bem) o que se objetiva a fazer, ser uma referência de SCRUM. A diferença que eu achei entre esse documentos e outros vários documentos que existem na internet, é o grau de detalhe de cada fase, de cada item do SCRUM. Gostei bastante da parte da documentação sobre o pregame, tem alguns tópicos legais que geralmente não existe em documentos sobre SCRUM.

Inclusive achei algo que nunca tinha lido em documentos sobre SCRUM, uma fórmula para ajustar estimativas. A fórmula é a seguinte: Estimate = Initial Estimate X (1 + (complexity + drag + working environment + multiple teams)). No texto são apresentadas tabelas para ajudar a descobrir os valores destas variáveis. Não sei sobre a praticidade desta fórmula, acho que vou tentar utilizá-la para ver o resultado.

O documento inclusive possui um apêndice, com cartas que podem ser impressas caso você queira utilizar o planning poker para fazer suas estimativas 🙂

E como de costume, o link para o documento [pdf] é aqui!

UPDATE!  O link está fora do ar, então coloquei o arquivo aqui.

Read Full Post »

Agile Certification

Na última sexta-feira, Scott Ambler publicou um artigo interessante sobre certificações Ágeis.

Neste artigo ele cita as diferenças entre as várias estratégias de certificação, citando o que ele considera bons e maus exemplos destas estratégias. Ele encerra o artigo fazendo uma crítica a certificação Certified Scrum Master.

Bem, o link é esse aqui!

Read Full Post »

Planning Poker

Há alguns dias atrás me deparei com essa prática e achei bastante interessante.

Planning Poker é uma prática que auxilia na estimativa de estórias e tarefas. Eu não irei tentar explicar aqui o funcionamento, apesar de ser extramente simples, o Planning Poker esta muito bem explicado aqui, inclusive com imagens. E aqui há outra explicação, retirada do livro Agile Estimating and Planning.

Eu acho que essa prática é bastante interessante quando se possui um grupo de pessoas trabalhando no desenvolvimento de um software, mas somente enquanto esse grupo de pessoas não forma um time. A partir do momento em que um time é formado, acredito que o problema que o Planning Poker busca resolver, não deve mais existir. Após algumas semanas as pessoas se conhecem mais, estão mais em sintonia e não tem (não deveriam ter) problema em dizer que discordam completamente da opinião de outra pessoa do time. É obrigação do SM ou do coach decidir até quando é necessário utilizar essa prática

Fiquei feliz que a pontuação sugerida no livro, é parecida com a pontuação que eu escolhi para ser utilizada na empresa. O livro sugere: 0, 1, 2, 3, 5, 8, 13, 20, 40, e 100. Na empresa eu escolhi utilizar: 1, 3, 5, 8, 13 e 21. Eu utilizo um conjunto menor de valores (bem parecido com uma seqüência de Fibonacci) mas a idéia é a mesma, sempre tentar quebrar a estória/tarefa em estórias/tarefas menores e não fornecer muitos valores, porque é difícil mensurar a diferença entre uma tarefa de 5 pontos de uma tarefa de 6 pontos.

Read Full Post »