O que é Scrum mesmo? Parte I

Posted on by
Reply

Percebi que não havia feito nenhum post especificamente sobre Scrum. Então comecei a escrever um post sobre conceitos e sobre a cultura Scrum, mas percebi que ficou muito longo. Tomei a decisão de, ao invés escrever um post longo que ninguém iria ler, farei uma série de posts falando sobre uma parte do Scrum. Neste post inicial irei falar sobre o que é o Scrum e qual é o seu real papel em um ambiente de desenvolvimento de software.

Scrum é um framework que vem sendo utilizado para gerenciar o processo de desenvolvimento de produtos complexos [Schwaber; Sutherland, 2011]. Através de processos empíricos, as pessoas envolvidas conseguem criar soluções para problemas encontrados e, consequentemente, melhorar o processo, o produto e próprio time.

Algumas pessoas pensam, erroneamente, que a função do Scrum é garantir a entrega do produto. Eu gostei de uma frase que o Ken Schwaber disse na Agile Vancover Conference: “Scrum is like your mother-in-law, It’s constantly pointing out your shortcomings.”. Achei muito interessante essa analogia e é exatamente como vejo o Scrum. Se o processo for seguido à risca, ele garante apenas que os problemas ficarão claramente visíveis e isso fica evidente durante as reuniões de retrospectivas. O time pode escolher “varrer para debaixo do tapete” o problema, mas ele provavelmente voltará a aparecer durante a sprints seguintes.

O Scrum, por si só, não diz como resolver problemas. Ele permite que as pessoas envolvidas possam criar suas próprias soluções e medir sua eficácia até encontrar a solução que melhor se encaixe. Para que isso aconteça o Scrum possui três pilares: transparência, inspeção e adaptação. As pessoas no time devem ser transparentes no que diz respeito a expor a real situação do andamento do projeto. O time deve inspecionar frequentemente os dados observados. E o último pilar é adaptar procedimentos que estejam interferindo no bom andamento/objetivos da Sprint.

Portanto, mostrando problemas sem dizer como resolvê-los e abrindo espaço para experimentos sugeridos pelo próprio time, o Scrum fomenta a colaboração, a confiança e motivação de todos os indivíduos envolvidos.

Referências:

Schwaber, Ken; Sutherland, Jeff. The Scrum Guide. http://www.scrum.org/scrumguides/. Julho, 2011.

Stand up meeting

Posted on by
Reply

 

A Stand up meeting é uma das reuniões mais famosas dentro do Agile. Não importa qual metodologia/técnica/processo/framework Agile que você use com certeza terá que fazer essa reunião. Essa reunião é de importância vital para o sucesso na entrega do produto e na comunicação entre o time. Este post tem como objetivo mostrar e discutir algumas técnicas para realizar uma Stand up meeting de forma efetiva e evitar que ela se torne uma grande perda de tempo.

Pra que serve?
Basicamente, é uma reunião de status para o time e apenas para o time. Essa reunião tem como objetivos: ajudar a começar bem o dia; reforçar o foco nas coisas certas; reforçar o senso de se trabalhar como um time; e comunicar o que está acontecendo. O time deve entender que tudo que é falado nesta reunião é importante para eles mesmos.

Onde e quando?
É necessário que seja estipulado um local e um horário fixo. Previsibilidade diminui a complexidade. Não espere por atrasados. Deve ser feita na frente do quadro de tarefas ou do quadro Kanban. Muitos times preferem fazer a Stand up meeting logo de manhã. Isso por um lado é muito bom, pois o time já começa sabendo o que deve ser feito. O lado negativo é que alguns times podem levar ao pé da letra e só começar a fazer suas tarefas após a reunião. Portanto, não espere a reunião para começar suas tarefas, mas comece seu dia com uma Stand up meeting.

Quem participa?
Todos os membros do time: desenvolvedores, um facilitador, stakeholders, etc. No Scrum, a presença obrigatória é apenas do time de desenvolvimento. O facilitador, como o próprio nome sugere, facilita a realização da reunião e mantém o foco. Alguns facilitadores preferem que os stakeholders não participem dessa reunião. Eu acredito que se os stakeholders não interferirem, sem ser requisitado pelo time, a participação deles não traz problemas.

Timebox de 15 minutos, no máximo!
O tempo fechado de 15 minutos faz com que os membros do time, inconscientemente, se lembrem em focar no objetivo da reunião. Uma reunião sem timebox faz com que as pessoas sejam mais prolixas e acabem adicionando assuntos não relevantes.

Stand up meeting é, literalmente, em pé.
Nós ficamos em pé para manter a reunião curta e objetiva. Só o fato de caminhar até o quadro de tarefas faz com que as pessoas fiquem focadas no que deve ser feito.

O que falar e em qual ordem?
Cada membro do time deve responder a três questões:

  1. O que eu fiz desde a última reunião?
  2. O que eu irei fazer até a próxima?
  3. Tive algum problema ou terei algum problema?

Não cabe ao facilitador fazer essas perguntas a cada membro do time e nem escolher qual membro do time começa. Essas atitudes vão contra o conceito de autogerenciamento do time. Uma abordagem interessante para escolher quem começa é a última pessoa que chegar ao Stand up meeting inicia a reunião. E depois segue da direita para a esquerda.

Não é uma reunião de status report para o facilitador!
Alguns membros do time têm dificuldade em falar em público e acabam falando em direção ao facilitador. O facilitador deve de alguma maneira lembrá-lo de que ele está falando para o time e não para ele. Há algumas maneiras sutis de mostrar isso ao time como, por exemplo, evitar dizer frases de aceitação ou parabenização quando algum membro do time expõe algo. Ex: “Muito bom!” ou “Parabéns!”. Outra forma é o facilitador desviar o olhar quando um membro do time parece estar falando diretamente com ele ou se mover por trás do círculo.

Deixe alguns assuntos para depois da reunião.
Algumas vezes o time começa a conversar sobre assuntos pertinentes ao trabalho realizado, porém, é necessário lembrá-lo de qual é o objetivo da Stand up meeting. O facilitador deve encorajar o time a anotar esses assuntos e conversar logo após a reunião. Fazendo assim eles não perderão o foco da reunião e poderão focar nos itens anotados no tempo apropriado.

Termine com uma frase para sinalizar o fim da reunião.
É importante manter ou elevar o moral do time, principalmente no início da manhã. Quando todos do time já falaram, o facilitador deve perguntar se há mais alguma informação a ser compartilhada, caso não exista, ele deve terminar com uma frase que sinalize o término da reunião e ao mesmo tempo eleve o moral do time ou os façam descontrair. Eu geralmente termino com alguma piada interna ou algo motivacional.

Portanto, para realizar uma Stand up meeting de forma efetiva é necessário deixar claro quais são os objetivos dessa reunião para que o time possa focar no que deve ser feito, sem deixar de motivá-lo.

Retrospectiva e evolução do time

Posted on by
Reply

As empresas, de um modo geral, focam na evolução do produto. Sempre levando em conta a qualidade do incremento, o ROI, satisfação do cliente, etc. Uma empresa que utiliza metodologias ágeis não pode esquecer jamais que não só o produto evolui mas o time também. E não há melhor oportunidade para o time se desenvolver do que em reuniões de retrospectivas.

A tarefa de ajudar um time a se tornar ágil e evoluir é algo muito complicado no início. Vários problemas podem estar impedindo que o time se desenvolva: inexperiência em metologias ágeis; problemas em adotar/digerir metodologias ágeis; alguém no time não está trabalhando como membro do time; problemas de comunicação; débito técnico; desmotivação; resistência à mudanças; enfim, inúmeros problemas. Mas esses problemas só são visíveis durante a sprint e expostos nas reuniões de Retrospectiva.

Quando sou alocado para ajudar um time, utilizo uma técnica que tem dado bons resultados: inicialmente não sugiro muita coisa ao time. Apenas que as reuniões do Scrum sejam seguidas à risca. Então ficou apenas observando o time tomando cuidado para não interferir no andamento da sprint. Durante a sprint anoto alguns pontos para discutir com o time e sugestões de mudanças. É importante que esses pontos sejam feitos apartir de observação de fatos e não de opniões (“achismo”). O trabalho de mudança começa mesmo na Retrospectiva. Os pontos anotados são colocados de forma objetiva e precisa dizendo exatamente quando aconteceu, porque aconteceu e qual foi o resultado. Expondo fatos e não opniões, o time se mostra menos resitente à mudanças. Uma vez endereçado os problemas o time deve discutir e chegar em um consenso sobre qual a melhor maneira de evitar que esses problemas voltem a acontecer. Dessa forma o respeito e a confiança entre o Agile coach/Scrum master e o time aumenta. É importante não tentar resolver todos os problemas de uma única vez.

Uma restrospectiva, normalmente, responde 3 questões básicas:

  • O que fizemos certo?
  • Onde tivemos problemas?
  • Como podemos evitar que esses problemas voltem a acontecer?

Perguntando o que deu certo ao time, você passa a mensagem que você entende que todos no time estão trabalhando para melhorar o processo. Apontando especificamente o que deu certo faz com que o time se responsabilize por manter esses pontos de acerto.

A segunda parte que é o endereçamento dos problemas faz com que o time desenvolva a habilidade de autoavaliação. O Agile coach/SM deve conduzir essa parte com cuidado fazendo questionamentos corretamente para conduzir o time ao cerne do problema e não apenas às causas.

A última pergunta é relacionada ao planejamento concreto do que fazer para que os problemas não voltem a acontecer. O time deve ser orientado a escrever tarefas específicas em post-its e estes devem ser guardados para a próxima retrospectiva onde o time vai dizer se aquela tarefa deu o resultado esperado ou não e se ela foi feita ou não.

O mais importante é motivar o time a resolver os próprios problemas. Sugestões podem ser dadas, mas a batida de martelo é sempre do time. O time deve aprender a andar com as próprias pernas e o trabalho do Agile coach/SM deve ser praticamente invisível.

Uma análise do Kanban

Posted on by
1

O Kanban vem sendo discutido e utilizado cada vez mais hoje em dia. Times, não apenas de desenvolvimento mas de várias áreas, vêm usando Kanban para aumentar o controle sobre as mudanças e melhorar a organização das tarefas diárias. Sua implementação e utilização as vezes geram mais dúvidas e problemas do que benefícios reais. Inúmeras perguntas surgem: “Como iremos montar o Kanban?”, “Há um Kanban pré-pronto para usarmos?”, “De que forma/ em qual momento iremos atualizar o quadro Kanban para refletir exatamente o que está acontecendo?”. Esse post tentará responder essas perguntas e algumas outras que possam aparecer.

O Kanban, de acordo com David Anderson (para muitos o pai do Kanban), é uma ferramenta Agile de gerenciamento de mudanças. Ela NÃO é uma ferramenta de gerência de projetos ou uma ferramenta de ciclo de desenvolvimento de aplicação .

A idéia do Kanban pode ser entendido com este exemplo: Imagine uma sala onde está ocorrendo uma exposição de arte. Nesta sala há 2 portas, uma de entrada e uma de saída. Na porta de entrada há um funcionário com uma caixa com um número X de tickets de entrada. Na porta de saída há um outro funcionário. Cada visitante recebe um ticket do funcionário ao entrar na sala. E quando o visitante sair da sala ele deixa o ticket com o funcionário na porta da saída. Quando o funcionário da entrada não tiver mais tickets na caixa ele deverá barrar a entrada das pessoas até que as pessoas que estão na sala liberem seus tickets na saída. Ou seja, o limite de pessoas dentro da sala nunca será maior que o número de tickets impresso.

Essa é a ideia básica do Kanban. Podemos resumir em três items [Knirberg, Skarin]:

  1.  Visualize o fluxo de trabalho
    1. divida o trabalho em pedaços, escreva cada um em cartãozinhos e coloque-os na parede;
    2. coloque nomes nas colunas para ilustrar o estado em que cada pedaço de trabalho se encontra;
  2. Limite o trabalho em progresso (Work In Progress – WIP)
    1. Atribua explicitamente limites para quantos items podem estar em progresso em cada estado do fluxo de trablalho;
  3. Faça medições do “lead time”:
    1. O termo “lead time” ou “cycle time” é a diferença da data em que o trabalho entrou em progresso e a data que ele ficou pronto;
    2. Tente otimizar processos para diminuir o lead time o máximo possível;

O time deve puxar as tarefas através do fluxo de trabalho. Não há timeboxes, nem sprints. A abordagem é um pouco mais livre do que o Scrum. A atualização do quadro Kanban deve ser feita de forma a refletir o que está sendo trabalhado.

As limitações de trabalho em progresso (Work In Progress – WIP) funcionam similarmente ao exemplo dos tickets de entrada para a mostra de arte. Caso em um dos estados do fluxo de trabalho esteja com WIP = 2 significa que no máximo 2 tarefas podem entrar naquele estado por vez. Essa abordagem parece simples, porém, aumenta o foco do time, melhora a performance e mostra claramente gargalos no processo. Ou seja, neste caso, supondo que haja 2 tarefas e elas ficam bloqueadas, o fluxo de trabalho acaba parando e todo o time deve fazer o melhor possível para resolver o problema para que o trabalho volte a fluir.

O Kanban utiliza-se de artifícios visuais para dar o perfeito entendimento para todos no time do que está sendo feito. É recomendado utilizar post-its coloridos com diferentes significados.

É importante dizer também que não há um Kanban default. Ele deve ser desenvolvido de acordo com os processos já utilizados da empresa e depois adaptado da maneira mais otimizada de acordo com lead time das tarefas. É difícil encontrar 2 estilos de Kanban exatamente iguais em empresas diferentes. Temos que ter cuidado ao implementar Kanban sabendo que cada empresa é uma empresa e não é porque um estilo de Kanban deu certo na empresa A que irá dar certo na empresa B.

Na  minha opnião o Kanban tem alguns pontos negativos:

  • Não há um momento/reunião específica para evoluir o processo ou o time. Nas documentações e livros falam que deve ser feito reuniões de Retrospectivas como acontece no Scrum, mas não há um momento adequado para tal. Acredito que fixar data para essa reunião e ter um timebox para ela adiciona previsibilidade e cria tradição que o próprio time tenta manter.
  • Não há papéis. No Scrum temos apenas Product Owner, Scrum Master e Time de desenvolvimento. O Kanban utiliza a orgranização que a empresa já está acostumada mesmo que possua a figura do “Gerente de projetos”. Vejo isso como um problema pois gerentes de projeto, geralmente, centralizam informações e intervêem no processo muitas vezes. Sem dizer que na maioria das vezes eles limitam as ações do time.
Acredito que o Kanban é uma abordagem muito interessante para gerenciar mudanças e melhorar a visualização do todo em um projeto. Por enquanto eu não a utilizaria sozinha, porém, acredito que junto com o Scrum os resultados podem ser muito satisfatórios. Mas conheço empresas que utilizam apenas Kanban e tem resultados muito bons.

Referências:

Kniberg, Henrik; Skarin, Mattias. Kanban and Scrum making the most of both. USA, 2010

As atribuições de um Scrum Master

Posted on by
1

As vezes leio em alguns fóruns e blogs pessoas discutindo sobre qual é o verdadeiro papel do Scrum Master dentro de um time Scrum. É necessário muito cuidado para não confundir Scrum Master com Gerente de Projetos. As atribuições são diferentes, o modo de se dirigir ao time é diferente, ou seja, toda a postura desses dois profissionais é diferente. Mas quais são as atribuições reais de um Scrum Master? E no que essas atribuições diferem das atribuições de um Gerente de Projetos?

O Scrum Master possui 2 atribuições: garantir que o processo está sendo seguido e remover impedimentos. Apesar de correto, acho muito simplista essas atribuições.

De acordo com Scrum Guide: “O Scrum Master é responsável por garantir que o Scrum seja entendido e seguido por todos. Isso é alcançado quando o time adere à teoria, práticas e regras do Scrum” [Schwaber; Sutherland, 2011]. Ou seja, o Scrum Master, nesta atribuição, é um gerente: gerente de processo. Acredito que essa atribuição seja a menos complicada pra entender e menos alvo de discussões.

Agora vamos pensar na atribuição “remover impedimentos”. A palavra “impedimento” pode ter muitos significados. A definição de impedimentos que utilizo é a seguinte: Impendimento é algo que evite que o time entregue o produto com maior valor possível ou que impeça que ele tenha a melhor produtividade possível. Para mim, impedimento é mais do que apenas algo que está bloqueando um membro do time de desenvolver uma tarefa.

O Guia do Scrum [Schwaber; Sutherland, 2011] diz como o Scrum Master deve apoiar o time de desenvolvimento:

  • auxiliando o time a ser auto-organizado e cross-functional;
  • ensinando e liderando o time a criar produtos de alto valor;
  • facilitando as reuniões que foram pedidas ou necessárias; e
  • ensinando e coordenando o time em organizações na qual o Scrum não é totalmente adotado e entendido;

Como visto, o Scrum Master deve ensinar ou auxiliar o time a desenvolver o melhor produto possível.

Tomemos como exemplo um time que durante a retrospectiva levantou que a qualidade nos testes está horrível impactando diretamente na qualidade de entrega. A falta de qualidade nos testes tornou-se um impedimento. Para retirar esse impedimento o Scrum Master pode resolver de várias maneiras. Se ele tiver o conhecimento de TDD, por exemplo, ele pode marcar um mini-curso para o time. Ou fazer um “coaching” com o time, ou seja, o Scrum Master faz Pair-programming com um desenvolvedor mostrando como desenvolver utilizando TDD. Isso se chama “liderança por exemplo”. É a qualidade mais esperada, na minha opnião, de um bom Scrum Master.
Caso ele não tenha conhecimento de TDD ele pode buscar profissionais externos à empresa para ministrar um curso ou fazer uma consultoria.

Em organizações que ainda estão começando a utilizar o Scrum ou Agile em seus projetos é mais difícil para o Scrum Master apenas gerenciar o processo e remover impedimentos. O time ainda não consegue tomar decisões sozinho e nem se autogerenciar. É necessário que o Scrum Master tenha uma postura  mais ativa sendo um coach.

Mas não devemos confundir postura ativa e coaching com dar ordens! O Scrum Master não deve confundir as bolas. Ele deve ser um líder e não gerente de pessoas ou chefe. Um time Scrum ou Agile deve aprender a caminhar com os próprios pés, porém, no início é necessário alguém para apontar o caminho. A linha entre liderança e “dizer o que fazer” é uma linha tênue que o Scrum Master/Agile Coach deve ter cuidado para não cruzar. Todas as mudanças devem ser sugeridas, explicadas ao time e ter o apoio deles uma vez que “Individuals and interactions over processes and tools” [Martin; Schwaber; Sutherland, 2001].

Portanto, as atribuições do Scrum Master são apresentadas muitas vezes de forma simplista demais para o dia-a-dia. O Scrum Master deve ter muito mais que conhecimento do processo. Ele necessita ter conhecimento de desenvolvimento e de boas práticas de programação SIM! Muitos times possuem débito técnico enorme. Fica mais fácil resolver esses impedimentos se o Scrum Master possui tal conhecimento. E sem falar da habilidade interpessoal que em metodologias Agile é imprescindível já que o centro do processo são as pessoas.

Referências

Schwaber, Ken; Sutherland, Jeff. The Scrum Guide. http://www.scrum.org/scrumguides/. Julho, 2011
Martin, Robert C.; Schwaber, Ken; Sutherland, Jeff. Agile Manifest http://agilemanifesto.org/, Outubro, 2011

Como resolver ou mitigar problemas com a ausência de membros chaves do time?

Posted on by
1

Acho que todos os times de desenvolvimento, independentemente do modelo de gerenciamento que utilizam, já encontraram problemas com ausência de membros com conhecimento específico durante a execução de um projeto. É comum ouvir em reuniões de retrospectiva “O Fulano-de-tal é especialista em X e ele teve que se ausentar por 4 dias. Por isso não conseguimos entregar o que tínhamos combinado.” ou “Fulano-de-tal estava participando de outros 3 projetos e, portanto, não conseguimos entregar o combinado”. Este tipo de problema é imprevisível. Não há como saber se um membro do time irá ficar doente, ou sair da empresa ou estar indisponível durante o andamento do projeto. Mas então, como é possível se preparar para esse tipo de problema tão comum em projetos mas ao mesmo tempo tão imprevisível?

Um time de desenvolvimento que utiliza Scrum (ou qualquer outra “vertente” Agile) deve ser autogerenciável, cross-functional, sem subdivisões de títulos ou subtimes [Schwaber; Sutherland, 2011].

O cross-functional é um bom início para solucionar esse problema “que acontece”. Um time cross functional é aquele que reúne todo o conhecimento necessário para criar um incremento do produto [Schwaber; Sutherland, 2011].

É claro que sempre teremos membros que entendem mais de uma área ou que possuem mais experiência do que outros membros do time. Este não é o problema. O problema surge quando apenas um membro do time possui conhecimento de uma área específica e que os outros membros desconhecem por completo. Então surge um conceito chamado Truck factor. Truck factor é de certa forma uma brincadeira que pode ser entendida como: “Quantas pessoas precisam ser atropeladas por um caminhão para que o projeto pare”.

Vamos a um exemplo concreto: Em um time de desenvolvedores Scrum de 5 pessoas há um único membro que tem conhecimento avançado de web-design e o resto entende muito pobremente ou nada. Supondo que este membro pegue uma gripe e precise se ausentar por 3 dias. O que acontece com o projeto na maioria dos casos? Ele pára! Ou seja, 4 pessoas do time não conseguem desenvolver mais tarefas por causa da depêndencia das tarefas de web-design. Neste caso o Truck factor é igual a 1. E esse cenário pode acontecer com banco de dados, arquitetura, tecnologia específica, etc.

Fica evidente que temos que manter o Truck factor sempre maior do que 1. Mas agora vocês devem estar se perguntando: “Ok, mas como aumentar o Truck Factor?”. Há várias maneiras de se aumentar o Truck factor. A que eu mais gosto e que é indipensável em um time Agile é o famoso Pair-programming ou Pareamento. Parear é algo intrínseco à cultura Agile.

pair_programming

Pair programming

Alguns benefícios do Pair-programming:

  • Aumento do foco no que se está trabalhando.
  • Revisão de código on the fly.
  • Melhoria na lógica e otimização do código.
  • Compartilhamento de conhecimento.

Esse último benefício do Pair-programming é o que irá fazer com que o Truck factor fique acima de 1. É extremamente indicado que um membro do time que tenha conhecimento avançado sobre determinada tecnologia faça Pair-programming com todos da equipe durante a sprint. Isso não quer dizer que todos do time conseguirão ter o mesmo conhecimento fazendo apenas Pair-programming, porém, todos terão pelo menos o necessário para continuar o projeto caso aquele membro se ausentar por algum tempo.

Portanto, a melhor forma de mitigar ou evitar o problema do Truck factor igual a 1 é incluir o Pair-programming no dia-a-dia da sprint. Além de evitar que o conhecimento fique concentrado em apenas um membro da equipe ele também traz vários benefícios para o time. O membro especialista deve ter em mente que ele deve identificar, treinar e amadurecer o conhecimento de outro membro do time. Até porque nunca se sabe quando um caminhão pode cruzar seu caminho… ;)

Referências:

Schwaber, Ken; Sutherland, Jeff. The Scrum Guide. http://www.scrum.org/scrumguides/. Julho, 2011.

Comparação entre gerência de projetos, gerência de produtos e seus resultados

Posted on by
Reply

Sempre que estou participando de discussões sobre gerência de projetos tradicional e AGILE coloco uma pergunta “Como podemos gerenciar de forma tradicional um produto que é tão pouco tradicional como o desenvolvimento de software?”.

Inicialmente vamos entender a definição de gerência de projetos. De acordo com [PMI, 2004] “O gerenciamento de projetos é a aplicação de conhecimento, habilidade, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisistos”. Agora, vamos dar uma olhada na definição de gerência de produtos: “A gerência de produto é uma disciplina e um processo de negócios que governa um produto da sua concepção até sua inserção no mercado com o objetivo de gerar o maior valor possível a um negócio. [Ebert, 2009].

Claramente já vemos algumas diferenças sobre a concepção entre gerenciamento de produto e projeto. No gerenciamento de projetos tradicional os requisistos devem ser bem definidos logo no início do projeto e qualquer modificação impacta diretamente no andamento do projeto aumentando o custo e aumentando o tempo (veja a figura abaixo do famoso triângulo das dependências). O acoplamento entre escopo, custo e tempo é muito forte neste tipo de gerenciamento. Uma vez implementado todos os requisitos acordados o projeto foi finalizado.

custo-escopo-tempo-qualidade

Relação Custo x Escopo x Tempo

No gerenciamento de produtos a diretiva principal é aumentar o valor do produto a ser entregue o máximo possível. Para isso ocorrer o escopo é modificado inúmeras vezes. O ciclo de vida de um produto é basicamente: Começa com um brainstorm, então as idéias são ordenadas de forma a agregar mais valor ao negócio, implementam-se as idéias escolhidas e libera-se o produto com uma ou mais funcionalidades novas. Este ciclo é repetido inúmeras vezes de forma incremental até que um dia o produto deixa de adicionar valor ao negócio e ele é descontinuado.

Vamos partir de dois exemplos práticos e explorar mais as diferenças:

Imagine a gerência de projetos tradicional aplicada em uma fábrica de carros. Primeiro a equipe monta um projeto do carro que se quer fabricar: quantidade de portas, quantidade de rodas, como será o painel, tamanho do bagageiro, etc. Ou seja, fecha todos os requisitos primeiro. Então fazem o cálculo do custo, cronograma, análise de risco, análise de mercado, etc. Se tudo for aprovado inicia-se a construção do carro. Ao final do processo o carro fica pronto e é vendido para o cliente. O carro está pronto.

 Agora peguemos como um exemplo uma empresa que é especializada em desenvolvimento de sistemas de controle de hotelaria. O responsável pelo produto produz uma lista de funcionalidades ordenada de acordo com critérios dele, ele discute com a equipe e a equipe cria ciclos de incremento (sprints). Quando o responsável pelo produto acha que já agregou valor o suficiente para ser posto à venda o produto é liberado.

Agora vamos às comparações:

Carro Software de controle de hotelaria
Escopo Fixado a quantidade de funcionalidades no projeto. De acordo com a ordem de importância dos items de uma lista de funcionalidades
Cronograma Tem um início e fim. Possui inúmeras entregas.
Estrutura básica Se você comparar 10 carros da mesma marca e mesmo modelo de lugares
diferentes todos terão as mesmas definições do projeto em que ele foi feito.		 Se você comparar dois Softwares de hotéis diferentes (clientes) eles
dificilmente serão iguais. Não estou falando da parte de design e sim da camada de
negócios que sempre vai mudar algo.
Erros ou problemas encontrados Quando algo é detectado como problemático e que poderia melhorar é
feito outro projeto e no final terei um outro carro do mesmo modelo, mas com
as melhorias do novo projeto.		 Se algo é detectado como problemático e que poderia melhorar no
software um novo ciclo incremental é criado no próprio produto onde é
consertado e repassado para todos os clientes.
Cálculo do valor de custo É feito um levantamento de todas as peças necessárias, a energia que
irá gastar para as máquinas na linha de montagem e o salário por hora dos
profissionais.		 Como calcular o custo de um software? Alguém sabe quanto custo uma
linha de código? Você pode multiplicar o valor hora de cada profissional envolvido
pelo tempo que eles trabalharam e somar tudo e mais as despesas com energia
elétrica mas isso seria o suficiente?

Com base nesses exemplos e comparações fica clara a diferença tanto na parte de gerenciamento quanto no próprio resultado deles.

Acredito que o modelo de gerenciamento de projetos tradicional é eficaz, muito bem estruturado e apropriado para certas empreitadas. Porém, para a construção de produtos são  necessárias muitas adaptações e uma fluidez de processo que esse modelo não provê.

É isso ae, até o próximo post!

Referências:
Ebert, D. C. (2009). Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 15-19.
PMI, (2004). PMBOK: Project Management Body of Knowledge, 2004, 3ª edição.