Posts Tagged ‘agile’

Retrospectivas

junho 25, 2009

Pessoal,

Seguindo a linha de posts relacionados ao Scrum Gathering, coloquei no InfoQ um outro post sobre a palestra de Restrospectivas do Boris Gloger.
Pessoal,

Temos que sempre tentar executar retrospectivas após o sprint, segue um artigo que fala bem sobre esta sessão do Scrum.

http://www.infoq.com/br/news/2009/06/6-segredos-executar-sucesso

Confiram lá !

Até mais

Palestra: Guerrilla SOA – Falando em Java 2009

maio 25, 2009

Guerrilla SOA

palestra de Dr. Jim Webber da ThoughtWorks

Foi uma palestra muito bacana, abordando de forma direta e engraçada um assunto que normalmente traz mais perguntas do que respostas.

Muitas vezes ele encontra muitos sistemas complexos e nestes casos eles utilizam middlewares. Mas ele vai mostrar uma outra opção que utiliza:

  • Agile: pode ser usado em aplicacoes grandes.
  • Web:  Não da forma que conhecemos.

Podemos trazer agile e web juntos

No começo da computação

No começo da computação era comum e normal ter “silos” de aplicações.  Algumas pessoas inteligentes, presenciando esse panorama, enxergaram a possibilidade de dividir e comunicar estes silos de aplicação. Estes caras fizeram muito “encanamento” para juntar estas aplicações.  E isto funcionava, porque de alguma forma os silos estavam ligados entre si. Não era bonito mas funcionava.

Através dos anos, com o desenvolvimento da computação, a competição surgiu e os especialistas de integração se tornaram muito fortes. Eles exercerciam muita influência e se tornaram muito grandes no mercado.

Eles absorveram muita coisa: BPM, Regras de negócio, adapters, GUI tools, segurança, transformations, confiabilidade…. Com isso, mais silos foram integrados e, mesmo assim, não se tornaram muito melhores.

Neste cenário, SOA veio ao resgate destes problemas. Veio para aumentar o nível de abstração, para pensarmos em nosso sistema com uma mente voltada ao negócio. Mas não é para ser implementado da forma que os livros pregam, não focam em processos de negócio, mas em uma visão de TI.

ESB poderia ser uma boa opção, mas ele é ingovernável, porque para ser efetivo todos os sistemas da empresa deveriam estar funcionando no mesmo bus. E se tivéssemos este bus, estaríamos replicando o problema que atualmente temos com os DBAs.  Além disso, esta solução não escala.

Pensando em agilidade

Ninguém pode negar a beleza do modelo tradicional. É mais confortável, parece que podemos prever tudo. Mas, sabendo que não podemos prever tudo, aprendemos ao longo do projeto. Por isso muitos projetos waterfall falharam.

Foi abordada a criação do manifesto ágil, e que os valores ágeis são bem diferentes do tradicional. E que para eles funcionarem tivemos que aprender sobre BDD, restrospectiva, TDD, review e outras técnicas. Aprendemos também a crescer de forma incremental. E temos que fazer isto para desenvolvimento de sistemas complexos e não só para uma única aplicação.

A WEB

A web quebrou regras. Não foi só uma plataforma de publicação, mas de coordenação de tarefas. Quando navegamos em um site como o Amazon, vamos tela a tela… sendo guiados no processo de compras.

A web é protocol-centric, fazendo com que não seja necessário nenhum middleware. É uma rede “burra”, mas que é uma boa idéia.

A rede telefônica é boa em comprar e prover serviços de voz. Quando tentamos utilizar para serviços de dados, chegamos a um limite. A internet é a rede mais burra possível, ela roteia os pacotes independente do que esteja sendo executado.

Tem uma arquitetura que permite o surgimento de inovação, sem que haja previsão do quão grande isso será.

SOA Tradicional

Formada por pessoas de gabinete e programadores no front.

A guerrilha SOA propõe a idéia de quebrar em diversos pequenos passos, como parte de um grande programa de mudança. Devemos dividir os serviços de acordo com os serviços de negócio, deixando com que os responsaveis do negócio definam e sejam responsáveis  por ele.

Devemos priorizar e entregar incrementalmente os serviços, assim damos valor ao trabalho daqueles que estão no gabinete e os que estão no front.

Web e Serviços

A web é um middleware. Ele gastou muito tempo trabalhando em soluções de middleware. E só depois percebeu que a web já fazia quase tudo. E além disso, a Web já está em todos os lugares.

Além disso, a web é incremental, porque podemos fazer deploy de coisas novas sem quebrar o que já existe. Fazendo com que o risco de usar a web seja muito baixo.

O middleware, neste cenário, é opcional. A web pode ser o seu ESB. Se precisar escalar, coloque um servidor proxy para sua aplicação. A Web é projetada para crescer.

As vantagens da tecnologias Web-Centric em comparação da abordagem tradicional:

  • evolutionary design (ao contrario do BDUF)
  • entrega constante (grandes projetos)
  • Mais barato (caro)
  • Incremental (arriscado)
  • Escala da internet (escala da empresa)
  • Tem em todos os lugares (especializada)
  • integração por produto, entregando valor para o produto

Blog:  http://jim.webber.name

Alexandre Gomes, da Sea, fez uma palestra sobre este assunto no lançamento do InfoQ Brasil.

Perguntas que foram feitas

Se SOA é ruim, porque falamos dela tanto?

– Muita gente faz dinheiro com ela.

– Queremos que SOA funcione.

Como usar HTTP para nossos serviços?

– Fornecer os serviços no lado do servidor.

– Implementar melhor máquina de estados no lado do cliente, aprendendo novas técnicas ou reaprendendo técnicas tradicionais.

Quando eu utilizaria SOA dentro de uma empresa?

– Nas mesmas situações que você utilizaria lits distribuídos hoje. usar distribuído por default, REST.

– No ano passado estava trabalhando para uma empresa no Canadá e perceberam que podiam cachear uma boa parte do catálogo utilizando REST. Desde então, ele usa como REST por default. Só não utilizaria em situações onde o tempo de latência deve ser inferior a 1 segundo. neste caso, ele pagaria por isso.

E a TV Digital?

Ele acha que está convergindo com a web, será um aliado natural da Web.

Scrum Gathering: Gerenciamento de projetos como uma competência estratégica

maio 13, 2009

Palestra: Gerenciamento de projetos como uma competência estratégica – Ricardo Vargas

O palestrante foi o primeiro latino-americano membro do board mundial do PMI. Fez uma palestra que falou como o PMI enxerga o mundo ágil e falou que não vê sentido na divisão entre mundo ágil e mundo “formal” ou “heavy”. O importante é entregar valor para o negócio.

O título da palestra seria o descrito acima, mas depois de conversar com algumas pessoas enquanto se preparava para a apresentação, resolveu mudar o título para “PMI, Scrum, Agile e o mundo”.

O que é o PMI?
São mais de 500 000 membros e profissionais certificados, em mais de 171 paí­ses. Praticamente metade dos membros são da área de TI, mas está presente em várias áreas.

O PMI quer:

  • Avançar a prática e a ciência de gerenciamento de projetos.
  • Reconhecer e compartilhar práticas eficientes em qualquer área.
  • Documentar e refinar muitas metodologias –  não aplicáveis para todos os projetos.

A essência do PMI:

Tem 40 anos de vida, o board tem 15 pessoas , 14 voluntários e 1 pago (o presidente).

Eles idealizam que:

“Mundialmente, organizações irão adotar, valorizar e utilizar o gerenciamento de projetos e atribuir a gerência de projetos a isto.”

Querem que organizações vejam o planejamento como crucial. fruto de um resultado que não tenha sido por sorte ou competências individuais, mas sim por processo.

PMI não é:

  • um centro de melhores praticas.
  • não preconiza pesada x leve, o pmi é um guarda-chuva. A mensagem do PMI não é que você tem que usar algo “by the book”
  • Não usa metodologias cascata.
  • Não é restritivo x prescritivo. Não tem a pretensão de dizer se um projeto é ou não PMBok.
  • PMI não é um cheklist, regras, especificação ou metodologia. É um guia.

Tem jeito de usar Agile e PMBok ?

Ele diz que é obvio que sim. Eles não são mutualmente excludentes. Isto porque o PMBok é:

  • Uma enciclopédia de melhores práticas.
  • Um livro de ferramentas e não de instruções.
  • Uma loja de comida e não uma receita.
  • É o quê e não o como.

Não existe um caminho único para definir um caminho ideal para o ciclo de vida do projeto. Não existe projeto certificado, quye seja PMBok ou não… a maioria das empresas pegam o framework e customizam de acordo com suas experiências.

Scrum, PMI e VC ? O que tem em comum?

Não importa se você é PMI ou Scrum, mas sim, se você entrega resultado. O que importa é se o seu projeto é bem executado ou não.

Um PMI pode virar scrum master?

Se contribuir para o sucesso, ele tem que ser o primeiro da fila. Tem que se interessar e incorporar o Scrum em sua caixa de ferramentas.

Os melhores gerentes de projeto que ele trabalhou em outras áreas vieram de TI. Estão acostumados a trabalhar com maior velocidade, adaptabilidade e flexibilidade. Isto, segundo ele, abre um mundo de oportunidades. Se quiser, você pode continuar gerenciando software, mas sabendo que pode gerenciar outras áreas.

O grande segredo do scrum é gerenciar bem as mudanças, em um ambiente que muda o tempo todo. Há 50 anos atrás, o mundo era mais lento e mais simples. Agora muda o tempo todo. Sete meses atrás, mudou muita coisa. E quem garante que nao vai mudar de novo?

O que o PMI tem feito em relação à agile?

  • Melhor grupo de interesses do PMI  e o melhor paper de estudantes são de pessoas que tratavam de metodologias ágeis. (isso em 2008). Semana que vem começa a comunidade virtual de agile do PMI.  Por isso, ele diz que não tem cabimento dizer que o PMI não gosta.

Qualquer coisa que você faça para melhorar o que você faz, é válido. Não importa se é PMI, Scrum ou afins.

E porque associamos gerenciamento de projetos a coisas demoradas e pesadas?
O gerenciamento de projetos teve raiz na construção e indústrias. Eram projetos de alto custo e com prazos extremamente longos, a flexibilidade era limitada e controle de prazo e custo rígidos.  Isto fez parte da raiz do PMI

Tecnologia é diferente de construção. Como conseguimos romper esta barreira que agile é só em tecnologia ?

  • Código é usualmente leve, modular e reutiliavel.
  • As máquinas estão cada vez mais baratas.
  • A maioria das dependências são lógicas e não físicas.

Como usar o mesmo conceito em uma plataforma de petróleo?

A quarta edição do PMBok discute este assunto, de como aplicar estes conceitos para o gerenciamento de projetos tradicional. Trata agile como uma das opções para você gerenciar o projeto.

Perguntas respondidas:

1 – Um gerente de projeto pode ser de outra área que não seja software?

  • Ele diz que com uma boa liderança, capacidade de resistir a stress, capacidade de planejar e uma visão holística, pode gerenciar projeto sem ter conhecimento da área. Mas ele precisa de ajuda de um líder técnico.
  • E muitas vezes, em tecnologia, o gerente atua como membro do time.  Mas isto exigirá capacidade maior do gerente de projeto.

2 – O PMI está preparado para equipes auto-gerenciáveis?

  • Para ele, o gerenciamento de projetos é fundamental para os projetos hoje.
  • PMI acredita neste modelo e o palestrante também.
  • A maior parte das pessoas não está preparada para se auto-gerenciar, voce tem que ter uma equipe que esteja madura e pronta para se auto gerenciar.

Minha opinião: Palestra tratou de um tema que sempre gera discussão, e muito se diz sobre a combinação de Scrum e PMI. Porém, na hora que foi perguntado sobre sua real opinião, ele acredita em duas coisas que discordo:

  • Não acredita que exista equipe auto-gerenciada;
  • Acredita na necessidade de um ser central nos projetos, meio que um herói muito capaz, que é o gerente de projeto.

Voltar para o resumo do primeiro dia