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
quinta-feira, 30 de outubro de 2008
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:
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 é:
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
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 é:
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)
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)
Conversas com o Product Owner
Como o desenvolvedor (EU) pensou nas funcionalidades
Confesso que após estes itens eu achei que estava podendo hahahahaha
Como o analista de testes pensou nas funcionalidades
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
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
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).
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)
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)
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
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.
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:
------------------------------------------
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
------------------------------------------
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
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:
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
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
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
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.
.jpg)
.jpg)
.jpg)
Abraços a todos,
Abu
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.
.jpg)
.jpg)
.jpg)
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....
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....
Assinar:
Postagens (Atom)
Postagens
