Reuniões Diarias

Quem tem algum sucesso para compartilhar nos nossos 5 minutos aconchegantes diários?

**************************************************************************************

- Tudo bem...Existem alguns obstáculos?

- Tudo



Atenciosamente,

Igor Alexandre Pereira de Castro

Workshop - Innovit

Oi pessoal,

Eu recomendo estes dois workshop´s.


Abraços,

Abu

Agile Tales

Oi pessoal,

Faz tempo que eu não coloco videos no Blog, mas este video é muito bom.

O link original: http://www.youtube.com/watch?v=g_Y-eHsADrw




Abraços,

Abu

Exemplo de Cartão de Historia

Retirado do link: http://kw-agiledevelopment.blogspot.com/2008/01/example-of-user-story.html
Oi pessoal,

Encontrei um bom exemplo de cartão de historia.




Observe que o desenho que representa a frente do cartão tem os dados de identificação do cartão de historia. Estes dados são: o numero (0001), o titulo (User Login), a historia do cartão (As a [register user]...) e ainda dados das conversas com o usuário, onde temos um esboço de como deve funcionar a tela e anotações do comportamento esperado.

Na segunda imagem nos temos as informações dos testes (confirmação), mostrando os cenários possíveis e esperados pelo usuário.





Abraços a todos,

Abu

Cartões de Historia

Cartões de historia é uma técnica de captura de requisitos de sistemas, esta técnica surgiu com a metodologia de desenvolvimento chamada de XP (extreme programming), porem podemos utilizar esta técnica com qualquer metodologia de desenvolvimento de sistemas ágeis.

Como “Cartões” têm o objetivo de capturar os requisitos eles se concentram em “quem, o quê e porquê de um recurso, e não como”. Neste ponto ele é igual a varias técnicas de levantamento de requisitos, onde tentamos identificar o que tem que ser feito e não como será feito.

O cartão de historia tem que ser escrito a partir de uma perspectiva do usuário. Desta maneira o cartão não deve possuir jargões técnicos ou informações de design, ou qualquer outra coisa que não seja informações de negocio. Um cartão deve ser escrito com a linguagem no negocio, para que seja compreendido por todos.

Um exemplo de cartão de historias pode ser:

Como um professor gostaria de lançar as notas de meus alunos, para que os alunos possam saber como estão indo na minha matéria.

Como um aluno gostaria de visualizar as minhas notas de modo que eu possa saber o meu desempenho nas disciplinas.

Observe que em ambos os casos estamos buscando um linguajar de negocio e buscando o as necessidades do sistema (em nível de negocio – o que tem que ser feito), mas em nenhum dos exemplos entramos em uma linguagem técnica e nem falamos “como vamos fazer”.

Um bom template de como escrever cartões é:

Como um [usuário papel], quero [meta], para que eu possa [motivo].

A primeira vista podemos achar que a parte do [motivo] não é necessária, mas a utilização do [motivo] nos leva a um entendimento melhor do objetivo pelo qual o cartão é útil. Ele nos ajuda a entender melhor como o requisito funciona e nos da uma idéia melhor para outras características do sistema.

Em Scrum nos buscamos identificar os cartões no inicio do projeto, para que ele de origem ao “Procuct Backlog”. Com os cartões identificados podemos dar origem a priorização e a estimativa dos mesmos.

Uma vez os cartões priorizados para execução em uma sprint eles devem ter os seus detalhes (tarefas) identificados. Não devemos identificar os detalhes de cartões que não fazem parte da sprint, desta maneira evitamos o gasto de energia na sprint corrente em trabalhos que fazem parte de outro momento temporal.

Mas como podemos organizar nossos cartões de historia?

Um cartão de historia deveria ter pelo menos três itens: Informações do cartão, dados de conversa com o usuário e testes de validação do cartão.

Informações do cartão são: nome, descrição da historia, um numero de referencia, estimativa, etc.

Conversas são anotações (lembretes) da historia e não uma especificação completa. Estas anotações servem de apoio para a obtenção de mais detalhes no momento de desenvolvimento, identificando como o software deve funcionar. Tudo que ajude a explicar a funcionalidade deve ser colocado como um item de conversa. É como um conjunto de palavras chaves, mas não tem a necessidade de ficar restrito a uma palavra, pode ser colocada (escrito) como uma frase.

Confirmação (Testes) são os casos de testes no verso do cartão. Os testes possibilitam o entendimento melhor do cartão, ajuda na busca de cenários que os usuários, desenvolvedores / analistas podem não ter pensado. Um cartão (requisito) tem que ser possível de ser testado.

Um cartão de historia tem que possuir uma única responsabilidade, ter cartões de historia com mais de uma responsabilidade dificulta o entendimento, a estimativa e a priorização. Cartões pequenos nos ajudam a realizar uma administração (gestão) do projeto.


Link de Referencia:

http://kw-agiledevelopment.blogspot.com/2008/01/user-stories-answers-on-postcard-please.html
http://kw-agiledevelopment.blogspot.com/2008/01/user-stories.html

Abraços a Todos,

Abu

Yes you can....

Yes you can....
Yes you can....
Yes you can....
Yes you can....


Link original http://www.implementingscrum.com/blog/2008/03/19/hot-scrummaster-replaces-original-scrummaster-yes-yes-we-can/


Isso é um perigo em gestão de projetos, não podemos dar “amem” para tudo. Negociações são necessárias, sem duvidas, mas devemos lembrar que o objetivo do Scrum Master é garantir o sucesso do projeto.
Devemos tomar cuidado em não favorecermos interesses pessoais e sim, “sempre”, interesses do projeto.
As vezes ficamos preocupados em não desagradar algum membro da equipe, com alguma decisão que devemos tomar, mas infelizmente (ou felizmente) as nossas tomadas de decisão são sempre (e tem que ser) em favor do projeto.

Abraços


Abu

BDD e Scrum

(1)
Chapéus indicam papéis. Uma pessoa pode assumir mais de uma função, ou Papéis diferentes em momentos diferentes.

(Abu): Em Scrum as equipes são generalistas, todos os integrantes da equipe devem e podem executar vários papeis, conforme a necessidade do projeto

(2)
Um testador, desenvolvedor e perito em domínio se reúnem com o dono do produto (Product Owner) para entendimento das histórias. Gradualmente as historias são decompostas e quebradas em um conjunto de especificações mais simples.

(Abu): Quase sempre as historias possuem mais de uma responsabilidade, esta sobrecarga de responsabilidade é o que nos chamamos de “Temas de Historia”. Uma historia com características de “Temas” devem ser quebradas em historias menores. O ideal é que uma historia possua apenas uma responsabilidade. Uma historia com apenas uma responsabilidade pode ser decomposta em “Tarefas” e executadas pela equipe.

(3)
O dono do produto (Product Owner) decide quais as historias vão ser trabalhadas e detalhadas na iteração. O escopo fechado da iteração não pode ser modificado.

(Abu): Em Scrum nos falamos que no planejamento da Sprint o Product Owner escolhe os Itens de Backlog que devem ser executados na Sprint. Os itens escolhidos pelo product Owner e comprometidos de serem entregues pela equipe não podem ser modificados.

(4)
Todos os comportamentos esquecidos pela equipe na iteração atual de trabalho, deve ser deixado para a próxima iteração. Estes comportamentos devem ser priorizados com o Product Owner para a definição da iteração correta de sua execução.

(Abu):Dentro da execução da Sprint vão ser encontrados novos comportamentos que a equipe não conseguiu identificar na reunião de planejamento da Sprint. Neste caso, estes comportamentos devem ser colocados como novos Itens de Backlog e no momento correto (Planejamento da Sprint) priorizado pelo Product Owner, para ser executado. Não devemos colocar mais Itens de Backlog numa Sprint que já esta negociada, pois corre o risco de não poder ser entregue o que já foi comprometido.

(5)
Desenvolvimento dos instrumentos de especificações, criação de erros e implementação das funcionalidades.

(Abu): Neste item a equipe desenvolve os artefatos necessários para o sistema, cria os testes (TDD) para que eles falhem e desenvolvem as funcionalidades esperadas pelo software. Esta é uma técnica de desenvolvimento, onde após os testes terem falhados, nos criamos as funcionalidades que permitam com que os testes cheguem ao resultado esperado. Um desenvolvimento focado a teste faz com que nosso código fique mais simples e principalmente coeso. Eu gosto muito dos testes, eles permitem a identificação e implementação de classes e métodos mais simples.

(6)
Depois que todos os testes forem passando, a história pode ser demonstrada ao dono do produto (Product Owner). Deve ser realizado testes manuais também.

(Abu): Em Scrum nos falamos que o Product Owner sempre esta presente e por estar presente ele sabe o que esta sendo entregue ou não. Mas mesmo com a sua presença nos temos uma reunião de Sprint Review, onde nesta reunião é oficializado o que esta sendo entregue e o que não foi possível de ser entregue, bem como a justificativa dos problemas encontrados. Mas o termo “Done” é definido junto com o Product Owner e deve fazer parte do conceito de “pronto” a execução e aprovação de todas as funcionalidades pelos testes. Também deve ser realizado testes manuais, que permitem a avaliação do produto como um “todo”. Fica a minha dica de utilização do software “Selenium” junto com o teste manual, para que este teste manual se torne um teste automatizado.


Abraços a todos,

Abu

Ronaldo

Bom dia pessoal,

Gastar energia em tarefas que não agregam valor nenhum ao cliente realmente é perda de tempo e dinheiro.
Quem nunca passou por uma situação parecida com a historinha a acima que atire a primeira pedra. Mas devemos aprender com os erros. Eu já participei de vários projetos em que os gerentes mandavam a equipe para a produção sem prioridades e atividades claras, mas todos nos (equipe) tínhamos trabalho. Muitos desses trabalhos se perdem, por serem desnecessários.
Alguns argumentos utilizados pelos gerentes para a situação apresentada foram:

Iniciem o trabalho, para que o cliente veja produtividade e pague a fatura do mês;
Vamos trabalhar, enquanto nos gerentes analisamos o que temos que fazer;
Vamos manter a equipe ocupada, assim não corre o risco de mandarem embora os que estão sem atividades.

Mas a situação que mais me deixava chateado era tarefas que não servia para nada e que após o projeto possuir um planejamento, estas tarefas teriam que ser refeitas.

Fica uma sugestão, uma dica, coloque a equipe em produção no momento correto, ou você gerente vai perder a confiança e o respeito da equipe.


Abraços a todos,

Abu

Gestão Ágil de Projetos com Scrum Florianopolis / Teamware

Oi pessoal,


Olha o curso que vai ser realizado aqui em Floripa. O curso não é meu, estou apenas fazendo propaganda.

Link original: http://teamware.com.br/cms/index.php?option=com_attend_events&task=view&id=50&Itemid=26

Abraços a todos,


Abu


------------------------


Treinamento Gestão Ágil de Projetos com Scrum SC


Objetivos:

Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades:

* Utilizar Scrum para gerir o trabalho como membro de uma equipe de desenvolvimento de produtos.
* Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento.
* Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum.
* Melhorar continuamente a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento.
* Melhorar continuamente a produtividade da equipe de desenvolvimento de todas as formas possíveis.
* Melhorar continuamente as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável.

Metodologia de Treinamento

Usaremos muitos exercícios durante o treinamento. Depois do treinamento não somente você entenderá Scrum, como sentirá a diferença. Este treinamento oferecerá o sentimento do Scrum em si mesmo.

O primeiro parte do treinamento é dedicado ao porquê e à Filosofia do Scrum. Durante o segundo momento descobriremos as ferramentas e o Como do Scrum.

Usando histórias, estudos de caso e experiências ensinaremos a metodologia Scrum e como aplicá-la para ser um gerente de projetos ágeis ou um membro de uma equipe usando Scrum para gerenciar o seu dia a dia.

AGENDA

Fundamentos de agilidade e Scrum, executando projetos com Scrum, planejando e escalando projetos Scrum, desenvolvimento offshore usando Scrum, orçando contratos de preço e data fixos, assegurando as práticas de engenharia.

* O que é Scrum?
* O que é o fluxo do Scrum?
* O que significa desenvolvimento iterativo e incremental?
* Planejamento e estimativas ágeis
* Retrospectivas de Sprints
* Planejamento estratégico e planejamento tático
* A Reunião Diária de Scrum e como trabalhar com uma lista de tarefas
* O Jogo da Velocidade - planejando e fazendo em ação

Materiais do curso por participante

* Uma Apostila do Treinamento por participante (Em português)
* Um CD com a metodologia Scrum, artigos e material de treinamento sobre Scrum (em ingles)
* Um Jogo de cartas de “Planning Poker” por participante
* Um Certificado de Participação do Treinamento “Gestão Ágil de Projetos com Scrum”



Dados do Treinamento

Duração

16 hrs.

Data e local

Dias 12 e 13 de Maio de 2008

Fundação Certi - Campus da UFSC, setor C, (ao lado do prédio da arquitetura).

Florianopolis

Investimento

O investimento para este workshop e a certificação é de R$ 1100,00

Inclui todos os materiais, licenças, certificado, materiais de treinamento, coffe-breaks e almoços.

Ver formas de pagamento no formulário de inscrição

Maiores informações envie suas duvidas e informações de contato para eventos@teamware.com.br

Informações sujeitas a mudança sem prévio aviso