Abraços,
Abu
quinta-feira, 30 de setembro de 2010
segunda-feira, 27 de setembro de 2010
Scrum e Requisitos por Sprint
Oi pessoal,
Vamos responder a uma pergunta realizada.
Tenho um projeto muito grande, como posso organizar este projeto no Scrum de maneira que eu não tenha uma grande Sprint de analise de sistemas e uma serie de Sprint de execução dos Itens de Backlog.
Bom vamos lá....
1 – Eu vou partir da hipótese que o Product Owner sabe o que ele deseja, isto é, ele sabe os assuntos a serem tratados no projeto, mas ele não tem todos as informações a nível detalhado de cada assunto.
2 – Devemos organizar o nosso Backlog, é uma boa pratica já organizar os requisitos por “Releases”, isto é, “Versões” e dentro de cada Release organizar os requisitos por Sprint's. Devemos lembrar que esta organização é para termos uma visão de tempo que as funcionalidades vão ser desenvolvidas e entregues, mas o Product Owner pode a qualquer momento reorganizar a prioridade do Backlog. O Product Owner não pode apenas mudar uma Sprint que já está em execução.
3 – Já temos o Backlog organizado por Sprint's e Releases, mas devemos lembrar que Scrum não define nenhuma forma de engenharia de software, ele apenas é uma forma de trabalho (Framework). Mas para um projeto de software é importante termos uma organização destes requisitos por grupo de assunto e identificarmos como um grupo se relaciona a outro. Uma boa técnica é um modelo de Domínio, cartão CRC, Modelo de Dados em Alto Nível, etc.
Com este trabalho de agrupamento e mapeamento de relacionamento entre os grupos de assuntos, o nosso desenvolvimento de software vai sofre alterações? A resposta é sim, mas o impacto é bem menor e bem menos traumático do que um trabalho sem a visão de grupos de assuntos. Outro ponto importante é que cada assunto vai ser refinado e a cada refinamento nos temos alteração no nosso sistema.
4 – Com isso passamos a ter um Backlog com requisitos definidos em alto nível e passamos a realizar o entendimento do requisito por Sprint.
Abraço a todos,
Abu
Vamos responder a uma pergunta realizada.
Tenho um projeto muito grande, como posso organizar este projeto no Scrum de maneira que eu não tenha uma grande Sprint de analise de sistemas e uma serie de Sprint de execução dos Itens de Backlog.
Bom vamos lá....
1 – Eu vou partir da hipótese que o Product Owner sabe o que ele deseja, isto é, ele sabe os assuntos a serem tratados no projeto, mas ele não tem todos as informações a nível detalhado de cada assunto.
2 – Devemos organizar o nosso Backlog, é uma boa pratica já organizar os requisitos por “Releases”, isto é, “Versões” e dentro de cada Release organizar os requisitos por Sprint's. Devemos lembrar que esta organização é para termos uma visão de tempo que as funcionalidades vão ser desenvolvidas e entregues, mas o Product Owner pode a qualquer momento reorganizar a prioridade do Backlog. O Product Owner não pode apenas mudar uma Sprint que já está em execução.
3 – Já temos o Backlog organizado por Sprint's e Releases, mas devemos lembrar que Scrum não define nenhuma forma de engenharia de software, ele apenas é uma forma de trabalho (Framework). Mas para um projeto de software é importante termos uma organização destes requisitos por grupo de assunto e identificarmos como um grupo se relaciona a outro. Uma boa técnica é um modelo de Domínio, cartão CRC, Modelo de Dados em Alto Nível, etc.
Com este trabalho de agrupamento e mapeamento de relacionamento entre os grupos de assuntos, o nosso desenvolvimento de software vai sofre alterações? A resposta é sim, mas o impacto é bem menor e bem menos traumático do que um trabalho sem a visão de grupos de assuntos. Outro ponto importante é que cada assunto vai ser refinado e a cada refinamento nos temos alteração no nosso sistema.
4 – Com isso passamos a ter um Backlog com requisitos definidos em alto nível e passamos a realizar o entendimento do requisito por Sprint.
Abraço a todos,
Abu
Dinâmica Carrinho de Papel - ULBRA Torres
Bom dia pessoal,
Este post vem com o material disponibilizado pela professora Caroline Porto, da Turma de Gerência de Projetos do Curso Sistemas de Informação e Superior Tecnólogo em Analise e Desenvolvimento de Sistemas - ULBRA Torres.
Professora Caroline, vou utilizar as palavras de Confúcio: "Ouço e esqueço. Vejo e recordo. Faço e compreendo.".
Parabéns pela sua iniciativa e tenha certeza que seus alunos vão recordar destes momentos e dos conhecimentos adquiridos por muito tempo.
Vamos as fotos...
Fica o meu convite aos alunos para me cadastrar e entrar em contato sempre que desejarem. Segue os meus endereços eletrônicos:
GMail: abuzitos@gmail.com
MSN: nelson_abu@hotmail.com
Skype: nelson_abu
Twitter: twitter.com/abuzitos
ICQ: 92912256
Abraço a todos,
Abu
Este post vem com o material disponibilizado pela professora Caroline Porto, da Turma de Gerência de Projetos do Curso Sistemas de Informação e Superior Tecnólogo em Analise e Desenvolvimento de Sistemas - ULBRA Torres.
Professora Caroline, vou utilizar as palavras de Confúcio: "Ouço e esqueço. Vejo e recordo. Faço e compreendo.".
Parabéns pela sua iniciativa e tenha certeza que seus alunos vão recordar destes momentos e dos conhecimentos adquiridos por muito tempo.
Vamos as fotos...
Fica o meu convite aos alunos para me cadastrar e entrar em contato sempre que desejarem. Segue os meus endereços eletrônicos:
GMail: abuzitos@gmail.com
MSN: nelson_abu@hotmail.com
Skype: nelson_abu
Twitter: twitter.com/abuzitos
ICQ: 92912256
Abraço a todos,
Abu
domingo, 26 de setembro de 2010
Palestra de Scrum na Empresa Certisign
Bom dia pessoal,
Segue as fotos da palestra realizada na empresa Certisign (http://www.certisign.com.br/) no dia 25 de agosto de 2010.
O convite foi realizado pelo amigo Gustavo Monarin e viabilizado pela incrível Maria Teresa (TECA).
Teca e Gustavo a palesta foi muito gratificante, os profissionais da empresa Certisign foram incríveis, eles se envolveram e potencializaram os trabalhos realizados.
Segue as fotos...
Abraço a todos,
Abu
Segue as fotos da palestra realizada na empresa Certisign (http://www.certisign.com.br/) no dia 25 de agosto de 2010.
O convite foi realizado pelo amigo Gustavo Monarin e viabilizado pela incrível Maria Teresa (TECA).
Teca e Gustavo a palesta foi muito gratificante, os profissionais da empresa Certisign foram incríveis, eles se envolveram e potencializaram os trabalhos realizados.
Segue as fotos...
Abraço a todos,
Abu
sexta-feira, 24 de setembro de 2010
quinta-feira, 23 de setembro de 2010
Estágio de Testes - Florianópolis - SC
A JExperts atua na prestação de serviços de consultoria e desenvolvimento de software, oferecendo soluções para a gestão estratégica, tática e operacional de Portfólios, Projetos e Programas.
Com perfil Inovador e atuação destacada nos diversos segmentos empresariais, a JExperts desenvolve soluções adequadas às diversas aplicações organizacionais, sempre primando por excelência na qualidade do desenvolvimento e atendimento a seus clientes.
Requisitos:
Noções de Programação (preferência Java);
Noção do software Eclipse;
Conhecimento em Banco de Dados;
Conhecimento das práticas e princípios de Teste de Software;
Noções sobre qualidade de software;
Conhecimento em Execução de testes.
Qualidades pessoais:
Facilidade para trabalhar em equipe;
Organização;
Capacidade para diagnosticar e reportar problemas;
Ser detalhista e observador.
Atribuições do cargo:
Execução de Teste Cases e Testes Exploratórios;
Aplicação de Técnicas Black Box;
Encontrar Bugs e Reportá-los;
Benefícios:
Bolsa R$ 600,00 + auxílio transporte;
Carga horária: 06h
Contato:
Interessados favor enviar currículo para talita@jexperts.com.br
Com perfil Inovador e atuação destacada nos diversos segmentos empresariais, a JExperts desenvolve soluções adequadas às diversas aplicações organizacionais, sempre primando por excelência na qualidade do desenvolvimento e atendimento a seus clientes.
Requisitos:
Noções de Programação (preferência Java);
Noção do software Eclipse;
Conhecimento em Banco de Dados;
Conhecimento das práticas e princípios de Teste de Software;
Noções sobre qualidade de software;
Conhecimento em Execução de testes.
Qualidades pessoais:
Facilidade para trabalhar em equipe;
Organização;
Capacidade para diagnosticar e reportar problemas;
Ser detalhista e observador.
Atribuições do cargo:
Execução de Teste Cases e Testes Exploratórios;
Aplicação de Técnicas Black Box;
Encontrar Bugs e Reportá-los;
Benefícios:
Bolsa R$ 600,00 + auxílio transporte;
Carga horária: 06h
Contato:
Interessados favor enviar currículo para talita@jexperts.com.br
segunda-feira, 20 de setembro de 2010
Scrum e PMBOK (Iniciação e Planejamento)
Bom dia pessoal,
Uma imagem mostrando como podemos unificar algumas ferramentas do Scrum e do PMBOK para realizarmos o inicio do nosso projeto e o seu planejamento.
Observação: Este material é utilizado para projetos de TI (Infra e Software), com equipes pequenas e multidisciplinares. O material também possui alguma adaptações nas ferramentas, para permitir uma agilidade na sua execução.
Abraços a todos,
Abu
Uma imagem mostrando como podemos unificar algumas ferramentas do Scrum e do PMBOK para realizarmos o inicio do nosso projeto e o seu planejamento.
Observação: Este material é utilizado para projetos de TI (Infra e Software), com equipes pequenas e multidisciplinares. O material também possui alguma adaptações nas ferramentas, para permitir uma agilidade na sua execução.
Abraços a todos,
Abu
terça-feira, 14 de setembro de 2010
Organizando o Backlog
Bom dia pessoal,
Vamos a resposta de uma pergunta que eu recebi, como posso organizar o meu Backlog?
Eu vou postar uma sugestão de organização do Backlog, mas fica o lembrete, é uma proposta, cada empresa deve organizar conforme as suas necessidades.
Vamos montar um Backlog para a Família de Produtos da empresa Microsoft chamado Microsoft Office.
Mas podemos inclusive pegar o exemplo da funcionalidade de negrito e colocar em um Backlog de componentes, pois está funcionalidade existe para vários Produtos da Família Office.
Ter uma organização de funcionalidades por Família e Produto permite encontramos funcionalidades que vão fazer parte do “núcleo” dos nossos produtos.
Ter uma visão de todas as funcionalidades que um Tema possui, permite gerenciarmos as Releases e Sprint's que essas funcionalidades vão ser implementadas, isto é, não temos que implementar todas as funcionalidades de um Tema de uma única vez e sim conforme a priorização do Product Owner.
Abraço a todos,
Abu
Vamos a resposta de uma pergunta que eu recebi, como posso organizar o meu Backlog?
Eu vou postar uma sugestão de organização do Backlog, mas fica o lembrete, é uma proposta, cada empresa deve organizar conforme as suas necessidades.
Vamos montar um Backlog para a Família de Produtos da empresa Microsoft chamado Microsoft Office.
Família de Produtos: Pacote Office
Produto: Word
Tema: Negrito
Pontos: (calculado conforme o esforço para implementar as funcionalidades do Tema)
Funcionalidades: Destacar o texto em negrito
MoSCoW: Must (Priorização do Product Owner)
História: Como um usuário de Word, desejo deixar os textos em negrito, para que eles tenham mais destaque que outras partes do textos.
Solicitante: José da Silva
Release: 1.1 (Release que a funcionalidade vai estar contida)
Sprint: 3 (Sprint da Release que a funcionalidade vai ser implementada)
Notas: (Alguma informação complementar)
Mas podemos inclusive pegar o exemplo da funcionalidade de negrito e colocar em um Backlog de componentes, pois está funcionalidade existe para vários Produtos da Família Office.
Ter uma organização de funcionalidades por Família e Produto permite encontramos funcionalidades que vão fazer parte do “núcleo” dos nossos produtos.
Ter uma visão de todas as funcionalidades que um Tema possui, permite gerenciarmos as Releases e Sprint's que essas funcionalidades vão ser implementadas, isto é, não temos que implementar todas as funcionalidades de um Tema de uma única vez e sim conforme a priorização do Product Owner.
Abraço a todos,
Abu
segunda-feira, 13 de setembro de 2010
Melhorando o Entendimento “Como fazer?”
Boa tarde pessoal,
Este post trata de como podemos melhorar o entendimento das equipes no processo de “resolver” o requisito, isto é, “como fazer?”.
A melhora no entendimento “do como fazer” faz com que a velocidade de implementação da equipe melhore muito, bem como a qualidade do produto a nível de negócio e engenharia.
Com essa História temos que encontrar as tarefas, tarefas que vão resolver o negócio e tarefas que vão testar o sistema.
Ferramenta de Apoio 1 - Interface de Apoio
Ter uma tela que representa a solução do requisito ajuda em muito os profissionais que possuem dificuldade em identificar Tarefas a partir de uma História.
Com a interface é muito mais fácil identificar as Tarefas de Negócio e Tarefas de Testes.
Ferramenta de Apoio 2 – Cartão CRC
Ajuda muito no processo de mapeamento dos domínios que o nosso sistema possui. Montamos um cartão com o nome do domínio (no nosso exemplo Usuários) e perguntamos ao domínio o que ele deve conhecer.
Com este cartão conseguimos identificar as classes que fazem parte do relacionamento e até mesmo a superclasse do nosso domínio.
É uma ótima ferramenta de analise de sistemas, até mesmo porque permite um dialogo fácil com profissionais que não são da área de TI.
Material complementar: http://blogdoabu.blogspot.com/2010/02/um-cartao-de-classe-cartao-crc.html
Ferramenta de Apoio - TDD
A figura mostra o ciclo de vida da implementação de um a História em uma Sprint com a utilização de TDD.
Porem devemos lembrar que nem todas as pessoas estão familiarizadas com o processo de quebrar uma História em Tarefas e estas Tarefas possuírem Tarefas de Testes.
Tarefas
Vamos criar tanto as Tarefas de Negócio quanto as Tarefas de Testes.
Quando a nossa equipe possui um Analista de Testes, o processo de identificação das Tarefas de Testes fica muito mais fácil e a equipe aprende a pensar em testes com o Analista de Testes, melhorando em muito o processo.
Com a existência das Tarefas de Testes a equipe passa a ter um foco de ataque, isto é, ela sabe o que implementar do negócio e o que implementar de testes que validam o negócio. Devemos lembrar que os profissionais que estão familiarizados com o desenvolvimento de testes automatizados, não possuem a necessidade de criar Tarefas de Testes, eles utilizam os testes automatizados como ferramenta de apoio a arquitetura que estão implementando para resolver o requisito de negócio.
Quadro de Tarefas
Colocamos as Tarefas de Testes e de Negócio.
Ferramenta de Apoio - UML
O inicio de um projeto pede uma arquitetura minima necessária para que o nosso sistema seja desenvolvido. Um modelo MVC é um exemplo. Mas devemos lembrar que na nossa equipe nem sempre todos os profissionais tem uma visão clara de como vai funcionar o modelo MVC.
Com o passar do tempo o nosso projeto passa a ser cada vez mais padronizado com modelos arquitetônicos e os profissionais do projeto sabem o que fazer, sem o auxilio de uma arquitetura desenhada graficamente.
Mas enquanto os nossos padrões não estão claros para todos, desenhar alguns diagramas ajuda muito.
A figura mostra o processo de analise orientada a objetos chamada ICONIX.
Mas estas ferramentas não tem necessidade de serem realizadas em software, elas podem ser realizadas em papel e colocadas a visibilidade de todos. Caso o nosso projeto exija documentos em UML para documentação, eles podem ser realizados no fim da Sprint, para diminuir o retrabalho.
Fazer desenhos no fim da Sprint em software, é desenhar o que foi feito, já os desenhos no inicio da Sprint são uma intenção do que pretendemos fazer e que pode ter uma distorção ao final da Sprint, exigindo uma correção dos documentos, caso eles tenham sido realizados em software.
Ferramentas de Apoio e Sprint
Devemos lembrar que todas estas ferramentas devem ser utilizadas respeitando o tamanho da Sprint.
Abraços a todos,
Abu
Este post trata de como podemos melhorar o entendimento das equipes no processo de “resolver” o requisito, isto é, “como fazer?”.
A melhora no entendimento “do como fazer” faz com que a velocidade de implementação da equipe melhore muito, bem como a qualidade do produto a nível de negócio e engenharia.
Exemplo - História: Cadastro de Usuário
Como usuário do sistema, desejo cadastrar uma conta para mim, para que eu possa acessar o sistema.
Com essa História temos que encontrar as tarefas, tarefas que vão resolver o negócio e tarefas que vão testar o sistema.
Ferramenta de Apoio 1 - Interface de Apoio
Ter uma tela que representa a solução do requisito ajuda em muito os profissionais que possuem dificuldade em identificar Tarefas a partir de uma História.
Com a interface é muito mais fácil identificar as Tarefas de Negócio e Tarefas de Testes.
Ferramenta de Apoio 2 – Cartão CRC
Ajuda muito no processo de mapeamento dos domínios que o nosso sistema possui. Montamos um cartão com o nome do domínio (no nosso exemplo Usuários) e perguntamos ao domínio o que ele deve conhecer.
Com este cartão conseguimos identificar as classes que fazem parte do relacionamento e até mesmo a superclasse do nosso domínio.
É uma ótima ferramenta de analise de sistemas, até mesmo porque permite um dialogo fácil com profissionais que não são da área de TI.
Material complementar: http://blogdoabu.blogspot.com/2010/02/um-cartao-de-classe-cartao-crc.html
Ferramenta de Apoio - TDD
A figura mostra o ciclo de vida da implementação de um a História em uma Sprint com a utilização de TDD.
Porem devemos lembrar que nem todas as pessoas estão familiarizadas com o processo de quebrar uma História em Tarefas e estas Tarefas possuírem Tarefas de Testes.
Tarefas
Vamos criar tanto as Tarefas de Negócio quanto as Tarefas de Testes.
Quando a nossa equipe possui um Analista de Testes, o processo de identificação das Tarefas de Testes fica muito mais fácil e a equipe aprende a pensar em testes com o Analista de Testes, melhorando em muito o processo.
Com a existência das Tarefas de Testes a equipe passa a ter um foco de ataque, isto é, ela sabe o que implementar do negócio e o que implementar de testes que validam o negócio. Devemos lembrar que os profissionais que estão familiarizados com o desenvolvimento de testes automatizados, não possuem a necessidade de criar Tarefas de Testes, eles utilizam os testes automatizados como ferramenta de apoio a arquitetura que estão implementando para resolver o requisito de negócio.
Quadro de Tarefas
Colocamos as Tarefas de Testes e de Negócio.
Ferramenta de Apoio - UML
O inicio de um projeto pede uma arquitetura minima necessária para que o nosso sistema seja desenvolvido. Um modelo MVC é um exemplo. Mas devemos lembrar que na nossa equipe nem sempre todos os profissionais tem uma visão clara de como vai funcionar o modelo MVC.
Com o passar do tempo o nosso projeto passa a ser cada vez mais padronizado com modelos arquitetônicos e os profissionais do projeto sabem o que fazer, sem o auxilio de uma arquitetura desenhada graficamente.
Mas enquanto os nossos padrões não estão claros para todos, desenhar alguns diagramas ajuda muito.
A figura mostra o processo de analise orientada a objetos chamada ICONIX.
Mas estas ferramentas não tem necessidade de serem realizadas em software, elas podem ser realizadas em papel e colocadas a visibilidade de todos. Caso o nosso projeto exija documentos em UML para documentação, eles podem ser realizados no fim da Sprint, para diminuir o retrabalho.
Fazer desenhos no fim da Sprint em software, é desenhar o que foi feito, já os desenhos no inicio da Sprint são uma intenção do que pretendemos fazer e que pode ter uma distorção ao final da Sprint, exigindo uma correção dos documentos, caso eles tenham sido realizados em software.
Ferramentas de Apoio e Sprint
Devemos lembrar que todas estas ferramentas devem ser utilizadas respeitando o tamanho da Sprint.
Abraços a todos,
Abu
Itens de Backlog não Executados
Bom dia pessoal,
Este post faz uma observação a Itens de Backlog que não são executados na Sprint e como devemos trabalhar com eles.
Vamos a figura....
Item 1 – Nosso Backlog. Este Backlog vai ser executado no nosso projeto. Devemos lembrar que ele pode sofrer alteração, conforme a necessidade do nosso Product Owner.
Item 2 - É realizado a distribuição dos Itens de Backlog pelas Sprint's. É uma boa pratica (alguns consideram uma perda de tempo, pois a tendencia é mudar). Eu gosto de fazer está distribuição, mas o que nós planejamos não é uma regra, pois a toda Sprint o Product Owner pode priorizar os Itens de Backlog que vão ser executados.
Item 3 – Devemos lembrar que toda Sprint possui data de início e data de termino. Também devemos lembrar que uma vez definida o tamanho da Sprint, este tamanho é respeitado até o fim do projeto.
Item 4 – Organizamos os nossos Itens de Backlog da Sprint com o mais importante na parte de cima e descendo os menos importantes, até chegar no Item de Backlog mesmo importante da Sprint. A equipe deve atacar o primeiro Item de Backlog e conforme não existir mais trabalho para todos no primeiro Item de Backlog vai se abrindo o Item de Backlog que está a baixo, respeitando sempre a priorização do Product Owner.
Seguindo este modelo nós não temos varias Sprint's sendo executadas em paralelo pela mesma equipe. Quando isso ocorre é um sinal de problemas que deve ser analisado com mais calma.
Os Itens de Backlog que não são executados dentro da Sprint, retornam para o Backlog e conforme a priorização do Product Owner a nova Sprint e seus Itens de Backlog são definidos.
Abraço a todos,
Abu
Este post faz uma observação a Itens de Backlog que não são executados na Sprint e como devemos trabalhar com eles.
Vamos a figura....
Item 1 – Nosso Backlog. Este Backlog vai ser executado no nosso projeto. Devemos lembrar que ele pode sofrer alteração, conforme a necessidade do nosso Product Owner.
Item 2 - É realizado a distribuição dos Itens de Backlog pelas Sprint's. É uma boa pratica (alguns consideram uma perda de tempo, pois a tendencia é mudar). Eu gosto de fazer está distribuição, mas o que nós planejamos não é uma regra, pois a toda Sprint o Product Owner pode priorizar os Itens de Backlog que vão ser executados.
Item 3 – Devemos lembrar que toda Sprint possui data de início e data de termino. Também devemos lembrar que uma vez definida o tamanho da Sprint, este tamanho é respeitado até o fim do projeto.
Item 4 – Organizamos os nossos Itens de Backlog da Sprint com o mais importante na parte de cima e descendo os menos importantes, até chegar no Item de Backlog mesmo importante da Sprint. A equipe deve atacar o primeiro Item de Backlog e conforme não existir mais trabalho para todos no primeiro Item de Backlog vai se abrindo o Item de Backlog que está a baixo, respeitando sempre a priorização do Product Owner.
Seguindo este modelo nós não temos varias Sprint's sendo executadas em paralelo pela mesma equipe. Quando isso ocorre é um sinal de problemas que deve ser analisado com mais calma.
Os Itens de Backlog que não são executados dentro da Sprint, retornam para o Backlog e conforme a priorização do Product Owner a nova Sprint e seus Itens de Backlog são definidos.
Abraço a todos,
Abu
sexta-feira, 10 de setembro de 2010
Modelo de Trabalho para Equipes Distribuídas em Projetos de Websites com Scrum
Resumo
Este post mostra uma proposta de trabalho para projetos web com equipes distribuídas que possuem foco em trabalhamos com criação de websites, comércio eletrônico, desenvolvimento de sistemas para web e publicidade online (SEO & SEM). Vamos pegar o exemplo do site da ScrumAlliance (http://www.scrumalliance.org).
Visão do Produto
Apresentação do produto a equipe de desenvolvimento. Pode ser utilizado vídeos, fotos, desenhos, storyboards, etc.
Ilustração 1: Visão do Produto
Backlog
Podemos utilizar os produtos da Google Docs para organizarmos nosso backlog.
Ilustração 2: Itens de Backlog
Sprint
O Item de Backlog deve ser quebrado em tarefas. Para facilitar o processo de análise, podemos levar para a equipe de desenvolvimento uma solução em wireframe, para que facilite o entendimento do requisito. Importante, a equipe pode ajudar no processo de melhoria do wireframe, ele não entra como uma verdade absoluta, entra apenas como um facilitador no processo de análise de sistemas a ser realizado pela equipe.
Uma boa pratica é deixarmos sempre disponível os wireframes e um mapa de navegação do sistema, para que os desenvolvedores tenham uma visão mais completa do projeto.
Ilustração 3: Wireframe de um Item de Backlog
Ilustração 4: Mapa de Navegação
Ilustração 5: Planejamento da Sprint - Item de Backlog X Tarefas
Quadro de Kanban
Ilustração 6: Quadro de Kanban (tarefas)
As tarefas devem ser colocadas em um quadro de Kanban, para que possamos acompanhar a execução dos itens de backlog. Podemos utilizar as ferramentas do Google Docs para está finalidade. Basta recortar e colar a tarefa, para ter a representação do post-it movimentado.
Reuniões Diárias
Ilustração 7: Reuniões Diárias
Todos os dias devemos realizar a nossa reunião de alinhamento de tarefas. No nosso exemplo temos que utilizar uma ferramenta que permita falar e todos escutarem, um exemplo é o skype sendo executado em grupo.
Mantendo a Qualidade
Podemos durante a execução da Sprint reduzir o risco das coisas estarem saindo do planejado, tanto a nível de qualidade como a nível de expectativa do item de backlog. Para podemos sempre estar alinhados a cada liberação do item de backlog pela equipe de desenvolvimento, nós podemos iniciar os testes durante a execução da Sprint, realizando desta maneira um trabalho de prevenção de erros.
Uma boa pratica é ter um servidor que possa receber o código a ser testado / validado pelo Product Owner.
Ilustração 8: A Sprint tem que realizar o processo inteiro
Review
Temos que realizar a entrega dos itens de backlog para o Product Owner, podemos utilizar o mesmo servidor de testes (comentado no item “Mantendo a Qualidade”).
Este item tem que ter o apoio de uma ferramenta de comunicação, como o skype em grupo, para que a apresentação do item de backlog sejá realizado ao Product Owner e o Product Owner possa fazer o aceite total, parcial ou rejeitar o item de backlog.
Ilustração 9: Review
Podemos gerenciar as nossas Review utilizando as ferramentas do Google Docs. Onde registramos os problemas / melhorias identificadas e se um item de backlog foi aceito 100%.
Os problemas / melhorias voltam a ser implementados quando o Product Owner desejar, pois ele é o responsável pela priorização dos itens de backlog.
Ilustração 10: Registro da Review
Retrospectiva
Podemos utilizar as ferramentas do Google Docs para realizar a retrospectiva, pois ela permite com que todos os integrantes do projeto possam escrever os itens da retrospectiva ao mesmo tempo.
Ilustração 11: Retrospectiva
A utilização do Skype em Grupo permite a explicação de cada item adicionado ao quadro de retrospectiva para toda a equipe.
Visão dos Documentos no Google Doc
A próxima figura mostra o jogo de planilhas criadas por Sprint.
Ilustração 12: Planilhas por Sprint
Conclusão
Este post apresentou uma proposta de trabalho, utilizando Google Docs e Skype. Mas podemos também utilizar o Google Talk, que também permite um bate papo em groupo. Podemos também utilizar softwares. Mas a questão não é a ferramenta e sim a sua utilização focada a resultados. A grande questão é como podemos realmente utilizar as ferramentas para repor a perda da comunicação face a face que estamos perdendo com a utilização de equipes distribuídas.
Abraço a todos,
Abu
Este post mostra uma proposta de trabalho para projetos web com equipes distribuídas que possuem foco em trabalhamos com criação de websites, comércio eletrônico, desenvolvimento de sistemas para web e publicidade online (SEO & SEM). Vamos pegar o exemplo do site da ScrumAlliance (http://www.scrumalliance.org).
Visão do Produto
Apresentação do produto a equipe de desenvolvimento. Pode ser utilizado vídeos, fotos, desenhos, storyboards, etc.
Ilustração 1: Visão do Produto
Backlog
Podemos utilizar os produtos da Google Docs para organizarmos nosso backlog.
Ilustração 2: Itens de Backlog
Sprint
O Item de Backlog deve ser quebrado em tarefas. Para facilitar o processo de análise, podemos levar para a equipe de desenvolvimento uma solução em wireframe, para que facilite o entendimento do requisito. Importante, a equipe pode ajudar no processo de melhoria do wireframe, ele não entra como uma verdade absoluta, entra apenas como um facilitador no processo de análise de sistemas a ser realizado pela equipe.
Uma boa pratica é deixarmos sempre disponível os wireframes e um mapa de navegação do sistema, para que os desenvolvedores tenham uma visão mais completa do projeto.
Ilustração 3: Wireframe de um Item de Backlog
Ilustração 4: Mapa de Navegação
Ilustração 5: Planejamento da Sprint - Item de Backlog X Tarefas
Quadro de Kanban
Ilustração 6: Quadro de Kanban (tarefas)
As tarefas devem ser colocadas em um quadro de Kanban, para que possamos acompanhar a execução dos itens de backlog. Podemos utilizar as ferramentas do Google Docs para está finalidade. Basta recortar e colar a tarefa, para ter a representação do post-it movimentado.
Reuniões Diárias
Ilustração 7: Reuniões Diárias
Todos os dias devemos realizar a nossa reunião de alinhamento de tarefas. No nosso exemplo temos que utilizar uma ferramenta que permita falar e todos escutarem, um exemplo é o skype sendo executado em grupo.
Mantendo a Qualidade
Podemos durante a execução da Sprint reduzir o risco das coisas estarem saindo do planejado, tanto a nível de qualidade como a nível de expectativa do item de backlog. Para podemos sempre estar alinhados a cada liberação do item de backlog pela equipe de desenvolvimento, nós podemos iniciar os testes durante a execução da Sprint, realizando desta maneira um trabalho de prevenção de erros.
Uma boa pratica é ter um servidor que possa receber o código a ser testado / validado pelo Product Owner.
Ilustração 8: A Sprint tem que realizar o processo inteiro
Review
Temos que realizar a entrega dos itens de backlog para o Product Owner, podemos utilizar o mesmo servidor de testes (comentado no item “Mantendo a Qualidade”).
Este item tem que ter o apoio de uma ferramenta de comunicação, como o skype em grupo, para que a apresentação do item de backlog sejá realizado ao Product Owner e o Product Owner possa fazer o aceite total, parcial ou rejeitar o item de backlog.
Ilustração 9: Review
Podemos gerenciar as nossas Review utilizando as ferramentas do Google Docs. Onde registramos os problemas / melhorias identificadas e se um item de backlog foi aceito 100%.
Os problemas / melhorias voltam a ser implementados quando o Product Owner desejar, pois ele é o responsável pela priorização dos itens de backlog.
Ilustração 10: Registro da Review
Retrospectiva
Podemos utilizar as ferramentas do Google Docs para realizar a retrospectiva, pois ela permite com que todos os integrantes do projeto possam escrever os itens da retrospectiva ao mesmo tempo.
Ilustração 11: Retrospectiva
A utilização do Skype em Grupo permite a explicação de cada item adicionado ao quadro de retrospectiva para toda a equipe.
Visão dos Documentos no Google Doc
A próxima figura mostra o jogo de planilhas criadas por Sprint.
Ilustração 12: Planilhas por Sprint
Conclusão
Este post apresentou uma proposta de trabalho, utilizando Google Docs e Skype. Mas podemos também utilizar o Google Talk, que também permite um bate papo em groupo. Podemos também utilizar softwares. Mas a questão não é a ferramenta e sim a sua utilização focada a resultados. A grande questão é como podemos realmente utilizar as ferramentas para repor a perda da comunicação face a face que estamos perdendo com a utilização de equipes distribuídas.
Abraço a todos,
Abu
quinta-feira, 9 de setembro de 2010
Real Software Engineering
Oi pessoal,
O vídeo vale a pena ser assistido.
Link original do vídeo: http://confreaks.net/videos/282-lsrc2010-real-software-engineering
PDF da apresentação: http://assets.en.oreilly.com/1/event/40/Real%20Software%20Engineering%20Presentation.pdf
O vídeo vale a pena ser assistido.
Link original do vídeo: http://confreaks.net/videos/282-lsrc2010-real-software-engineering
PDF da apresentação: http://assets.en.oreilly.com/1/event/40/Real%20Software%20Engineering%20Presentation.pdf
Real Software Engineering
Glenn Vanderburg
Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all.
That’s odd, because in every other field, the term “engineering” is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being “anti-engineering” (as they are often described), actually represent the best of engineering principles applied to the task of software development.
quarta-feira, 8 de setembro de 2010
quarta-feira, 1 de setembro de 2010
Florianópolis - Vaga Desenvolvedor Java
Empresa de Telecomunicações, com mais de 19 anos no mercado, procura profissional para atuar no desenvolvimento de sistemas WEB.
Estamos em busca de um profissional Java, com experiência em desenvolvimento web (JSP + Hibernate + MySQL), para dar continuidade a projetos em andamento e atuar no desenvolvimento de novas soluções.
Conhecimentos básicos de Linux são desejáveis.
Interessados enviar currículo com pretensão salarial com o assunto Currículo profissional JAVA, para guilherme.mertens@manteltelecom.com.br
Estamos em busca de um profissional Java, com experiência em desenvolvimento web (JSP + Hibernate + MySQL), para dar continuidade a projetos em andamento e atuar no desenvolvimento de novas soluções.
Conhecimentos básicos de Linux são desejáveis.
Interessados enviar currículo com pretensão salarial com o assunto Currículo profissional JAVA, para guilherme.mertens@manteltelecom.com.br
Assinar:
Postagens (Atom)
Postagens
