Engenharia de Software - Edição 45

mag

azin

eengenhariade software

Edio 45 - Ano 04

AgilidadePMI versus Scrum: O equilbrio ser possvel?

ProjetoDando foco ao

negcio com DDD

GerenciamentoFerramentas para Gesto de Projetos

TesteTestes funcionais

de software

DesenvolvimentoConhea tcnicas para manter seu cdigo limpo Parte 7

Segurana da InformaoConhecendo a ISO 15408

Corpo Editorial

EditorRodrigo Oliveira Spnola

ColaboradoresMarco Antnio Pereira Arajo Eduardo Oliveira Spnola

Jornalista ResponsvelKaline Dolabella - JP24185

Na Webwww.devmedia.com.br/central(21) 3382-5038

Ano 4 - 45 Edio - 2012

No h mais dvidas de que a indstria de software uma das mais im-

portantes atualmente. O mercado brasileiro de software e servios de

TI, segundo o ltimo relatrio da ABES, de US$ 19 bilhes e cresce

de 25% a 30% ao ano desde 2004. Porm, grande parte do software produzido

ainda defeituoso, inadequado aos desejos do cliente, entregue fora do prazo

e acima dos custos esperados.

Neste cenrio, temos observado mais recentemente ao surgimento do Kan-

ban. A histria do Kanban para desenvolvimento de software, assim como a

histria da grande maioria das metodologias, modelos de maturidade, proces-

sos de desenvolvimento e processos em geral, comea com um grande dese-

jo, muitas ideias, testes (na prtica) e diversos ajustes at atingir os primeiros

casos de sucesso.

A principal diferena do Kanban para as demais metodologias de desenvol-

vimento de software atuais que ele foi um modelo adaptado de outra inds-

tria, a de manufatura, mais especificamente da Toyota. Kanban (com K mais-

culo) um mtodo de mudana evolutivo para monitoramento e melhoria

de processos de produo, que utiliza kanban (com k minsculo) para auxiliar

na visualizao do fluxo e para permitir a criao de um sistema puxado de

trabalho alm de outras ferramentas para catalisar a introduo de ideias Lean

nas reas de desenvolvimento de software e operaes de TI.

Neste contexto, esta edio da Engenharia de Software Magazine destaca

como tema de capa Kanban. Para isso, traz dois artigos muito interessantes so-

bre o tema: Kanban no desenvolvimento de projetos de software e Kanban:

o gil adaptativo.

Alm destes dois artigos, teremos mais seis nesta edio:

PMI versus Scrum: O equilbrio ser possvel?

Ferramentas para Gesto de Projetos

Conhecendo a ISO 15408

Testes funcionais de software

Dando foco ao negcio com DDD

Boas prticas para escrita de mtodos, funes e procedimentos Parte 7

Desejamos uma tima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spnola [email protected] e Mestre em Engenharia de Software pela COPPE/UFRJ. Autor de diversos artigos cientficos

sobre Engenharia de Software publicados em revistas e conferncias renomadas, dentro e fora do

pas. Experincia de participao em mais de 20 projetos de consultoria para diferentes empresas

tendo atuado com gerncia de projetos, requisitos e testes de software. Implementador certificado

do MPS.BR, tendo tambm experincia atuando junto a empresas certificadas CMMI.

Marco Antnio Pereira [email protected] e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em

Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Ba-

charelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do

curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e

Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao

Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador

da Engenharia de Software Magazine.

Eduardo Oliveira [email protected] Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. ba-

charel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o

mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA

(Grupo de Engenharia de Software e Aplicaes).

Atendimento ao Leitor

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se

voc tiver algum problema no recebimento do seu exemplar ou precisar de algum

esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de

jornal, entre outros, entre em contato com:

www.devmedia.com.br/mancad(21) 3382-5038

Publicidade

Para informaes sobre veiculao de anncio na revista ou no site entre em

contato com:

[email protected]

Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc

gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para

entrar em contato com os editores e dar a sua sugesto!

Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria

de publicar.

EDITORIAL

Apoio

NDICE

Agilidade Fundamentos

06 - Kanban: o gil adaptativo

Flavio S. Mariotti

11 - Kanban no desenvolvimento de projetos de softwareThiago Ghisi

17 - PMI versus Scrum: O equilbrio ser possvel?Luiz Carlos Vianna

Engenharia Fundamentos

23 - Ferramentas para Gesto de ProjetosAline da Silva Tinoco e Marco Antnio Pereira Arajo

31 - Conhecendo a ISO 15408Dayana Fernanda Trapp e Rodrigo Oliveira Spnola

37 - Testes funcionais de softwareElisngela Andrade Bruno, Paulo C. Barreto da Silva e Thiago Salhab Alves

Arquitetura e Desenvolvimento

42 - Dando foco ao negcio com DDDRobson Castilho

49 - Boas prticas para escrita de mtodos, funes e procedimentos Parte 7Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo

Edio 05 - Engenharia de Software Magazine 5

6 Engenharia de Software Magazine - Kanban: o gil adaptativo

Flavio S. Mariotti [email protected]

Especialista em Engenharia e Arquitetura de Software. Ps Graduado pelo Instituto de Pesquisa Avanada de Tecnologia IBTA em Engenharia de Software baseado em SOA. Bacharel em Sistemas de Informao pela UNIUBE e tcnico em Processamento de Dados pela FEB. Consultor independente no desenvolvimento de software em arqui-tetura OO, SOA, GIS e Plataforma .NET.

De que se trata o artigo?Este artigo traz uma breve abordagem do modelo Kanban. O objetivo apresentar o sistema Kanban e explicar sua proposta. Entender o conceito de visua-lizao e o porqu algo to simples pode fazer uma diferena to grande na qualidade dos resultados.

Em que situao o tema til?Nos ltimos anos o conceito de metodologia gil vem movimentando o mundo de desenvolvimento de software. Metodologias mais populares como Scrum e XP, criadas nas fabricas de software, vem ganhando cada dia mais espao nas empresas de tecnologia. Essas ferramentas surgiram com a proposta de melhorar e agilizar os processos envolvidos no desenvolvimento de software, po-rm no mundo real fica claro que os processos ain-da no esto perfeitos. Mas o que fazer ento, sendo que essas ferramentas esto, teoricamente,

maduras e eficientes no que se prope? Como identificar onde esto os gargalos que fazem as equipes falharem nos seus sprints? Podemos dizer com que o Kanban pode ajudar a identificar essas falhas e solucion-las.

Resumo?O mtodo Kanban para desenvolvimento de sof-tware e processos geis tem como nfase no sobrecarregar os membros que compe a equipe de criao do produto. Por isso, o mtodo contem princpios bsicos como: a equipe ou membro deve iniciar uma nova tarefa quando capaz de realiz-la agora, a equipe deve aceitar mudan-as incrementais e evolutivas estimuladas pelo mtodo Kanban e respeitar os atuais processos, papis e responsabilidades. Neste sentido, este artigo ir apresentar o sistema Kanban e explicar sua proposta.

Kanban: o gil adaptativoIntroduzindo Kanban na equipe gil

O Kanban baseado na ideia onde atividades em andamento devem ser limitadas. Um novo item s pode ser iniciado quando o item em andamento finalizado ou quando uma funo automtica inicia o mesmo instantaneamente.

O Kanban, basicamente, tem como principal objetivo transformar o tra-balho em andamento visvel para toda equipe, criando um sinal visual que indica que o novo trabalho pode ou no ser iniciado e se o limite acordado para cada fase est sendo respeitado.

Fundamentos da Agilidade

Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.


AgiLidAdE

Neste momento, provavelmente voc est se perguntando, o que isso tem de interessante? David J. Anderson teve essa mesma sensao e segundo ele A teoria do Kanban no soa muito revolucionria nem parece afetar profundamente o desempenho, cultura, capacidade e maturidade de uma equipe e a organizao na qual est inserida. Mas o impressionante que afeta! O Kanban parece uma mudana pequena e, no entanto, muda tudo a respeito de uma empresa.

Portanto, o Kanban no um processo e nem descreve papeis e faces para serem seguidos. Podemos dizer que o Kanban uma abordagem para mudana gerencial do projeto, um concei-to para introduzir alteraes em um ciclo de desenvolvimento de software ou gerenciamento de projetos.

Os mtodos geis fornecem transparncia sobre as ativida-des em andamento e concludas, e reportam mtricas com velocidade. O Kanban, no entanto, vai um passo alm e d transparncia ao processo e seu fluxo, expondo gargalos, filas, variabilidade e desperdcios. Portanto, tudo que impacta no desempenho da equipe de produo e para entrega de valor, fica explcito no modelo Kanban.

O que Kanban?O nome Kanban de origem japonesa e sua traduo seria

como sinal ou carto. Portanto, vamos chamar de sina-lizador ou melhor registro visual. O nome Kanban surgiu dos sistemas de carto usados nas indstrias de produo, que tinham como finalidade o gerenciamento do fluxo de trabalho atravs da organizao de desenvolvimento.

O Kanban, com seu mecanismo de sinalizao, tem como objetivo apresentar uma atividade de trabalho em processo, ou seja, o nmero de atividades ou cartes em circulao equivalente capacidade do sistema.

Uma outra caracterstica importante do modelo Kanban o conceito de puxar tarefa quando h capacidade de process-la. Esse recurso vai de encontro ao tradicional modelo de empurrar tarefa conforme sua demanda, mantendo assim o bom desempenho da equipe. Portanto, ao invs dos membros que produzem o produto receberem atividades conforme suas demandas, os requisitos so adicionados a lista de backlog e puxados pelos membros que liberam suas atividades corren-tes e se tornam disponveis para iniciar uma nova tarefa.

Uma boa metfora que descreve essa regra imaginarmos uma rodovia que suporta at 100 veculos para manter o fluxo de trafego com um bom desempenho, porm em todos os feriados essa rodovia recebe em torno de 200 veculos. Essa de-manda no suportada pela rodovia gera um congestionamento afetando consideravelmente o desempenho do trafego. Logo, no adianta empurrar um numero de atividades no suportada pela equipe, isso ir causar um congestionamento e afetar o desempenho de produo.

A implementao do modelo Kanban se resume em trs etapas que so: Visualizar os processos; Limitar o trabalho em processo do ingls WIP (work in progress);

Gerenciamento do lead-time, ou seja, tempo que a ativi-dade leva para passar por todas as fases at a sua entrega.

O sistema KanbanPara entendermos a proposta desde conceito, vamos primei-

ro estudar o sistema Kanban. Vamos chamar as tarefas que compe o painel Kanban de cartes. O nmero de cartes representa a capacidade limite acordada em cada fase de um sistema que so colocadas em circulao.

Cada carto funciona como um mecanismo de sinalizao e o sistema s permite iniciar uma nova tarefa quando um carto est disponvel. muito importante respeitar essa regra, e fazer com que qualquer novo trabalho espere em uma fila at que um carto se torne disponvel.

O sistema Kanban fornece um mtodo simples, barato e fcil de implementar e rapidamente comea a apresentar resultados permitindo gerenciar o limite de atividades em andamento e garantindo o bom desempenho da equipe.

Afinal, por que usar um sistema Kanban?Ao entender a proposta de um sistema Kanban, se torna

simples perceber que o uso de um sistema prepara e limita o trabalho em andamento para uma capacidade suportada pela equipe. Esse recurso proporciona o equilbrio da demanda de uma equipe controlando o seu rendimento, e consequentemente, acelerando sua produo.

simples deduzir que todas as pessoas produzem mais quando conseguem equilibrar a vida pessoal e profissional. O Kanban buscar atingir um ritmo sustentvel de desenvol-vimento para que todos os indivduos possam alcanar esse objetivo entre vida pessoal e profissional. Segundo David J. Anderson, O Kanban rapidamente elimina as questes que prejudicam o desempenho, e desafia uma equipe para se con-centrar em resolver essas questes a fim de manter um fluxo constante de trabalho.

O Kanban atua fornecendo visibilidade nos processos, dei-xando explcito os problemas e prendendo o foco da equipe em qualidade. Portanto, este comportamento reflete os defeitos, pontos de sobrecarga, custos econmicos sobre o fluxo de rendimento e a variabilidade. A simples regra de limitar os trabalhos em andamento no sistema Kanban estimula maior qualidade e maior desempenho na execuo de cada tarefa.

O Kanban, com a combinao de fluxo, contribui para a reduo do estresse da equipe e melhora a previsibilidade e colaborao, refletindo com isso, nas datas de vencimento para entrega de ta-refas. Com a equipe produzindo e cumprindo os prazos de libera-o, o Kanban ajuda a fortalecer os laos de confiana dos clientes, parceiros, fornecedores e outras entidades relacionadas.

Ao aplicar o Kanban, respeitando suas pequenas exigncias, o sistema tende a contribuir para a maturidade da equipe, podendo at afetar a cultura organizacional da empresa. Com a identificao de falhas, a equipe consequentemente concentra-se em uma fora tarefa para resolv-las, e por contar com maior contribuio da equipe, a tendncia de prevenir problemas futuros.


Por conta desta filosofia, o Kanban vem mostrando efici-ncia e ganhando diariamente diversos profissionais que se renderam aos benefcios proporcionados por ele.

Aplicando o sistema Kanban no desenvolvimento de software

Para o desenvolvimento de software, comum o uso de um sistema Kanban digital. Porm, pode-se manter o conceito de painel fsico e digital, isso reconhecido como boa prtica uma vez que ele mantm o princpio de sinalizao visual.

Algumas empresas tem implementado o Kanban fsico utili-zando lousas, painis, paredes ou tabuleiros. Na verdade, no existe um objeto recomendado para usar, o importante que este painel seja visvel, atingindo o conceito de sinalizador visual. Ainda neste artigo sero apresentados alguns modelos de painel Kanban.

importante lembrar a alguns profissionais que vem usando paredes ou at mesmo portas do escritrio para sinalizar as ati-vidades em andamento que, mesmo essa tcnica conseguindo servir como sinalizador visual das atividades em andamento, no podemos considerar isso um modelo Kanban. Para ser um sistema Kanban necessrio existir a ideia de puxar tarefas, conforme o limite acordado em cada fase, ou seja, para se tonar um sistema Kanban necessrio aplicar as trs etapas cruciais que so: criar o painel de visualizao, limitar os processos WIP e gerenciar o lead-time, aplicando o conceito de puxar uma nova tarefa quando um carto est disponvel.

PriorizaoAo aplicar os trs primeiros passos para a implementao do

modelo Kanban, os resultados tendem a aparecer com: cdigos de alta qualidade, lead-time de desenvolvimento relativamente curto, e controle do desempenho de produo.

O gerenciamento do limite deve ser feito de forma rgida, evitando a priorizao de excees imprevistas no negcio, e focando no desenvolvimento dos itens conforme acordado na estratgia do projeto. recomendado que a ateno da gesto seja mais dedicada para melhorar a capacidade e previsibili-dade de entrega.

Buscando a maturidade na produoPara alcanar o adjetivo maturidade, fundamental que a

equipe primeiro busque aprender a construir cdigos de alta qualidade e equilbrio no trabalho em andamento para cumprir suas datas de entrega.

A busca pela qualidade est conectada com a velocidade no nvel de produo. O desempenho da equipe de desenvolvi-mento pode ser fortemente beneficiada com a eliminao de retrabalhos, com isso, a equipe pode alcanar um ritmo de produo de alta performance.

Comportamento emergente com KanbanO Kanban foi implementado na Corbis em 2007 pelo seu

idealizador David J. Anderson. Este trabalho resultou em uma lista de comportamentos emergentes que vem crescendo

rapidamente com novas implementaes Kanban. provvel, e esperado, que esta lista cresa medida que aprendemos mais sobre os efeitos do Kanban nas empresas. Os comportamentos que preenchem a lista atualmente so:1. Processos limitados e adequados para cada fluxo do projeto;2. Desenvolvimento sem a necessidade de iterao;3. Gerenciamento do custo de implementao;4. Valores otimizados para classes de servios;5. Gerenciamento de risco com alocao de capacidade;6. Gesto quantitativa;7. Tende a atingir outros departamentos;8. Mescla pequenas equipes e proporciona um maior grupo de trabalho.

Sinalizador visual KanbanO sinalizador visual Kanban funciona como uma ferramenta

de sinalizao de processos, deixando explcito o fluxo de valor atravs do processo em andamento. Para os adeptos ao Scrum, o quadro Kanban pode ser comparado ao recurso de quadro/placa Scrum para visualizao de tarefas.

Assim como a sequncia de colunas que representam os diferentes estados de uma tarefa existente durante o processo de desenvolvimento, o carto ou sinalizador Kanban movido de uma fase ou estado para outro, at que tenha sido aprovado para entrega.

Um quadro simples representando o sistema Kanban pode conter as seguintes etapas: anlise, desenvolvimento, aceitao e implantao. Esse modelo, primeira vista, pode lembrar o conceito da engenharia de cascata, porm na prtica, o Kanban no atua como o cascata e evita os problemas decorrente do conceito. O Kanban tem como linha de produo a regra de limitar o processo em anda-mento, o WIP, essa regra evita as falhas apresentadas pela engenharia cascata.

A teoria do sistema Kanban no quadro visual aplicada com a regra em que cada coluna ter um WIP estabelecido e representados pelo nmero mximo de cartes em cada fase. O carto composto por uma breve histria do usu-rio, descrevendo seus requisitos. Todo carto entra na fila de backlog e aguarda a liberao de capacidade para entrar nas colunas seguintes. Quando as atividades envolvidas com o carto na coluna em andamento so finalizadas, o mesmo movido para a coluna seguinte, liberando espao para entrada de um novo carto.

O procedimento aplicado acima gera o conceito de puxar cartes para inicializao. A prioridade dos cartes a serem iniciados deve seguir as exigncias e estratgias do projeto.

Exemplos de sinalizadores visuais KanbanO quadro de sinalizao visual do Kanban uma das princi-

pais etapas propostas pela ferramenta, porm, cabe ressaltar que ao aplicar o limite de trabalho em andamento e determinar o lead-time, importante customizar o quadro conforme suas necessidades.


AgiLidAdE

Nesta etapa do artigo, ser apresentado um modelo de quadro Kanban. Este exemplo ser customizado conforme as necessi-dades da equipe. O importante respeitar as poucas polticas exigidas pelo Kanban, e depois customizar na tentativa de acelerar e aperfeioar o conceito de comunicador visual.

A Figura 1 ilustra um modelo simples de sinalizador visual Kanban. Nesta representao, fica fcil identificar o limite de cartes estabelecidos para cada fase. Este limite est repre-sentado pelos nmeros em vermelho no cabealho. Os cartes ilustrados pelos retngulos representam uma breve histria dos usurios, ou seja, as demandas. As imagens com formato de rosto representam os responsveis pelos trabalhos em an-damento. Portanto, este exemplo aplica as trs etapas cruciais para obter os benefcios alcanados com o sistema Kanban.

Figura 1. Ilustrao de um sinalizador visual Kanban

importante ressaltar que o desenvolvimento de um quadro Kanban ir evoluir conforme as necessidades de cada organiza-o. Algumas empresas vem incluindo uma coluna chamada Refletir. Esta fase prope uma reflexo por cada carto que chega ao estado final do processo. Esta coluna adicionada ao quadro na tentativa de aplicar melhoria continuada em todos os processos.

Mattias Skarin publicou recentemente em seu blog dez diferentes quadros de visualizao. Na apresentao de cada modelo proposto por Mattias Skarin, fica clara a evoluo dos sinalizadores conforme a necessidade de cada equipe. Conhea mais acessando o endereo: http://blog.crisp.se/2009/11/16/henrikkniberg/1258359420000.

Trabalhando com processos limitadosO Kanban vai alm de rastrear e demonstrar visualmente

o progresso de uma atividade em andamento. No Kanban, o conceito de limitar o que deve ser feito aplicado em todas as colunas do quadro. Essa uma maneira rpida de reduzir o lead-time.

Para os usurios do Scrum, essa uma diferena fundamental entre o quadro Scrum e o quadro Kanban. Um dos desafios co-muns enfrentados com o Scrum o atraso na entrega conforme

o sprint. A entrega com atraso apresenta riscos e tende a afetar o desempenho da produo, afetando significativamente o resultado de valor entregue ao cliente.

O Scrum prope aos membros da equipe a trabalharem juntos em apenas uma necessidade antes de iniciar um novo item. O Kanban aplica essa orientao de forma implcita e explcita, definindo um limite no nmero de itens em anda-mento. Ao limitar a quantidade de trabalho em andamento, a equipe , consequentemente, forada a colaborar na busca por soluo nos itens que apresentam riscos para o desempenho do desenvolvimento.

Outro benefcio alcanado com a aplicao de limites de trabalho em andamento o ganho do conceito de puxar novos itens, o que garante que nunca a demanda excede a capacidade de produo. recomendado que os limites sejam estabelecidos pela equipe em colaborao e a equipe de administrao ou gesto do projeto. Isso contribui para otimizao no fluxo de trabalho. Essa colaborao tambm implica na gesto alinhada com a estratgia do negcio e proteo do limite WIP.

Benefcios alcanados com o KanbanAlguns estudos vem mostrando os diversos benefcios alcan-

ados pelas equipes que adotaram o Kanban. Algumas van-tagens observadas so: falhas tornam-se claramente visveis em tempo real; o benefcio de encontrar os gargalos faz com que as pessoas passem a colaborar ainda mais para a cadeia de valor em vez de apenas fazerem a sua parte.

Um outro aspecto interessante do modelo Kanban que ele fornece uma evoluo gradual do processo cascata para o modelo de desenvolvimento gil de software. Com isso, vem conquistando as empresas que ainda no tinham se rendido s metodologias geis. O fato de poder fazer desenvolvimento de software gil, sem necessariamente ter que usar o time-box, iteraes e sprints de Scrum, torna o modelo mais amigvel e fcil de ser adotado.

Outro benefcio relevante observado com o uso do Kanban que, naturalmente, o conceito tende a se espalhar para outros departamentos da organizao, aumentando a visibilidade de tudo o que est acontecendo na empresa.

Combinando mtodos geisUma dvida frequente nas discusses e fruns sobre metodo-

logias geis : posso utilizar Kanban junto com meu processo atual? A resposta simples e positiva, SIM. O Kanban vem com a proposta de agregar. Portanto, o primeiro passo visualizar o processo atual adotado pela empresa, e implementar os conceitos Kanban para encontrar os gargalos existentes no processo.

Mitos e verdades do KanbanComo toda metodologia, o Kanban j vem recebendo algumas

caractersticas que no condizem com a realidade. Uma delas o mito que o Kanban no um processo com iteraes. Na verdade, a iterao Kanban pode ser usada se necessria. Esse recurso opcional, o importante faz-lo somente se existe uma necessidade em seu contexto.


Outro mito comum sobre o Kanban dizer que no se usa estimativas, na verdade esse tambm um item opcional, e requer cuidado com o uso desse recurso.

Um erro comum visto em debates sobre Kanban dizer que esse modelo melhor que Scrum, XP, RUP e etc. O Kanban apenas mais uma ferramenta do processo, e no h tal com-parao para determinar qual melhor ou pior. Outro erro dizer que o Kanban veio para substituir as tradicionais metodo-logias geis. Novamente cabe lembrar que o Kanban apenas um recurso que interfere sobre o gerenciamento de fluxo de trabalho, portanto, sua proposta no substituir nenhuma ferramenta, e sim, implementar os conceitos de mudana de unidade, aplicando o modelo visualizao, limites de WIP e evoluir com seus resultados.

ConclusoCom este artigo podemos concluir que o Kanban permite de

forma efetiva visualizar o fluxo de trabalho e dividir o trabalho em partes, escrevendo cada item em um carto e incluindo ele no painel de visualizao.

O uso de colunas nomeadas atua como sinalizador, ilustrando onde cada item est no fluxo de trabalho. A aplicao de limite de trabalho em progresso (WIP work-in-progress) em cada coluna contribui para gesto e diminuio do lead-time.

provvel que diversas equipes de software adotem o Kanban, sendo que algumas podem adotar o Kanban defini-tivamente, enquanto outras equipes usaro Kanban no nvel de portflio de projetos, continuando a utilizar outras meto-dologias no nvel de equipes pequenas.

Kanban ainda uma ferramenta muito nova e vem se es-tendendo desde pequenas equipes para o projeto de portflio

Limited WIP Society

http://www.limitedwipsociety.org/

InfoQ - Kanban

http://www.infoq.com/Kanban

Kanban and Scrum making the most of both

http://www.infoq.com/minibooks/kanban-scrum-minibook

David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010.

Jim Benson; Tonianne DeMaria Barry, Personal Kanban, 2011.

John M. Gross; Kenneth R. McInnis, Kanban Made Simple, 2008.

Links

D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.Para isso, precisamos saber o que voc, leitor, acha da revista!D seu voto sobre este artigo, atravs do link:

www.devmedia.com.br/esmag/feedback

D

seu Fe

edback

sob

re esta edio

at o fluxo de valor da organizao. A verdade que vrias empresas vem buscando alinhar seus esforos e ganhar vanta-gens competitivas em seus mercados, e o Kanban, sem dvida, pode ser uma ferramenta de auxilio na busca de uma produo com alto desempenho.


Thiago Ghisi [email protected] / @thiagoghisi

Ps-graduando em Gesto de Negcios (UNISUL). Bacharel em Cincia da Compu-tao (UNISUL, 2011). Tcnico em Redes de Computadores (SENAI, 2005). consultor certificado para implementa-o do MPS.BR e Sun Certified Program-mer for the Java Platform, SE 6. H 6 anos no ramo de tecnologia e desenvolvimento de software, j atuou como: Professor Vo-luntrio de Informtica, Tcnico em Infor-mtica, Pesquisador de Iniciao Cientfica, Desenvolvedor, QA, Gerente de Projetos, Analista de Sistemas e de Requisitos, Au-ditor de Garantia da Qualidade (PPQA) e Analista de Processos. Possui experincia na definio e implantao de processos aderentes ao CMMI e ao MPS.BR e, em ava-liaes MA-MPS nvel F e SCAMPI Classe A nvel 2. entusiasta em desenvolvimento gil desde 2007. Atuamente, trabalha na Nexxera Techpeople, em Tubaro, SC.

De que se trata o artigo?Neste artigo ser apresentado o mtodo Kanban, uma interessante e simples abordagem para mo-nitoramento e melhoria de processos de software que tem uma forte inspirao no Sistema Toyota de Produo.

Em que situao o tema til?Se a sua empresa ou a sua equipe est com difi-culdades para melhorar a forma de trabalho, no importando se ela usa ou no mtodos geis, o Kanban pode ser uma das melhores alternativas para fazer isso com o mnimo de resistncia. Alm de ser um mtodo muito simples, comparado maioria das metodologias/frameworks de desen-volvimento atuais, suas propriedades promovem a colaborao.

Resumo?O mtodo Kanban para desenvolvimento de sof-tware a cada ano ganha mais destaque na inds-tria de TI, pois vem conseguindo promover a me-lhoria contnua no processo de trabalho de muitas equipes de empresas das mais variadas reas de negcio e tamanho. Nesse artigo apresentada uma introduo ao mtodo Kanban, destacando os seguintes tpicos: Histrico e as motivaes que levaram David Ander-son a fazer a adaptao do mtodo da indstria de manufatura (Toyota) para a indstria de software; As cinco propriedades centrais e o funcionamen-to do mtodo; Kanban pode ser considerado um mtodo gil? Um guideline para ter sucesso com o mtodo Kanban, focando principalmente no que deve ser priorizado para se obter as melhorias mais signifi-cativas mais cedo.

Kanban no desenvolvimento de projetos de softwareEntendendo os desafios e a receita para o sucesso

No h mais dvidas de que a in-dstria de software uma das mais importantes atualmente. O mercado brasileiro de software e ser-vios de TI, segundo o ltimo relatrio da ABES [9], de US$ 19 bilhes e cresce de 25% a 30% ao ano desde 2004. Porm, grande parte do software produzido

ainda defeituoso, inadequado aos de-sejos do cliente, entregue fora do prazo e acima dos custos esperados.

Observando esses e muitos outros problemas, h mais de 10 anos, 17 profissionais da rea escreveram e assinaram um manifesto: o manifesto para desenvolvimento gil de software.



12 Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software

Neste, todos concordaram com alguns valores comuns, dentre eles: As metodologias geis concentram-se nas pessoas envolvidas na produo; Os planejamentos em longo prazo so falhos; mais importante aceitar e adaptar-se a mudanas do que seguir planos rgidos; Software funcionando o melhor indicador de progresso nos projetos de software.

Tendo como base grande parte dos princpios desse manifes-to, bem como a filosofia Lean do Sistema Toyota de Produo (TPS Toyota Production System), surgiu o Kanban para Desenvolvimento de Software.

A filosofia Lean tem como objetivo a constante identificao e a eliminao de qualquer espcie de desperdcio no sistema de produo.

A histria do Kanban para desenvolvimento de software, assim como a histria da grande maioria das metodologias, modelos de maturidade, processos de desenvolvimento e pro-cessos em geral, comea com um grande desejo, muitas ideias, testes (na prtica) e diversos ajustes (o mtodo cientfico) at atingir os primeiros casos de sucesso.

A principal diferena do Kanban para as demais metodolo-gias de desenvolvimento de software atuais que ele foi um modelo adaptado de outra indstria, a de manufatura, mais especificamente da Toyota. David Anderson [1] foi o grande responsvel por essa adaptao.

A histria comea em 2002, quando Anderson, cansado de ver equipes de desenvolvimento e departamentos inteiros de TI merc de outros departamentos, decide voltar seus esforos para responder a duas perguntas [1]:1. Como proteger a minha equipe da demanda incessante de negcio e alcanar o que a comunidade gil chama de ritmo sustentvel?2. Como adotar uma abordagem gil em toda a empresa e superar inevitveis resistncias mudana?

Como cita em seu ltimo livro, Kanban: Successful Evolutio-nary Change for Your Technology Business [1], publicado em 2010, Anderson tinha um grande desejo: encontrar no setor de TI uma relao ganha-ganha entre o departamento de negcio e as equipes de desenvolvimento de software e TI.

Na tentativa de atingir esses objetivos, David idealizou, testou e falhou muitas vezes nas diversas organizaes em que trabalhou. Ele notou que implantar um processo de de-senvolvimento de software totalmente prescritivo, na maioria das vezes, no funcionava. Assim, chegou concluso que um processo precisava ser adaptado para cada situao, e que para fazer isso, era necessria uma liderana ativa em cada equipe. Porm, esta era muitas vezes inexistente. E, mesmo com uma liderana certa, ele duvidava que mudanas signi-ficativas acontecessem sem uma metodologia ou, no mnimo, sem orientaes de como adaptar o processo para atender a diferentes situaes.

Para David, sem um conjunto mnimo de orientaes para guiar o lder, treinador ou engenheiro de processo, qualquer adaptao no processo estava susceptvel a ser aplicada sub-jetivamente. Novos times sempre iro resistir a mudanas se voc empurrar para eles processos que foram feitos para outras realidades e que tiveram bons resultados l.

A concluso que David chegou que preciso ter uma evo-luo com o novo time de uma forma incremental, partindo do processo que atualmente seguido. Isso porque: Cada time diferente: diferentes conjuntos de habilidades tcnicas, capacidades e experincia. Cada projeto diferente: oramento, cronograma, escopo e riscos diferentes. E, cada organizao diferente: o processo de produo de software diferente em cada rea de negcio. [1].

Esse o principal motivo pelo qual o Kanban um framework para melhorias. Isto , ele orienta que o processo de trabalho deve ser customizado em cada time de cada projeto de cada organizao. Ou seja, um processo no deve ter suas prticas seguidas risca da mesma forma em todos os times, de todos os projetos, de todas as organizaes do mundo, como a grande maioria das metodologias do mercado prescreve.

Em 2005, o mtodo de trabalho de David Anderson era base-ado principalmente na Teoria das Restries (TOC Theory of Constraints) e na FDD (Feature Driven Development).

A Teoria das Restries foi apresentada pela primeira vez em 1984 por Eliyahu M. Goldratt, no famoso livro A Meta. Segun-do David Anderson [1], a habilidade de identificar gargalos em um sistema o primeiro passo para entender a Teoria das Restries. O efeito dos sistemas puxados, ou, processo de produo puxado so tpicos que tambm ajudam a compre-ender melhor a teoria. Nele, a sada de produtos acabados, tal como o software pronto para ser usado, ao final do processo de desenvolvimento, dita o ritmo da introduo de novos requi-sitos no sistema. Isso evita acmulos de produtos inacabados ao longo da linha de montagem, diminuindo a quantidade de trabalho em progresso. J a FDD uma famosa metodologia gil que o prprio David ajudou a criar.

Mais tarde, em 2007, aps fazer algumas customizaes na sua forma de trabalho inspiradas em prticas do Sistema Toyota de Produo, David apresentou nas conferncias Lean New Product Development e Agile 2007 os resultados prelimi-nares do uso de Kanban na Corbis, uma empresa fundada por Bill Gates, da Microsoft.

Durante certo perodo, David chegou a ter dvidas a respei-to da eficincia do Sistema Toyota de Produo, mesmo com muitas pessoas falando o contrrio. Porm, aps conhecer um pouco mais a respeito do pensamento de Taiichi Ohno, um dos criadores de tal sistema, e a ideia por trs da cultura Kaizen (a qual ser falada no prximo tpico), David reconheceu, [1] atravs de experincias ao longo dos cinco anos posteriores a eficincia desse sistema que originou o Kanban.

Kanban (com K maisculo) um mtodo de mudana evolutivo para monitoramento e melhoria de processos de produo, que utiliza kanban (com k minsculo) para au-xiliar na visualizao do fluxo e para permitir a criao de


AgiLidAdE

um sistema puxado de trabalho alm de outras ferramentas para catalisar a introduo de ideias Lean nas reas de de-senvolvimento de software e operaes de TI. um processo evolutivo e incremental. Kanban lhe permite atingir processos otimizados para contextos muito especficos, com resistncia mnima e mantendo um ritmo sustentvel para os trabalha-dores envolvidos. [1].

O mtodo KanbanComo implementar mudanas continuamente no processo

de trabalho da equipe com sucesso? Este um ponto funda-mental e um dos motivadores centrais das cinco propriedades do mtodo Kanban: 1. Visualizar o fluxo de trabalho; 2. Limitar a quantidade de trabalho em andamento; 3. Medir e otimizar o fluxo de trabalho; 4. Tornar explcitas as polticas do processo;5. Gerenciar quantitativamente.

O Kanban no uma metodologia, mas sim um framework para implementar mudanas de forma incremental. Esse um conceito muito importante para que se entenda o Kanban como um todo j que, quando se fala em metodologias, fala-se em conjuntos de prticas e o Kanban no tem nenhuma prtica prescrita. H, nele, somente propriedades que devem guiar a melhoria no processo atual, no importando quais prticas estejam sendo usadas.

Ao usar o Kanban, como veremos mais detalhes ao decorrer do artigo, esperado que se consiga visualizar quais prticas esto sendo positivas e quais esto sendo negativas e isso, consequentemente, vai conduzir a mudanas, que, natural-mente adicionaro, eliminaro ou alteraro as prticas atuais de trabalho.

A forma mais comum de se conseguir visualizar o fluxo de trabalho atravs de um kanban. Esse uma espcie de qua-dro, que pode ser fsico, normalmente colocado em uma das paredes do local onde a equipe trabalha, ou virtual. O uso do quadro virtual tem alguns prs e contras. Os pontos fortes so basicamente a facilidade de extrao de mtricas e o histrico. O principal ponto fraco dessa abordagem a dificuldade que a equipe ter para analisar e evoluir conjuntamente o processo de trabalho.

Nesse quadro, inicialmente devem ser modeladas cada uma das etapas necessrias para se produzir o software, isto , todo o workflow de trabalho. E, em cada uma dessas etapas deve ser colocado e mantido um carto, a fim de simbolizar um trabalho que est em andamento, como podemos ver na Figura 1. Cada um desses cartes deve conter informaes detalhadas sobre a atividade, bem como quem est desenvolvendo o item, e quando o mesmo foi iniciado.

No Kanban para desenvolvimento de software, o kanban deve ser mantido e evoludo por toda a equipe, o tempo todo. A proposta baseia-se em fazer a prpria equipe enxergar onde est errando e deix-la tomar decises seguindo um framework simples, que guiar grande parte dessas melhorias.

Figura 1. Kanban systems for software development [10]

Para Alisson Vale [5], em atividades que envolvem trabalho criativo, como desenvolvimento de software, o propsito do Kanban provocar conversaes sobre o sistema de trabalho.

Para limitar a quantidade de trabalho em andamento necessrio definir, monitorar e manter um limite mximo de tarefas em andamento para cada uma das etapas de trabalho mapeadas no quadro kanban, como visto na Figura 1.

Ao estabelecer os limites, a equipe comea a identificar onde esto os principais gargalos do processo de produo e comea a ter que terminar todo o trabalho inacabado na linha de produo para conseguir puxar mais trabalho para o gargalo. Com isso, o trabalho tende a ser finalizado de uma forma incremental e no de uma forma cascata, tornando-se assim um sistema puxado (TOC), onde a equipe que dita a sua capacidade de produo.

O uso do sistema puxado, juntamente com a visualizao de todo o processo de desenvolvimento por toda a equipe, permite implementar mudanas no processo de modo incremental. Consequentemente, h reduo significativa da resistncia, o que facilita o alcance do ritmo sustentvel, teoria to comenta-da em desenvolvimento gil, mas para a qual poucas definies existem alm das 40 horas semanais de trabalho.

Uma citao de David [1] sintetiza isso: Um interessante efeito colateral de sistemas puxados que eles limitam o trabalho em andamento (WIP Work In Progress) para certa quantidade acordada, evitando assim que trabalhadores fi-quem sobrecarregados..

Outro fator importante o ganho que se tem ao praticamente impedir que uma mesma pessoa execute vrias tarefas no mes-mo projeto em paralelo. Vale destacar tambm o processo Just in time (JIT), que evita o acmulo de estoque ao longo do processo de desenvolvimento, como se faz no ciclo de vida em cascata. Nesse caso, software em estoque so todos os requisitos que ainda no foram liberados para o cliente usar.

No desenvolvimento de um software, como em qualquer outra atividade intelectual, por mais contra intuitivo que possa parecer, executa-se com mais qualidade e mais rapidamente duas tarefas fazendo-as uma de cada vez, do que as duas em paralelo o tempo todo.


Segundo Rodrigo Yoshima [7], um dos grandes pontos fortes desse mtodo o modelo embutido nele para trabalhar com a melhoria de processos, o modelo Kaizen. Alm do modelo Kai-zen, existe o modelo Kaikaku. Vamos s diferenas: Kaikaku uma palavra que define mudanas de processos classificadas como melhoria radical. [7].

Implantar o Scrum, por exemplo, exige esse cenrio [7], pois o Scrum requer profundas mudanas organizacionais como a gesto abdicar de muitos instrumentos de controle, quebrar com a separao entre os grupos e mudar posies hierrquicas estabelecidas.

Kaizen a palavra Lean para indicar mudanas de melhoria menores e contnuas. Ao contrrio do Kaikaku, Kaizen no to traumtico, melhor aceito por todos (gerentes inclusive) e mais simples de implementar. Tudo a nossa volta est suscetvel a um evento Kaizen. Kaizen simplesmente significa mudana para melhor. [7].

Na abordagem Kanban, aplicando a cultura Kaizen, antes de mudar qualquer coisa devemos entender o ambiente de trabalho. Se filas, bloqueios, gargalos ou problemas entre reas esto nos prejudicando, primeiro, vamos visualizar isso, convencer o grupo dos problemas e usar Kaizen para a melhoria do ambiente com pequenas mudanas incrementais e constantes. Isso ir fortalecer a cultura da empresa, pois ela compreender suas falhas com provas palpveis que sero a motivao para as mudanas [7].

Segundo Jos Papo [8], alm disso, a filosofia e prticas Lean, como o caso do Kanban, focam na auto-organizao do time, na responsabilidade conjunta pelos objetivos de negcio do projeto e na produtividade com qualidade e com ritmo sustentvel. Todas elas so prticas de administrao consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento.

As duas ltimas propriedades do Kanban citadas (tornar ex-plcitas as polticas do processo e gerenciar quantitativamente) so praticamente atendidas deixando claro para toda a equipe as trs primeiras propriedades e reforando que toda sugesto de otimizao no processo deve ter como base modelos mate-mticos que provem as mtricas.

Kanban uma metodologia gil?Nos ltimos tempos, acompanhamos uma briga forte entre

Kanban e as demais metodologias geis, principalmente o Scrum. A polmica central : quem usa Kanban gil?

Rodrigo Yoshima [9] explica que o maior objetivo do Kanban melhorar um processo existente, por pior que ele seja. Ainda segundo Yoshima, o Kanban permite melhorar at mesmo processos que seguem o ciclo de vida em cascata, fazendo eles se tornarem geis e podendo melhorar continuamente, e at mesmo superarem o Agile. Isso tudo graas cultura Kaizen que o Kanban quer trazer tona.

Outro ponto a ser destacado que para o Kanban, diferente da grande maioria das metodologias geis, no importa quais prticas voc ir aplicar para melhorar o seu processo, o im-portante que voc tenha argumentos, preferencialmente estatsticos, que expliquem o porqu dessas decises.

Como David ressalta em seu livro [1], a abordagem evolutiva do Kanban, que promove a implementao de mudanas no proces-so de forma incremental, tem sido controversa na comunidade gil de desenvolvimento de software. Isso ocorre principalmente porque se sugere que as equipes no adotem um mtodo ou modelo de processo. Vale ressaltar que a atual indstria de servios e ferramentas desenvolveu-se em torno de um pequeno conjunto de prticas definidas em dois populares mtodos de desenvolvimento gil: XP e Scrum. Depois, com o Kanban, os indivduos e as equipes esto habilitados para desenvolver suas prprias solues por meio de um processo nico que evitaria a necessidade de tais servios e ferramentas. Isso porque os mesmos requerem um novo conjunto de ferramentas e servios muito especficos para cada realidade. Dessa forma, torna-se mais complicado para essa indstria ganhar dinheiro.

Tanta discusso acerca do assunto fez o pessoal do Kanban criar um logo de manifesto chamado: Yes We Kanban, que David [1] explica: O slogan Yes We Kanban se destina a enfatizar que voc tem permisso. Voc tem permisso para tentar Kanban. Voc tem permisso para modificar o seu pro-cesso. Voc tem permisso para ser diferente. Sua situao nica e merece o desenvolvimento de um processo adapta-do e otimizado para o seu domnio, o seu fluxo de valor, os riscos que voc gerencia, as habilidades de sua equipe e as demandas de seus clientes..

Portanto, podemos dizer que o objetivo de Kanban no tornar a sua equipe gil, e sim, melhorar a forma de trabalho. Ele tanto pode melhorar processos geis como tambm pode melhorar processos tradicionais.

Qual a receita para ter sucesso com Kanban?Para que qualquer pessoa que queira ser um agente de

mudana na sua organizao tenha sucesso rpido (ou, uma melhoria rpida) e com baixa resistncia da equipe, com foco na melhoria de processos em alguns pontos com o uso ou at mesmo sem o uso do mtodo Kanban, preciso seguir algumas etapas. De acordo com David, so elas: 1. Focar na qualidade;2. Limitar a quantidade de trabalho em progresso;3. Entregar frequentemente;4. Balancear demanda com a capacidade mxima;5. Priorizar tarefas;6. Atacar fontes de variedade.

O autor orienta que essas etapas sejam seguidas na ordem em que so apresentadas. A partir de agora, passa-se a discorrer um pouco a respeito de cada uma delas.

Focando na qualidadeComo os agentes de mudanas nas empresas de TI so ge-

ralmente pessoas com um background tcnico, essa tende a ser uma das etapas mais fceis de ser implementada, princi-palmente por ser um problema bem entendido por todos. As outras etapas desse guia [1] tendem a ter uma implementao mais difcil porque dependem da colaborao de outras reas


AgiLidAdE

e equipes. Com isso, exigem que o agente de mudana tenha muitas habilidades de negociao, articulao e bastante in-teligncia emocional [1].

Os maiores geradores de retrabalho em desenvolvimento de software so os defeitos causados principalmente pela baixa qualidade das entregas. E, alm de um gerador de retrabalho, baixa qualidade faz os clientes ficarem inseguros e a equipe desmotivada.

O incentivo qualidade das entregas tem um grande impacto na produtividade das equipes com altas taxas de defeitos. Segundo David [1], em equipes verdadeiramente ruins, somente concentrando-se na qualidade pode-se obter uma melhoria de produtividade de at dez vezes.

Para David [1], tanto as tcnicas de desenvolvimento gil como as abordagens tradicionais tm seu mrito para a melhoria da qualidade. As principais prticas incentivadas por ele para a melhoria da qualidade so:1. Escrever testes automatizados, preferencialmente antes;2. Revisar cdigo (Verificao);3. Fazer atividades de anlise e design do software de forma colaborativa;4. Usar Design Patterns;5. Usar ferramentas modernas de desenvolvimento.

Parece haver uma vantagem psicolgica em pedir para os desenvolvedores escreverem testes antes, porm, importante ressaltar que tambm existem inmeros casos de sucesso com a escrita dos testes aps a codificao.

Inspees ou revises de cdigo ajudam a melhorar tanto a qualidade externa como, notadamente, a qualidade interna do software. Todas as tcnicas tm o seu valor. Programao em par e reviso por pares so alguns exemplos. No entanto [1], ins-pees de cdigo so melhores quando so feitas em pequenas quantidades vrias vezes. David menciona [1] que ele costuma encorajar as suas equipes a inspecionar cdigo, todos os dias, por pelo menos 30 minutos.

Sem dvidas, quando toda a equipe trabalha em conjunto na anlise dos problemas para as solues de design, a qualidade superior do que quando apenas uma pessoa faz isso. Assim como as inspees de cdigo, atividades de modelagem de software devem ser feitas em pequenas quantidades, todos os dias.

Os padres de projeto de software, mais conhecidos pelo termo original em ingls Design Patterns, descrevem solues para problemas j conhecidos e recorrentes no desenvolvimento de software orientado a objetos. O uso de padres de projeto garante que defeitos de design sejam eliminados j no incio do projeto.

O uso de ferramentas modernas de desenvolvimento melhora a qualidade porque a grande maioria dessas inclui funes de anlise de cdigo esttica e dinmica, que evitam que os desenvol-vedores introduzam problemas bsicos e j bem compreendidos, como falhas de segurana, no software.

Limitando a quantidade de trabalho em andamento fcil especular porque limitar a quantidade de tarefas em

andamento aumenta a qualidade. A complexidade do trabalho

do conhecimento, como em desenvolvimento de software, cresce exponencialmente com a quantidade de trabalhos em andamento. Tanto a transferncia como a descoberta de infor-maes no desenvolvimento de software conhecimento tcito por natureza e criado durante sesses de trabalho colabora-tivo, face a face. A informao verbal e visual, mas em um formato casual, como um esboo em um quadro branco.

Nossas mentes tm uma capacidade limitada para armazenar conhecimento tcito. E, quanto mais tempo passa, h mais falhas para recordar detalhes precisos. Assim, uma srie de erros cometida. Equipes que trabalham de um modo gil, em um mesmo espao de trabalho, tm uma maior facilidade em reter o conhecimento tcito.

Mas, independentemente da forma de trabalho da equipe, o conhecimento tcito se deprecia com o passar do tempo. Por isso, tempos de espera (lead time) menores so essenciais para os processos que envolvem muito conhecimento tcito. O foco da reduo de trabalho em andamento est diretamente rela-cionado com a reduo dos tempos de espera (lead time).

Assim, podemos deduzir que haver menor depreciao de conhecimento tcito quando temos menos trabalho em progresso o que resultar em maior qualidade. Em resumo, reduzindo a quantidade de trabalho em andamento, melhora-se a qualidade e possibilita-se entregas mais frequentes. Isso aumenta a confiana externa na equipe.

Alm de reduzir a quantidade de trabalho em andamento, importante reduzir o tempo de uma iterao, pois isso tambm trar um impacto positivo significativo na qualidade. Segundo David [1], parece que existe uma relao entre a quantidade de trabalho em andamento e a qualidade, ou seja, defeitos vo aumentar com o aumento da quantidade de WIP. Portanto, faz sentido que iteraes de duas semanas sejam melhores do que iteraes de quatro semanas e que iteraes de uma semana sejam melhores ainda. Iteraes mais curtas iro resultar em entregas de maior qualidade.

Seguindo a lgica das evidncias apresentadas, se sabido que limitar o WIP ir melhorar a qualidade, por que no intro-duzir poltica explcita para isso, deixando assim os gerentes livres para se concentrarem em outras atividades? Essa jus-tamente uma das propriedades do Kanban. Entretanto David afirma [1] que ainda no existe nenhuma evidncia cientfica desse resultado que foi observado apenas empiricamente.

Entregando frequentementePara entendermos a importncia dessa etapa, David apresenta

uma excelente analogia em seu livro [1]: Quando eu ensino isso nas aulas, eu gosto de perguntar s mulheres da classe o que elas pensam sobre duas situaes depois de ter um pri-meiro encontro com um cara: Situao 1: Eles tiveram um bom encontro, mas depois disso ele no d sinais de vida a ela durante duas semanas. Mas, ento, ele aparece em sua porta com um ramo de flo-res e um pedido de desculpas; Situao 2: Eles tiveram um bom encontro e na mesma noite a caminho de casa ele envia uma mensagem de texto a ela


dizendo: Eu me diverti muito esta noite. Eu realmente quero me encontrar com voc novamente. Posso ligar para voc amanh? E, esse mesmo cara, segue ligando e enviando mensagens dia aps dia.

Qual cara vocs acham que elas preferem?.

Pequenos e frequentes gestos no custam quase nada, entre-tanto, eles constroem mais confiana do que grandes e caros gestos ocasionalmente. Portanto, realizar frequentemente pequenas entregas de alta qualidade constri mais confiana para as equipes parceiras do que entregas maiores, mas com menos frequncia.

Balanceando a demanda com a capacidade mximaConstruir um consenso em torno da necessidade de equilibrar

a demanda contra a capacidade da equipe crucial. No entanto, para isso, preciso resolver problemas como a disfuno entre os papis e as responsabilidades dos membros da equipe.

Essa etapa implica definir a taxa em que a equipe aceita novos requisitos no processo de desenvolvimento de software para corresponder com a capacidade em que a equipe pode entregar cdigo de qualidade.

Quando se faz isso, fixa-se efetivamente a quantidade de trabalho em andamento, permitindo efetivamente que seja a equipe que crie a demanda de acordo com a sua capacidade (sistema puxado).

Priorizando tarefasPriorizar trabalho da rea de negcios, e no da rea de

TI da organizao. Assim, no deveria ser da competncia de um gerente tcnico fazer isso. Entretanto, infelizmente, comum a rea de negcios delegar a responsabilidade e deixar um gerente tcnico priorizar o trabalho e depois culpar que o gerente fez escolhas erradas.

Neste ponto, a ateno da gerncia deve-se voltar para otimi-zar o valor entregue ao invs de meramente a quantidade de cdigo entregue.

Atacando fontes de variedadePodemos entender como fontes de variedade tudo aquilo

que de alguma forma prejudica o desempenho do processo de produo.

Atacar as fontes de variedade a ltima etapa da receita porque alguns tipos de variedade exigem profundas mudanas de comportamento e, consequentemente, uma alta resistncia da equipe.

A dica para implementar essa etapa focar nas fontes de va-riedade que requerem pequenas mudanas de comportamento e que podem ser aceitas facilmente pela equipe.

Segundo David [1], no se deve focar nessa etapa sem antes implementar e dominar as primeiras cinco etapas da receita.

Resumindo, essa receita a forma que David [1] acredita que uma equipe de desenvolvimento de software deve amadure-cer: Em primeiro lugar, aprender a construir cdigo de alta qualidade. Em seguida, reduzir o trabalho em andamento,

encurtar os lead times, e entregar (software funcionando) com frequncia. Em seguida, equilibrar a demanda contra a capacidade mxima, limitar a quantidade de trabalho em andamento, e criar folga para liberar capacidade, o que permitir a melhoria contnua. Ento, com isso funcionando razoavelmente e continuamente otimizando a capacidade de desenvolvimento de software, melhore a priorizao para otimizar a entrega de valor..

O Kanban permite que voc implemente todas as seis etapas dessa receita.

Concluso interessante conhecer as motivaes que levaram David

Anderson a chegar at o mtodo Kanban para o Desenvol-vimento de Software e, atravs da sua receita, entender o porque da maioria das propriedades por trs do Kanban. Essa metodologia tem sido um assunto recorrente e tende a continuar sendo, j que uma forma eficiente de melhorar continuamente a rea.

Se a sua empresa est com dificuldades para melhorar, no importa se ela adota mtodos geis ou no, o Kanban pode ser uma das alternativas para fazer isso com o mnimo de resistncia, pois, alm de toda a simplicidade do mtodo, suas propriedades promovem a colaborao.




D

seu Fe

edback

sob

re esta edio

1. Anderson, D. (2010) Kanban: Successful Evolutionary Change for Your Technology Business.

Washington, Blue Hole Press.

2. Martin, R. (2011) The Clean Coder: A Code of Conduct for Professional Programmers. Indiana,

Prentice Hall.

3. Anderson, D. (2003) Agile Management for Software Engineering: Applying the Theory of

Constraints for Business Results. New Jersey, Prentice Hall.

4. Bernab, J. (2011) Mais comprometimento = menos produtividade? http://www.teamware.

com.br/blog/mais-comprometimento-menos-produtividade/

5. Vale, A. (2011) Kanban Explicado. http://www.slideshare.net/alissonvale/kanban-explicado

6. Wikipdia. TOC. http://pt.wikipedia.org/wiki/Teoria_das_restri%C3%A7%C3%B5es

7. Yoshima, R. (2011) Kaikaku Kaizen, http://blog.aspercom.com.br/2011/09/09/kaikaku-

kaizen/

8. Papo, J. (2010) Porque Lean/Agile funcionam? http://josepaulopapo.blogspot.com/2010/03/

agile-lean-funciona-por-que.html

9. ABES (2011). O Mercado Brasileiro de Software em 2011. http://www.abes.org.br/UserFiles/

Image/PDFs/Mercado_BR2011.pdf

10. Corey Ladas (2007). Kanban systems for software development (Imagem) http://

leansoftwareengineering.com/wp-content/uploads/2007/08/kanban1.png

Referncias


Luiz Carlos Vianna [email protected]

Atua h mais de 13 anos na rea de TI, em diversas reas - desde gesto, apoio tcnico para a equipe de vendas, anlise e levantamento de requisitos, consultoria de processos e metodologias, planejamento de arquitetura, desenvolvimento e testes. Engenheiro Eltrico de formao, com ps-graduao em administrao e especiali-zao em gesto de projetos. Certificado ScrumMaster, PMP, ITIL e COBIT.

De que se trata o artigo?O artigo trata da utilizao em conjunto do PMI e do Scrum para o controle de projetos. O artigo voltado mais para o ambiente de empresas que no so de TI, mas que a utili-zam para atingir os seus objetivos.

Em que situao o tema til?Este artigo til a todos que desempenham papel como lderes em projetos de TI; a todos os gerentes de projetos que precisam se re-lacionar com a rea de TI em seus projetos; a todos aqueles responsveis por reas de TI que estejam buscando uma melhoria na produtivi-dade de seus processos; e a todos que querem conhecer um pouco mais sobre metodologias geis em ambientes organizacionais.

Resumo?Atualmente, bastante tem se falado a res-peito da utilizao do PMI com metodolo-gias geis sendo inclusive tpico de dis-cusso dentro do prprio PMI. A ideia deste artigo dar um overview a respeito tanto do PMI quanto do Scrum, e tentar mostrar como ambas as propostas se encaixariam em um projeto que lida com TI.

PMI versus ScrumO equilbrio ser possvel?

Quando falamos de melhoria da produtividade e qualidade na rea de desenvolvimento de software, temos visto um embate entre duas grandes vertentes: defensores da gesto de projetos (com maior nfase ao PMI), e defensores de mtodos geis de desenvolvimento (mais fortemente, o Scrum).

Com o crescimento do nmero de em-presas (e gerentes de projetos) utilizan-do-se de metodologias de desenvolvi-mento geis para ampliar o portflio de ferramentas de gerenciamento, alguns voluntrios do PMI criaram um grupo de pesquisas a respeito da utilizao dessas metodologias em projetos.

Um dos subprodutos foi a criao de uma certificao voltada para os gerentes de projetos que buscavam se aproximar das prticas geis.



18 Engenharia de Software Magazine - PMI versus Scrum

Pode-se at questionar a criao de uma prova, mas isso de-monstra o interesse que as metodologias geis tm despertado em toda a comunidade que lida com software.

Uma boa parcela das pessoas que atuam na rea de TI j deve ter ouvido comentrios de pessoas que dizem que ambos so incompatveis, e que apenas uma jogada de marketing. Outros comentrios dizem que sim, eles so totalmente com-patveis, e que quem no consegue ver isso no entendeu nada de ambas. Mas afinal, d ou no d para integrar PMI e metodologias geis?

Neste artigo, iremos falar um pouco sobre PMI e Scrum, tentar encontrar semelhanas e diferenas, e verificar a possibilidade de construir um ponto de equilbrio na busca de melhores processos de desenvolvimento.

Breve introduo ao ScrumO Scrum um processo interativo para o desenvolvimento de

aplicaes. Como caractersticas, podemos destacar: Integrao com o cliente A equipe deve estar sincronizada sempre com o proprietrio do produto para no perder o foco; Priorizao das atividades Fazer o que mais importante para o cliente; Desenvolvimento incremental As entregas devem ser constantes e funcionais, para que o proprietrio possa avaliar o que foi feito e obter valor rapidamente; Equipes auto gerenciadas Cabe equipe decidir como fazer e o ritmo que deve seguir.

No Scrum, o cliente (representado pelo papel do Product Ow-ner) inicialmente define quais so as suas necessidades e monta uma lista chamada Product Backlog. Confira o fluxo do Scrum na Figura 1. O Product Owner rene-se ento com a equipe, e explica os itens para ela.

A equipe adiciona os itens necessrios do ponto de vista tcnico (por exemplo, demandas de segurana obrigatrios), e determina uma estimativa de tempo para a construo de cada item.

Com base nessa estimativa de tempo e na importncia para o negcio, o Product Owner prioriza os itens que devero seguir no prximo ciclo (ou Sprint). No Scrum, todos os Sprints tm a mesma quantidade de tempo pr-determinada (fixo, determi-nado em acordo, e em geral entre 15 a 21 dias).

A equipe agora tem uma lista de itens que devem ser re-alizados. Ela deve ento se organizar para a realizao das atividades.

Neste Sprint, a equipe deve se esforar para entregar o que combinou com o Product Owner. O produto do ciclo deve ser um pedao de software inteiramente funcional caso contrrio, o item no ser considerado completo, e ir para o prximo Sprint.

Por fim, aps a entrega das novas funcionalidades, a equipe se rene para analisar o que aconteceu no ciclo, e entender o que poderia ser melhorado no processo. Esta reunio chamada de Retrospectiva.

Breve introduo gesto de projetos baseada no PMBOK

Com o objetivo de estudar e difundir as melhores prticas de gerenciamento de projetos, o Project Management Institute (PMI) analisou projetos de diversas reas (engenharia, desenvolvi-mento de software, manufatura, etc.) e identificou um conjunto de processos e prticas que, se bem trabalhados e monitorados, costumam levar ao sucesso dos projetos. Ele ento agrupou essas informaes em um livro, que ficou conhecido como Project Management Book of Knowledge (PMBOK).

Antes de entendermos o que gesto de projetos, vamos en-tender qual a definio de projeto. Segundo o PMBOK, projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Da, pode-se destacar: Esforo temporrio Entenda que temporrio no significa curto. Um projeto pode levar anos para ser feito. Entretanto, ele deve ter comeo, meio e fim. Algo que se repete continuamente NO caracteriza um projeto; Cria um produto, servio ou resultado especfico Um projeto deve sempre gerar um resultado nico, algo que no existia antes. Sendo assim, construir um sistema que integra a parte contbil da empresa um projeto. Garantir a operao do software e responder ao chamado dos usurios no.

Vamos ilustrar esse conceito, dando trs exemplos:1. Construo de um mdulo contbil em um ERP corporativo;2. Criao de uma campanha de marketing, para promover a marca da empresa. Essa campanha ir envolver a criao de um portal para os clientes e uma campanha de divulgao com os fornecedores;3. Atendimento de um chamado para a correo de um bug no ERP corporativo.

No primeiro exemplo, fcil identificar que um projeto, cujo produto o prprio mdulo contbil. J no segundo exemplo, a fronteira menos definida: O produto do projeto a campanha de marketing. Tanto o portal quanto a elaborao do material de divulgao so subprodutos do projeto (e podem, inclusive, serem separados em subprojetos). A realizao da campanha em si pode se tornar uma atividade de rotina na empresa e, portanto, deixa de ser um projeto.

Figura 1. Ciclo de desenvolvimento Scrum


AgiLidAdE

Por fim, o ltimo exemplo NO considerado um projeto, j que uma atividade rotineira (entretanto, em alguns casos, a identificao de um bug pode trazer a necessidade de criao de um projeto para corrigir o problema).

Agora que entendemos a definio do que seria um projeto, vamos ver qual seria a definio de gerenciamento de projetos, extrada do PMBOK: Aplicao de conhecimento, habilida-des, tcnicas e ferramentas s atividades do projeto a fim de alcanar os requisitos do projeto. Sendo assim, gerenciar um projeto compe-se das seguintes atividades: Identificar quais so os requisitos (aonde queremos chegar?); Identificar as mtricas ou indicadores de sucesso (como saber se chegamos?); Traar planos (o que temos que fazer para chegar l?);Adaptar os planos s mudanas nas necessidades e corrigir os desvios (estamos na direo certa?).

Neste ponto, o PMBOK um guia para o gerente de projetos. Ele traz um conjunto de processos e prticas que so aplicveis a projetos bem sucedidos em diversas reas. Na verso atual (4.0), ele traz um conjunto de 32 processos reunidos em cinco grupos de processos. Cada um desses grupos est atrelado a um momento dentro da fase do projeto. Esses grupos so: Iniciao: Identifica tudo o que precisa ser feito ANTES de se iniciar o projeto. Isso compreende: obter a aprovao do cliente para o incio do projeto, identificar quais so os objetivos por trs do projeto e mapear pessoas que possam impactar (posi-tiva ou negativamente) o andamento do projeto; Planejamento: Neste ponto, devemos traar um plano de como vamos fazer o que deve ser feito; Execuo: J temos tudo em mos, ento precisamos colocar o que foi planejado em execuo; Monitoramento e Controle: Precisamos garantir que no ir haver desvios de rumo. Caso haja necessidade de corri-gir alguma coisa, precisamos fazer as mudanas de rumo apropriadas; Encerramento: No podemos considerar que um projeto (ou fase) foi entregue se no tivermos o aceite formal do projeto. Alm disso, esse o ponto em que encerrarmos contratos (em caso de subcontrataes), e fazemos uma reviso formal para que possamos aprender com os nossos erros.

Para quem mais familiarizado com administrao, isso nada mais que uma verso do modelo PDCA (Plan-Do-Check-Act).

Alm disso, esses momentos se intercalam, de forma que cada parte do projeto pode estar em um momento diferente. Para dar um exemplo: em um projeto de um grande site podemos subcontratar uma empresa de design para fazer o layout do mesmo. Assim que ela nos entrega o layout, validamos o que foi entregue e finalizamos o contrato processos tpicos de Encerramento mesmo quando ainda estamos no meio da Execuo do desenvolvimento do cdigo.

Nem todo projeto composto, obrigatoriamente, de uma nica fase. De acordo com a nossa necessidade, podemos ter uma ou

mais fases em um projeto. Podemos notar aqui certa semelhana entre as entregas sequenciais do Scrum e as fases do PMBOK.

Alm disso, os processos tambm podem ser classificados pelas reas de conhecimento ao qual eles se referem, que podem ser vistas na Figura 2. Cada uma dessas reas de conhecimento se refere a algo que o gerente de projetos deve gerenciar durante o projeto.

Os processos da rea de integrao so comuns e integram as demais reas. Nela temos os processos ligados a organizar o planejamento, gerir mudanas, organizar indicadores de progresso e atuar sobre eles, e como encerrar um projeto. Considera-se que esta a funo primria de um gerente de projetos (i.e. ser o integrador).

Figura 2. PMI reas de conhecimento

Isso no significa que os conhecimentos, as habilidades e os processos descritos sempre devem ser aplicados de forma uni-forme em todos os projetos. Para qualquer projeto especfico, o gerente de projetos, em colaborao com a equipe do projeto, sempre responsvel por determinar quais processos so apropriados e o grau de rigor apropriado para cada um.

E agora, possvel mesmo compatibilizar ambos os mundos? Afinal, d ou no d para integrar PMI e Scrum?

Foco no objetivoA primeira coisa que precisamos entender que gerenciar

um projeto muito mais do que fazer software. Muitas pessoas (e, infelizmente, alguns gerentes de projeto)

acreditam que o sucesso de um projeto depende apenas se ele foi entregue atendendo s restries de tempo, prazo, custo e qualidade.

Na realidade, a viso moderna de gesto nos diz que para que possamos considerar um projeto como um sucesso, temos que poder responder positivamente s duas perguntas abaixo: O produto do projeto atendeu as necessidades do cliente? O cliente est contente com o resultado pelo menos o su-ficiente para continuar pagando o seu salrio ou contratando sua empresa?


Ou seja, no adianta construirmos um projeto que um case do ponto de vista da metodologia, se o produto no agregar valor ao cliente. Trazer valor para quem paga o que vai ga-rantir que nos perpetuemos na empresa/mercado.

Para atendermos a esses objetivos, precisamos olhar muito mais do que apenas o produto que construmos (seja uma casa, um carro, ou um software). Para termos sucesso real, precisamos olhar para os fatores externos ao projeto. Precisamos: Identificar quem ser impactado pelo projeto (vulgos stakeholders); Garantir que o projeto tenha os recursos necessrios para ser realizado (equipe, verba, sala, etc.); Determinar e garantir a infraestrutura necessria para sua operao (sejam, por exemplo, servidores, novos processos operacionais, treinamento interno da equipe de operao); Gerenciar as expectativas das pessoas (seja o time do projeto, reas usurias, cliente, associaes externas como sindicatos, etc.); Identificar a quem seria interessante auxiliar/prejudicar o andamento do projeto, e atuar de forma proativa, visando ampliar/minimizar o impacto de suas aes; Entre outros fatores.

Claro que, grande parte dos projetos de TI so pequenos, envolve um pequeno nmero de pessoas e recursos e utilizam uma infraestrutura muitas vezes pr-existente. Assim sendo, raramente nos preocupamos com esses fatores.

Mas uma anlise inadequada pode virar uma bomba relgio na empresa. Podemos ter cenrios aonde, por planejamento inadequado, podemos ter um problema nas mos.

Para citar um exemplo: por no termos realizado uma anlise adequada de utilizao, ao colocarmos o nosso projeto no ar o banco de dados da empresa (compartilhado com outros siste-mas) fica sobrecarregado e para, comprometendo o fechamento mensal. O problema pode at ser resolvido rapidamente, mas o custo do impacto gerado j foi incorrido.

Nesse aspecto, podemos ver que as prticas do PMBOK ampliam as ferramentas do Scrum trazendo uma viso mais ampla do negcio.

O gerente de projetos no ScrumKen Schwaber, um dos pais do Scrum, define o Product Owner

como sendo o responsvel por representar os interesses de todos que tenham algum interesse no projeto ou seu produto resultante. Ele obtm os fundos para o projeto, cria a lista de requisitos, os objetivos de retorno do investimento (ROI) e planos de liberao..

Por aqui voc j pode notar que, dependendo do projeto, o gerente de projetos tem uma grande afinidade com o papel do Product Owner. Apesar dele no ser a pessoa que melhor conhece o negcio, a pessoa que conhece a empresa e tem o respaldo poltico para agir em nome do patrocinador do projeto (poder este declarado no termo de abertura) e poder para mobilizar a empresa em uma direo.

E com relao ao papel de ScrumMaster? Ser que ambos podem se misturar? Novamente, citando Ken Schwaber, temos

que O time uma estrutura auto gerenciada, auto organizada e multi funcional, responsvel por descobrir como transformar o Backlog do produto em um incremento de funcionalidades dentro de uma interao. Os membros do time so respons-veis, coletivamente, pelo sucesso de cada interao e do projeto como um todo.

Destacamos o termo auto gerenciada porque no Scrum todos os membros da equipe so responsveis pelas decises e pelos planos de ao. E, assim sendo, so tambm corresponsveis pelo sucesso de suas decises.

O lder (ScrumMaster) ento no visto como algum res-ponsvel por tomar decises, montar planos de ao ou dar ordens todas essas so responsabilidades da equipe. O lder possui apenas um papel adicional: agir como facilitador tanto dentro do time (para que a equipe no se perca em conflitos) e entre a equipe e o ambiente externo (o ambiente externo representado aqui pelo Product Owner). Ou seja, ele um representante em uma equipe auto gerenciada.

Olhando sob o ponto de vista tradicional, gerentes esto em outro grau hierrquico. Raramente as pessoas sero capazes de separar esse fato de suas rotinas. Sendo assim, o fato de haver dentro do time algum em uma hierarquia diferente pode atrapalhar o auto gerenciamento do time e com isso perdermos a prpria integrao que torna um grupo de pessoas um time de desempenho diferenciado. Isso pode se transformar em um desafio para o gerente de projetos, o que pode no trazer bons resultados ao projeto.

Alm disso, em projetos grandes, raramente sobrar tempo ao gerente de projetos para estar constantemente com a equipe, j que em geral eles tm outras responsabilidades como: lidar com fornecedores, reunir-se com os interessados, se envolver com a poltica da organizao, identificar e enderear riscos internos/externos ao projeto, cobrar recursos que foram pro-metidos, comunicar a diretoria sobre o andamento do projeto, etc. Ou seja, como ele pode no estar disponvel para a equipe sempre que necessrio, ao invs de tornar-se um facilitador ele pode acabar atuando mais como um gargalo ao desenvol-vimento do projeto.

Seria muito bom ento que o ScrumMaster fosse algum da prpria equipe de desenvolvimento, algum que conhece a ro-tina diria da equipe e que tem o apoio desta. E para incentivar a auto-organizao, um bom passo seria que este seja indicado pela prpria equipe a qual ele ir representar.

Como controlar o escopo?Um dos grandes pesadelos do gerente de projetos a mu-

dana de escopo. Mudanas de escopo causam retrabalho, atrasos, e aumentam o custo e os riscos do projeto. Precisamos compreender que o antigo mantra do gerenciamento no pra-zo, no oramento, dentro do escopo no realista para um ambiente dinmico.

Muito provavelmente iremos ter mudanas profundas nos requisitos durante toda a vida do projeto. Seja porque o cliente ainda no tem uma ideia completamente formada sobre o que o produto (esse ponto ainda mais grave no


AgiLidAdE

desenvolvimento de produtos abstratos como software), por-que ocorrem mudanas de legislao, polticas e de mercado (cada vez mais comuns nos dias de hoje), ou o surgimento de novas tecnologias.

O prprio PMBOK mostra sua preocupao com o inespe-rado. Em algumas situaes, ele nos sugere quebrar nosso projeto em fases progressivamente mais detalhadas conforme caminhamos (o chamado Planejamento por Ondas Sucessivas). Alm disso, vrios processos de controle de mudanas so apresentados.

Infelizmente, o PMBOK no explcito o bastante para nos dizer COMO fazer. Sendo assim, vrios gestores e/ou crti-cos simplesmente deixam esse ponto para segundo plano, e utilizam o PMBOK apenas como a velha cartilha do modelo waterfall. Alm disso, a maioria das ferramentas auxiliares usadas para o controle do projeto (como o WBS e o grfico de Gantt) torna-se bastante difcil de ser atualizada, dependendo do grau de detalhes que o gestor utilizar para controlar o seu projeto.

Neste aspecto, o Scrum pode nos auxiliar bastante. Por sua prpria natureza, como se o Scrum nos dissesse: Ei, como eu posso te dizer o que eu vou te entregar a daqui a seis meses se nem voc sabe o que vai precisar?. Ao invs de controlar o que precisa ser feito a partir das TAREFAS (como construir a tela XPTO), o Scrum sugere controlar o que precisa ser feito atravs das FUNCIONALIDADES que devem ser agregadas.

Alm disso, ao invs de tentar congelar o escopo do projeto por meses, o Scrum busca congelar pequenos trechos do projeto por vez e atuar neles o chamado Sprint. O resto do projeto ainda indefinido e, como tal, s nos preocupamos em defini-lo melhor quando nos aproximarmos deste ponto.

Buscamos fazer, mais para o comeo, as atividades mais prioritrias para o cliente. Para isso, o cliente (Product Owner) o responsvel por priorizar as atividades. Para priorizar, utilizamos sistemas de pesos e faixas de corte (por exemplo, itens obrigatrios, itens que podem ser entregues em uma segunda fase e itens opcionais).

Ao trabalharmos com entregas constantes e focando apenas no que mais prioritrio para o cliente naquele momento, tornamos visvel o que estamos fazendo e, caso as prioridades mudem, iremos dispender menos tempo em replanejamento.

Alm disso, podemos reavaliar o produto de uma fase e, caso necessrio, atuar em cima do nosso processo rapidamente para corrigir/evitar problemas e reavaliar o prazo ou at mesmo cancelar o projeto.

Como estimar prazos?No devemos nos enganar: A primeira pergunta do diretor

comercial da sua empresa quando pedir um projeto quando ele estar pronto (segunda, caso seja um projeto contratado externo).

Isso tem relao, muitas vezes, com a prpria estrutura de planejamento da empresa. Como dito anteriormente, o softwa-re muitas vezes apenas uma pequena parte de um projeto como um todo. A empresa precisa treinar as pessoas, preparar

material de marketing, adequar normas e procedimentos ma-nuais, e muitas outras atividades antes que o software possa entrar no ar.

Claro que, em um primeiro momento, qualquer estimativa que fizermos ser sempre uma estimativa de elevada incerteza. As estimativas que temos no comeo do projeto s sero refina-das durante a vida do projeto, para refletir detalhes adicionais. Entretanto, para quem melhor perguntar quanto tempo uma tarefa ir durar? Para o gerente que tem centenas de atividades na cabea, ou para a pessoa que ir realizar a tarefa?

Sendo assim, a forma mais precisa de fazer essa estimativa definir o que deve ser feito (definido como funcionalidades, como por exemplo permitir ao cliente agendar um voo) e perguntar diretamente a quem vai fazer a tarefa quanto tempo ir levar para cumprir uma atividade. No PMBOK isto est previsto, e chama-se de estimativa bottom-up, e dentre as alternativas ela considerada a mais precisa. J o Scrum nem leva em conta as demais alternativas, sendo papel da equipe definir estimativas para cada um dos itens do backlog neces-srios para o desenvolvimento do produto.

De posse das estimativas de tempo de desenvolvimento e da prioridade atribuda a cada funcionalidade pelo respon-svel pelo produto, agrupamos as nossas atividades dentro de Sprints, e temos uma ideia de quantos ciclos (ou Sprints) o conjunto de atividades necessrio ir levar para ficar pronto.

Como estimar custos?O Scrum no entra em detalhes na questo do custo do projeto,

mas precisamos lidar com os custos envolvidos no desenvol-vimento principalmente quando produzimos sistemas para um cliente.

Em um projeto de TI, na maior parte das vezes o principal custo est relacionado aos gastos com mo-de-obra. Para os demais custos (podemos ter gastos com servidores, contratao de funcionrios, taxas, seguros e outros), podemos utilizar os conceitos identificados no PMBOK.

No mundo ideal, estamos trabalhando em paralelo com a empresa cliente (ou somos funcionrios do cliente) e cada funcionalidade necessria orada em alguma unidade de medida pela equipe, e o valor de cada ponto nesta unidade multiplicado por um preo fixo. Caso haja alguma incoerncia na estimativa, como uma estimativa incorreta, os dois lados reveem os motivos e os custos adicionais so compartilhados por ambas as partes.

Podemos discutir o quanto quisermos a respeito das virtudes dos modelos de contrato a custo reembolsvel ou contrato por tempo e material (bem semelhantes ao descrito acima) para a estimativa de projetos de TI, mas muitas vezes ser difcil convencer as empresas a aceitar tipos de contratos diferentes de contratos de preo fixo. Esse o tipo de contrato mais usual no mercado, e essa ser uma situao comum com a qual o gerente de projetos ir se deparar.

Uma abordagem bastante comum na literatura fixar paco-tes de pontos. Nesta abordagem, o comprador efetivamente est comprando uma potencialidade de desenvolvimento.


Caso sejam necessrias alteraes de escopo, caso o saldo de pontos estejam dentro do definido em contrato, as alteraes solicitadas pelo cliente podem ser feitas desde que outras atividades sejam excludas. Este tipo de contrato uma aborda-gem interessante, e pode permitir empresa cliente se adaptar para lidar com um fornecedor que trabalha sob este modelo de desenvolvimento.

Como gerir mudanas?Com relao gesto de mudanas, a abordagem tradicional

do PMBOK de buscar variaes em cima do plano no se encai-xa bem em um cenrio dinmico. Isso porque se considera que o plano est correto, e o que foge ao plano precisa ser analisado e compreendido e a causa raiz deve ser determinada.

Em ambientes dinmicos, o plano representa apenas a melhor previso que pudemos realizar, dados todos os fatores desconhe-cidos envolvidos. Sendo assim, assumir a mudana como norma parece ser muito mais efetivo do que reagir mudana.

Entretanto, como conseguimos encaixar a adaptao mudana ao nosso planejamento? Como saber o impacto que uma mudana vai trazer ao nosso projeto? E como eu cobro por isso?

Conforme comentado anteriormente, no Scrum o nico mo-mento em que se congela as atividades durante um Sprint. Fora deste perodo, o responsvel pelo produto possui liber-dade para repriorizar, incluir ou excluir atividades.

Caso haja espao no cronograma, as alteraes so ento absorvidas pelo cronograma e custos atuais. Mas na maior parte dos casos no haver espao disponvel. Neste caso, como devemos agir?

Neste caso, as atividades menos prioritrias so deslocadas para baixo na escala, e caso no haja prazo suficiente ou outras atividades levem mais tempo do que o previsto, as atividades so canceladas de baixo para cima (ou seja, da menos impor-tante para a mais importante). Como a lista de prioridades est disponvel para todos, o gerente deve apenas comunicar aos interessados at quais funcionalidades sero implementadas na verso, e quais ficaro de fora.

Se analisarmos o PMBOK, este fluxo basicamente equivale ao Comit de Mudanas, mas neste caso o rbitro responsvel pela deciso do comit seria o prprio Product Owner, e as mudanas solicitadas seriam consideradas pr-aprovadas se as alteraes efetuadas no impactarem na quantidade total de trabalho do projeto. Caso haja impacto no total de trabalho, acordos comerciais podem ser revistos.

ConclusoNeste artigo, pudemos ver como o Scrum pode ser utilizado

pelo gerente de projetos de forma a trazer ganhos de produti-vidade no desenvolvimento de software e como compatibilizar a definio e a gesto de escopo, tempo e custo, alm de como enxergar a gesto de mudanas sem ferir os padres de pro-cesso descritos no PMBOK.

Alm disso, vimos como a gesto de projetos acaba tendo uma preocupao mais ampla que o Scrum quando nos prope pensar no impacto do projeto como um todo na empresa, nos usurios, clientes, fornecedores e comunidades. Sendo assim, o que TI est fazendo muitas vezes apenas a ponta do ice-berg, ou seja, apenas uma frao do trabalho total que ser necessrio para atingir os objetivos da empresa.

Como precisamos ter algum capaz de advogar por isso no dia-a-dia do desenvolvimento, o artigo prope que o geren-te de projetos se afaste do controle das atividades, para se aproximar mais do papel do responsvel pelo produto final, aproximando-o do papel de Product Owner.




D

seu Fe

edback

sob

re esta edio

Project Management Institute. (2008). Um guia do conhecimento em gerenciamento de

projetos (PMBOK Guide) 4a Edio

Mike Cottmeyer. (2009). Agile PMP: Managing Software Projects in the Face of Uncertainty

Kelley Hunsberg. (2011). Change is Good

Michele Sliger. (2008). Agile Project Management and the PMBOK Guide

Ken Schwaber. (2004). Agile Project Management with Scrum

Mike Griffiths. (2004). Utilizing Agile Principles alongside A Guide to the Project Management

Body of Knowledge (PMBOK Guide) for better project execution and control in software

development projects.

Ron Armstrong Requirements of a Self-Managed Team Leader

http://www.leader-values.com/Content/detail.asp?ContentDetailID=1004

Referncias


Marco Antnio Pereira Arajo [email protected]

Doutor e Mestre em Engenharia de Sis-temas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela UFJF, professor dos Cursos de Bacha-relado em Sistemas de Informao do CES/JF, da FMG e da USS, professor do curso de Bacharelado em Cincia da Computao da FAGOC, professor do curso de Tecnologia em Anlise e Desenvolvimento de Sistemas da FAA, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

Aline da Silva [email protected]

Ps Graduada em Gerncia de Projetos em Engenharia de Software Centro de Ensino Superior de Juiz de Fora. Tecnloga em Siste-mas para Internet Faculdades Integradas Vianna Jnior. Consultora de Marketing Digi-tal - 8Ps . Atua como Gerente de Projetos na Ato.interativo agncia digital.

De que se trata o artigo?Aborda a importncia do uso de ferramentas para gesto de projetos com o objetivo de mostrar as principais funcionalidades das mais populares. Neste contexto, o artigo destaca a importncia do gerenciamento de um projeto e a utilizao de ferramentas que podem auxiliar nessa tarefa, alm de ressaltar suas principais caractersticas.

Em que situao o tema til?O tema se torna fundamental para gerentes e empresas que buscam aprimorar a gesto de seus projetos levando em considerao fatores como escopo, tempo, recursos, custos e qualidade, entre outros.

Resumo?O gerenciamento de projetos deve ser feito com a aplicao de conhecimentos, habili-

dades, ferramentas e tcnicas. Com o uso de metodologias, a implantao da cultura de projetos pode ser realizada para garantir a aplicao dos princpios de gerenciamento de projetos de forma padronizada, buscan-do atender da melhor forma s necessidades das organizaes. Neste sentido, este artigo abordar cinco das principais ferramentas de gesto de projetos, suas vantagens e desvan-tagens apresentadas. Alm disso, ir destacar a importncia da gesto de projetos dentro das organizaes, ressaltando as funes que o gerente deve exercer, como o planejamento de aes, a definio de processos e tcnicas, o uso de ferramentas adequadas ao projeto e suas principais funcionalidades.

Documents

Engenharia de Software - Edição 45