quinta-feira, 30 de outubro de 2008

Testes Tradicionais e Testes Ágeis

Oi pessoal,

Este post traz uma visão do Teste de Software realizado de maneira Tradicional e de maneira Ágil.

O texto traz partes retiradas do artigo Agile QA/Testing de Elisabeth Hendrickson, mas este post não tem o objetivo de ser uma tradução do artigo. Seguindo esta visão o texto possui contribuições minhas e da Neilza. Temos também o vídeo da apresentação da Elisabeth, que é indiscutivelmente uma das melhores apresentações que eu já assisti sobre teste de software.

Link do PDF original: http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf





Teste de software de maneira Tradicional

Nós não vivemos no mundo perfeito onde os requisitos levantados no início do projeto não vão mudar, e o entendimento desses requisitos será possível junto com a tarefa de seu levantamento.

No mundo perfeito o processo levantamento de requisitos, design, codificação e testes será feito uma única vez, pois nesta única execução ele já vai ser realizado de maneira correta.

O teste de software executado de maneira tradicional irá realizar o teste após o término da análise, design e codificação, e os erros encontrados serão entradas do processo de análise, onde o analista de sistemas realiza a validação do erro encontrado pela equipe de testes e após o trabalho do analista de sistemas, é executado o processo de maneira seqüencial, isto é, design, codificação e teste novamente (figura 1).

Um problema que ocorre na não existência de um mundo perfeito é que os cronogramas de projetos não comportam o processo de análise, design, codificação e teste mais que uma vez.

Quando esse processo é executado mais de uma vez, acarreta em impactos nos cronogramas e consequentemente na tríplice restrição: Escopo, tempo e custo, que traz impacto direto na qualidade.



Na falta do mundo perfeito os gerentes do projeto na hora de estabilizar o cronograma realizam cortes de tempo, o que acarreta em impacto na qualidade (tríplice restrição), assim o primeiro tempo a ser cortado é o tempo dos testes de software (figura 2).

Como software nada mais é que algoritmo implementado, o tempo de codificação é sempre protegido o máximo possível, sem código implementado não existe teste e é nessa visão de execução que o teste é punido.



Testes Ágeis

Para a implementação de técnicas ágeis no ambiente de testes, temos a necessidade de mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdução ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, este item faz parte do manifesto ágil. Desta maneira passamos a fazer um trabalho mais próximo com o cliente, onde a sua participação no processo é peça chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes e não apenas o analista de testes. Em ágil nós falamos que a equipe é infectada por testes e desta maneira o sistema é construído para estar testado desde o início do projeto e não apenas no fim da codificação.

A qualidade passa a ser da equipe e não apenas dos analistas de testes ou profissionais que possuem a palavra “Qualidade” nos seus cargos.

O projeto que nasce com cobertura de teste desde início permite Teste de Regressão, que é executar testes em todo o sistema e não apenas na funcionalidade implementada.

Ter um sistema com cobertura de testes desde o início, é realizar o máximo possível de uma cobertura automatizada de testes, para que o trabalho manual e repetitivo não venha a ocorrer.

Esta técnica traz ganho de tempo na execução do teste, onde o custo de transformar um caso de teste em automatizado rapidamente se paga. Eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a terceira vez que eu executo a bateria de testes, eu já vejo como este custo de 30% saiu barato.

O tempo de execução do automatizado com relação ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento realizar um teste de regressão são maiores.

Os testes de maneira ágil devem seguir o conceito de pequenas interações, para que a informação de retorno como está sendo construído o sistema e os erros que existem sejam rapidamente identificados e corrigidos. O término de uma interação deve ter todos os testes executados com êxito (figura 3).



Eu gosto muito da frase:”Como nós iremos testar isso?”, que deve ser utilizada juntamente com a frase: “Como nós vamos construir isso”.


Os desenvolvedores e os testadores devem fazer parte de uma mesma equipe, para que exista colaboração e comunicação entre eles. Assim conseguiremos criar o conceito de equipe e poderemos realizar a condução dos testes e do desenvolvimento do sistema como uma única equipe, isto é, todos juntos, onde os acompanhamentos da execução do desenvolvimento e da execução de testes estão sincronizados, e estes profissionais acompanham a execução, falha e status de ok do código validado pelos testes.


É uma mudança de paradigma, mas é uma mudança que trás resultados rápidos e perceptíveis.

Abraços, Abu e Neilza.

quarta-feira, 29 de outubro de 2008

Exemplo de Caso de Teste

Como o Abu fala, olá pessoal...

Eu vou mostrar como podemos idealizar um documento de caso de teste. Este template é utilizado com Uses Cases. Mas para frente eu faço um post de teste de software e Cartões de História.

Um Use Case da origem a vários casos de teste e estes casos de teste são colocados em um documento chamado Plano de Teste.

O Plano de Teste pode ser construído até mesmo em um documento de Excel e deve possuir as colunas de acordo com a necessidade(processo) de cada empresa:




1)Cenário: Fluxo de execução, como nos casos de uso, que temos fluxo principal, alternativos ou de exceção. Esta técnica descreve os requisitos;

2)Caso: número do caso de teste, serve para gerenciamento dos casos de teste

3)Versão: versão do teste, onde a primeira execução o teste esta com o número 1, na segunda execução o número vai ser 2 e assim por diante;

4)Executor: quem executa o teste;

5)Cenário Testes: é um status do teste, isto é, pode ser: verifica, ordena, busca, grava, etc.

6)Caso Teste: os caminhos necessários para a interação entre o ser humano (testador) e o software

7)Resultado Esperado: o que o software deve apresentar de resultado após a execução do caso de teste

8)Execução: controle do caso de teste, onde é mostrado se o mesmo já foi executado, não possui erros, não foi possível de ser executado, etc

9)Data: data da execução do caso de teste

10)Observação: é colocados informações pertinentes aos resultados obtidos na execução do caso de teste


Como podemos observar este documento é possível de ser criado quando nós temos muita informação do que deve ser testado, daí a sua utilização com Uses Case.
Em processos de desenvolvimento de software formais, isto é, onde temos papéis e responsabilidades bem definidos e equipes com perfil por habilidade, esta técnica demonstra a sua importância no auxílio da qualidade do produto que está sendo gerado, mas a questão é:


“Como criar testes em ambientes de desenvolvimento de software que o aprendizado do que deve ser feito é de maneira empírica?”

“Como criar testes de software quando não temos Uses Case e sim Cartões de História?”


Vamos responder estes itens nos próximos post, por hora, para quem está inserido em desenvolvimento de software NÃO AGIL, fica este post como uma contribuição.

Abraços a todos,

Neilza

segunda-feira, 27 de outubro de 2008

Documentação viva com Teste de Software

Oi pessoal, segue mais um post da serie referente a Testes de Software, mostrando como eu estou implantando os testes automatizados e documentação nos projetos que estou trabalhando no momento. Aqui segue algumas dicas que eu recebi da Neilza (Analista de Testes) e que foram realmente aplicados.

Um dos problemas existentes com a documentação de sistemas é que esta documentação é uma representação simbólica. Apenas o código é a documentação verdadeira do que o software faz (executa).

É comum a documentação ficar obsoleta, pelos mais diversos motivos que ocorrem em projetos de desenvolvimento de software. Um dos males desta desatualização da documentação é que ela pode levar a entendimentos errados do que o algoritmo esta programado a executar. A muito se ouve a frase: Pior que a inexistência de documentação é a documentação que esta desatualizada.

Eu tenho aplicado junto a equipe de teste de software a materialização da documentação em testes automatizados, onde o teste automatizado realiza a execução de cenários principais e alternativos dos requisitos implementados. O teste passa a ser a documentação do sistema e neste caso eu não estou falando de testes unitários e sim testes de funcionalidades.

Eu tenho utilizado em meus projetos a ferramenta Selenium, que permite a captura da interação humana com o sistema e materializa em um script que pode ser executado de maneira automatizada.

Cada teste do Selenium capturado e adicionado ao projeto recebe um cenário de execução explicativo, em forma de JavaDoc (Pode ser RubyDoc, PHPDoc, etc).

Quando desejamos saber o que um domínio forte de informação faz, basta abrirmos os testes que ele possui. Cada domínio possui um conjunto de classes de teste, que representam as regras e comportamentos esperados deste domínio.

Para que o entendimento destas regras não fique em algoritmo, o que é restritivo para o entendimento de profissionais não familiarizados com algoritmo é criado métodos com o nome o mais próximo possível a funcionalidade esperada e o cenário de execução da funcionalidade.

Um exemplo de como representamos este cenário de execução é:
O ator faz...
O sistema faz...
O ator faz...
O sistema faz...
O sistema faz...


Com esta técnica podemos gerar a qualquer momento um relatório com as funcionalidades que um domínio possui e ainda executar estas funcionalidades para saber se os resultados obtidos são os resultados esperados.

Sempre que realizamos uma manutenção corretiva ou evolutiva em uma funcionalidade do sistema, podemos provocar efeitos colaterais a outros módulos do sistema. A única maneira de saber se estes efeitos indesejados provocaram um efeito colateral ao sistema é a realização dos testes necessários.

Com esta técnica de captura de testes pelo Selenium, nos podemos realizar testes de regressão a qualquer momento.

A nova funcionalidade deve ser registrada nos programas de teste, para que os algoritmos de testes de software mais os textos explicativos fiquem em conformidade ao algoritmo testado. É software testando software e a documentação explicando o que esta sendo testado.

Como os algoritmos de testes são pequenos, ate mesmo um cenário desatualizado fica de fácil entendimento pela equipe de TI, permitindo a sua correção. O esforço de uma correção de um cenário de teste é bem menor que o esforço da correção de uma documentação mais abrangente, pois podemos rapidamente validar se o algoritmo de teste faz o que ele deveria fazer, ao contrario de uma documentação mais abrangente como um Use Case.

Este post fica como uma lição aprendida minha.

Abraços,

Abu

Obs.: Muito obrigado pela ajuda Dona Patroa (Neilza)

domingo, 26 de outubro de 2008

Como pensa: Desenvolvedores e Testadores de Software

Oi pessoal, segue o primeiro post sobre teste de software. Neste primeiro post eu e a Neilza buscamos mostrar a diferença que existe na forma de pensar do desenvolvedor de software e o analista de teste de software.

Para mostrar esta diferença foi pego um requisito e apresentado aos dois profissionais, analista de teste de software e desenvolvedor de software.

Requisito (em forma de cartão de historia)

Como um aluno desejo calcular a media final da disciplina cursada, de modo que eu possa saber se estou aprovado ou de exame.


Conversas com o Product Owner

2 notas, PR1 e PR2
Media: 7,0
Mínimo: 4,0 para poder fazer exame
Calculo: (PR1 + PR2) / 7,0


Como o desenvolvedor (EU) pensou nas funcionalidades


1) Verificar se PR1 esta com valor null
2) Verificar se PR2 esta com valor null
3) Verificar se PR1 tem valor maior que 10
4) Verificar se PR2 tem valor maior que 10
5) Calcular a media
6) Mostrar mensagem de aprovado, reprovado ou exame


Confesso que após estes itens eu achei que estava podendo hahahahaha

Como o analista de testes pensou nas funcionalidades

1) Primeiro ele montou casos de testes com ênfase em o aluno estar logado
2) Depois o caso de teste já se preocupou em como a funcionalidade vai estar disponível no sistema, com por exemplo um item de menu
3) Fez casos de teste pensando na UI (interface), se preocupando com os campos de apresentação da informação (tamanho, habilitado/desabilitado, ordem de preenchimento, etc)
4) Fez casos de testes pensando nas probabilidades de entrada de dados, PR1 igual a vazio, PR2 igual a vazio, notas maiores que 10, etc. Para cada combinação existiu a preocupação com a apresentação das mensagens ao usuário
5) Fez casos de testes com dados cadastrados no banco de dados, para que o processamento das medias e apresentação das mensagens correspondentes fossem passiveis de ser testadas


O item deste exercício que mais me chamou a atenção foi a quantidade de casos de testes criados para um problema tão simples, como um calculo de media de uma disciplina cursada por um aluno. Eu não coloquei os casos de teste e sim fiz um resumo dos itens que ele tratava.

A lição aprendida que tirei deste exercício é que o desenvolvimento orientado ao comportamento, isto é, o teste idealizado pelo analista de teste faz com que após o termino do desenvolvimento a minha funcionalidade implementada esteja em conformidade com as expectativas criadas pelo analista de testes. Desta forma a minha funcionalidade implementada não terá apontamentos de erros ou itens abertos por falta de analise de sistemas.

Eu já participei de projetos que a quantidade de apontamentos de erros ou falta de comportamento para uma Use Case era muito maior que a quantidade de funcionalidade que o Use Case tinha.

Outra lição aprendida é que a analise de sistemas realizada pelo analista de teste e o desenvolvedor de software faz com que os erros de falta de especificação seja diminuída, pois cada um dos “Papeis” ataca a sua responsabilidade no sistema. Isso fica claro na questão do usuário estar logado e as necessidades de como executar a funcionalidade, por exemplo, um item de menu.

Este item mostra claramente a vantagem das equipes multidisciplinares e ainda a vantagem de toda a equipe estar junta no processo de analise de sistemas.

Um abraço a todos,

Abu e Neilza

Blog do Abu e Teste de Software

Oi pessoal, vamos iniciar uma serie de posts sobre teste de software com a ajuda da patroa do Abu, a Sra Abu (Neilza Andrea Abu Samra Rahal).




Já faz tempo que estamos querendo fazer uma casadinha (alem do relacionamento marido e mulher já existente) mostrando como o desenvolvimento ágil de software e a área de testes de software pode caminhar juntos.

Como primeiro post fica o link de dois vídeos que já existia no Blog do Abu sobre teste de software.

Primeiro link: Fala sobre desenvolvimento de software focado a comportamento (Behaviour Driven Development - BDD).

http://blogdoabu.blogspot.com/2007/09/beyond-test-driven-development.html

Segundo Link: Fala sobre Agile QA/Testing

http://blogdoabu.blogspot.com/2007/08/agile-testing.html

Terceiro Link: É o pdf da apresentação do link anterior

http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf

Quarto Link: É um dos link's que eu mais gosto, é sobre BDD e mostra como funciona o processo de desenvolvimento de software utilizando esta metodologia.

http://blogdoabu.blogspot.com/2008/04/bdd-e-scrum.html


Abraços a todos,

Abu e Neilza

terça-feira, 21 de outubro de 2008

VAGA: Arquiteto de Informação

A Knowtec Ltda, empresa do ramo de Tecnologia da Comunicação e Informação, seleciona candidatos para o cargo de Arquiteto de Informação. A contratação é imediata.



Requisitos mínimos para o exercício do cargo são:

Graduado ou graduando em fase de conclusão em Ciências da Computação, Sistemas de Informação, Processamento de Dados, Design Gráfico ou Web Design;
Experiência em produção de wireframes de macro e micro arquiteturas;
Conhecimentos avançados em usabilidade;
Facilidade de trabalhar em equipe, criatividade e agilidade;
Disponibilidade de horário: das 8h às 18 h - 8 horas diárias;
A empresa oferece:



• Remuneração compatível com a função;

• Benefícios: Vale transporte + Vale Alimentação ou Refeição

• Contratação: CLT



Local de trabalho: Rodovia SC 401, n.º 600, Módulo 6 Conjunto B – Bairro João Paulo – Parq Alfa Tec - Florianópolis - SCA



Knowtec atua no mercado desde 2001. Concentra suas atividades nas áreas de Inteligência Competitiva, Monitoramento de Mídia Online e desenvolvimento de softwares. Possui uma equipe formada por profissionais especialistas em análise de sistemas, comunicação e biblioteconomia.



Se este é o seu perfil, então venha trabalhar conosco. Envie seu currículo resumido para rh@knowtec.com (item Assunto: Vaga Arquiteto de Informação), até o dia 27/10.



Nossa matriz está localizada em Florianópolis, mas temos uma filial em Seattle (EUA).

sábado, 18 de outubro de 2008

Mapas Mentais e Scrum

Boa noite pessoal, este post é em homenagem ao meu amigo Victor Hugo Germano, que publicou no seu Blog (A Maldita Comédia) o post original sobre esse assunto - Scrum Checklist no MindMeister.

Primeiramente vamos mostrar o link do software utilizado para gerar Mapas Mentais de Maneira On-Line (http://www.mindmeister.com/).

Agora, vamos passar o link do mapa mental criado pelo Victor Hugo Germano referente ao Scrum Checklist (http://www.mindmeister.com/maps/show_public/10105831)

Eu so fa deste guri, so quem já trabalhou com ele sabe o excelente profissional que ele é.


Para quem não conhece Mapas Mentais, segue o Link sobre o que é mapa mental e como criar (http://www.mapasmentais.com.br/artigos/para_que_mm.asp)

Link de exemplos de mapas mentais:

Festas
Churrascos



Terminamos este post com a imagem do Mapa Mental Criado por Victor Hugo Germano





Abraços a todos e parabéns Victor por mais uma contribuição para a comunidade Agil do Brasil.

Nelson Abu

segunda-feira, 13 de outubro de 2008

Curso: Gerenciamento de Projetos de Softwares com Scrum

APESENTAÇÃO DO CURSO:
------------------------------------------
Nome: Gerenciamento de Projetos de Software com Scrum
Carga horária: 16h

O curso apresenta aos alunos a metodologia de gerenciamento de projetos de software que vem revolucionando o mercado. Esteja preparado para aplicar Scrum na sua empresa, e entenda como e porque gigantes como Yahoo, Microsoft e Google vêm obtendo excelentes resultados com o uso desta abordagem. O objetivo do curso é de preparar profissionais para darem início às experiências com a abordagem ágil Scrum em seus projetos.

PROGRAMA:
------------------------------------------
1. O que é gerenciamento ágil de projetos?
2. Manifesto Ágil
3. Papeis e Responsabilidades de um projeto utilizando Scrum
4. Equipes em Scrum
5. Definindo um projeto
. Identificando Requisitos (Itens de Backlog)
. Use Case X Cartão de Historia
6. Realizando o planejamento de execução do projeto
. Priorização
. Estimativa
7. Calculando o Prazo de Entrega do Projeto
. Quantidade de Sprints
. Itens de Backlog por Sprint
8. Gráficos de Acompanhamento do Projeto
. Product Burndown Chart
. Sprint Burndown Chart
. Release Burndown Chart
9. Planejamento da Sprint (Sprint Planning)
. Identificação de tarefas
. Estimativa das tarefas
10. Executando o Projeto
. Quadro de tarefas (post-its)
. Reuniões diárias
. Equipe auto-organizavel
11. Reuniões de termino de Sprint
. Sprint Retrospectiva
. Sprint Review
12. Scrum aplicado a outros seguimentos.

INFORMAÇÕES:
------------------------------------------
Data e horário: Dias 29 e 31/Outubro e 05 e 07/Novembro das 18:15h as 22:15h

Local: ACATE – Associação Catarinense de Empresas de Tecnologia - Rua Lauro Linhares, 589 - Auditório do 1° Andar - Trindade - Florianópolis - SC

Investimento: R$ 685,00 por pessoa, com desconto de 5% para empresas associadas a ACATE.

Forma de pagamento: depósito bancário na conta corrente abaixo:
Banco: 001 – Banco do Brasil - Agência: 1453-2 - Conta Corrente: 33.470-7 Nome do Titular: DSOFT SISTEMAS LTDA - CNPJ: 04.088.505/0001-00
Obs.: os valores serão devolvidos caso o curso seja cancelado por não atingir o número mínimo de participantes.

Informações: Com Samya Campana, pelo fone (48) 3028-6119, ou pelo e-mail cursos@dsoftsistemas.com.br.


Material: Os alunos receberão apostila, material para acompanhamento das aulas e certificado de participação.

Informações adicionais: Veja maiores informações sobre o curso: http://www.dsoftsistemas.com.br/page10.aspx

Sobre o SCRUM:
------------------------------------------
Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a área de desenvolvimento de software, pelo especialista Ken Schwaber. Ken define Scrum, em um de seus livros, como: "um processo Ágil ou ainda um framework para gerenciamento de projetos Ágeis". O nome foi inspirado numa jogada de Rugby. Após uma "reunião" (agrupamento em torno da bola), o objetivo é retirar os obstáculos à frente do jogador que correrá com a bola, para que possa avançar o máximo possível no campo e marcar pontos. Dentre as técnicas de utilização do Scrum, há a entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores a uma semana ou superiores a trinta dias.

Mini-currículo do instrutor:
------------------------------------------
Prof. Nelson Abu Samra Rahal Junior, especialista em gerenciamento de projetos ágeis, graduado em Processamento de Dados, pós-graduação em Didática e Metodologia de Ensino, pós-graduação em Gerência de Projetos para a Área de TI (PMI), Mestrado em Ciência da Computação e Certificado em Scrum Master.


FICHA DE PRE-INSCRICAO:
------------------------------------------
Solicitamos que seja encaminhado o comprovante de depósito para o e-mail: cursos@dsoftsistemas.com.br ou por fax: (48) 3028-6119 e que seja preechida e enviada a ficha de inscrição abaixo:
Nome:
Telefone:
e-mail:
Empresa:
Dados para Emissão da NF:
Nome/Razão Social: CPF/CNPJ:
Endereço:

REALIZACAO:
------------------------------------------
DSOFT SISTEMAS, CURSOS E PROJETOS DE TI
Telefone: (48) 3028-6119
Site: www.dsoftsistemas.com.br

Todos os nossos cursos podem ser personalizados e realizados in-company para satisfazer os requerimentos e as necessidades da sua empresa. Para maiores informações visite http://www.dsoftsistemas.com.br/page4.aspx

Fotos do Treinamento de Scrum na Estácio de Sá

Bom dia pessoal,

Segue a relação de fotos tiradas no encontro de 8 horas de scrum na Estácio de Sá. Neste encontro foi realizada a união das turmas de Gestão em Sistemas de Informação e Tecnologia em Redes de Computadores.

Também tivemos a participação de várias empresas, o que permitir o enriquecimento do treinamento.

No treinamento foi utilizado o tabuleiro desenvolvido por mim chamado de o Jogo do Scrum, o que permite um acompanhamento do processo de maneira Lúdica.

Com este treinamento eu chego a mais de 300 alunos em treinamento de Scrum utilizando o tabuleiro do Jogo do Scrum.



Este tabuleiro pode ser utilizado por qualquer pessoa, para ajudar na implantação do processo do Scrum.

Quem tiver duvidas sobre o processo ou sobre o tabuleiro pode entrar em contato.

Um muito obrigado ao professor Sergio que viabilizou o encontro e o treinamento.

Amplexos,

Abu









quarta-feira, 8 de outubro de 2008

Scrum e Kanban

Bom dia pessoal,


A pergunta é: Porque o quadro de acompanhamento de execução de tarefas é importante?

Uma resposta rápida é: “Viabiliza a comunicação e visibilidade entre os integrantes da equipe”.

Mas um quadro de post-its permite muito mais, ele permite o acompanhamento da construção de um Item de Backlog, onde cada fase da construção de uma peça, que faz parte do Item de Backlog pode ser rapidamente identificada pela equipe.

Se um Item de Backlog possui 10 tarefas, apenas ao termino da execução dessas 10 tarefas que o Item de Backlog vai estar terminado.

Esta técnica tem fundamentação cientifica, conforme o texto a baixo:

Kanban é uma palavra japonesa que significa literalmente registro ou placa visível.

Em Administração da produção significa um cartão de sinalização que controla os fluxos de produção em uma indústria. O cartão pode ser substituido por outro sistema de sinalização, como luzes, caixas vazias e até locais vazios demarcados.

Coloca-se um Kanban em peças ou partes específicas de uma linha de produção, para indicar a entrega de uma determinada quantidade. Quando se esgotarem todas as peças, o mesmo aviso é levado ao seu ponto de partida, onde se converte num novo pedido para mais peças. Quando for recebido o cartão ou quando não há nenhuma peça na caixa ou no local definido, então deve-se movimentar, produzir ou solicitar a produção da peça.

O Kanban permite agilizar a entrega e a produção de peças. Pode ser empregado em indústrias montadoras, desde que o nível de produção não oscile em demasia. Os Kanbans físicos (cartões ou caixas) transitam entre os locais de armazenagem e produção substituindo formulários e outras formas de solicitar peças, permitindo enfim que a produção se realize Just in time - metodologia desenvolvida e aperfeiçoada por Taiichi Ohno e Toyota Sakichi conhecida como Sistema Toyota de Produção.

PACE, João Henrique. O Kanban na prática. Rio de janeiro:Qualitymark, 2003. ISBN 85-7303-4-1-7
RITZMAN, Larry P. Administração da produção e operações. São Paulo: Prentice Hall, 2004. ISBN 85-87918-38-9.


Referencia do texto: http://pt.wikipedia.org/wiki/Kanban




Podemos melhorar a definição de aplicabilidade desta tecnica incluindo o seu uso na produção de software, como em Scrum.

Segue fotos de um quadro de post-its criados pelo meu colega Gabriel (Scrum Master de um dos projetos da emrpesa) - Blog do Gabriel Vieira: http://gabrielscrum.blogspot.com/.






A parte mais dificil da utilização dos post-its é a identificação das tarefas necessarias para a execução de um Item de Backlog. Sem a identificação dessas tarefas não temos como identificar tarefas não previstas e nem mesmo identificar a quantidade de horas necessarias para a produção do Item de Backlog.

O levantamento de tarefas de um Item de Backlog no Planejamento da Sprint demonstra que o processo Scrum esta bem maduro na equipe que esta executando o projeto.

Mas falamos mais sobre a identificação de tarefas em outro momento, neste post vamos ficar apenas como o nosso “Kanban”.


Abraços a todos,

Abu

terça-feira, 7 de outubro de 2008

Unidade (Não quebre em áreas)

Não quebre em áreas

Muitas empresas separam design, desenvolvimento, redação, suporte e marketing em áreas isoladas. Enquanto a especialização tem suas vantagens, também cria uma situação em que os funcionários só enxergam seus próprios mundos ao invés da aplicação web como um todo.

Integre sua equipe ao máximo para que exista um diálogo contínuo em todas as etapas do processo. Faça um sistema de verificações e balanços. Não deixe que coisas se percam nas transcrições. Tenha redatores trabalhando com designers. Faça com que os desenvolvedores tenham ciência dos pedidos de suporte.

Melhor ainda, contrate pessoas com múltiplos talentos, que podem atuar em diversas frentes. O resultado final será um produto mais harmonioso.

Retirado do Livro: Caindo na Real


E é esta criatividade e sinergia que a Equipe de profissionais do IEA (Instituto de Estudos Avançados – http://www.iea.org.br) possui. Podemos observar a “criatividade” (ate de mais) no dia de meu aniversario.
Obrigado a todos do Instituto, pelas oportunidades criadas e confiança depositada ao agora, um ano mais velho Abuzitos.






















Abraços a todos,

Abu

segunda-feira, 6 de outubro de 2008

Pizza Ágil do Abu - Executando Itens de Backlog

Bom dia pessoal,

Hoje vamos falar de como iniciar a execução dos itens de Backlog, utilizando o exemplo de como fazer pizza.
Quando nos temos uma relação de itens de backlog a serem executados por uma equipe, a equipe deve utilizar o conceito de todos contra um, isto é, a equipe inteira ataca a execução do item de backlog.
Mas o que deve ser feito quando não existe trabalho para todos da equipe no item de backlog?
A resposta é simples, abrimos a execução de um novo item de backlog e alocamos o resto da equipe que não tinha tarefas a serem executadas no item inicial. Desta maneira abrimos a execução de itens de backlog conforme a quantidade de integrantes existentes na nossa equipe.

Mas como fica na execução da pizza?

A equipe do projeto de produção de pizza foi de 4 pessoas.

3 pessoas da equipe fizeram o processo de abertura da massa de pizza, sendo que a cada massa aberta um dos integrantes do item de backlog “abrir massa de pizza” realizada a tarefa “pré-assar massa de pizza”.

Em paralelo um integrante da equipe realizou o item de backlog “cortar: lingüiças, tomates e cebola”. Pois não tinha como ele participar do primeiro item de backlog “abrir massa de pizza”.

Ao termino das massas de pizza abertas e pré-assados, pode dar inicio ao item de backlog “montar pizza com sabores desejados”. Neste item de backlog foi iniciado com os 3 colegas que tinham terminado o item de backlog “abrir massa de pizza” e durante a execução do item de backlog “montar pizza com sabores desejados” foi acrescentado o 4 colega da equipe, pois o mesmo já tinha terminado o seu item de backlog “cortar: lingüiças, tomates e cebola”.

Com as massas de pizzas já montadas com os sabores desejados, foi dado o inicio do item de backlog “assar pizzas”, que foi realizado apenas por um integrante da equipe, pois a tarefa so comportava uma pessoa.

A cada pizza assado foi dado o inicio o item de backlog “cortar pizza em fatias” e o item de backlog “servir os convidados”, que pode ser realizados pelos colegas de equipe que estavam sem atividades.

Também foi realizada em paralelo por um colega a compra de matérias primas para a pizza, pois a mesma terminou antes de todos os discos de pizzas estarem montados. É neste momento que falamos que não adianta tentar prever tudo antes do inicio do projeto, pois é na execução que achamos riscos eminentes.

Eu tinha previsto apenas 8 discos de pizza com 1 Kg de queijo e na execução a receita que sempre é exata gerou 10 discos de pizzas, faltando queijo. Eu faço pizza todos sábados e nunca uma receita gerou tantos discos de pizzas, para vermos que por mais que exista experiência em uma atividade que sempre realizamos, sempre podem ocorrer situações imprevistas, pois nunca teremos controle sobre tudo.

RECEITA DA PIZZA - 8 Pizzas

1 – Kg de farinha
1/2 - Litro de água morna
30 – Gramas de fermento
1 – Colher de açúcar (a que utilizamos para tomar sopa)
1/3 – Colher de sal (a que utilizamos para tomar sopa)
6 – Colheres de Óleo (a que utilizamos para tomar sopa)


COMO PREPARAR

Coloque a água, depois o fermento, depois o sal, depois o açúcar, mecha bem.
Coloque a farinha aos poucos e vai amassando, ate virar uma massa bem sequinha e lisa.
Deixe crescer por 30 minutos
Abra os discos
De uma pré-assada nos discos
Monte a pizza com o sabor desejado
Asse as pizzas.













Abraços a todos,

Abu

sábado, 4 de outubro de 2008

Software para Planning Poker

Boa noite pessoal (Sabado - 23:27) esposa trabalhando aqui do meu lado e eu batendo perna na internet. O lado bom da situação é que estou podendo ler e rever sites que a tempos não visito.

Neste vai e vem em páginas web eu encontrei um software que permite a criação de Cartões de História e permite jogarmos Porker para a contagem de pontos dessas histórias.



Link: http://www.mountaingoatsoftware.com/products/poker

Um exemplo:

Criando um Jogo de Poker


Definindo o Requisito


Formatando em Cartão de História


Seleciona a Carta de Pontos Desejado


O software permite que os jogadores participarem ao mesmo tempo. É como um Fórum de bate papo, porém a comunicação entre as pessoas está nas cartas selecionadas e o grupo de bate papo é o Cartão de História selecionado.

Imagem de término do jogo para um Cartão de História


Imagem dos participantes do Jogo


O melhor de tudo, é feito em Ruby.

Abraços a todos,

e boa noite....