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

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.

Deploy continuo, integraçao continua não basta

View more presentations from Guilherme Silveira.

Fonte:

 

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

Bye see you next post

Respeito Lean – Construindo a cultura da conservação

Criar uma cultura que sustente todos os funcionários consiste na geração de respostas positivas as perguntas: O meu trabalho é valorizado? A minha opinião conta? Novas idéias são bem vindas? Pessoas são tratadas com respeito? Eu sou avaliado e recompensado no meu desempenho? O ato de liderança é com integridade?

Desafio da comunidade Lean é explicar a verdadeira natureza de respeito mútuo para as pessoas, gestores e colaboradores. Para todos irem na melhor direção na resolução de seus problemas.

O autor do artigo ligou para Norman Bodek, presidente do PCS Press, que contribuiu com artigo com sua convicção: "Se não derem às pessoas um trabalho que elas possam sair com um sentimento de respeito, algo está errado."

Em seguida, ele destacou três etapas para a criação de uma cultura de conservação através do respeito pelas pessoas:

"Etapa # 1 - Capacitar o trabalhador." Cita Jidoka.

Um conceito inteligente e pioneiro do Sr. Toyoda. Permitindo que trabalhador controlasse várias máquinas. Capacitando o trabalhador a solucionar um problema com qualidade.

"Etapa # 2 - Todo mundo faz parte da equipe", afirma Bodek.

As pessoas sentem-se respeitadas quando fazem parte de uma equipe. No Japão, após 10 anos no cargo, um funcionário tornar-se um líder do grupo ou algum cargo similar. O investimento em treinamento do funcionário é pago com serviços de qualidade. Investir em pessoas vale pena para empresa.

"Etapa # 3 - Rápido e fácil kaizen." Bodek descreve o benefício como: "Em vez de esperar a gestão mudar o meu trabalho, agora estou com poderes para mudar a mim mesmo. Tenho o poder de fazer coisas criativas no trabalho."

Isto pode traduzir-se em obter idéias criativas de cada funcionário. De acordo com Bodek, "A média empresa no Japão economiza $4000 por ano por funcionário. Um ano atrás a Subaru teve 108 idéias implementadas por trabalhador.”

As pessoas continuarão nas empresas se continuarem sendo ouvidas e envolvidas. Fatores fortes motivacionais para conservação.

Fonte:http://leanconnections.com/lean-management-articles/respect-for-people

Artigo: Respect for People

Nothing Adds Value to Lean Like Respect for People
By Adam Zak

Bye see you next post

Bala de prata somente na literatura

Quando um projeto de software esta com os seguintes problemas:

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

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 um porta copo ou direção hidráulica que você não tem necessidade. Ou pedir pão na padaria e não dizer como quer, apesar de ter pão fresco você recebe pão quase fresco.

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 a culpa realmente foi do projeto que ficou distante do desejo do cliente.

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 é método cascata com todo seu processo software e qualidade pelos testes. O projeto de software orientado ao cliente.

Mas a colaboração do cliente é primordial para qualquer método escolhido.

Claro que a empresa corre o risco de perder o projeto. Já vi empresas perderem projetos, mas também vi empresas dando a volta por cima refazendo os projetos.

Bye see you next post

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

 

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

22 minutos de Reunião

fonte: www.youtube.com/watch?v=z6536UbT_QA&fmt=18

Bye see you next post

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

Podcast #7 – Lean Software Development - Bluesoft

Podcast #7 - Lean Software Development from Bluesoft on Vimeo.

Fonte: http://vimeo.com/11494695

Bye see you next post

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

 

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

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

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