Evento Falando em Agile 2008 da Caelum

este artigo foi acessado 19 vezes desde (02-01-2012)

Eu estive presente no segundo dia do evento Falando em Agile 2008 realizado pela Caelum e posso lhes dizer que muitas coisas me deixaram impressionados e que as informacoes que ouvi dos palestras foram proveitosas para iniciar algumas reflexoes.

Vou comecar pelo comeco, afinal, a primeira impressao e a que fica.

O evento estava muito bem organizado, com uma equipe prestando suporte aos clientes que estiveram presentes e retirando duvidas, entregando material de suporte e cds dos patrocinadores (que foram Yahoo, Globo.com e Borland). Para se ter uma ideia do servico prestado, eu nao estava na relacao dos inscritos para o evento pois na realidade era para outro membro da equipe estar la, mas como ele estava envolvido em outras atividades, acabou que eu fui.

Expliquei a questao para o pessoal da mesa de credenciamento, identificando a empresa e etc e eles automaticamente lembraram do caso da inscricao da empresa e resolveram o meu problema fazendo um cracha com meu nome e entregando o material, enfim… cheguei e ja fui ouvindo “tenha um bom evento” de tao rapido que foi o atendimento.

Outra coisa que me impressionou foi a infra estrutura do local. Um local muito bom (rua Sao Joaquim, 460 – Liberdade), com varios saloes(usamos somente um) e espaco para cofee break e etc. Coube todo mundo com sobra. Nao houve tumulto e tudo se apresentou a contendo.

O cofee break que mes engordar um pouco mais(vale lembrar os fdm ;\ que me chamam de gordo nesse momento), suco de laranja, doces, salgados, cafe(bom cafe). Quem nao tomou cafe em casa se satisfez e quem tomou, repetiu a dose.

Putz… vamos falar das palestras logo entao…

A grade das palestras que eu assisti foi:

1. Scrum em ambientes PMBok. Qual caminho a ser seguido? – Alexandre Magno (Caelum)
2. Scrum na Globo.com. Derrubando mitos – Danilo Bradusco(Globo.com)
3. Padreos para introducao de novas Ideias na industria de software – Damiel Cujier / Fabio Kon (IME-USP)
4. Experiencias de um agilista em uma empresa global – Daniel Wildt e Giovano Salvador
5. Negocio e TI: alinhamento e agilidade – Robson Caiado (Borland)
6. A maldicao da fabrica de software agil

Todas elas foram muito interessantes e tiveram seus atrativos. Logico que algumas mais que outras, mas, no fim. Valeu a pena mudar o cronograma. Por isso, vou falar de cada uma delas agora e contar um pouco do que cada uma me fez refletir

Scrum em Ambientes PMBok. Qual o caminho a ser seguido? – Alexandre Magno

No início não tive interesse pela palestra, isso pelo simples fato de que não trabalho em ambiente PMBok, mas no decorrer da coisa o palestrante foi soltando algumas frases que me fizeram começar a prestar atenção.

1. Barely sufficiente = > Antes de criar um documento discutir com as pessoas se ele é realmente necessário(eliminar desperdício de trabalho).
2. Conceito de pronto => Cada um tem um diferente dentro do time e isso precisa ser acertado.
3. Síndrome de Nostradamus aplicada à documentação: “… mas um dia podem querer ver esse documento…”
4. Acordo de trabalho: montar um junto a equipe e afixa-lo em local visível => Time Auto gerenciável
5. Gerente: Facilita a reunião e torna altamente visível as informações geradas, para todos os membros./ Facilitar a reunião de planejamento
6. Fugir do micro gerenciamento.
7. Product Back Log é do Product Owner.
8. O time gerencia as tarefas diárias.
9. O Scrum Master auxilia o cliente a criar um product Backlog facil de manter/alterar
10. Trabalhar para não ter times com membros flutuantes. Preferir times dedicados
11. TIme gerencia as dependências de tarefas e o Scrum Master foca nas dependências de projeto.
12. Executivos veêm gráficos.
13. Time tem responsabilidade sobre orçamentos.
14. Critérios de aceitação como DONE. Testes dentro da iteração usando testes automatizados com uma lista de critérios e excessões.
15. Manter times cross projetos é igual torcer para palmeiras e corintians ao mesmo tempo
16. Calcular percentual de dedicação de membros do time é impossível quando se esta em mais de um projeto.
17. Cada sprint tem uma retrospectiva
18. Manter radiadores de informação visíveis
19. Convidar time a identificar riscos em todas as reuniões e deixar os identificados visíveis nos radiadores de informação
20. Chamar fornecedores para retrospectiva do atendimento do contrato.
21. Mudança: Gerenciamneto Comando|Controle passar a ser liderança servidora

Scrum na Globo.com. Derrubando mitos – Danilo Bradusco(Globo.com)

Esta palestra cobriu o case da globo.com com relação as metodologias ágeis e me impressionou muito as diferenças que foram captadas pelo
pessoal da empresa na medida em que eles iam utilizando as métricas e vendo o sucesso na entrega dos projetos.

vamos então aos cacos

1. Overhead de comunicação é diminuido pois as informações fluem melhor
2. Menor quantidade de bugs devido aos testes iterativos
3. Dar liberdade ao PO para apresentar o que quer. Se ele não conseguir apresentar dar tempo à ele para que ele repense e tente apresentar novamente.
4. Melhor voce se adaptar a mudança
5. Continuar escalando o conceito de DONE
   Quando esta desenvolvido=>
   Quando esta testado.=>
   Quando esta em producao.=>
   …
6. Práticas ageis de Engenharia
7. Esquetes.
8. Personas
9. Confiança X Contratos.
10. Identificar papéis e não Atribuir Cargos.
11. É possível escrever software de qualidade sem burocracia.
12. Times com profissionais de várias áreas e cada categoria de profissional precisa de padrões(para DBA por exemplo).
13. Scrum meeting de nicho: deixar esses times criar e manter seus padrões(DBA, por exemplo).
14. Síndrome do PO Virtual: Ninguém sabe que é o PO
15. Erros
    Não treinar os times no início

    Paralelizar o trabalho(no final ter 90% do trabalho=nada)

    Planning sem ter o backlog organizado.

16. Qualidade é inegociável. X Escopo negociável
17. Síndrome do sofá-cama: Todo mundo fazendo mais ou menos uma coisa(O coordenador que é dba e que dá uma força no design…)
18. A maneira como você faz as coisas é muito importante.

Padrões para Introdução de Novas Idéias na Indústria de Software – Daniel Cukier/Fabio Kon (IME – USP)

O conteúdo desta palestra foi interessante, apesar de inicialmente ter me feito pensar em sair…

É o seguinte: Dureza ouvir dos outros coisas que você já pensou, falou, fez… mas que não identificou/julgou, como bom ou ruim. Essa palestra foi recheada disso – Padrões de comportamento – meu, seu e até de quem acha que não tem.

1. Conectores: Pessoas que apesar de não ter importancia vital no contexto acabam agindo como radiadores de informação.
2. Se você respeitar o tempo das pessoas, você ganhará a confiança delas.
3. Timebox: definir um período de tempo gera comprometimento.
4. Simplemente faça – “Só os idiotas esperam a perfeição. O sábio procura o aprendizado. Gandhi”
5. Tudo São pessoas.
6. Grupos de estudo informal são importantes.
7. Métodos ágeis foram os primeiros a olhar para as pessoas.
8. Patrocinador Local(o cara que apoia o projeto) é uma necessidade importante para qualquer trabalho.
9. Convite a todos para a ocasião. Nem todos vão aceitar, mas sentirão-se honrados.
10. Idéias pertencem a todos os envolvidos e não a quem a teve.

Experiência de um agilista em uma empresa Global

1. Olhar a ponta do Iceberg e dar o prazo sem o lhar a parte submersa é o mais comum.
2. Finding ways to become more effective with truth….
3. Waterfall lifecycle?
4. Reescrevendo Software? Cliente com uma série de espectativas…
5. Porcentual de cobertura de código é diferencial importante.
6. Time reconhece liderança
7. Investing in good stories
8. Go read The toyota talent
9. Scrum team Coaching
10. Principio de Qualidade Iso 9000

O papel do Product Owner e priorização de Product Backlog

1. PO precisa saber quem é o target – Precisa ter os conhecimento necessários senão bypassed e o time toma suas próprias decisões.
2. PO e time = link frágil
3. PO não técnico smepre esta pressionado.
4. Product Owner(PO) tem que criar a visão. O time tem que comprar isso
5. Visão CompartilhadaClara e ContretaSer difícil de AlcançarCriar Desejo
6. PO é o responsável pelo ROI.
7. Não precisa complicar=> Exemplo: Mas o mágico(big boss) quer um relatorio diário, então vou precisar usar uma ferramenta. => Resposta: Não precisa não. Vai até o Quadro todo dia de manhã, tira uma foto bo burn down chart e envia por e-mail(é essa informação que o executivo precisa – o gráfico da meta).
8. Priorizando o BacklogBenefícios a serem medidos nos itens e que são os critŕios de sucesso e decidem o Why or Why?<=PO:DinehrioAudiência

   Satisfação do Cliente

   Fidelidade

9. PO entende o Cliente/Assunto/Comunicação
10. Ideal seria manter ao menos 3 sprints a frente já mais ou menos organizados para que em caso de finalização adiantada e não presença do PO o time possa dar continuidade ao trabalho em outra história.
11. Modelo de ficha de tarefaEu como [CLIENTE]quero[FUNCIONALIDADE]por que assim[RETORNO]
12. Atrás da ficha o PO tem de anotar o critéiro de aceitação pq se no dia da demo ele estiver de mau humor, mesmo assim não vai conseguir fugir da aceitação dizendo que algo não saiu como esperado.
13. Tomar Cuidado com o Over Architecture
14. Não fazer uma coisa antes de precisar dela
15. Formas de Calculo de Prioridade de Itens do BacklogModelos FinanceirosBenefício RelativoMétodo de Cano(Itens são classificados em (Must Have: Importantes senão a aplicação não tem por que existir, Linear: Itens que fazem diferença, destacam, Exciters: Aqueles que não fazem a diferença na aceitação do produto, mas se existirem, legal.)
16. Para dar percepção de em que categoria um item entra é interessante uma pergunta funcional e outra não funcionalO que voce acha de todo dia, quando chegar no hotel, encontrar um lata de cerveja grátis no seu frigobar?
    Legal, iteressante, eu ia gostar

    O que voce acha se não tivesse essa lata lá?
    Não ia fazer diferença entre eu escolher esse hotel e outro.