Como aplicar o Kanban na Gestão de Projetos de Software

Existe uma forma rápida e simples de se implementar os princípios de gestão de projetos em uma empresa de produção de software?

Sim, uma alternativa é aplicar o Kanban.

Kanban é uma palavra de origem japonesa que significa placa ou registro. O Kanban permite agilizar a produção de componentes de software. Originário na indústria automobilística, os Kanbans físicos (cartões – ou post-it) se movimentam ou transitam entre as atividades de um processo de produção, permitindo uma gestão eficaz de um projeto – Esta forma gestão foi conhecida como Sistema Toyota de Produção.

A implementação do Kanban em equipes de produção de software é dividida em duas etapas: 1 treinamento e 2 implantação.

1 Treinamento

a) Divida a sua equipe de produção de software em grupos de 3 desenvolvedores. Por exemplo, se sua equipe possui 15 colaboradores você terá 5 grupos. Cada grupo deve desenvolver 4 aviõezinhos de papel, 2 barquinhos (vide foto dos aviões abaixo). Perceba que termos 6 componentes a serem desenvolvidos. Importante: é permitido as equipes consultar uma réplica dos aviõezinhos e dos barquinhos.

b) Antes de iniciar o desenvolvimento cada grupo deve preencher um post-it com as seguintes informações:

• Nome do componente a ser desenvolvido (aviãozinho A ou B – barquinho).
• Data de Início.
• Tempo (em minutos) estimado para o desenvolvimento.
• Responsáveis pelo desenvolvimento (lembrando que o componente pode ser desenvolvido por 1, 2 ou pelos 3 integrantes do grupo).

c) Cada post-it deve ser afixado no quadro Kanban, geralmente, o quadro é dividido 3 fases: to do (para fazer), doing (fazendo), done (feito). Todos os grupos devem afixar os post-it no to do – vide figura abaixo. Utilize um quadro negro para construir o Kanban, isso facilitará a interação da sua equipe com os princípios básicos da gestão.

d) Inicie a produção dos componentes – neste caso os post-it são movimentados (pelos responsáveis) para a fase doing – vide figura abaixo.

e) Terminado a produção dos componentes, os post-it são movimentados, novamente, para a fase done. Além de movimentar os post-it os responsáveis pela produção devem informar:

• Data de término.
• Tempo (em minutos) utilizado para o desenvolvimento – vide figura abaixo.

Durante o treinamento, solicite que a equipe pare a produção e analise o quadro, e permita que mesma extraia as seguintes informações: % de componentes a desenvolver – % de componentes em desenvolvimento – % de componentes prontos.

2 Implantação:

a) Após realizar o treinamento, confeccione um quadro Kanban para cada projeto de software no ambiente produtivo de sua empresa (vide figura abaixo).

b) Com certeza os seus projetos são divididos em requisitos e cada membro de sua equipe é responsável pela implementação de um componente ligado a um determinado requisito. Cada componente deste irá gerar um post-it.

c) Fixe os post-it no quadro Kanban. Para produzir software você pode customizar o seu quadro com um número maior de fases, por exemplo: to do, project, implement, test, done.

d) Movimente os post-it de acordo com a execução das atividades.

e) Após o post-it percorrer todas as atividades, armazene as informações mapeadas em uma planilha. Lembrando que você terá uma planilha para cada projeto. Neste momento você inicia a confecção de uma base histórica de projetos. Esta base será de grande utilidade nas estimativas de tempo, custo e esforço de novos projetos.

Em tempo, você pode “kanbanizar” seus projetos utilizando estas ferramentas:

https://kanbanflow.com/

http://kanbanize.com/ctrl_home

https://trello.com/

J. A. Fabri – fabri@utfpr.edu.br

Vídeo aula (4-5) sobre pontos por função – Mapeando a Complexidade das Entrada de Dados

Disponibilizo as duas últimas vídeo-aulas do curso de pontos por função. As demais podem ser acessadas por meio destes post:

Antes de acessar os vídeos é importante ler este texto.

.

.

.

Fabri – fabri@utfpr.edu.br

Vídeo aula (3) sobre pontos por função – Mapeando a Complexidade das Entrada de Dados

Pessoal no dia 27 de março, publiquei uma vídeo-aula sobre a teoria de Pontos por Função para mapear os arquivos de interface externa. Neste vídeo apresento o mapeamento da complexidade da entrada de dados.

Para entender o conteúdo desta aula, é interessante acessar os link:

É possível comprar 1000 pontos por função.

Vídeo-aula sobre a contagem dos arquivos lógicos interno.

Vídeo-aula sobre a contagem dos arquivos de interface externa.

Abraços

Fabri – fabri@utfpr.edu.br

Vídeo aula (2) sobre pontos por função – Arquivo de Interface Externa

Pessoal, após a publicação do último post, recebi vários e-mails solicitando que as vídeos aulas sobre pontos por função fossem disponibilizadas. Vou acatar as solicitações, lembrando que tenho várias limitações perante as câmeras.

Para entender o conteúdo desta aula, é interessante acessar os link:

É possível comprar 1000 pontos por função.

Vídeo aula sobre a contagem dos arquivos lógicos interno.

J. A. Fabri – fabri@utfpr.edu.br

Vídeo aula sobre pontos por função

Pessoal, nesta semana tive a oportunidade (claro, dentro de minhas limitações) de gravar algumas aulas sobre pontos por função. Aproveito a oportunidade para disponibilizar a primeira delas para toda a comunidade. Iniciamos nosso curso mapeando a complexidade dos arquivos lógicos internos.

Antes de executar o vídeo, sugiro que todos leiam este texto.

José Augusto Fabri – fabri@utfpr.edu.br

Ferramenta de gestão de tempo focada na Técnica Pomodoro.

A técnica Pomodoro (tomate em italiano) é caracterizada como uma abordagem pessoal para o planejamento temporal de suas atividades. Esta técnica começou a ser desenvolvida por Francesco Cirillo no início da década de 1980. Cirillo buscava a melhora da qualidade de seu tempo de estudo, focando sempre em eliminar as distrações e as interrupções que desviam sua atenção.

Cirillo fez uma aposta com ele mesmo, conseguir estudar durante 10 minutos sem qualquer tipo de distração ou interrupção. A marcação desse tempo foi feita com um timer de cozinha no formato de um tomate.

Mais informações sobre a técnica aqui.

Uma ferramenta que possibilita a aplicação da técnica pode ser baixada a partir deste link.

José Augusto Fabri – fabri@utfpr.edu.br

Gestão de si mesmo

O sucesso de uma carreira passa pela gestão de si mesmo. Esta gestão foca 4 pontos principais:

1) auto-conhecimento: Quais suas potencialidades]? Você é bom em que? Quais suas fragilidades? Você necessita melhorar em que?

2) auto-disciplina: O que é realmente importante para você? Faça suas escolhas. Tenha disciplina para que as escolhas sejam caracterizadas como um processo de crescimento. Mantenha o foco.

3) auto-confiança: Responda para você mesmo, o por que você é bom em uma determinada área? Não se compare com o outro, você tem que ser melhor em relação a você mesmo.

4) fisiologia: Cuide de você e da sua saúde, se você não consegue cuidar de você como irá cuidar dos outros?

Para mais detalhes sobre a gestão de si mesmo, assista o vídeo abaixo:

José Augusto Fabri – fabri@utfpr.edu.br

Utilizando o diagrama de espinha de peixe para a definição do escopo de um projeto de software.

O Diagrama de Ishikawa, também denominado Diagrama de Causa e Efeito ou Diagrama Espinha-de-peixe caracteriza-se como uma ferramenta utilizada pela Teoria Geral da Administração para a gestão e Controle de Qualidade de diversos processos. O diagrama foi proposto pelo engenheiro Kaoru Ishikawa em 1943.

A sua composição estrutural mapeia as causas de um determinado problema. Toda e qualquer causa pode ser classificada em seis tipos diferentes: Método, Matéria prima, Mão-de-obra, Máquinas, Medida e Meio ambiente (o diagrama também é conhecimento como Diagrama 6Ms).

Exemplo: A causa (ou motivo) que leva a ocorrência de um determinado problema pode estar relacionado a composição da Matéria prima, ou o atraso no processamento das informações de uma determinada Máquina, ou ainda, na falta de capacidade da Mão de obra.

Perceba que a composição estrutural do diagrama é composta por (vide figura em anexo):

• Cabeçalho: Título, data, autor.
• Efeito: Título do projeto (ou problema a ser resolvido). O título é escrito no lado direito, envolvido pela cabeça do peixe.
• Eixo central: Uma flecha horizontal apontando para o projeto.
• Categoria: Principais grupos de fatores que se relacionam com o projeto.
• Causa: Todo e qualquer projeto é fracionado em sub-projetos (ou sub-causa), perceba que é necessário executar sub-projetos (ou sub-causas) para atingir o sucesso no projeto como um todo.
• Sub-causa: Causa que pode contribuir com uma causa maior.

As figuras mapeadas no início deste post apresentam a estrutura genérica e a aplicabilidade de um diagrama em um projeto de software.

Perceba que na cabeça da espinha você encontra a idéia do projeto: Desenvolvimento de uma ferramenta de planejamento e controle de produção de software (PCP-SW). A primeira superior espinha mapeia as pessoas envolvidas no projeto; a segunda as atividades de processo sistêmico; a terceira os equipamentos necessários para que o projeto possas ser implantado com sucesso. As espinhas da parte inferior mapeiam as fontes dos requisitos, o ambiente no qual o projeto será implantado e forma de gestão que será aplicada.

Benefícios do diagrama:

• Possibilita o mapeamento do escopo do projeto;
• Registra as causas potenciais que podem ser revistas e atualizadas;
• Possibilita aglutinação, via brainstorm, dos stakeholders durante o desenvolvimento do diagrama.

 José Augusto Fabri – fabri@utfpr.edu.br

O roteamento (ou distribuição) da produção em um projeto de software

Produzir software cada vez mais rápido com um custo reduzido e com maior qualidade caracteriza-se como fator determinante dentro de um mercado altamente competitivo. Existem vários modelos de processo, de qualidade e de gestão que provêm práticas consolidadas focadas em questões de produtividade. Porém, a maioria destes não foca questões relacionadas à produção distribuída. Questões relacionadas ao roteamento da produção são muitas vezes tangenciadas (ou desprezadas) pelos referidos modelos. Dentro deste contexto questiona-se:

Quais os atributos que devem ser considerados no momento que se deseja distribuir (ou rotear) a produção de um produto caracterizado como software?

A produção distribuída de software é concretizada por meio de um grupo de empresas (ou desenvolvedores) que trabalham em conjunto durante o desenvolvimento de um projeto. Durante o roteamento da produção alguns atributos devem ser considerados:

• Qualidade: A organização responsável por parte da produção deve possuir características sólidas de qualidade. O nível de satisfação no atendimento dos requisitos, a capacidade de integração do produto são questões que devem ser mapeadas no momento de rotear.
• Tempo de produtividade: Não basta possuir um padrão de qualidade sólido, as organizações que recebem parte da produção devem atender a demanda rapidamente. Lembre-se que em mercado altamente competitivo a qualidade deve vir aliada a velocidade na entrega.
• Custo: Possuir políticas sólidas e eficazes para determinar o custo de produção é um fator que deve ser considerado na matriz (entidade que detém a responsabilidade pela execução do projeto) e nas filiais (entidades subcontradas para produzir parte do software).
• Segurança e sigilo de informações: Um ambiente seguro que acondicione todo o modelo de negócio e atributos do projeto deve ser uma constante na matriz e nas filiais.
• Cultura: Matriz e filiais devem alinhar nas questões ligadas a cultura organizacional – empresas de culturas diferentes não conceberão a integridade no projeto.
• Comunicação: O protocolo de comunicação entre matriz e filiais deve ser claro, conciso e consistente. Ambas devem respeitar o protocolo delineado para que a comunicação ocorra com o mínimo ruído.
• Sincronização: Matriz e filial devem buscar um sincronismo de produção. É importante que ambas tenham subsídios para equalizar questões de processo e de projeto.
• Processo: O processo de produção deve ser delineado e institucionalizado na matriz e nas filiais.

Lembre-se, o roteamento da produção pode maximizar produtividade desde que os atributos sejam mapeados na matriz e nas filiais. Caso contrário, aconselho a desenvolver o produto sem qualquer nível de distribuição.

 Abraços

Fabri – fabri@utfpr.edu.br

Alguns fatores provocam erros nas estimativas em um projeto de software

No post anterior defendi a ideia que as estimativas para projetos pequenos (ou menos complexos) tendem a acarretar um menor erro em relação da definição de tempo. Esta prerrogativa é inversa quando os projetos possuem uma complexidade maior.

Terminei o post com a seguinte questão:

Por que isto ocorre?

Neste texto enumero alguns fatores que podem mapear uma resposta.

1 – Os requisitos em projetos menores são mais estáveis, as mudanças provocadas pelo ambiente (novas necessidade do usuário, atendimento aos novos aspectos legais) não são freqüentes.

2 – Os projetos maiores e mais complexos demandam um tempo de desenvolvimento considerável, quando comparados a projetos menores. Com um mercado aquecido e a elasticidade temporal delineada dada as características deste tipo de projeto, o turnover pode ser caracterizado como um delimitador na gestão do cronograma.

3 – Projetos maiores exigem um maior entendimento do domínio sistêmico que contextualiza a aplicação (ou software). Mergulhar profundamente neste domínio requer dedicação e uma boa carga de estudo. Estes aspectos não delineados na composição temporal para execução de um projeto.

4 – Projetos com um maior número de requisitos requerem a aplicação de modelos de processos caracterizados na filosofia evolucionária ou incremental. Estes modelos não proporcionam ao analista de sistema um mapeamento do ambiente sistêmico e das características do produto nas fases iniciais do projeto. Os consumidores de software exigem que custo e prazo sejam mapeados nos momentos iniciais do desenvolvimento do produto. A ausência de informações sistêmicas nestes momentos provê estimativas de tempo e custo irreais.

Aproveite a oportunidade e complete os itens enumerados.

José Augusto Fabri – fabri@utfpr.edu.br