Gomes Andre Faria - Agile. Desenvolvimento de software com entregas frequentes e foco no valor de negocio стр 9.

Шрифт
Фон

Já com Kanban o processo é um fluxo contínuo e não é preciso que todo o tra-

balho planejado esteja concluído para que uma entrega seja realizada. No momento

16

Casa do Código

Capítulo 1. Introdução à Métodos Ágeis

da entrega, algumas tarefas estarão prontas e outras em progresso; as que estiverem

prontas farão parte da entrega, e as que não estiverem ficarão para a próxima.

Em meados de 2007, Rick Garber e David J. Anderson apresentaram nas confe-

rências o Lean New Product Development e Agile 2007, os resultados prelimina-

res do uso de Kanban na Corbis, uma empresa que vende imagens e clips de vídeo

fundada por Bill Gates, da Microsoft. Desde então, o Kanban vem ganhando mais e

mais força na comunidade de desenvolvimento de software e mais empresas passa-

ram a adotá-lo.

Kanban está bastante relacionado com o conceito de Pull Systems

(sistemas de

produção puxados), do Toyota Production System (TPS). Tradicionalmente, antes da

Toyota, a grande maioria das indústrias utilizava o conceito de Push Systems (siste-

mas de produção empurrada).

Um sistema de produção empurrada caracteriza-se quando a primeira operação

do processo recebe uma ordem de produção e a executa, empurrando o resultado da

operação atual para a operação seguinte. Em sistemas empurrados, não há ligação

direta entre o que é produzido e a demanda do cliente, ou seja, pode-se dizer que

o fato de um item ter sido produzido não significa que um outro item tenha sido

vendido.

Já um sistema de produção puxada exige que cada operação do processo seja

alimentada pela demanda da etapa anterior, estabelecendo uma ligação direta entre

o consumo real do cliente e a quantidade produzida. Dessa forma, o fato de um item

ter sido vendido, geraria a demanda para a fabricação de outro. Em uma abordagem

de desenvolvimento de software, poderíamos dizer que a demanda para se trabalhar

em uma nova funcionalidade seria gerada quando alguma outra fosse entregue.

Kanban é uma palavra japonesa que significa cartão sinalizador. É utilizado no

Sistema Toyota de Produção (TPS) e também por diversas empresas que aderiram à

filosofia Lean para representar, em um sistema puxado de produção, um sinal para

que se puxe mais trabalho, ou seja, para que o processo seja alimentado.

Kanban é dos métodos de desenvolvimento de software menos prescritivos, que,

de acordo com Henrik Kniberg, possui apenas três prescrições [34]:

1) Visualizar o fluxo de trabalho (workflow);

2) Limitar o trabalho em progresso;

3) Gerenciar e medir o fluxo.

17

1.8. Qual é o Melhor Método?

Casa do Código

Kanban incentiva a adaptação baseada em contexto. Deste modo, parte-se da

premissa que não existe uma única solução que resolva todos os problemas de to-

dos os diferentes contextos, e por isso há a necessidade de adaptação, em que cada

processo deve se adequar às necessidades do contexto a que pertence.

Kanban também recomenda que se meça o lead time, tempo médio para se com-

pletar um item, de forma que o processo deve ser continuamente otimizado para

tornar esse tempo cada vez menor e mais previsível.

1.8

Qual é o Melhor Método?

Kniberg define ferramenta como qualquer coisa que possa ser usada para atingir

uma tarefa ou objetivo , e processo como a forma que se trabalha [34]. Para ele,

métodos como Scrum, XP e Kanban são ferramentas para processos, e questionar

qual é o melhor deles é o mesmo que comparar se um garfo é melhor do que uma

faca, ou seja, isso depende do contexto e do objetivo em questão.

Nenhum método é completo e nenhum é perfeito, por isso, sinta-se livre para

combinar as ferramentas e aproveitar o que funcionar melhor para seu contexto, ou

seja, considerando a cultura da sua organização, as habilidades da sua equipe e as

restrições de seu projeto. É comum, por exemplo, que se adote práticas de engenha-

ria de XP, como programação em par e integração contínua, em times que utilizam

Scrum.

Todo projeto de desenvolvimento de software é diferente, possui pessoas com

habilidades diferentes, níveis de experiência diferentes, orçamento, prazo, escopo e riscos diferentes. Os valores da organização e suas metas também são específicos,

e com toda essa variação, sem dúvida, as restrições também serão diferentes. Por-

tanto, você deve procurar compreendê-las de forma a explorá-las da melhor maneira

possível visando atingir bons resultados.

Assim como as práticas, os papéis em uma equipe ágil, podem variar de acordo

com o método utilizado e contexto da equipe. Fique atento para utilizar apenas pa-

péis que de fato agreguem valor, e para não incluir papéis conflitantes.

Cada novo método que você estuda e conhece é mais uma ferramenta para sua

caixa de ferramentas, a pergunta certa não é qual é o melhor método, mas qual o

método mais adequado para esse contexto, e então, munido de sua caixa de ferra-

mentas, você terá condições de escolher a melhor abordagem para cada desafio.

18

Casa do Código

Capítulo 1. Introdução à Métodos Ágeis

Ваша оценка очень важна

0
Шрифт
Фон

Помогите Вашим друзьям узнать о библиотеке

Популярные книги автора

Agile
0 55