Oi pessoal, o projeto aqui na empresa está indo muito bem.
Na correria do projeto não deu tempo de realizar post's referentes ao seu andamento. Mas vamos colocar alguns itens que merecem ser registrados.
Foi utilizado durante todo o ciclo de vida do projeto conceitos de Lean. Os nossos projetos aqui são de criação de produtos (hardware e software) e manutenção evolutiva de produtos já existentes.
Para a implantação do processo foi utilizado o quadro de Kanban, que tem algumas características diferentes do nosso quadro tradicional de Taskboard do Scrum.
Foi realizado durante toda a fase do projeto a busca constante da redução de desperdício e a busca do "menos". Conseguimos manter este foco graças a equipe existente na empresa e a filosofia que já existia na corporação.
Em varias reuniões o comercial (Fernando) e o engenheiro chefe (Thiago), buscavam o foco no que realmente agregava valor ao produto.
Segue algumas fotos do nosso quadro de kanban
Itens não previstos
Processo de negocio do produto “Portal”
Fotos da fabrica e de vários produtos.
Abraços a todos, e um muito obrigado a equipe da GTT.
Abu
quinta-feira, 24 de setembro de 2009
sexta-feira, 18 de setembro de 2009
Criando UML em seu Blog, Wikis, Forum, etc
Oi pessoal,
Meu amigo Tomita que mandou este link. Ele deve estar com saudades dos dias em que passávamos o dia inteiro apenas modelando diagramas.
http://yuml.me/
Abraço a todos,
Abu
Meu amigo Tomita que mandou este link. Ele deve estar com saudades dos dias em que passávamos o dia inteiro apenas modelando diagramas.
http://yuml.me/
Abraço a todos,
Abu
quinta-feira, 17 de setembro de 2009
Scrum vs. Kanban: FIGHT!
quarta-feira, 16 de setembro de 2009
terça-feira, 15 de setembro de 2009
Balsamiq Mockups
Oi pessoal,
Segue fotos de um software para criamos protótipo de tela muito bom.
Link: Site
Abraços,
Abu
Segue fotos de um software para criamos protótipo de tela muito bom.
Link: Site
Abraços,
Abu
sexta-feira, 11 de setembro de 2009
Requisitos - Quanto de detalhes são necessários?
Oi pessoal,
Já que recebi alguns chat e e-mails elogiando o post de requisitos vamos para mais um. A área de analise de sistemas eu gosto muito e já trabalhei muito tempo como analista de sistema.
É muito gostoso descobrir os requisitos e fazer a análise do entendimento de cada requisito identificado.
A questão é: Quanto de informação eu tenho que ter para permitir o entendimento do requisito?
Eu não sei se o desenho dos Bolos cai bem, mas o objetivo das fotos é que ambas são de bolo, mas uma foto possui muito mais detalhes de acabamento e enfeite que o outro. Desta maneira um bolo demora muito mais para ser feito que o outro.
No caso dos requisitos os fatores que nos levam a colocar mais informação ou uma quantidade de informações menores são:
Estes itens apresentados cai muito bem com relação a Use Cases e Cartão de História. Eu utilizo os dois, conforme as características do projeto que estou participando. Mas o Cartão de História funciona muito bem com os itens:
Clientes são amplamente envolvidos
Equipe junto (Não separada geograficamente)
A equipe de testes faz parte da análise de sistemas
Estes três itens são utilizados em Scrum, quando nos temos o PO sempre disponível e comprometido, a equipe junta no mesmo ambiente de trabalho e fazendo parte de todo o processo do Framework do Scrum. Na equipe está presente os profissionais de Teste.
Este foi um post rápido, fica o convite para os leitores olharem os itens que promovem + ou - detalhamento dos requisitos e complementar este post?
Referência Bibliográfica: Livro
Um abraço a todos,
Abu
Já que recebi alguns chat e e-mails elogiando o post de requisitos vamos para mais um. A área de analise de sistemas eu gosto muito e já trabalhei muito tempo como analista de sistema.
É muito gostoso descobrir os requisitos e fazer a análise do entendimento de cada requisito identificado.
A questão é: Quanto de informação eu tenho que ter para permitir o entendimento do requisito?
Eu não sei se o desenho dos Bolos cai bem, mas o objetivo das fotos é que ambas são de bolo, mas uma foto possui muito mais detalhes de acabamento e enfeite que o outro. Desta maneira um bolo demora muito mais para ser feito que o outro.
No caso dos requisitos os fatores que nos levam a colocar mais informação ou uma quantidade de informações menores são:
Menor (-)
Clientes são amplamente envolvidos
Os desenvolvedores têm experiência considerável do domínio da aplicação
Precedentes estão disponíveis
Pacotes de soluções serão utilizados
Maior (+)
Desenvolvedores terceirizados
Equipe do projeto distribuída geograficamente
Testes serão baseados em requisitos
Estimativas precisas são necessárias
Rastreabilidade dos requisitos são necessários
Estes itens apresentados cai muito bem com relação a Use Cases e Cartão de História. Eu utilizo os dois, conforme as características do projeto que estou participando. Mas o Cartão de História funciona muito bem com os itens:
Clientes são amplamente envolvidos
Equipe junto (Não separada geograficamente)
A equipe de testes faz parte da análise de sistemas
Estes três itens são utilizados em Scrum, quando nos temos o PO sempre disponível e comprometido, a equipe junta no mesmo ambiente de trabalho e fazendo parte de todo o processo do Framework do Scrum. Na equipe está presente os profissionais de Teste.
Este foi um post rápido, fica o convite para os leitores olharem os itens que promovem + ou - detalhamento dos requisitos e complementar este post?
Referência Bibliográfica: Livro
Um abraço a todos,
Abu
quinta-feira, 10 de setembro de 2009
Fatores de Velocidade no Desenvolvimento de Requisitos
Oi pessoal,
Valos falar sobre alguns fatores que influenciam o tempo de desenvolvimento de um requisito.
Menor Tempo
Analista altamente qualificados e experientes
Extenso envolvimento do cliente com representações apropriadas de usuários
Reutilização de projetos anteriores
Cliente disponível para responder rapidamente a duvidas
Escopo claro e estável
Experiência de desenvolvedores em domínio de aplicações
Substituição de uma aplicação antiga
Revisão em par para remover ambigüidades e buscar omissões
Maior Tempo
Projeto desconhecido ou domínio da aplicação
Envolvidos no projeto geograficamente distribuídos
Barreiras da Linguagem entre os participantes do projeto
Processo de tomada de decisões ruim
Projetos grandes
Muitos ou diversas classes de usuários
Desenvolvimento de software concorrente e reengenharia de processo de negócio
Dependência externas e incertezas
Complexas interações entre hardware e componentes de software
Não existir um processo de desenvolvimento de requisitos
Referência Bibliográfica: Livro
Abraços a todos,
Abu
Valos falar sobre alguns fatores que influenciam o tempo de desenvolvimento de um requisito.
Menor Tempo
Analista altamente qualificados e experientes
Extenso envolvimento do cliente com representações apropriadas de usuários
Reutilização de projetos anteriores
Cliente disponível para responder rapidamente a duvidas
Escopo claro e estável
Experiência de desenvolvedores em domínio de aplicações
Substituição de uma aplicação antiga
Revisão em par para remover ambigüidades e buscar omissões
Maior Tempo
Projeto desconhecido ou domínio da aplicação
Envolvidos no projeto geograficamente distribuídos
Barreiras da Linguagem entre os participantes do projeto
Processo de tomada de decisões ruim
Projetos grandes
Muitos ou diversas classes de usuários
Desenvolvimento de software concorrente e reengenharia de processo de negócio
Dependência externas e incertezas
Complexas interações entre hardware e componentes de software
Não existir um processo de desenvolvimento de requisitos
Agora vamos pegar os fatores de menor tempo e correlacionar com Scrum
Analista altamente qualificados e experientes
Revisão em par para remover ambigüidades e buscar omissões
(Abu) A analise realizada por toda a equipe no planejamento da Sprint, potencializa o trabalho de Análise de Sistemas e a revisão dos requisitos.
Extenso envolvimento do cliente com representações apropriadas de usuários
Cliente disponível para responder rapidamente a duvidas
(Abu) É um dos trabalhos realizados pelo PO
Referência Bibliográfica: Livro
Abraços a todos,
Abu
Equipe Innovit de Lego
segunda-feira, 7 de setembro de 2009
Plugin: Kanban para Redmine
Oi pessoal,
Está disponível no meu site: http://www.abuzitos.com.br o plugin de Kanban para o software redmine (http://www.redmine.org).
Outros post referentes a este plugin
http://blogdoabu.blogspot.com/2009/04/redmine-e-personalizacao-eu-amo.html
http://blogdoabu.blogspot.com/2009/03/kanban-eletronico.html
http://blogdoabu.blogspot.com/2009/03/redmine-e-kanban.html
Abraço a todos,
Abu
Está disponível no meu site: http://www.abuzitos.com.br o plugin de Kanban para o software redmine (http://www.redmine.org).
Outros post referentes a este plugin
http://blogdoabu.blogspot.com/2009/04/redmine-e-personalizacao-eu-amo.html
http://blogdoabu.blogspot.com/2009/03/kanban-eletronico.html
http://blogdoabu.blogspot.com/2009/03/redmine-e-kanban.html
Abraço a todos,
Abu
domingo, 6 de setembro de 2009
quinta-feira, 3 de setembro de 2009
Concorra a um curso de Ruby pela Object Training
Oi pessoal,
Eu uso profissionalmente Ruby e sempre recomendo as pessoas. Se a sua necessidade na área de desenvovimento de sistemas é ter uma linguagem de programação que permita desenvolver rápido e com foco no negocio, principalmente quando estamos amadurecendo o negocio e tentando entrar no mercado, esta linguagem de programação é muito boa.
Segue o link do post.
Link: http://www.rubyinside.com.br/concorra-a-um-curso-de-ruby-pela-object-training-2085
Abraços a todos,
Abu
Eu uso profissionalmente Ruby e sempre recomendo as pessoas. Se a sua necessidade na área de desenvovimento de sistemas é ter uma linguagem de programação que permita desenvolver rápido e com foco no negocio, principalmente quando estamos amadurecendo o negocio e tentando entrar no mercado, esta linguagem de programação é muito boa.
Segue o link do post.
Link: http://www.rubyinside.com.br/concorra-a-um-curso-de-ruby-pela-object-training-2085
Abraços a todos,
Abu
Assinar:
Postagens (Atom)