Esqueceram de mim

A principal tarefa de um Scrum Master é curta e grossa: garantir o bom funcionamento do Scrum. Existe uma tarefa implícita nesta frase, que é extremamente desafiadora: educar bons Product Owners. Muitos Product Owners ainda não conhecem seus papéis como deveriam, geralmente têm bastante experiência em projetos de software e raramente são incentivados a criar uma comunidade para que possam desafiar suas certezas em prol de uma nova realidade. Além disso, eles enfrentam a principal mudança que os métodos ágeis trazem consigo: foco nas pessoas como o verdadeiro motor durante o desenvolvimento de um produto, não no projeto. Em um primeiro momento, a cultura ágil privilegia os times de desenvolvimento de produtos, o que torna a adoção da cultura mais fácil para os desenvolvedores. Por conta da dificuldade particular de educar Product Owners, muitos acabam “esquecidos” pelos Scrum Masters e viram verdadeiros pedregulhos no caminho dos times.

Quem é o Product Owner?

O primeiro passo para se educar um Product Owner é saber quem ele é (ou quem ele pode ser). E definir quem é o Product Owner é uma tarefa do Scrum Master. Algumas características ajudam nesse desafio:

Segundo Roman Pichler, em Agile Product Management with Scrum, um Product Owner deve ser:

• Visionário e executor;
• Líder e membro do time;
• Comunicador e negociador;
• Com poder de decisão e comprometido;
• Disponível e qualificado.

Levando em consideração tais características, podemos elencar alguns profissionais que podem se encaixar no papel:

Analista de negócio: Este profissional tem a peculiaridade de conhecer bem as regras de negócio de uma organização sendo ele um profissional de TI. Pelo forte foco no produto que a cultura ágil prega, ele acaba sendo uma boa opção por seu conhecimento das necessidades da organização. O problema é que nem todo analista de negócio sabe ou quer medir o progresso do desenvolvimento do produto e resolver, ele próprio, as barreiras de comunicação que dificultam a integração entre as partes de um produto.

Gerente de produto: Pouco explorado, este profissional é utilizado em pouquíssimas empresas. Na minha opinião, é a melhor representação de um Product Owner. É um analista de negócio, que tem responsabilidade sobre o prazo de seu produto e precisa reportar o progresso do desenvolvimento do mesmo aos seus clientes. O único perigo com este profissional é o de ser uma pessoa hiperativa que não consegue esperar que as soluções emirjam do próprio time. Esta atitude pode minar a auto-organização e a auto-gestão do time.

Gerente de projetos: Algumas empresas já tentaram elencar gerentes de projetos como Product Owners. Funciona bem, desde que o profissional consiga se desvencilhar do hábito de comando e controle que seu papel original propõe. Adotando uma mentalidade de coach, de liderança-servidora e focando no produto e na satisfação do cliente acima de tudo, o gerente de projetos também pode se tornar um bom Product Owner.

Usuário-chave: Usuários têm outros afazeres em suas rotinas que não podemos ignorar. Quando estamos falando de projetos pequenos, onde o próprio dono de um empreendimento trata com 1 ou 2 desenvolvedores, o usuário-chave como Product Owner funciona muito bem. Quando o produto começa a crescer e ficar mais e mais complexo, surgem questões tecnológicas das quais um usuário-chave não tem a mínima ideia do que significam. Sem contar que este tipo de Product Owner tem a tendência à otimização local e ignora as questões de integração com outras áreas da empresa dentro do produto. Nesse momento, um usuário-chave como Product Owner pode ser extremamente prejudicial ao produto.

Um bom Product Owner leva todos a bons sprints

Um time Scrum que não tem um bom Product Owner está fadado a fracassos. Os insulmos oridundos deste papel são tão importantes quanto o produto que está sendo desenvolvido pelo time de desenvolvimento. Em todas as experiências que tive com times ágeis, o Product Owner tinha um peso enorme sobre o progresso do time. Negativo ou positivo. Um bom Product Owner sabe motivar o time em prol da sua visão de produto e consegue, facilmente, definir o plano de ação para ter aquele produto, ao final de um projeto ou período. Um mau Product Owner é capaz de segurar o progresso do time inteiro e, mais do que isso, desmotivá-lo por sua falta de visão, clareza e segurança e colocar seu produto em sérios apuros. Sem um bom Product Owner, não há um bom time. Sem um bom time, não há um bom produto.

Coaching, não só mentoring

Para um time de desenvolvedores, o que importa é desenvolver software e ter seu conhecimento constantemente desafiado para que criem boas soluções para os problemas que encontram durante a construção de um produto. Se estamos utilizando Agile ou Waterfall, pouco importa. Desde que todos sintam-se em casa e estejam felizes em estar ali. Em minhas experiências, é relativamente fácil conduzir a adoção de um framework ágil em um time de desenvolvedores. Principalmente porque a cultura ágil favorece seu bem-estar. É um trabalho muito mais forte de mentoring, de ensino, do que de coaching.
No caso do Product Owner, a realidade é outra. Desenvolvedores, designers, testadores. Todos continuam sendo desenvolvedores, designers e testadores. Mas um Product Owner, provavelmente, era gerente de projetos ou analista de negócio. Além disso, a cultura ágil “prejudica”, à primeira vista, o seu tempo de resposta ao cliente. Ele está passando por 2 grandes mudanças: no formato do seu trabalho e no seu próprio papel dentro da cultura. Não há dúvidas: haverá resistência. E tal resistência não é quebrada somente com o mentoring em Scrum do Scrum Master. Este Product Owner vai precisar de um Scrum Master no papel de seu coach, ajudando-o a desenvolver novas competências para uma nova realidade e auxiliando-o no questionamento de suas certezas para descobrir novas certezas. Não é um trabalho fácil, nem breve, mas é fundamental.

Scrum Master: seja parceiro do seu Product Owner

Costumo dizer que, no Scrum, o gerente de projetos foi dividido em 2: Scrum Master, responsável pelo processo e pelas pessoas, e Product Owner, responsável pelo produto. Antes, um gerente de projetos era responsável por processo, pessoas e produto. Fatalmente, e não pouco frequente, seu foco se mantinha no produto, ignorando o bem-estar das pessoas e a manutenção de um bom processo de desenvolvimento do produto. Scrum Masters e Product Owners, juntos, devem representar gerentes de projetos melhores do que os representados em uma só pessoa, pois as atenções estão bem divididas. Se estes dois papéis representam um profissional, para que ambos tenham sucesso é preciso uma colaboração e parceria muito fortes. Apesar das rusgas e discussões que os prazos e negociações trazem, Scrum Masters e Product Owners trabalhando em parceria são vitais para o bem-estar e felicidade do time de desenvolvimento  e, consequentemente, para o time Scrum e, consequentemente, para o produto e, consequentemente, para a empresa e, consequentemente…

#soudev

O que é desenvolver software?

 

Desenvolver um software envolve muito mais processos e pessoas do que o ato de escrever instruções que programem o comportamento de um computador. Todos os passos, artefatos, ferramentas e pessoas envolvidas em um projeto de construção de um software têm igual importância. Desenvolver um software é o ato milenar de desenvolver um produto. Quando trabalhamos em um processo como tal, não basta contarmos como “sucesso” somente o cumprimento da nossa parte. Durante o desenvolvimento de um software, somos uma comunidade de profissionais com objetivos em comum. Objetivos tecnológicos em comum e objetivos de negócio também em comum. Em um time de futebol, não basta a defesa defender. Isso não configura sucesso. O ataque precisar marcar gols.

 

Um projeto de desenvolvimento de software nada mais é do que uma ferramenta que nos ajuda na organização dos nossos esforços rumo à entrega de um produto de qualidade. Um equívoco comum na área é o fato de o projeto de desenvolvimento de um software tornar-se mais importante que o próprio software sendo desenvolvido. O produto deve ser o centro das atenções. Suas funcionalidades, qualidade e satisfação do cliente. Não as datas e previsões descritas em um cronograma. Deve-se pensar em gestão de produto, e não na gestão de projeto. Deve-se buscar excelência em qualidade de produto, não excelência em cumprimento de prazos.

 

Em um ambiente ágil, colaboração é a palavra-chave para que uma comunidade de profissionais conclua a construção de um produto. Aliás, colaboração é a palavra-chave em qualquer comunidade que possui um objetivo comum. Quando mães buscam seus filhos nas escolas e conversam entre si ponderando sobre a escola, vez ou outra surge um esforço colaborativo para viabilizar reuniões com professores e diretoria que visam buscar melhorias na qualidade de ensino e tratamento de seus filhos. Estas mães formam uma comunidade. Um grupo de pessoas com um objetivo em comum: dar a melhor educação e ambiente possíveis a seus filhos. Em um projeto de desenvolvimento de software, todos, do cliente ao desenvolvedor, devem formar uma comunidade de profissionais que colaboram em prol de um único objetivo: a entrega de um software de qualidade que atenda às expectativas do cliente e de seus usuários. Meu objetivo não é ser um excelente Scrum Master. Mas, sim, ser o melhor Scrum Master para a comunidade onde me encontro. A comunidade que desenvolve o mesmo produto que estou desenvolvendo.

 

Em um ambiente ágil, todos os esforços têm igual importância. Como em uma comunidade. O usuário desenvolve software, o patrocinador desenvolve software, o gerente de projetos desenvolve software, o scrum master desenvolve software, o testador desenvolve software, o designer desenvolve software, o desenvolvedor desenvolve software, o arquiteto desenvolve software. Embora trabalhemos como profissionais especializados, fazemos parte de times. E quando isso acontece, não basta que o nosso trabalho de codificação esteja excelente e o trabalho do designer esteja muito ruim. Se estamos desenvolvendo um produto como uma equipe, precisamos ajudar nossos companheiros designers ou testers a realizarem o seu trabalho também com a mesma qualidade que realizamos o nosso trabalho, e vice-versa. Então, em vez de afirmarmos “a minha parte eu fiz direito”, por que não questionar: como posso ajudar meu companheiro de jornada? O que mais posso fazer para ajudar a construir um produto de qualidade? Não uma tela de qualidade, um código de qualidade ou um planejamento de qualidade.

O Caminho da Felicidade

Transparência é um dos valores do Scrum. E é um valor fundamental para que o sentimento de confiança, tão importante em projetos ágeis, cresça saudável em um ambiente ágil. Confiança nos liderados e confiança nos líderes. Confiança nos gestores. Transparência é fundamental para que o foco de um Time em um projeto de desenvolvimento de software mantenha-se única e exclusivamente no problema que é preciso resolver e no software que se desencadeará dessa solução. Perde-se muito em qualidade quando o foco está em sustentar pequenas mentiras. Defender uma realidade que ainda não existe e tentar fazer com que o Time, a todo custo, crie, enfim, a realidade que foi anteriormente pintada. Sem transparência, não há qualidade.

A ferramenta-símbolo de um ambiente ágil de desenvolvimento de software é o kanban. Um kanban ajuda a gerenciar um determinado fluxo de trabalho e, no caso de Times, o mesmo fica exposto para que o Time possa, por si só, gerenciar o seu fluxo de trabalho. É um radiador de informação. Quem quer que passe por ele, será “convidado” a conferir as informações nele contidas. Informações vivas e fáceis de serem lidas ou interpretadas. Diferentemente de um cronograma criado no MS Project, por exemplo. As informações ficam guardadas, como em uma geladeira. Só temos a informação quando a procuramos. Isso, se quisermos procurar. E, mesmo que imprimamos o cronograma e o coloquemos em uma parede, não seria tão simples ler suas linhas ou interpretar suas informações ou seu gráfico de Gantt. O valor de um kanban visual é enorme: radiador de informação. Bem como o Sol, que radia luz e calor sem que precisemos pedir.

Porém, um kanban é uma ferramenta que facilita a visualização do fluxo de trabalho em um sprint. Mas, qual seria uma maneira fácil de visualizar o posicionamento de um Time frente ao projeto em que se encontra? E se o Time quiser saber o percentual de completude de uma release, ou quanto falta para uma release terminar? E sobre o projeto como um todo? Quantos % do projeto cada release represente? E quantos % de uma release representa um sprint? Ou o quanto o Time terá que se esforçar para compensar um sprint perdido e manter uma boa entrega, segundo o próprio, de acordo com a data esperada para o término de uma release? O Product Backlog contém todas estas informações. Porém, estão guardadas em uma geladeira e não são de fácil acesso para o Time. Principalmente para os desenvolvedores e testadores, que estão focados demais em seus trabalhos para calcular todas estas informações. Talvez, sequer sintam vontade de chegar a estas informações. Afinal, quando uma release ou um projeto estiver próximo do seu fim, o Product Owner deixará claro. Ou eles já saberão de antemão, no início de um projeto ou de suas releases, as respectivas expectativas de término no calendário. Mas, e durante os sprints? E durante as releases? Como permitir que um Time monitore facilmente o seu avanço? Como Scrum Master e facilitador, partindo das necessidades que o meu Time tinha em relação ao seu avanço dentro do projeto e do tamanho da sua jornada, criei um jogo chamado “Caminho da Felicidade”, como mostra a figura abaixo.

 

O Caminho da Felicidade é baseado em um “mapa do tesouro”. Ao final do caminho indicado pelo mapa está o final do projeto, o tesouro perseguido pelo Time. A felicidade. A realização individual, coletiva e corporativa. Este caminho possui marcos em % a cada 10% de sua extensão e pequenas bandeiras vermelhas, que representam releases não-entregues. Ao final de cada sprint, o Time mede, sem se preocupar muito com a exatidão da informação, mas sim com a representação gráfica mais fiel possível de seu progresso, o quanto a velocidade atingida em seu sprint contribuiu para que o Time avançasse ao encontro do seu tesouro, em Story Points. A cada release conquistada, o caminho ganha uma bandeira verde no lugar da bandeira vermelha. A bandeira amarela representa 50% do projeto.

Este “tabuleiro” fica preso junto ao kanban do time. E se utiliza de uma peça (um ímã ou adesivo), que representa o Time no Caminho da Felicidade. É responsabilidade do Time atualizar as informações de tamanho de cada release, de acordo com informações conseguidas com o Product Owner, preferivelmente, a cada final de sprint. Desta forma, eles conseguem, também, manter-se atualizados do quanto o backlog está crescendo ou diminuindo perante as negociações do Product Owner com o cliente. Então cada sprint conquistado representa x% de avanço rumo a entrega de uma release e y% rumo a entrega de um projeto.

O Caminho da Felicidade é uma maneira lúdica, simples, eficiente e divertida de encarar o progresso e os percalços de um Time durante a sua jornada rumo ao objetivo maior, que é a entrega de um software que atenda as expectativas do cliente com qualidade. Da mesma forma que um kanban é um radiador de informação para um sprint, o Caminho da Felicidade é um radiador de informação para um Product Backlog, facilitando a visibilidade do tamanho e atualizações do mesmo para o Time.

Reunião Diária: muito maior do que se imagina

Uma Reunião Diária é muito mais do que uma simples reunião onde todos os membros do time se juntam para dizer o que estão fazendo. Se fosse tão simples quanto isso, eu diria que a Reunião Diária não tem utilidade alguma, pois simplesmente olhar para o quadro já informa tudo o que cada pessoa está fazendo. Esta reunião é uma reunião de “status report” para o próprio time. Ora, se um time se diz auto-organizável, este deve ser maduro o suficiente ao ponto de que cada um de seus membros assuma compromissos perante o time e o próprio time saiba cobrar estes compromissos. A Reunião Diária é o momento para isso.

Times iniciantes no Scrum ou no XP utilizam a seguinte fórmula para obter o real valor desta reunião e mantê-la “chamativa”:

• 15 minutos de reunião
• O que fiz até esta reunião?
• O que farei até a próxima reunião?
• O que impede meu trabalho?

O valor envolvido nesta reunião é a comunicação. E a maior utilidade dela é a possibilidade de os membros do time assumirem compromissos perante os outros membros e cobrarem compromissos anteriores. É bom lembrar: aquele grupo específico de pessoas está reunido em prol de um objetivo maior. Em um time, o sucesso é compartilhado e o fracasso também. O que o outro está realizando é tão importante quanto o que eu estou realizando. É tão parte do meu trabalho quanto o código que eu mesmo faço. Isso se chama código comunitário: todo o código gerado pelo time é de responsabilidade de cada um de seus membros. Portanto, se você fez besteira ou está enrolando para terminar uma tarefa, seja humilde o suficiente para se retratar perante o time e agir em prol do seu sucesso.

Quando um compromisso é assumido em uma Reunião Diária, isso quer dizer que, até a próxima, este compromisso estará liquidado. Se não estiver, o mínimo que os outros membros do time devem fazer é se interessar pelo que impediu o compromisso de ser honrado. Uma falha do próprio time pode ter ocasionado isso. Uma falha do ScrumMaster pode estar causando isso.

A Reunião Diária mantém-se curta para que não seja evitada. Assim, caso haja algum problema maior para ser resolvido, outra reunião, entre as partes interessadas ou todos, pode ser iniciada após o status, e todos os outros membros seguem o seu fluxo de concentração. O tamanho e a frequência desta reunião permitem que os membros do time mantenham-se focados pela maior parte do tempo no objetivo do sprint. Sua frequência diária é fruto do tamanho curto de um sprint, e permite que não haja desperdícios ou surpresas durante o mesmo, além de manter o time sincronizado.

Ou seja:

• 15 minutos de reunião – mantém a reunião relevante e enxuta.
• O que eu fiz até esta reunião? – O compromisso que eu assumi na última reunião deve estar liquidado nesta reunião. Se não estiver, há um impedimento ou mal-planejamento.
• O que farei até a próxima reunião? – O compromisso é assumido perante todos os outros membros do time. Respeitar este compromisso é respeitar o time.
• O que impede meu trabalho? – Impedimentos devem ser relatados ao ScrumMaster. A resolução de impedimentos deve ser cobrada do ScrumMaster.

Fibonacci com Pimenta, Parte 2

No post anterior sobre estimativa de projetos de desenvolvimento de software utilizando os números de Fibonacci, conhecemos a origem dos números, o motivo que cria a sequência como ela é e por que é mais fácil para nós, seres humanos, estimar por relativismo e não por absolutismo. Neste novo post, veremos como estimar projetos de desenvolvimento de software utilizando Story Points, como monitorar o andamento do projeto com eles (e motivar seu time) e, enfim, como responder as perguntas capitais: quando o software estará pronto e quanto irá custar.

Quando falamos em estimativa, buscamos informações de experiências prévias sobre o que queremos estimar que nos embase o suficiente para sermos satisfatoriamente assertivos. Porém, no mundo do software, é extremamente difícil haver experiências suficientemente parecidas que nos permitam ser assertivos ao ponto de não termos um prejuízo considerável ou perdermos um prazo. Sim, é possível acertar estimativas sob estas condições e ter, assim, projetos de sucesso. Mas as estatísticas mostram que o percentual destes projetos não passa de 50%. Um índice perigoso quando se trata, por exemplo, de um projeto de desenvolvimento de um software que objetiva melhorar um processo de densitometria óssea. Um projeto de construção civil; um prédio residencial, altamente previsível, por sua vez, beira os 100% de assertividade. Ou seja, para que sejamos capazes de ser assertivos em nossas estimativas de projetos de desenvolvimento de software, precisamos de projetos previsíveis. Projetos que se repetem, que têm muito em comum. Como isso é quase impossível na nossa área, precisamos monitorar o nosso caminho. Literalmente, andar pisando em ovos. As condições que precisam ser criadas em prol da previsibilidade de um projeto de desenvolvimento de software (um mesmo time que já passou por diversos projetos junto e adquiriu experiência suficiente como um time em sua existência) são poucos, insuficientes para tornar nossas estimativas assertivas, e nos obrigando a monitorar a saúde de nossos projetos e estarmos preparados para tormarmos decisões rápidas sobre o destino do mesmo. Em comparação ao futebol, há quanto tempo não se vê um time supercampeão no Brasil? A rotatividade, o “não conseguir manter a base do time” não permite mais que isso aconteça. Bem como nos times de software. Então? É ou não é ser previsível, por mais matemáticos que sejamos?

Usando Story Points para estimar trabalho
Já sabemos que somos melhores estimando por relação entre objetos do que usando números exatos. Então, como podemos usufruir de nossa natureza em prol de nossos objetivos na construção de software? Simples: Usando Story Points, que se baseiam nos números de Fibonacci. Para isso, basta atribuirmos “pesos” aos requisitos de nossos projetos baseando-nos nos Story Points (0,1,2,3,5,8,13,20,40,100). Esta sequência está presente em muitos decks comercializados de Planning Poker, um jogo para intermediar a estimativa de construção dos requisitos de um software que visa facilitar a colaboração em um time. Porém, em seu último post, Ken Schwaber defende que a estimativa use a real natureza dos números de Fibonacci. Ou seja, não teríamos 20 na sequência de Story Points, e sim 21. E o próximo número não seria 40, mas sim 34. E concordo com ele, pois a natureza dos números de Fibonacci já é suficiente para deixar claro o peso de cada requisito. Não há necessidade de adaptação.

Para testarmos a estimativa com Story Points, imaginemos o seguinte projeto: um time precisa ler 4 publicações, conforme abaixo:

Se as publicações são completamente desconhecidas pelo time, a probabilidade de haver falhas na estimativa deste projeto é bem alta. Se alguns membros do time conhecem algumas das publicações, as chances de o time acertar a estimativa aumenta. Se todos conhecem as publicações, as chances de sucesso do projeto são altíssimas, pois o método para atingir o objetivo já é bem conhecido por todos: ler. Se um membro do time não sabe ler, isso ficará evidente em uma rodada de Planning Poker. E como funciona uma rodada?

O Planning Poker é um jogo colaborativo que favorece a criação de consenso dentro de um time sobre a estimativa de tamanho de um determinado trabalho e ajudar a descobrir riscos no projeto. Todos os membros do time escolhem, individualmente, sua estimativa para cada requisito que lhe é apresentado em uma reunião de detalhamento e planejamento para a construção de requisitos. Suas escolhas são mantidas em segredo, para que um membro não influencie o outro. E, por fim, as estimativas são apresentadas, todas de uma só vez. Diferenças entre as estimativas fatalmente aparecerão, o que leva à necessidade de um melhor entendimento, pelo time, do requisito, e a rodada é repetida até que o entendimento pelo time sobre o requisito esteja homogêneo. Isso ajuda, no caso do nosso projeto, a descobrir quem já tem experiência em ler determinada publicação e pode ajudar o time e que membro do time não sabe ler, o que pode ser um risco para o projeto e precisa ser tratado.

Para mim, ler o livro sobre CMMI teria uma pontuação de 20. Já para um companheiro, seria 8, pois ele já leu algumas partes e eu nunca peguei no livro. Então, entramos em um consenso de que a estimativa para lermos o livro sobre CMMI pode ser 13, porque os membros do time que conhecem o livro terão a carga extra de ajudar os que desconhecem. E, os que desconhecem, terão a carga extra de chegar ao mesmo nivel dos demais.

Ora, se o livro sobre CMMI tem 13 pontos de peso, ler a revista Caras não pode ser um esforço do mesmo tamanho. Porém, dependendo da experiência prévia do time, o livro sobre Orientação a Objetos pode chegar ao mesmo nível de esforço do livro sobre CMMI. Como podemos concluir, estimar depende muito da experiência prévia do time que executará as tarefas. Este projeto pode ter uma pontuação total de 30 para o meu time. Mas, para o seu, pode ser 20. Quanto tempo um time leva para atingir 30 ou 20 pontos? Mais uma vez, depende da experiência prévia destes times. Meu time pode levar 1 semana para atingir 30 pontos. Seu time pode levar o mesmo tempo para atingir 20 pontos. Então, devemos aprender a montar supertimes? Não. Temos que aprender a promover o crescimento individual de cada membro dos nossos times e reter, assim, os talentos necessários para o sucesso de nossos projetos.

Navegando por mares bravios: Se vigiamos os marinheiros, o mar nos surpreende
O sextante é uma ferramenta de navegação que permite saber o quão próxima uma embarcação está de seu destino. Se o capitão desta embarcação se preocupasse em saber se todos os seus marinheiros estão trabalhando como deveriam e se o estão fazendo da forma “correta”, esta embarcação teria grandes probabilidades de nunca chegar ao seu destino. Afinal, quem estaria no encargo de manter a embarcação na sua devida rota e motivar seus marinheiros informando-os do resultado de seu trabalho em prol do cumprimento do objetivo, que é a sua chegada a um local pre-determinado? Ainda há a enorme possibilidade de uma tempestade surpreender o capitão controlador, pois não estaria engajado em cumprir com seu objetivo, que não é manter seus marinheiros ocupados, mas guiar a todos de forma segura e competente ao seu destino. Portanto, em nossos projetos de desenvolvimento de software, nossa única preocupação é medir o quanto de software produzido com qualidade tem em mãos, para que, dentro do prazo acordado com nosso cliente, lhe entreguemos seu produto.

Progresso = Software funcionando. Foco no valor do software para o negócio, não no cronograma
Responder às questões “quanto custará”

e “quando ficará pronto” em um projeto de desenvolvimento de software é análogo a navegar uma embarcação. É necessário progredir, ou seja, ter software funcionando com qualidade, para que consigamos saber em que data conseguirá entregar o software a cada momento do ciclo de vida de um projeto e quanto isso custará. Diante de uma data previamente definida por nossos clientes, precisamos ajustar o escopo do projeto para que os requisitos de maior valor de negócio para o nosso cliente sejam priorizados, e, assim, consigamos satisfazer suas expectativas. Por isso, é de suma importância a participação ativa do cliente no projeto. Concluimos que tentar responder a estas perguntas no início de um projeto (certas vezes, até antes do início) é impossível. É um chute, qualquer que seja o método utilizado, em se tratando de software. Fatalmente, esta estimativa será atualizada durante o andamento do projeto. E os métodos ágeis de desenvolvimento de software prevêem este fato. E focam todo o esforço dedicado a um projeto na entrega o mais breve possível de valor para o cliente em forma de software, e não nos ajustes do cronograma e do tamanho do time em um projeto focando um plano criado no início do mesmo.