Como e por que criar Mapas do Fluxo de Valor para projetos de engenharia de software

Apesar de o Mapeamento do Fluxo de Valor ser bem conhecido para aplicativos de manufatura, sua utilidade não é tão conhecida assim para a comunidade de engenharia de software. Este artigo explica como começar um processo de Mapeamento do Fluxo de Valor e revela como os Mapas do Fluxo de Valor podem impactar de maneira positiva a maneira como seu software é produzido.

Ted Rivera, Software Developer, IBM

Ted RiveraTed Rivera faz parte da equipe de engenheiros de Transformação e Melhoria da Engenharia de Software no IBM Software Group, que desenvolveu a educação ágil e enxuta padrão da empresa, assim como os recursos para os chefes e gerentes de projetos nas equipes ágeis. Rivera trabalhou com dezenas de equipes IBM ao redor do mundo.



22/Mar/2010

Os Mapas do Fluxo de Valor possuem dois objetivos: ajudar as organizações a identificar e acabar com atividades de desperdício. Encontrar problemas e criar processos mais eficientes não é fácil; até mesmo a melhor organização pode tornar-se mais eficiente e eficaz. Mas fazer com que mudanças organizacionais substanciais que realmente eliminem o desperdício aconteçam é uma obrigação difícil. É fácil identificar desperdícios, mas é totalmente diferente acabar com o desperdício em primeiro lugar. Os Mapas do Fluxo de Valor podem estimular as qualificações da organização para identificar desperdícios e ajudar a guiar a mudança necessária. Primeiro, o mais importante: O que é um Mapa do Fluxo de Valor e como se pode produzir um de maneira inteligente. Os exemplos e conceitos a seguir são baseados na aplicação de um Mapa do Fluxo de Valor em uma organização de engenharia de software, mas estes conceitos são aplicáveis em uma grande variedade de cenários.

Como criar um Mapa do Fluxo de Valor

Um simples exemplo ilustra como um Mapa do Fluxo de Valor pode ser criado. Uma equipe em particular enfrentou restrições em viagens e lhe foi pedido que trabalhassem com um grupo fora da organização para chegar a um acordo sobre como colaborar em um projeto importante. O acordo necessitava estar pronto antes do início do trabalho. A Figura 1 mostra o Mapa do Fluxo de Valor criado por eles para descrever sua situação.

Figura 1. Realização do acordo (sem viagens)
Graphic shows a simple Value Stream Map

Considere os diversos elementos que fazem parte desse Mapa do Fluxo de Valor básico:

  1. Um processo ou atividade organizacional é identificado como desperdício em potencial. Ele pode ser um processo ou atividade simples ou complexa. Simplesmente escolha um processo ou um problema que você acredite que seja relevante ou importante.
  2. Esse processo ou atividade é dividido em suas tarefas constituintes.
  3. Os relacionamentos entre as tarefas são identificados.
  4. O tempo médio de trabalho necessário para concluir cada tarefa é estimado. Não é necessário a precisão perfeita. Se, algumas vezes, leva-se 3 horas para fazer algo, outras vezes 7 horas e outra vez 4 horas, devemos estimar que, em média, leva-se cerca de 5 horas para executar o trabalho para essa tarefa.
  5. O tempo médio de espera entre tarefas no processo é identificado. Mais uma vez, seria adequado usar uma estimativa, já que raramente acontece que altos níveis de precisão sejam possíveis ou necessários.
  6. O tempo total de trabalho, o tempo decorrido, o tempo desperdiçado e a eficiência são calculados.
  7. Se qualquer tarefa deve ser repetida, inclua o número médio de repetições (ou ciclos, como no exemplo acima).
  8. Opcional: Uma alternativa "what if?" (e se?) pode ser criada (uma segunda figura semelhante, às vezes referida como Mapa do Fluxo de Valor de "future state", ou "estado futuro"). Se uma ou mais mudanças foram instituídas, como se parecerá o estado futuro em termos de tempo de trabalho total, tempo decorrido, tempo desperdiçado e eficiência?

Faça o melhor para assegurar que seu Mapa do Fluxo de valor inicie e termine com um cliente real. Acima de todos os outros objetivos, estamos tentando ser úteis para as pessoas que compram e usam nosso software. Os Mapas do Fluxo de Valor nos ajudam a pensar em "O que está atrapalhando a entrega de valores a eles?" Os Mapas do Fluxo de Valor também devem incluir todas as etapas que contribuem para a entrega de valor ao cliente - até mesmo (ou especialmente) quando múltiplas equipes estão envolvidas na entrega. Muitas vezes, o desperdício é coletado nesses limites organizacionais.


Antipadrões que devem ser esperados ao criar um Mapa do Fluxo de Valor

Além desse exemplo básico, consideremos alguns dos elementos que podem, em potencial, fazer parte da criação de um Mapa do Fluxo de Valor. Se nosso objetivo é identificar e acabar com o desperdício em processos ou atividades, a primeira etapa será identificar uma ou mais possíveis origens de desperdício. Pode ser difícil identificar os problemas organizacionais mais importantes com os quais precisamos lidar. O que devemos procurar? Para começar, considere os seguintes antipadrões que podem existir em sua organização, pois eles fornecem pistas para ajudar a identificar que Mapas do Fluxo de Valor podem necessitar serem criados (adaptado de um conjunto de antipadrões identificados por Paul Gibson). Deve-se ouvir um toque de tambor constante no plano de fundo para melhorar: delegue, autorize, delegue, autorize.


Filas

Olhando pela superfície, pode não ser óbvia a frequência com que as filas aparecem em uma organização. Mas, até mesmo uma caixa de entrada de e-mail pode ser, e geralmente é, uma fila. E se o chefe da equipe depender do e-mail como uma notificação de que está na hora de fazer uma revisão de código? E se uma mensagem de e-mail somente for enviada a um chefe de testes quando uma construção estiver completa, em vez de ter se tornado pública de alguma maneira? E se um funcionário tiver que esperar indefinidamente para que um gerente aprove um formulário para que um ID possa ser produzido? As filas estão em todos os lugares, e listas de e-mails não processadas são apenas um antipadrão a ser considerado que pode ser categorizado como uma fila.

Figura 2. Filas
Visual image of a queue

Pode-se avaliar o efeito de qualquer fila observando nos itens de tempo mínimo que estão em fila, assim como o tempo médio necessário para processar um item em uma fila. Se, de vez em quando, a fila vai para zero, ela, provavelmente, estará somente manipulando a carga de trabalho variável. No entanto, se a fila nunca estiver em zero, o efeito final é atrasar todos os itens que tiverem passado para esse tempo mínimo, multiplicado pela duração média. Assim, por exemplo, caso processe um item por dia e possua uma fila mínima de 20, o efeito é atrasar cada item em 20 dias.


Listas não processadas

As listas não processadas são muito similares às filas, mas o próprio nome pode ajudá-lo a encontrá-las. As filas de requisitos não processadas são um bom exemplo. Como regra geral, use a ideia de que uma lista de requisitos não processada não deve nunca ser maior do que poderia ser concluído em dois releases do seu software. Se o seu produto ou projeto possui uma lista de requisitos não processada que levaria 100 anos para ser completada, a lista não processada é muito grande. O que fazer com todo o restante da lista não processada? Excluí-la. Caso seja importante, as partes interessadas lhe dirão, então algo poderá ser feito.

Mary e Tom Poppendieck oferecem uma abordagem mais sofisticada e um pouco menos extrema para manipular listas de requisitos não processadas maiores. As quatro etapas a seguir estão no segundo livro, Implementing Lean Software Development (consulte a seção de Recursos):

  1. Comece perguntando "Quantos itens dessa fila não poderão ser concluídos de maneira realística?" Corte todos os itens que não serão concluídos imediatamente. Seja honesto. Simplesmente pressione a tecla delete.
  2. Então, você se livrou de quantos itens? Metade? Agora, faça uma análise de Pareto com os itens restantes. Classifique cada item em uma escala de 1 a 5. Os itens críticos serão classificados como 5. Os itens não importantes serão classificados como 1. Agora, livre-se de todos os itens que não foram classificados com 4 ou 5. Simplesmente pressione Delete. Não se preocupe; se eles forem importantes, eles retornarão.
  3. Agora, pegue os itens que permaneceram e calcule quantos dias, meses ou anos de trabalho eles representam. Você adicionará outros itens à lista que serão mais importantes? Com isso em mente, você possui a capacidade de resolver os itens restantes na lista em um futuro próximo? Em caso negativo, deve-se incluir uma capacidade adicional?
  4. Se sua lista ainda for extremamente longa, ela deve possuir algum outro objetivo além de tomar decisões eficazes sobre o que deve ser feito e o que não deve ser feito. Por exemplo, uma lista longa pode desviar a atenção ou absorver solicitações frívolas. Divida a lista em duas, uma que tratará de objetivos exteriores e a outra que será mantida curta e com a qual você trabalhará.
Figura 3. Ciclos de revisão desnecessários
Graphic shows an unnecessary review cycle

Um outro exemplo chave de listas não processadas é uma lista de defeitos não processada. Não devemos sacrificar a qualidade em projetos de engenharia de software disciplinados. Mas se sua lista de defeitos não processada for enorme, seria inteligente corrigi-los? Você poderá ter uma qualidade menor corrigindo muitos defeitos? Com uma lista de defeitos não processada muito grande, além de perder tempo gerenciando essas listas não processadas, é improvável que você veja o que é realmente importante. E se você fez algo radical, como excluir uma lista de defeitos não processada, pensando que, ao prosseguir nenhum defeito poderia cruzar o limite de interação? Isso seria inteligente, possível ou praticável? Independentemente, as listas não processadas necessitam ser identificadas e eliminadas ou altamente minimizadas. Se existirem listas não processadas, elas devem ser necessárias e gerenciáveis.


Revisão regular e reuniões para soluções

Reuniões de status semanais, pontos de verificação de gerenciamento mensais e revisões de operações trimestrais são, normalmente, parte do fluxo de trabalho do desenvolvimento de software. Inclua as reuniões feitas para a preparação para outras reuniões de revisão e a lista pode aparentemente parecer infindável. Pare um pouco e identifique as reuniões que estão por vir no calendário de sua organização. Quais dessas reuniões são realmente necessárias? Quais são gargalos? Se forem necessárias aprovações (até mesmo isso pode ser colocado em dúvida), o processo de aprovação pode ser assíncrono? Pode ser possível diminuir o ciclo para que os tempos de espera caiam? Lembre-se de que, se uma reunião de revisão/decisão exige retrabalho e outro ciclo de revisão, o efeito final é atrasar a decisão em um mês, mesmo se forem necessárias apenas algumas horas de trabalho.

Além disso, seria adequado considerar a eficácia das reuniões que estão acontecendo caso seja determinado que as reuniões sejam necessárias. Há um objetivo claro para elas? É necessário um facilitador? As ações e resultados são claros? O progresso é consistentemente evidente?

Reuniões presenciais diárias curtas podem ajudar a estabelecer uma regularidade que guia o processo e identifica problemas rapidamente nos projetos de engenharia de software. No entanto, quando introduzimos reuniões presenciais diárias de 15 minutos em uma equipe, pedimos que fizessem isso somente se quisessem pagar um preço, ou seja: Que reuniões de duas horas existentes podem ser canceladas para justificar o estabelecimento de 1,25 horas de reuniões por semana que serão a força vital da equipe? Resumindo, a pior coisa que uma organização pode fazer é acrescentar reuniões sem pensar a respeito do que pode ser excluído ou substancialmente diminuído. Além disso, insistimos para que essas reuniões diárias sigam rigorosamente o tempo limite de 15 minutos.


Retornos de chamadas

Organizações de suporte a software geralmente operam por meio de um processo que incorpora retornos de chamadas de maneira intencional. A lógica é mais ou menos a seguinte:

  • Qualquer pessoa pode atender ao telefone (à parte, esse não é o caso). Contrate alguém com qualificações básicas para lidar com assuntos como verificações de licença, confirmação de informações de contrato, etc., e treine-as para responder às questões mais simples e indicar bases de conhecimento ou outros recursos aos clientes. Designe uma prioridade ou severidade à ligação. Enfileire os chamados de problema.
  • Tenha uma outra equipe com engenheiros com maiores qualificações para tratar essas chamadas por prioridade ou severidade.

Além de alguma frustração que a pessoa que ligou possa ter, essa é a maneira mais eficiente de usar recursos? Não seria o caso de engenheiros com maiores qualificações serem capazes de entregar valor aos seus clientes - solução de problemas, neste caso - de maneira muito mais rápida? Se desenvolvedores e testadores de software, por exemplo, atendessem ligações de suporte de vez em quando, eles não estariam mais a par da necessidade de tratar de problemas comuns no software?

O objetivo deste antipadrão não está restrito a chamados de problemas. De maneira mais ampla, para onde estão sendo direcionadas as chamadas para sua organização e como elas estão sendo manipuladas? Os retornos de chamadas representam um tipo de mecanismo de enfileiramento.


Fluxograma mostra aprovações necessárias múltiplas

Devido ao fato de este artigo focar principalmente no uso de Mapas do Fluxo de Valor para equipes de engenharia de software, seria justo observar que, se contratarmos engenheiros de software profissionais, devemos tratá-los como profissionais. Vale a pena questionar cada processo de aprovação que está acontecendo. Certamente, verificações e balanços adequados são válidos, mas dois exemplos podem mostrar os problemas em potencial com processos de aprovação incômodos.

Figura 4. Aprovações múltiplas
Flow chart shows multiple required approvals

Imagine uma organização que aprove a contratação de engenheiros para uma equipe que esteja em outro país. Por questões de simplificação, imagine que eles estejam tentando contratar engenheiros no Brasil e que os aprovadores da empresa estão nos Estados Unidos. Considere as etapas pelas quais a equipe no Brasil pode ter que passar:

  • Os engenheiros do Brasil entrevistam vários candidatos e escolhem o melhor.
  • O gerente dos engenheiros do Brasil deve aprovar.
  • O gerente intermediário dos engenheiros do Brasil também deve aprovar.
  • O gerente de nível nacional do Brasil também deve aprovar.
  • Os departamentos de recursos humanos e financeiro no Brasil devem aprovar.
  • Os departamentos de recursos humanos e financeiro nos Estados Unidos devem aprovar.
  • Aprovações de gerenciamento técnico (em um ou mais níveis) também devem ser feitas nos Estados Unidos.

Não é de se surpreender que um processo como este leve mais de um ano para ser concluído. Nenhum dos aprovadores acrescentará qualquer valor real. Por que não dar à equipe do Brasil um orçamento claro e um número alvo de funcionários e deixar que ela gerencie?

Um outro exemplo pode ser útil. Imagine um produto de software que não é vendido exclusivamente como um produto individual, mas como parte de uma solução maior - algumas delas podem possuir possíveis partes móveis. O que aconteceria caso tivesse que tomar uma decisão de arquitetura? Considere a simplificação que a Figura 5 mostra.

Figura 5. Decisões de arquitetura
Diagram shows development involving many products

Imagine que você seja um arquiteto que trabalha em um Produto A. A equipe da qual você faz parte quer que o Produto A funcione com os Produtos B, C, D, E, F e G. Pode ser o caso de os Produtos B, C, D e E serem construídos por uma outra parte da organização e os produtos F e G podem ser construídos por uma outra organização. Também pode ser o caso de o Produto G ser muito importante para o fluxo de receita de sua empresa.

Você possui duas escolhas básicas no que diz respeito à maneira na qual as decisões de arquitetura podem ser tomadas. Talvez, as reuniões onde as decisões são tomadas a respeito de como tudo deve funcionar em conjunto podem ocorrer a cada trimestre. No entanto, o principal problema desse tipo de abordagem é que, visto que essas reuniões acontecem raramente, poderá levar muito tempo até que seja tomada uma decisão-chave a respeito do modo como o Produto A será desenvolvido. Isso pode dificultar a entrega do Produto A com alta qualidade em uma programação curta.

Na prática, encontramos uma outra maneira que funciona bem. Se tratarmos o arquiteto do Produto A como um engenheiro inteligente e encorajá-lo a tomar decisões baseadas em seu melhor julgamento (para que a equipe não fique atrasada) e então comunicar a toda equipe sobre as decisões de arquitetura fora do caminho crítico, esse tipo de tomada de decisões otimista significaria cerca de 95% do tempo que o arquiteto acerta. E os 5% quando eles erram? Não é culpa do arquiteto; a equipe decidiu que essa abordagem funcionaria melhor. Decidimos que o retrabalho necessário para esses 5% quando as mudanças precisarem ser feitas na arquitetura valem a velocidade geral que foi ganha. Também deve ser observado que a taxa de sucesso de 95% deve ser maior do que a de equipes que esperaram pela aprovação.


Atividades paralelas com custos de integração

A razão pela qual a "integração contínua" é o mantra central para as práticas de engenharia de software ágeis e enxutas é o fato de que a integração de grandes amostras de código é realmente difícil de ser feita. Quanto mais tempo o código de estrutura estiver sendo usado e quanto mais tempo as suposições não forem contestadas, os desafios de integração serão mais difíceis.

Figura 6. Gargalos causados por atividades paralelas
Flow chart of frequent integrations

Usando novamente o fluxograma na Figura 6, seria ruim o suficiente se o Produto A fosse desenvolvido de uma maneira em que as construções fossem feitas sem frequência e os componentes ou módulos do produto fossem somente integrados esporadicamente. Mas, imagine se, além disso, o fato de a integração com outros produtos na solução maior estivesse sendo "adiado". Problemas inevitáveis seriam descobertos mais tarde no processo e provavelmente teríamos problemas de qualidade.

Além de a integração contínua ser feita para o Produto A e, esperançosamente, para cada um dos produtos na solução, construções frequentes da solução maior também devem ser feitas dessa maneira.


Ciclos de teste longos

É sempre caro adiar os testes até o final do processo de desenvolvimento. Quanto maior o tempo entre a injeção e a introdução de um erro, mais difícil será a correção. Esta é a razão pela qual testes de unidade, desenvolvimento guiado por testes, programação em pares, revisões de código e inspeções, automação de testes e muitas outras práticas significativas são frequentemente enfatizadas em círculos ágeis e enxutos para ajudar a eliminar o desperdício.

Se o seu Mapa do Fluxo de Valor revelar "ciclos" de teste longos no momento decisivo, é provável que você esteja garantindo o desperdício. O que pode ser feito para que testes de sistema funcionais e parecidos com os clientes possam ser executados durante as iterações de desenvolvimento?

Mesmo que sua equipe não reserve períodos longos ou tardios para o teste de sistema, em um Mapa do Fluxo de Valor, é importante distinguir entre o tempo gasto realizando o teste real e o tempo gasto corrigindo código. Não é incomum, por exemplo, que em uma organização de testes grande seja capaz de completar todos os seus testes em cerca de uma semana, considerando que o código seja genuinamente estável. Caso possua um ciclo de testes de sistema de 13 semanas, pode acontecer que grande parte desse tempo seja usado para reparar defeitos do que para os testes e que focar na remoção prematura de defeitos pode reduzir de maneira significativa o ciclo de teste do sistema e o ciclo geral?

De maneira similar, ciclos de teste longos podem ser um sintoma de subotimização geral de seu processo de desenvolvimento. Se eles existirem, pode acontecer de a análise das necessidades da organização acontecerem para considerar uma maneira de maximizar o fluxo geral ao invés de maximizar a capacidade da organização de gerar códigos não testados?


Ligando o fluxo de valor a seu cliente em ambos os terminais

Frequentemente, as equipes falarão a respeito da criação de Mapas do Fluxo de Valor que considerem um fluxo organizacional interno. De maneira ideal, quanto mais concebível for, um cliente real externo interessado deve ser identificado no início e no fim do Mapa do Fluxo de Valor.

Por exemplo, pode ser o caso de sua equipe estar revisando um Mapa do Fluxo de Valor para entender quanto tempo leva para implementar um novo requisito que vem de uma fonte de cliente externa. Frequentemente, as equipes considerarão o final desse Fluxo de Valor como sendo o horário de entrega do produto ou projeto. No entanto, na verdade, o final do Mapa do Fluxo de Valor deveria identificar o que é necessário para implementar o produto ou projeto no ambiente de produção, onde esse mesmo cliente está obtendo o valor real do seu requisito original. Caso esteja criando um aplicativo baseado na Web, pode acontecer de seu cliente estar em produção assim que você postar as mudanças em seu código. Em contraste, caso esteja produzindo um código para venda em uma loja de TI, as considerações de implementação deveriam ser de extremo interesse. Nesse caso, uma série de atividades que acontecerá após a entrega, que é, na verdade, parte do Fluxo de Valor, pode ser considerada como áreas possíveis de desperdício e candidatas a otimização através de mudanças na maneira como as atividades são anteriormente concluídas no ciclo.


Razões para criar Mapas do Fluxo de Valor

Há três razões principais para criar Mapas do Fluxo de Valor: objetividade, claridade e persuasão.

A emoção e a opinião possuem seu lugar. Mas questões sobre potenciais processos e atividades organizacionais que necessitam de mudanças - que são o objetivo dos Mapas do Fluxo de Valor - são mais bem tratadas de maneira imparcial. Consideremos uma amostra bem básica do Mapa do Fluxo de Valor usada no início deste artigo. Considere que você vai até o escritório de um responsável por tomar decisões e diz, "O custo seria reduzido e seria mais satisfatório para os clientes se viajássemos para seus escritórios da próxima vez que precisássemos assinar um acordo." É muito fácil para essa pessoa fornecer uma resposta padrão: "Neste momento, não aprovamos viagens."

Se, ao invés disso, um simples Mapa do Fluxo de Valor for apresentado, essa mesma decisão poderia ser tomada, mas o problema ficaria claro e a economia em potencial e o possível benefício ao cliente seria muito mais óbvio. E se você criasse um segundo Mapa do Fluxo de Valor - um Mapa do Fluxo de Valor de estado futuro - que defina esse contraste de maneira clara: "'Com a viagem, nos custaria $1.200 para concluir esse contrato e isso seria feito em dois dias. Sem ele, gastaríamos $13.500 (baseado na contagem de funcionários e outros custos) e nos levaria um mês e meio." Isso não daria mais chances a seu argumento? Apesar de o resultado ainda ser o mesmo (ou seja, a viagem não ser aprovada), a probabilidade de economia pode ser notada no caso de a viagem ser aprovada pode ser considerada de maneira mais objetiva. Ao invés de argumentar ou refletir sobre a decisão, pode-se fornecer justificativas para exceções adequadas.

Um exemplo final pode ser útil: Como uma solicitação do cliente é manipulada. Estude esse diagrama feito a mão na Figura 7.

Figura 7. Mapa do Valor Fixo, implementando uma solução do cliente
Image shows a hand-drawn Value Stream Map

Visão ampliada da Figura 7.

Examine o fluxo por um momento. Um número de pontos é destacado nesse exemplo. Primeiramente, ele não é bonito. Se ele fosse convertido em um gráfico claro usando o Microsoft® Visio® ou alguma outra ferramenta, isso mudaria seu conteúdo? Na verdade, não. Quanto mais fácil for criar Mapas do Fluxo de Valor, será mais provável que sua organização começará a usá-los de maneira rotineira. Considere também alguns dos recursos desse Mapa do Fluxo de Valor em particular e, rapidamente, tire algumas conclusões importantes:

  • A abordagem de desenvolvimento geral que está sendo usada por essa equipe em particular parece ser, essencialmente, um processo em cascata.
  • Apesar de o gráfico conter somente os tempos de espera e não os tempos de trabalho associados a essas tarefas, algumas questões se destacam sobre o tempo de trabalho. Na produção dos tempos de trabalho que estão associados a essas tarefas, pode ser o caso de as próprias tarefas estarem escondendo desperdício. Algumas dessas tarefas (tais como "Develop / Document / Test") precisarão ser divididas ainda mais para assegurar que não haja desperdício.
  • Há muitos ciclos de aprovação aqui. Todos eles são valiosos?
  • Não há loops aqui, o que pode ser devido ao fato de o gráfico ser uma simplificação. Dito isso, com que frequência alguns desses ciclos de aprovação são repetidos? Eles podem ser a origem de desperdícios adicionais.
  • De maneira positiva, é bom ver que esse processo em particular (uma solicitação de recurso) se inicia e termina com o cliente. Como consideramos, frequentemente é o caso de algumas equipes pensarem isso, pois eles entregaram o software ou concluíram o trabalho de alguma outra maneira, mas eles terminaram seus trabalhos. No entanto, o cliente ainda deve implementar seu software em vários casos, e às vezes, em ambientes complexos.

Muitas outras observações poderiam ser feitas sobre esse Mapa do Valor de Fluxo em particular, mas, fundamentalmente, o problema principal é que todas as pessoas envolvidas podem dar um passo atrás e pensar a respeito do fluxo de uma solicitação de recurso na organização. Em comparação, deve ser muito mais fácil sugerir que a maior área de desperdício deve ser tratada. Seria muito mais trabalhoso dividir mais ainda as tarefas para um nível adequado de detalhes e calcular o tempo geral de trabalho e o tempo geral desperdiçado, como no primeiro exemplo. E então, muito provavelmente, se tornará mais claro o que necessita ser tratado primeiro - e por quê.


Resumo

Os Mapas do Fluxo de Valor nos ajudam a criar uma melhoria organizacional, progresso em nossos processo e métodos e, mais importante, softwares melhores. Os Mapas do Fluxo de Valor podem nos ajudar tanto a identificar quanto interromper o desperdício em uma organização. Ao alavancar as lições aprendidas nesse artigo, sua organização pode se tornar mais eficiente e entregar produtos de maior qualidade a seus clientes.

Recursos

Aprender

  • Poppendieck, Mary e Tom. Implementing Lean Software Development. Addison-Wesley Professional, 2007, páginas 103-104
  • Obtenha a especificação do Business Process Execution Language para Serviços da Web, Versão 1.1 no developerWorks.
  • Leia BPELJ: BPEL for Java technology, um White Paper que explica como as duas linguagens podem ser usadas juntas para construir aplicativos de processos de negócios (developerWorks, março de 2004).
  • Confira os recursos de desenvolvimento ágeis do IBM® Rational® Requirements Composer, que podem ajudar toda a sua equipe a definir, atualizar e gerenciar requisitos durante o ciclo de vida de desenvolvimento do produto.
  • Conheça outros aplicativos na IBM Rational Software Delivery Platform, incluindo ferramentas de colaboração para desenvolvimento em paralelo e equipes geograficamente distribuídas, além de software especializado para gerenciamento de arquitetura, gerenciamento de ativos, gerenciamento de alteração e release, gerenciamento de requisitos integrados, gerenciamento de processo e de portfólio e gerenciamento de qualidade.
  • Visite a área do software Rational no developerWorks para obter os recursos técnicos e as melhores práticas dos produtos da Rational Software Delivery Platform.
  • Examine os cursos do Rational (baseados em computador local, baseados na Web e online conduzidos por instrutor). Aprimore suas habilidades e aprenda mais sobre as ferramentas do Rational com esses cursos, que abordam desde o nível básico até o avançado. Os cursos neste catálogo estão disponíveis para compra do início ao fim do treinamento baseado em computador local ou do treinamento baseado na Web. Além disso, alguns cursos de "Introdução" disponíveis são gratuitos.
  • Assine a newsletter do IBM developerWorks, uma atualização semanal sobre o que há de melhor nos tutoriais, artigos, downloads, atividades da comunidade, webcasts e eventos do developerWorks.

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=484089
ArticleTitle=Como e por que criar Mapas do Fluxo de Valor para projetos de engenharia de software
publish-date=03222010