segunda-feira, 31 de maio de 2010

1+1=3 uma doença de Gerência de Projetos

Um projeto é composto por duas tarefas de um dia de prazo cada uma, o que levaria dois dias para terminar.

Você pega a primeira tarefa e leva um dia para fazer.

No outro dia você retoma um trabalho e depois passa para um outro colega a segunda tarefa. Quando passa tarefa já é o turno da tarde, metade de um dia perdido.

O colega fica feliz que terminou no prazo, mas tem outra tarefa que esta terminando e começa a segunda tarefa do projeto no outro dia. Metade de um dia perdido novamente.

O que era para levar dois dias para terminar consome três dias.

Fonte: http://www.heptagon.com.br/5dgp-5

Bye see you next post

Métodos ágeis e boas práticas no design centrado no usuário

Fonte: http://www.viddler.com/explore/lbalves/videos/4/

Bye see you next post

Palestra F1 AMADi - Design Centrado no Usuário - Caio Cesar

Design centrado no usuário é primordial para desenvolvimento do produto de sofware, usando ou não metodologias ágeis.

Fonte:

http://www.viddler.com/explore/caiocgo/videos/1/

e

http://www.viddler.com/explore/caiocgo/videos/2/

e

http://www.viddler.com/explore/caiocgo/videos/3/

 

Bye see you next post

segunda-feira, 24 de maio de 2010

Deploy continuo, integraçao continua não basta

Excelente apresentação sobre deploy continuo ministrada por Guilherme Silveira. Não basta somente integração continua para ágil é necessário pensar no deploy continuo.

 

http://www.slideshare.net/guilhermecaelum/deploy-continuo-integraao-continua-no-basta

Bye see you next post

quarta-feira, 19 de maio de 2010

Bala de prata somente na literatura

silver_bullet_grips

 

 

 

 

 

 

Quando um projeto de software esta com os seguintes problemas:

  • O cliente reclama que software não esta como solicitou. Pois o projeto foi construído imaginando o que cliente queria e, também baseado em negócios similares. Mas houve pouca comunicação com o cliente;
  • O cliente esta insatisfeito com a prorrogação do prazo de entrega. E esta pensando em romper o contrato;
  • O software já foi consertado várias vezes, mas esta com erros.

A falta de comunicação entre o cliente e a equipe de software (líder e equipe) é principal causa dos problemas.

Claro que alguns clientes não querem envolvimento. Um exemplo é comprar um carro, e pedir o kit completo para não ter envolvimento na montagem do carro, dai vem bancos de couro que você não gosta.

Digamos que este projeto esteja sendo desenvolvido com método cascata e, para solucionar o problema vou tentar aplicar métodos ágeis. Afirmo que não vai funcionar, e mudar de ágil para cascata também não vai funcionar.

Quando um software esta a tempo sendo desenvolvido e refeito, tentar remendar com uma metodologia nova não vai funcionar. A bala de prata é somente na literatura.

Todos os projetos de softwares que vi com estes problemas, acabaram sendo refeitos. E com maior colaboração do cliente.

Alguns clientes culpam a tecnologia, mas o pior problema é a falta de comunicação entre cliente e equipe de software.

Para novo projeto pode ser adotado métodos ágeis com suas boas práticas de TDD, design simples, refatoração, integração continua, ambiente energizado e etc..

Outra alternativa é o método cascata com todo seu processo software e devidos testes.

O sucesso de um projeto de software tem como ponto chave a boa comunicação entre cliente e equipe de software para qualquer metodologia adotada.

Bye see you next post

terça-feira, 18 de maio de 2010

Os Três Estágios de Maturidade de uma Equipe de Software

maturidade[1] 

Uma equipe é falha, porque não é madura para construir um processo ágil que exige auto-organização.

Os Três Estados de uma Equipe em Termos de Maturidade

  • Fase Caótica: a equipe não possui a habilidade, motivação ou ambição para se tornar equipe auto-organizável.
  • Fase Mid-Life (meia idade): a equipe possui algumas habilidades para auto-organização.  Tomando algumas decisões, sem a necessidade de um líder.
  • Fase Madura: a equipe é totalmente auto-organizável e o líder da equipe é espécie de veículo de comunicação, ao invés de um tomador de decisões.

O avanço da equipe para a próxima fase proporciona para líder a visualização da atual fase da mesma.

Equipe Caótica

É uma equipe que tem falta dos seguintes itens:

  • Técnica de conhecimento;
  • Motivação;
  • Ambição.

Fonte: http://5whys.com/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html

Bye see you next post

Falando em Agile 2008: palestra do José Papo

Palestra do José de Papo no Falando em Agile 2008 : Contratação de projetos de Software, manutenção de sistemas e portfólio de projetos com Agilidade.

José Papo é professor da Universidade São Judas, na FIAP e na PUC-SP, além de ser arquiteto de software e usar Scrum, OpenUP e RUP em seu projetos.

Falando em Agile 2008: palestra do José Papo

Fonte: http://blog.caelum.com.br/2009/03/09/falando-em-agile-2008-palestra-jose-papo/
Bye see you next post

domingo, 16 de maio de 2010

Lição de Liderança e Trabalho em Equipe

Lições de Liderança, Motivação e Trabalho em Equipe baseadas no Filme Fomos Heróis.

Fonte: http://www.blogdofabossi.com.br/

e

www.youtube.com/watch?v=ZHfBLc6NKYs

Bye see you next post

quinta-feira, 6 de maio de 2010

STAREAST 2008: Testing Lessons from Extreme Programmers, Elisabeth Hendrickson

Os testadores avisam que Extreme Programming (XP) não tem papel definido para eles na equipe. Contudo, as equipes XP se consideram "infectados por teste”.

Equipes XP praticam TDD, escrevem testes de unidade antes de escrever o código a ser testado. Praticam ATDD escrevendo testes de aceitação antes de implementar uma funcionalidade.

Equipes XP usam a integração contínua para lhes dar resposta rápida sobre os efeitos das mudanças. Programam em pares, uma técnica que resulta na revisão de todo o código antes de ser verificado, as equipes XP testam continuamente desde do primeiro momento de um determinado projeto. Você poderia até chama-lós de "Obcecados por testes". Isso ajuda a explicar a obsessão Elisabeth Hendrickson autora de www.testobsessed.com, que as equipes XP gostam tanto.

Elisabeth passou os últimos anos buscando descobrir como os testadores podem contribuir eficazmente em projetos Extreme Programming. Neste vídeo de sua apresentação principal STAREAST 2008, partes Elisabeth mostra suas experiências e as outras lições que aprendeu com testadores para poderem jogar bem e terem sucesso em equipes XP.

Fonte: video.google.com/videoplay?docid=-3903817398443328799#

Bye see you next post

Chaves Testes Relacionados as Práticas Ágeis

 

    Temos quatros áreas principais de perigo para desenvolvimento ágil: 

    • Ambigüidade: Não saber o que seus clientes querem;

    • Dependências: Escrever ou remover código que irá danificar o aplicativo;

    • Hipóteses: Basear-se em produtos dos outros e não consultar o cliente;

    • Capacidade: Tendo muito ou pouco do que é necessário: Informação, pessoal ou qualquer coisa que possa retardar ou parar o progresso da criação e implantação das iterações.

      Após exposição das áreas de perigo do desenvolvimento ágil, foi apresentado um slide intitulado "8 Chaves Testes Relacionados a Práticas Ágeis”, mas somente foi descrito 7 Chaves Testes:

      1. ATDD – Desenvolvimento Orientado a Testes de Aceitação

      Começar os testes no início, no começo da concepção e ensaio.  No entanto ficará sempre uma questão em mente:

      ”Como a mudança ou adição afetará o resultado final?"

      2. TDP - Teste Dirigido a Práticas

      Fazer expectativa explícita e expulsar ambigüidade. Alinhar as expectativas, a documentação e alavancar o desenvolvimento com foco em resultados executáveis, não afastasse dos requisitos a menos que o projeto possa ser melhorado.

      3. Testes de regressão

      Reduzir a latência e ajustar o projeto de acordo com o feedback (resposta). Corrigindo os defeitos que são detectados, mas não perdendo o foco do curso do teste inicial.

      4. Teste de propriedade coletiva

      Geralmente uma equipe tem inúmeras aplicações.

      Se encontrar um bug numa outra aplicação que não é foco atual da equipe, entretanto é preciso consertar para aplicação foco, partilhar essa descoberta com a equipe explicando como o encontrou e o resolveu.

      Manter a equipe informada acelera o processo de testes e avançará a propriedade coletiva da equipe.

      5. Integração Contínua

      Quando encontrar um bug consertá-lo. O procedimento aconselhável é consertar o defeito e compartilhar a solução com a equipe.

      6. Teste Exploratório

      Teste exploratório é implementado simultaneamente com o desenvolvimento de um aplicativo.

      É uma ótima maneira de se familiarizar com o aplicativo, analisar como reage às situações diferentes.

      Os testes de projeto que você esteja certo que resultará em falha, mantê-los em mente quando estiver escrevendo testes exploratórios

      Receber e dar feedback (resposta) é uma excelente maneira de estudar a direção. E ver se produto esta indo para direção certa.

      7. Ensaio da Entrega

      Mesmo quando aplicativo passou por todos os testes, oferece ao usuário uma experiência comprovadamente positiva, sendo livre virtualmente de defeitos e parecendo pronto para chegar ao mercado: PARE.

      Um dos piores fracassos é o lançamento de produto prematuramente com problema. Testes nem sempre podem prever como uma aplicação vai responder a diferentes entradas.

      O  Ensaio da entrega é uma prática que nenhuma equipe deverá saltar dando um grande valor para forma que público vai reagir ao pedido, avaliando performance e quanta de carga poderá suportar. Quebrando mais cedo ou mais tarde conforme a necessidade.

      Fonte:

      STAREAST: Is my software development organization agile? By Dan Mondello, Assistant Editor

      29 Apr 2010 | SearchSoftwareQuality.com

      Quase todo artigo foi baseado no conteúdo da oradora Elisabeth Hendrickson-STAREAST.

      http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1511177,00.html?track=NL-498&ad=764596&asrc=EM_NLN_11484769&uid=5314741

      Bye see you next post

      Story-Time! O Oculto Scrum Meeting de Kane Mar

      backlog 

      Sua equipe tem dificuldade de previsão em relação ao projeto ser completado? Você tem um grande número de estórias não estimadas no seu product backlog? Suas reuniões de planejamento consomem vários dias e com confrontos? Se for assim, pode ser que você esteja esquecendo crescimento do product backlog.

      Ken Schwaber em geral, informa que a equipe deve dedicar cinco por cento do seu tempo (em todos os Sprint) para cuidado do backlog. Este processo é geralmente conhecido como cuidado ou manutenção do backlog. Uma boa definição:

      “Há muitas coisas na preparação de um backlog para um futuro trabalho. Adição de novas estórias e estórias já existentes, um extrato estórias existentes,  tamanho, adicionar valores para melhorar e assim por diante.”  Dr. Dan Rawsthorne, CST

      Muitos clientes reconhecem a recomendação Schwaber dos cinco por cento, mas não seguem. Eles entendem que precisam gastar cinco por cento do seu tempo no cuidado do backlog, evitando o crescimento ruim. Mas não conseguem fazer isso, conseqüentemente, suas reuniões de planejamento se tornam tensas e longas.

      Kane Mar (O autor) há vários anos defende o cuidado explicito do backlog como parte do Scrum. Ele aconselha as equipes estabelecer uma programação regular com reuniões semanais que durem duas horas. É uma oportunidade para discutir e cuidar do backlog, sendo assim a reunião de planejamento poderá ser eficiente e produtiva. O autor chama essas reuniões "Story-Time".  Embora não seja uma parte formal do Scrum, ele descobriu que “Story-Time” melhora o planejamento do projeto e reduz reuniões de planejamento de confronto, que são comuns para muitas equipes.

      A reunião “Story-Time” deve ser realizada na mesma hora e local todas as semanas e envolvendo toda a equipe, incluindo o PO e Scrum Master. A única intenção desse encontro semanal é trabalhar através do backlog a preparação para o trabalho futuro. Isso pode incluir a adição de novas estórias e já existentes, divisão de estórias grandes e dimensionamento.

      Portanto, se sua equipe passa a maior parte do planejamento de reuniões discutindo sobre semântica, considere as reuniões “Story-Time” como racionalização para previsão. O autor cita que:

      “Eu adoraria saber como ela impacta seu dia-a-dia.”

      Fonte:

      Story-Time! The hidden Scrum meeting by Kane Mar

      Bye see you next post

      terça-feira, 4 de maio de 2010

      Os Cincos Passos Fundamentais Para Melhor Enfrentar o Estresse

      Os cinco passos para melhor enfrentar o estresse:

      1. Identificar a fonte: Se você pode definir o que faz com que estresse, pode examinar a fonte. Isto pode ajuda-ló a antecipar a próxima vez que acontecer.

      2. Decida se o estresse é real ou antecipado. Estresse Real pode ser tratado no momento; estresse antecipado está vivendo no futuro. Deixe o futuro acontecer e viva o momento.

      3. Escolha a sua perspectiva. O quão ruim é o estressor? Considere a fonte e faça a seguinte pergunta: está vendo de forma realística ou embaciado? tendenciosa ou antecipação? Existe uma outra visão que pode levar a esta situação? Você tem uma escolha na perspectiva que escolher.

      4. Lembre-se que a forma como você reage à pessoa e / ou situação irá definir o tom para interações a mais e os níveis de estresse! Escolha a sua abordagem e resposta.

      5. Use a sua rede de apoio. Como família, amigos e seu coach para ajudar a lidar com o estresse.

      Fonte:

      Artigo Stress and Coaching de Anne Rose  http://ht.ly/1GS5X

      Bye see you next post

      Agregando Práticas e Princípios do XP e Lean no Scrum

      Organization chart

      O scrum é usado para controlar e gerenciar o desenvolvimento de software e produto de forma interativa e incremental. Possui:

      • Papéis(Roles);
      • Artefatos(Artifacts);
      • Cerimônias (Cerimonies).

      Geralmente muito adotado pela facilidade de entendimento. Os papéis, artefatos e cerimônias são bem definidos.

      Mas faltam algumas práticas e princípios a mais para construir produto de maneira ágil.

      Agregaria no scrum algumas práticas do xp, como:

      • Teste primeiro e refatoração, ou seja, práticas TDD;
      • Histórias;
      • Design incremental;
      • Integração continua;
      • Ambiente de trabalho informativo;
      • Trabalho energizado e outras práticas conforme as necessidades.

      Agregaria no scrum os seguintes princípios lean:

      • Elimine desperdícios;
      • Inclua a qualidade no processo;
      • Crie conhecimento;
      • Adie comprometimentos;
      • Entregue rápido;
      • Respeite as pessoas;
      • Otimize o TODO.

      Bye see you next post