sábado, 24 de janeiro de 2009

Retrospectiva Equipe Scrum de Scrum

Oi pessoal,


Segue o resultado da retrospectiva realizada com as equipes do projeto Novo LMS.

Retrospectiva da Equipe de Scrum de Scrum

Emocional
Avaliação da equipe
Constantes entradas / saídas
Prazo do projeto
Redução de prazo
Integração equipe de testes com desenvolvimento

Comentários (Abu): Aqui de novo o problema da avaliação realizada pela empresa e que não teve um resultado conforme a expectativas dos funcionários.
Também foi identificado o problema de entrada e saída de pessoas no inicio do projeto, quando ainda estávamos com o risco do projeto ser cancelado.
Foi muito ruim a demora da definição do prazo de entrega do projeto. O mesmo abalo ocorreu em fase de entrega do projeto, onde foi determinado que o mesmo devesse ser entregue 30 dias antes da data final, decisão esta que foi cancelada e o projeto teve a sua data original mantida.
De novo o lado bom da entrada da equipe de testes no projeto e sua integração tranqüila com a equipe de desenvolvimento.


Organização
Scrum of Scrum

Comentários (Abu): O Scrum de Scrum também foi elogiado e o melhor de tudo, teve a sua origem solicitada pelas próprias equipes.


Produtividade
Comprometimento EaD
Adequação Ferramentas (+)
Entrada do Pinter
Entrada da Dani
Entrada da equipe do CRM
Entrada da equipe de Testes
Entrada do Filipi
Entrada do Helio
Engtrada do Maia
Entrada do DBA
Adequação com plataforma OSx
Equipe de testes integradas com os desenvolvedores
Entrada do Jéferson (Interface)

Comentários (Abu): Na parte de organização nos sentimos falta da equipe de produtos, nosso Product Owner deu um show, mas nosso contato ficou muito fixo apenas a ela.
A produtividade teve seu aumento de velocidade de execução do projeto conforme a entrada de cada novo integrante na equipe. Foi perceptível que a entrada de mais uma pessoa tinha um tempo de adaptação de uma Sprint e depois já podíamos observação que este novo colega inserido no projeto aumentava a produção.


Processual (Scrum)
Treinamento com Ferramentas (-)
Mac Gabriel
Introdução dos testes estruturados
Treinamento CSM
Treinamento CSPO
Maquinas novas equipe CRM

Comentários (Abu): A parte mais importante foi os treinamentos oficiais com o Alexandre Magno e equipe de testes.


Riscos
Infra
Comprometimento EaD
Quantidade de pessoas
Prazo de entrega
Testes
Interface vs Cake
Definição de requisitos
Banco de dados
Prazo para testes / produção (-)
Treinamento

Comentários (Abu): O projeto não teve tempo de se montar uma infra para o desenvolvimento dos sistemas e no fim do projeto passamos por problemas referentes a infra-estrutura.
E um dos riscos mais importante foi o prazo de construção, testes e tempo desejado de entrar em produção.


Tecnológico
Framework
CVS (+)
CVS Tag´s
MySql
Servidor de Homologação

Comentários (Abu): Este projeto teve sua execução com o Framework Cake/PHP e ele se demonstrou um bom Framework.
Ganhamos equipamento, monitores, etc.
So no fim do projeto foi montado o servidor de homologação, no decorrer do projeto todas as entregas e conseqüentemente validações a nossa PO utilizou o servidor de desenvolvimento.
O CVS nos ajudou muito e praticamente não tivemos problemas de merge ou de “orelhadas” por mal uso da ferramenta.


O Scrum de Scrum foi uma das melhores coisas que ocorreram neste projeto e o mesmo vai ser mantido para o gerenciamento de todos os demais projetos.

Também a retrospectiva com a equipe de Scrum de Scrum foi muito rica.

O mais incrível é que o daily meeting de 15 minutos (que as vezes demorava 30) permite com que todos tenham visibilidade de como o projeto estava sendo executado por todas as equipes.

Abraços a todos,

Abu

Retrospectiva da Equipe de Desenvolvimento

Oi pessoal,


Segue o resultado da retrospectiva realizada com as equipes do projeto Novo LMS.

Retrospectiva da Equipe de Desenvolvimento

Emocional
Insatisfação da equipe com a avaliação
Sair da curva de aprendizado e realmente integrar o projeto
Integração de união da equipe
Formação do sentimento de uma equipe única
Saída da paulinha do banco de dados
Pizzas do Abu
Apoio e reconhecimento das partes do Teto de Fabrica
Café da manha de comemoração ao fim de ano e desenvolvimento
Banquetas

Comentários (Abu): A empresa fez uma avaliação dos funcionários, ma esta avaliação não atendeu as expectativas dos avaliados, o que gerou uma insatisfação no trabalho.
A cada novo desenvolvedor que era integrado na equipe existiu um tempo de aprendizado nas tecnologias que estavam sendo utilizado e ao mesmo tempo nos tivemos a preocupação de cada desenvolvedor de se integrar ao novo projeto.
Foi gerado um grande sentimento de equipe, este item foi fantástico.
Durante o projeto a Paulinha teve que ir para um novo projeto, o que deixou um sentimento triste na equipe.
Foi realizados algumas atividades de integração de equipe, como a Pizza do Abu e o café da manha promovido pelo nosso gerente.
Ganhamos no decorrer do projeto um jogo de banquetas, que ajudou muito o trabalho de desenvolvimento em par.


Organização
Comprometimento da EaD
Jorge como Gerente
Falta de informação para trabalho
Re-posicionamento das equipes
Equipe envolvida no daily para conhecimento geral
Separação da equipe de desenvolvimento (márcia/gabriel e filipi/pinter/helio)
Treinamento e certificação Scrum Máster do Gabriel

Comentários (Abu): Na parte de organização nos sentimos falta da equipe de produtos, nosso Product Owner deu um show, mas nosso contato ficou muito fixo apenas a ela.
Também durante o projeto o Jorge virou gerente, o que permitiu uma produtividade maior no decorrer do projeto, pois vários impedimentos focados a custos $$$ ele resolveu muito rápido.
No inicio do projeto teve uma falta de informação, informação como data de entrega, escopo global, pessoas envolvidas, etc. Com a entrada do Jorge na projeto estes itens foram resolvidos.
Um ponto positivo apontado pela equipe foi o daily meeting e a constante organização de lugares conforme as pessoas que estavam trabalhando no mesmo Item de Backlog. Eu sempre tentei manter equipes de 3 pessoas no Maximo, para melhorar a comunicação entre os integrantes de cada equipe.
Também foi apontado como ponto positivo o Gabriel ter feito o curso oficial de Scrum Máster, pois ele trouxe mais organização para a equipe que ele estava inserido.


Produtividade
Entrada do Pinter
Mudanças de Especificação
Especificação Incompletas
Testes e validações antes das entregas pela equipe
Entrada equipe CRM
Divisão em 2 equipes aumentou a produtividade
Entrada do Filipi
Design do sistema
Entrada da Fernanda na equipe de testes
Entrada do Helio
Consultoria Prof. Julia IEA
Gabriel Resolvendo Problemas Infra / DB
SQL´s Filtros Paulinha
Entrada Luiz
Falta de Especificação Filtros
17/18 Treinamento Scorm

Comentários (Abu): a produtividade teve seu aumento de velocidade de execução do projeto conforme a entrada de cada novo desenvolvedor.
Foi perceptível que a entrada de mais uma pessoa tinha um tempo de adaptação uma Sprint e depois já podíamos observação que este novo colega inserido no projeto aumentava a produção.
Também nas nossas lições aprendidas por Sprint iniciamos o processo de validar dentro da equipe os Itens de Backlog que seriam entregues, para não ocorrer erros na apresentação do Sprint Review.
Para aumento de produtividade o gerente viabilizou todos os custos necessários para atender um Tema chamado Padrão Scorm, com consultores e cursos.
Tivemos perda de produtividade com a saída de um desenvolvedor para arrumar itens de Infra-Estrutura.
Tivemos a melhora de produtividade com o trabalho do Fernando Maia na parte de arquitetura da informação de construção das telas.
Também tivemos um ganho de produtividade com a volta da Paulinha para ajudar na construção de filtros de consulta. Este modulo foi criado por uma equipe e a Paulinha fez o trabalho de cadastramento de filtros e validação do modulo.


Processual (Scrum)
Reuniões diárias no posto de trabalho
Entrada da equipe de testes integrada no processo de desenvolvimento
Treinamento da Camila como PO
Em determinada etapa do projeto ficamos “PRESOS” as atividades do quadro
Review e Retrospectiva
Scrum of Scrum
Caixinha de $$
Entrega de Builds

Comentários (Abu): Um ponto positivo foi a realização de Daily Meeting nos próprios postos de trabalho, a integração da equipe de desenvolvimento com a equipe de testes, o treinamento de Product Owner da Camila com o Alexandre Magno.
A equipe também gostou das reuniões de Sprint Review e Sprint Retrospectiva.
A equipe se adaptou a quadro de kanban e quando não tínhamos post-it’s de uma tarefa chegávamos ate mesmo esquecer que a tarefa tinha que ser executada.
Foi criada uma caixa de dinheiro para cada falha que alguém cometia no decorrer dos trabalhos, estas falhas foram chamadas de “orelhadas” e tinha o custo de 1,00 real.
O Scrum de Scrum também foi elogiado e o melhor de tudo, teve a sua origem solicitada pelas próprias equipes.


Riscos
Problemas diversos com servers
Infra
Equipe – Entrada de novo
Scorm
Problemas com o banco de dados
Configuração dos servidores como bibliotecas soap
Banco de dados
Testes

Comentários (Abu): Nos tivemos vários riscos durante o projeto, o interessante que riscos identificados mas que não geraram problemas não foram lembrados na retrospectiva. Apenas riscos que geraram problemas hahahaha
O projeto não teve tempo de se montar uma infra para o desenvolvimento dos sistemas e no fim do projeto passamos por problemas referentes a infra-estrutura.
A entrada de novas pessoas no projeto não trouxe problemas, as equipes receberam os novos integrantes e fizeram de tudo para que a entrada deles fossem o menos traumático possível.
Scorm, banco de dados, testes todos foram tratados e tiveram o maior apoio da gerencia, para que tudo que fosse necessário fosse realizado.


Tecnológico
CVS
Framework
Treinamento dos Novos
Monitores Novos
Maquina de homologação

Comentários (Abu): Este projeto teve sua execução com o Framework Cake/PHP e ele se demonstrou um bom Framework.
Ganhamos equipamento, monitores, etc.
So no fim do projeto foi montado o servidor de homologação, no decorrer do projeto todas as entregas e conseqüentemente validações a nossa PO utilizou o servidor de desenvolvimento.
O CVS nos ajudou muito e praticamente não tivemos problemas de merge ou de “orelhadas” por mal uso da ferramenta.


Então....

Foi um show, o pessoal deu um banho, faz muito tempo que não vejo uma equipe tão grande, tão integrada e principalmente tão assertiva.

Não teve problemas de briga, conflitos, etc

Cada integrante realmente mostrou que agregava valor, isso ficou vivenciado nas entradas e saídas dos colegas no decorrer do projeto.

PO, Infra, Desenvolvedores, Testes, DBA, Design, etc todos realmente agregaram valor ao projeto.

Parabéns a todos,

Abu

sexta-feira, 23 de janeiro de 2009

Retrospectiva da Equipe de Testes

Oi pessoal,


Segue o resultado da retrospectiva realizada com as equipes do projeto Novo LMS.

Retrospectiva da Equipe de Testes

A equipe de testes foi criada no meio do projeto, isto é, com o desenvolvimento já em andamento. No inicio ficamos no processo Waterfall, pois a equipe de testes poderia gerar alguns riscos ao projeto, principalmente na perda da velocidade de desenvolvimento. Após algumas Sprints a equipe de testes foi integrada na mesma Sprint que estava a equipe de desenvolvimento, virando uma equipe única.

Emocional
Integração com a equipe de desenvolvimento
Acolhimento da equipe de testes pela equipe de desenvolvimento
Férias dos estagiários
Confraternização de fim de ano
Saída do Jorge (Estagiário)
Chegada da Fernanda

Comentários (Abu): Como a equipe foi formada no meio do desenvolvimento, teve um processo emocional de preocupação em ser aceito pelos demais colegas de trabalho. Esta aceitação ocorreu naturalmente, o que gerou uma satisfação dos testadores.
Também foi dados aos profissionais de teste de software, inclusive os testadores estagiários um período de férias do natal ao ano novo.
Como a equipe é nova, pela primeira vez eles participaram das comemorações de fim de ano da empresa (que é um show).
Teve uma parte triste, que foi a saída de um colega de trabalho, Jorge Sá. O Jorge foi estudar nos USA.
O ultimo item emocional foi a alegria da equipe com a entrada da analista de testes Fernanda Matos.


Organização
Mudança para o andar de baixo
Mudança do local da equipe de testes
Organização dos testes de forma estruturada
Chegada da Fernanda trouxe mais organização a equipe de testes

Comentários (Abu): Aqui o ponto que mais chama atenção é com relação a onde a equipe de testes passa a ter seus postos de trabalho. Como no inicio o processo era Waterfall eles ficavam no andar de cima da empresa.
Pela necessidade de integração com a equipe de desenvolvimento e de ficar alinhados na mesma Sprint de desenvolvimento eles foram colocados no andar térreo, junto com os demais colegas do projeto.
Também temos o destaque da melhoria da organização de trabalho com a entrada da Fernanda Matos.


Produtividade
Mudança de horário para o período da manha
Divisão das tarefas

Comentário (Abu): Foi dada a possibilidade dos estagiários terem um horário de trabalho no mês de Dezembro e Janeiro flexível e isso foi apontado como um fator de melhoria na produtividade.
Também a distribuição das atividades passa ser mais organizada, com a ajuda da Fernanda.


Processual (Scrum)
Aprendizado coletivo sobre a metodologia
Daily meeting
Reuniões diárias com a equipe de testes

Comentários (Abu): Todos os integrantes da equipe de testes aprenderam Scrum durante a execução do projeto e as reuniões de Daily Meeting foram colocadas como ponto positivo no dia a dia dos trabalhos.


Riscos
Treinamento dos estagiários
Ambiente de testes instável
Equipe de testes inexperiente
Inexperiência
Banco de dados

Comentários (Abu): Os riscos na área de testes foram a falta de conhecimento dos testadores com relação a ferramenta Selenium e PhpUnit.
O ambiente de testes so Selenium não é dos mais estáveis, o que trouxe alguns problemas para o projeto.
E a organização de um banco de dados de apoio a construção e execução dos testes automatizados.

Observação: No final tudo deu certo, os testes automatizados estão muito bons, superou as minhas expectativas. E este foi o primeiro projeto da empresa com um equipe de testes e todas esta parafernália.


Tecnológico
Falta de treinamento
Maquinas novas
Monitor LCD novo
Falta de um equipamento so para executar os testes automatizados

Comentários (Abu): Terminamos o projeto sem uma maquina exclusiva para execução de testes automatizados. Nos executávamos sempre na maquina de um dos testadores.
Os testadores ganharam equipamentos melhores para a execução dos seus trabalhos, pois as primeiras maquinas eram terríveis.
Também ganharam um monitor LCD para a execução dos testes com este tipo de dispositivo.


Meus amigos...

Nos montamos uma equipe de testes no meio do desenvolvimento do projeto. Contratamos estagiários para a execução dos testes. Contratamos uma analista de testes para a melhoria do processo.
Iniciamos a execução dos testes em forma de Waterfall e depois realmente fizemos testes com características agíeis.

Eu so posso resumir os trabalhos destes profissionais com uma frase: “Foi uma das melhores coisas que nos fizemos”, sem a equipe de testes junto, não teríamos chego a aonde chegamos.

Muito obrigado ao Paulinho, Felipe, Marcio e Fernanda.

Abraços a todos,

Abu

Caso de Sucesso Utilizando Scrum – Software Entregue

Oi pessoal,

Segue um conjunto de fotos de um pequeno pedaço do nosso software de LMS que foi desenvolvido utilizando Scrum. Também vai um conjunto de fotos da equipe executando o processo de Scrum.


















Um abraço a todos,

Abu

terça-feira, 20 de janeiro de 2009

Retrospectiva do Product Owner ao Termino do Projeto

Oi pessoal,

Estamos entrando na fase de manutenção do sistema e aproveitando para a realização da retrospectiva do projeto em relação ao desenvolvimento do software.

Segue as informações passadas pela nossa Product Owner, Camila.



- Maior visibilidade do trabalho da TI;
- Maior integração com a Equipe = ótima convivência;
- Aquisição de conhecimentos técnicos de TI que contribuirão para o trabalho no EaD;
- Visão geral do processo;
- Vivência da metodologia Scrum;
- Negociação de prioridades, foi muito positivo, equipe flexível em favor do processo;
- Aprendizado constante, em especial, na priorização de necessidades, adquirindo maior flexibilidade em favor do projeto como um todo;
- Visão de planejamento e gerenciamento de processos;
- Comprometimento da equipe foi muito positivo;
- Troca constante de conhecimento entre os profissionais;
- Respeito pelo espaço e saber do outro;
- Equipe alegre, disponível, atenta às necessidades do outro;
- Ajuda mútua

Obrigado Camila, você realmente fez diferença neste projeto.

Abraços a todos,

Abu

domingo, 18 de janeiro de 2009

Como implantar Scrum?

Oi pessoal,

Segue uma receita de bolo de como podemos implantar Scrum na empresa, estas informações são apenas algumas dicas.

Um bom começo é fazer uma apresentação do Framework para as pessoas que vão trabalhar diretamente no projeto (Equipe), para que todos saibam como funciona e o que eles terão de tarefas agregadas no seu dia a dia. Eu já trabalhei em empresas que não queria nem de perto uma técnica de trabalho que pudesse atrapalhar o processo já existente e desta maneira realizar uma apresentação pode ser uma atividade difícil em ambiente de trabalho. Uma vez um gerente me falou: “Se quer mostrar um processo diferente do nosso, que não seja em horário de trabalho, pois vai atrasar o projeto”.
Então... Apresentamos na hora do almoço ou após o horário de trabalho. Algumas vezes também fora da empresa, em um local mais agradável.

Outra dica é introduzir o deily meeting, pois permite uma comunicação entre os integrantes da equipe. Quase sempre demora muita para as pessoas de fora do projeto perceber o que esta ocorrendo, principalmente quando o daily é realizado de maneira não formal, como tomando café. Mas lembre-se uma vez o Scrum funcionando na sua empresa o daily tem uma serie de itens rigorosos para que ele funcione.

O quadro de kanban é o próximo passo, já que esta sendo realizado daily temos que ter uma visibilidade de como esta indo as tarefas que temos que executar. Eu já vi quadro de kankan escondido ate mesmo dentro do armário. Esta pratica não é boa, pois o objetivo do kanban é visibilidade, porem quando o processo esta sendo implantado de maneira não oficializada pode ser uma alternativa.
Também já vi varias equipes com quadro pequenos colados do lado do micro, no tampão da mesa, etc.

Observação: Ate mesmo quem utiliza processos de gerenciamento de projetos com software (tipo Microsoft Project Server), documentação em Use Case, diagramas de UML, etc. podem utilizar as técnicas de daily e kanban.
A questão é que o kanban pode ajudar o desenvolvedor a mapear todas as tarefas que ele deve executar de um Use Case e o daily permite que todos os desenvolvedores do mesmo projeto saibam como esta indo o trabalho do colega. Isto não é Scrum, mas pode ser uma ajuda a um processo de implantação do Scrum. No mínimo vai ajudar o processo existente.

Pessoal.... Após a equipe conhecer o Framework Scrum, estar praticando daily e ter kanban como ferramenta de apoio podemos implantar outras partes do processo como planejamento de Sprint, seleção de Itens de Backlog por Sprint, contagens de pontos, retrospectiva, review, etc etc etc


Quem desejar maiores informações, uma ajuda pode mandar um e-mail (abuzitos@gmail.com), entrar em contato.

Abraços a todos,

Abu

sexta-feira, 16 de janeiro de 2009

Painel: BayAPLN Agile Expert Panel

Oi pessoal,


A InfoQ Brasil publicou um artigo com as perguntas respondidas por especialistas de desenvolvimento ágil de projetos. O artigo esta publicado em: http://www.infoq.com/br/news/2009/01/BayAPLN-Agile-Expert-Panel

Eu vou responder as perguntas, não sou nenhum grande mestre, mas acredito que posso ajudar com uma visão mais brasileira das respostas.
O artigo também não deixa claro qual a profundidade das respostas que os entrevistadores estavam buscando, eu tomei a liberdade de ir respondendo conforme a minha interpretação das perguntas.
Esta atividade foi muito gostosa de ser realizada, eu espero que as minhas respostas possam ajudar os leitores.

Pergunta (1):
Quais são os principais desafios para a adoção de Agile à nível de empresas e as formas mais eficazes para resolver esse problema?

Resposta:
Mudança cultural. Eu tenho no blog a reportagem com o chefe de TI da rede globo onde ele comenta que os próprios funcionários têm que ter atitude e desta maneira ajudar a mudar a cultura da empresa.
É muito difícil mudar uma cultura quando a alta gerencia não tem interesse, eu mesmo trabalhei em uma empresa que não foi possível implantar técnicas ágeis, mesmo nos meus últimos dias nesta empresa nos tentamos uma união de todos os profissionais do projeto em um único local (sala), quadro de kanban e daily meeting.
Vários dos colegas de trabalho que saíram desta empresa hoje usam Scrum ou outra técnica ágil, mas naquela empresa que trabalhávamos juntos não foi possível.

Pergunta(2):
Como construímos confiança?

Resposta:
Existe vários níveis de confiança, com relação ao cliente é por intermédio do atendimento de suas expectativas. Uma maneira de atender a expectativa do cliente é por intermédio das entregas constantes e também pela visibilidade da execução do projeto.
Com relação a equipe é com o engajamento que se conquista com o trabalho em equipe, gerando cumplicidade entre os integrantes desta equipe.

Pergunta(3):
O que podemos fazer em relação à percepção de que o Agile e design ou experiência de usuário não se misturam muito bem?

Resposta:
Este item eu não sei a resposta, apenas sei que no projeto que estamos entregando ate o dia 23/01/2009 nos temos um profissional na equipe (Fernando Maia) que realizou a arquitetura da informação do projeto e a construção das interfaces dentro do processo ágil de trabalho e ainda fez este trabalho pegando informações com os usuários.
Eu coloco que o profissional é que faz a diferença e esta habilidade do Fernando fez com que esta percepção dentro do projeto não tenha ocorrido.

Pergunta(4):
Como quantificamos os benefícios financeiros de uma organização que quer tornar-se ágil?

Resposta:
Na empresa que eu estou trabalhando (IEA) nos temos o orçamento financeiro do projeto e agora ao termino do projeto que realizamos (projeto este de aproximadamente 8 mil horas de trabalho) esta sendo contabilizados os custos realizados na execução do projeto e confrontados com o orçamento inicial.
Dados que nos já temos é que foi consumido uma quantidade de horas menor do que o orçado para o projeto.
Mas este exemplo que eu passei é o mais simples, tem benefícios que são bem mais difíceis de mensurar, como a melhoria técnicas das equipes, diminuição do risco de impacto no projeto pela perda de um colega de trabalho, entre outros.

Pergunta(5):
Agile deve ser apresentado de forma diferente em diferentes culturas/países?

Resposta:
Eu acho que não, eu aprendi agile com a Martina, onde ela trouxe uma visão de sua aplicação no seu pais (Holanda) e eu peguei o conhecimento passado e apliquei na realidade dos projetos que eu trabalhava.
O conhecimento deve ser passado em sua forma original e cabe ao gestor do projeto (Scrum Máster) ter a flexibilidade / criatividade de adaptar o processo em sua realidade.

Pergunta(6):
Qual é a importância de um coaching para a adoção e o sucesso do Agile?

Resposta:
É o grande ponto chave, inclusive mesmo as equipes que já utilizam as técnicas deve passar constantemente por retrenamento, para que possamos sempre melhorar a forma de trabalho e continuar evoluindo o processo.

Pergunta(7):
Por que gravitamos em direção a simplicidade?

Resposta:
Eu sempre falo que simplicidade sim, porem aderente a uma boa arquitetura, onde deve ser utilizado boas praticas de programação como modelo de patternos, normalização de banco de dados, entre outras técnicas importantes para o desenvolvimento de software.
Se a solução é complicada para ser implementada é sinal que esta complexibilidade é um alerta que devemos entender melhor o problema, antes de achar a solução.

Pergunta(8):
Como você sabe o quanto ensinar?

Resposta:
Eu falo sempre que quando deixamos de simplesmente aplicar as técnicas do Framework de Scrum e passamos a entender o porque de sua utilização, sua origem e principalmente a onde esta técnica que nos levar é a hora que já temos conhecimento suficiente para passa a diante. Mas não devemos dar o peixe e sim devemos ensinar a pescar.

Pergunta(9)
E se o líder não percebe que eles tem um problema?

Resposta:
Problemas existem o tempo todo e as vezes não são identificados pelo Scrum Máster, devemos estimular cada vez mais a comunicação e eu costumo nas reuniões de daily meeting sempre perguntar se alguém esta identificando algum risco para o projeto.

Pergunta(10)
E quanto a tendência de ficar dentro da cultura Agile e aumentar a ciência da cultura atual?

Resposta:
Eu não saquei o objetivo da pergunta.

Pergunta(11)
O que nós podemos fazer se a velocidade do time é medida e eles querem aumentá-la entregando funcionalidade de baixa qualidade?

Resposta:
Qualidade não deve ser negociada. No livro peopleware ele mostra que a busca cada vez mais pela qualidade aumenta a produtividade, vale a pena ler este livro, Tom De Marco da uma aula de gerencia de projetos e principalmente, gerencia de equipes.

Pergunta(12)
Será que as iterações são apenas para treino?

Resposta:
Quando as equipes estão aprendendo as técnicas ágeis sim, mas depois são uma forma de trabalho que permite a busca do sucesso do projeto.

Pergunta(13)
Como você vê o Agile em 2009?

Resposta:
Eu quero ir, quem sabe no agile 2010, 2011, etc. Afinal tem um valor salgado para nos Brasileiros.

Abraços a todos,

Abu

Retrospectiva de Encerramento de Projeto

Oi pessoal,


Este é o registro da execução da Retrospectiva de Encerramento de Projeto. Esta sendo aplicada a técnica de TIMELINE.

Iniciamos a atividade preparando o ambiente para a realização dos trabalhos.



Para os post-its foi criado uma legenda para que os post-its coloridos facilite a categorização do evento que a equipe deseja representar.



A Primeira equipe a realizar a retrospectiva.




A Segunda equipe a realizar a retrospectiva, esta equipe é uma equipe de Scrum de Scrum.







A Terceira equipe a realizar a retrospectiva.










Ao termino das atividades de levantamento de eventos cada colega de trabalho fez uma linha que representa o estado emocional que ele estava em um determinado período de tempo com relação aos eventos ocorridos no projeto.
Um evento pode ser registrado como uma ação positiva ou negativa.

Quem desejar ter mais informações sobre esta técnica basta entrar em contato.

Abraços a todos,

Abu

Agile Development, Agile Design - Web 2.0 Expo Berlin

Oi pessoal,


Esta apresentação mostra a parte de Interfaces (UI) e desenvolvimento ágil.



Abraços a todos,

Abu

quinta-feira, 15 de janeiro de 2009

Atividade: Linha do Tempo (Timeline)

Oi pessoal, segue um post que mostra uma técnica para realizarmos uma reunião de retrospectiva do projeto.

O link original do material é: http://media.pragprog.com/titles/dlret/Activities.pdf

Espero que gostem.


Amplexos,


Abu


------ X -----

Propósito
Estimular lembranças do que aconteceu durante o desenvolvimento do trabalho.
Criar uma imagem do trabalho de muitas perspectivas. Examinando hipóteses sobre quem fez o quê e quando. Ver padrões ou quando os níveis de energia mudaram. Use esse recurso para "apenas os fatos" ou fatos e sentimentos.

Tempo Necessário
Trinta a noventa minutos, dependendo do tamanho do grupo e o tamanho das atividades executadas.

Descrição
A equipe escrever cartas (post-its) para representar as lembranças, que foram significativas para eles, ou outro evento significativo durante a iteração, a liberação, ou projeto e depois publicá-las em (aproximadamente) por ordem cronológica. A retrospectiva apóia o líder da equipe para discutir os acontecimentos e compreender os fatos e sentimentos durante a iteração, libertação, ou projeto.

Passos
1. Inicie a atividade, dizendo "Nós iremos preencher (completar) uma linha de tempo para criar uma figura completa desta iteração / release / projeto. Nos desejamos identificar a perspectiva de cada colega de trabalho.

2. Dividir a equipe em pequenos grupos, não tendo mais que cinco pessoas por grupo. Manter as pessoas que trabalharam em estreita colaboração com todos os outros juntos (afinidade por grupos). É melhor ter dois pequenos grupos que representam uma afinidade do que um grande grupo.
Todos devem pegar os post-its ou canetas, etc.
Certifique-se que cada pessoa tem uma caneta. Devemos lembrar as pessoas para escrever de maneira legível, para que todos possam ler os post-its.

3. Descreva o processo.
Pergunte as pessoas sobre o que ocorreu na iteração / release / projeto, resgatando todos os pontos memoráveis, significativos, eventos importantes, coisas ruins e registre esta informação em post-its um abaixo do outro. Cada post-its só pode ter uma informação.
Relembre ao grupo que o objetivo é de identificar muitas perspectivas. Caso não exista consenso sobre algum dos itens identificados em post-its não tem importância, pois se o item for importante para pelo menos uma das pessoas da equipe, já é suficiente para o seu registro.
A atividade deve durar no máximo 10 minutos.
Pode ser utilizado post-its com cores diferentes, mas deve ser colocada uma legenda que explique o significado de cada cor.
Escrever em letras legíveis.

4. Monitorar a atividade dos debates e a escrita dos post-its. Tomar cuidado para que a atividade consuma muito tempo de debate e desta maneira não gere post-its, caso isso ocorra lembre a equipe que deve iniciar o trabalho de escrever os registros nos post-its.
Quando o grupo já tiver uma pilha de cartões (post-its), convidar as pessoas para começar a publicá-las (veja a Figura).

5. Quando todas as cartas (post-its) estão destacadas, convidar a equipa a analisar a linha de tempo e ver o que outros já publicaram. Após a verificação dos itens publicados, solicite para as pessoas adicionarem novos cartões, caso alguém lembre de algum evento importante e que não foi registrado.

6. Permitir uma pausa antes de realizar a analise da linha do tempo.

Variações
É possível utilizar algumas variações sobre a atividade de linha do tempo. Estas possibilidades podem ser de utilizar materiais como cartões, post-its, canetas coloridas, pontos, etc. Existem diversas formas de estimular o resgate dos fatos e sentimentos ocorridos durante a execução do projeto.

Por exemplo:

Cores para representar Sentimentos: Para se utilizado tanto para fatos e sentimentos para representar estados emocionais.

• Azul = tristeza, raiva, mau
• Vermelho = desafiado, estagnou
• Verde = satisfeito, bem sucedido, energético
• Amarelo = cauteloso, confuso
• Purple = diversão, surpresa, humor
• Salmão = fatigados, sublinhou

Cores para representar Eventos: Para ser utilizado para representar tipos de eventos.

• Amarelo = técnica ou tecnologia relacionados
• Pink = equipe ou pessoas relacionadas
• Verde = organização relacionados

Cores para representar Funções: Para ser utilizado para representar funções (Papeis no projeto).

• Azul = desenvolvedores
• Pink = clientes
• Verde = GQ e ensaios
• Amarelo = escritores técnicos

Cores para representar Temas: Para ser utilizado quando a equipe pretende concentrar em assuntos específicos, usar cores para identificar eventos relacionados a temas específicos.

• Amarelo = equipe comunicação
• Azul = equipamento de utilização
• Pink = relacionamentos com os clientes
• Verde = práticas de engenharia

Você pode escolher o seu próprio esquema de cores com base nos cartões e post-its disponíveis para você.

Materiais e Preparação
Quadro branco, papel de parede, fitas, canetas coloridas, post-its coloridos, etc

Exemplo

Figura: um cronograma para uma retrospectiva que analisou três iterações.
A equipe estava apenas começando retrospectivas e quis olhar para trás mais que apenas uma iteração.

Resumo do Abu

Material
• Quadro
• Canetas Coloridas
• Post-its

Execução
1. Dividir as pessoas em equipes
2. Definir legenda dos cartões
3. Executar a atividade de criar os cartões
4. Criar uma coluna para todos os post-its e colar todos os post-its nesta coluna
5. Revisão da equipe para identificar se não falta nenhum evento ou sentimento
6. Dividir os post-its em colunas que representam as Sprint´s / Iterações / Meses, etc
7. Criar um espaço abaixo das colunas para a adição de um gráfico emocional
8. Cada integrante da equipe desenha uma linha que represente o seu estado emocional no período (sprint)

Legenda
• Verde = Tecnológico
• Amarelo = Emocional
• Salmão = Organização
• Rosa = Produtividade
• Azul = Processual
• Roxo = Riscos

Criando um Produto com Técnicas Ágeis

Oi pessoal,

Segue o texto da criação de um produto adotando as técnicas recomendadas no mundo ágil, esta técnica é utilizada no treinamento de Product Owner oferecido pela Scrum Alliance e que pode ser realizado aqui no Brasil com o Alexandre Magno.

Para a realização dos trabalhos foi agendado três dias de trabalho, sendo que em cada dia apenas duas horas de reunião se fez necessário.

No primeiro dia foi apresentado a agenda e como a dinâmica funciona, sendo esta atividade de no máximo 10 minutos.





Realizamos o trabalho de definir o que é o nosso produto a ser construído, nesta definição buscamos a caracterização das informações:

1 – Nome do produto
2 – Pontos Chaves para Vender
3 – Principais Características do Produto
4 – Requisitos Operacionais do Produto
5 – Gráficos
6 – Quais Benefícios o Nosso Produto traz para o Cliente
7 – Os atributos de Performance e Qualidade que o Produto deve ter

Ao termino das atividades do primeiro dia nos já tínhamos um texto que definia quem é o publico alvo, o que estes clientes possuem de necessidade, o nome do produto, o que este produto possui, o que ele tem de diferencial a seus concorrentes e pontos fortes do nosso produto.




No segundo dia de atividades nos relacionamos os requisitos macros do produto e confrontamos estes requisitos com a nossa definição de produto do primeiro dia. Esta atividade foi bem interessante, pois permitiu identificar requisitos que não fazem parte da nossa definição de produto e a falta de requisitos para atender o que nos definimos como produto.



Também foi possível ao termino do segundo dia definirmos os principais marcos do projeto, bem como a visão de escopo para atender o primeiro marco.



Com o escopo macro definido do primeiro marco, nos definimos os temas a serem tratados nesta entrega. Bem como uma contagem de pontos para ter visibilidade do esforço necessário para a realização do projeto.



Com os pontos identificamos a nossa velocidade e criamos o Product Burndown Chart.



No terceiro dia realizamos a entrega para a gerencia das informações.

Um abraço a todos,

Abu

domingo, 11 de janeiro de 2009

quinta-feira, 8 de janeiro de 2009

Material de Scrum

Oi pessoal,

Eu montei um material de 125 paginas com informações de desenvolvimento ágil. As informações foram retiradas do Blog do Abu e organizadas por assunto.

Segue o índice de conteúdo.

1) Finalmente eu tomei vergonha na cara.. 6

2) Voce sabe o que é Scrum?. 7

3) Palavras de Ken Schwaber 9

4) Mapas Mentais e Scrum.. 10

5) Manifesto Ágil 13

6) Programação Ágil?. 14

7) Qual é a diferença entre Scrum e RUP?. 16

8) Os macacos e as bananas. 18

9) Jogo Scrum.. 19

(Passo: 1) Quantidade de profissionais na equipe Scrum
(Passo: 2) Criar Backlog
(Passo 3) Fazer a classificação dos itens Backlog (priorização)
(Complemento) Priorização
(Passo 4) Equipe identifica a quantidade de pontos de esforço para cada Item do Backlog
(Complemento) Estimativa
(Passo 5) Velocidade da equipe?
(Passo 6) Definir a quantidade de Sprint´s
(Passo 7) Montar Product Burndown Chart
(Passo 8) Montar Release Burndown Chart
(Passo 9) Distribuir Itens do Backlog por Sprint
(Passo 10) Reunião de Planejamento do Sprint (Sprint Planning Meeting)
(Passo 11) Quebrar Sprint Backlog em Tarefas e Estimar o Tempo
(Complemento) Plannig Poker
(Complemento) Software para Planning Poker
(Passo 12) Montar Sprint Burndown Chart
(Complemento) Execução da Sprint
(Passo 13) Reunião de Dally
(Complemento) Reunião de Dally
(Passo 14) Equipe escolhe as Tarefas
(Complemento) Pizza Ágil do Abu - Executando Itens de Backlog
(Complemento) Scrum e Kanban
(Complemento) Quadro de Kanban
(Passo 15) Jogue o dado e descubra quantas tarefas foram realizadas
(Complemento) Tarefas
(Passo 16) Atualizar o Sprint Burndown Chart
(Passo 17) Sprint Review
(Passo 18) Sprint Retrospective
(Passo 19) Atualizar Release Burndown chart
(Passo 20) Atualizar Product Burndown chart
(Passo 21) Se existe outro Sprint volte para o item 9
(Passo 22) Fim do Projeto
(Complemento) Processo SCRUM
(Complemento) Papeis em Scum
(Complemento) ScrumMaster - I
(Complemento) ScrumMaster - II
(Complemento) ScrumMaster - III
(Complemento) Product Owner - I
(Complemento) Product Owner - II

10) Engenharia de Software.. 56
Incremental / Interativo
Waterfall

11) Cartões de História.. 60
Exemplo de Cartão de História
Exemplos de Cartões de Historia
Épicos, Temas e Cartões de Historia
A história de "estória"
Implementando Cartões de Historias Priorizados pelo Product Owner

12) Blog do Abu e Teste de Software.. 77
Como pensa: Desenvolvedores e Testadores de Software
Documentação viva com Teste de Software
Exemplo de Caso de Teste
Testes Tradicionais e Testes Ágeis
Comandos de JUnit
BDD e Scrum
Testando Cartão de História
Documentação viva com Teste de Software II
Melhorando a Confiabilidade do Sistema Durante a Sprint
Exemplos de Testes criados para Cartões de Historia
TDD para o Cartão de Historia – 001
Desenvolvimento Orientado a Testes (TDD)
Story Test-Driven Development

13) Fichas de Auxilio a Implantação do Framework SCRUM... 110
Reuniões Diárias
Implantando Planejamento do Sprint
Definindo o Tamanho do Item de Backlog

14) Caindo na Real 113

15) Lean. 117
LEAN e os 7 desperdícios
Lean – 7 Tipos de Desperdício – ProduçãoA Arte da Guerra - História e Lenda.. 120

16) Software de Gerenciamento de Projetos Scrum e Outros. 121

17) Scrum em Trabalhos Administrativos?. 124

18) Mini Currículo do Instrutor



Quem desejar receber o material, que possui compactado 4 Mb deve encaminhar um e-mail de retorno solicitando o arquivo.

e-mail: abuzitos@gmail.com

Amplexos,

Abu