BT

Brasil terá representação na primeira conferência internacional sobre Lean & Kanban

por Manoel Pimentel em 21 Jan 2009 |

Ocorrerá nos dias 6 e 7 de maio desse ano de 2009 em Miami (Flórida-EUA), o Lean & Kanban Conference 2009 que será o primeiro evento internacional sobre o Sistema Kanban e Lean aplicado ao desenvolvimento de software.

O sistema Kanban oriundo do STP(Sistema Toyota de Produção) é uma das ferramentas do pensamento Lean que nos habilita a gerenciar de maneira enxuta o ciclo de produção ou evolução de produtos.  Recentemente essa filosofia vem ganhando muita sinergia para o desenvolvimento de software, principalmente em função da disseminação das metodologias ágeis, que de certa forma, é um excelente início para a prática de conceitos inerentes ao Pensamento Lean.

Esse evento contará com expressivos nomes da comunidade internacional de Lean e Agile como Dean Leffingwell, Alan Shalloway e David J. Anderson. E o Brasil estará sendo representado através de um palestrante de peso, pois trata-se de Alisson Vale, Diretor da Phidelis Tecnologia e um dos pioneiros no Brasil sobre a adoção de Agile e Lean no seu cotidiano de desenvolvimento de software.

Fiz uma entrevista bem interessante com ele sobre a sua experiência com Lean e com o próprio sistema Kanban, o resultado foi uma entrevista altamente esclarecedora e motivadora para adoção desse modelo nos cenários que forem apropriados.

Manoel Pimentel  Alisson, explique-nos rapidamente o que é o Kanban e como ele está sendo aplicado na indústria de software hoje?

Alisson Vale  -  Bom, antes de tudo deixa eu tentar contextualizar essa técnica dentro do TPS. O Sistema Toyota é, como nós sabemos, centrado na eliminação de desperdício. A estratégia central é criar um fluxo unitário interligando processos e operações para tornar as perdas evidentes. Dessa maneira você estimula o processo de melhoria contínua.  Na verdade, sempre há fluxo em qualquer processo, por mais caótico que ele seja. O segredo está em tornar esse fluxo mais “enxuto” de modo que a menor quantidade possível de inventário seja processada pelo sistema em um dado momento. Uma das maneiras de tornar um fluxo de trabalho mais “enxuto” é fazendo com que a relação entre operações dependentes seja limitada por acordos bem definidos que estipulem quem faz o quê e quando. Um sistema puxado (ou Pull System) faz isso, viabilizando o fluxo como decorrência. O trabalho é passado de uma operação a outra de modo que a operação-cliente sinalize para a operação que a precede (fornecedora) que está pronta para o próximo trabalho. O kanban é essa sinalização.

A técnica do kanban começou a ser utilizada em desenvolvimento de software com a introdução dos métodos ágeis. Um quadro com cartões e post-its é utilizado para sinalizar o status do trabalho em andamento. Quando a equipe move, por exemplo, um cartão para a área de "concluído" do quadro, ela sinaliza para o demandante (o Product Owner, no caso do Scrum, por exemplo) que está pronta para o próximo trabalho. Isso permite a criação do fluxo dentro de uma iteração e impede que a demanda seja empurrada para a equipe em grandes lotes. É um exemplo de Pull System. Mas em termos Lean, um Pull System pode ser utilizado para melhorar processos de modo geral. E ele pode ir além do framework mais simplificado do Scrum e assim ajudar uma equipe de projeto a criar sustentabilidade para o trabalho que executa. 

Em 2006, o David Anderson publicou um artigo chamado “Kanban In Action” onde ele descreveu sucintamente o método que utilizou na Corbis para garantir atividades de sustentação que não podem seguir o sistema de iterações sugerido pela abordagem ágil tradicional. Era preciso sustentar o produto diariamente enquanto ele evoluía quinzenalmente. Nessa abordagem ele expandiu o uso do quadro kanban de modo a representar o ciclo de vida de um item de trabalho dentro do processo utilizado. O que antes era apenas 3 colunas (pendente, em andamento e concluído) passou a ser um instrumento de representação de toda a cadeia de valor, viabilizando a criação de um autêntico Pull System. Isso foi feito por meio do estabelecimento de limites para diferentes tipos de atividade (bugs, manutenção, análise, design, etc) e por meio da definição de regras simples que definiam o acordo para movimentação desses itens ao longo da cadeia de valor. O efeito dessa abordagem foi a limitação do trabalho em andamento (o que chamamos de Work in Process (WIP)) e o balanceamento da capacidade contra a demanda. Desde então, tem-se utilizado o nome KSE (Kanban for Sustaining Engineering) para descrever essa abordagem e temos percebido que é cada vez maior o número de pessoas no mundo inteiro que a vem utilizando e obtendo bons resultados em cenários bem diversos. Hoje a comunidade interessada já conta com mais de quinhentos membros e há uma grande movimentação sobre o assunto.   

Manoel Pimentel – Lean e Agile têm uma sinergia histórica e prática muito forte, como se dá a relação entre esses dois paradigmas na sua opinião?

Alisson Vale  -  Não é muito simples para as pessoas saberem onde começa uma coisa e termina outra. Lean e Agile são muitas vezes confundidos. De fato, há uma forte intersecção entre esses paradigmas. Há vários traços Lean em Agile e os dois paradigmas se complementam de alguma forma. Na minha opinião, seria muito difícil adotar Lean em desenvolvimento de software se ainda estivéssemos trabalhando no modelo waterfall. Foram técnicas ágeis que nos possibilitaram aplicar conceitos Lean fundamentais como valor, fluxo, melhoria contínua, cadência e outros. O que eu acho limitadora é a idéia de que Agile na forma de Scrum+XP representa o melhor e talvez o único modo de aplicar Lean a desenvolvimento de software. Essa abordagem é um excelente ponto de partida, mas se o paradigma Lean for plenamente entendido durante o processo, há uma boa probabilidade que essa abordagem sofra uma série de mudanças a médio e longo prazo.    

Manoel Pimentel – Porquê?

Alisson Vale  -  Porque Lean leva em consideração tudo que está fora da trincheira de um projeto. O paradigma Ágil é sobre software e sobre as pessoas que o fazem. Lean é sobre o negócio como um todo. Um exemplo dessa relação ocorre em empresas com uma grande base de clientes em um mercado onde cada player tem um modo potencialmente diferente de operar. Essas empresas têm muita demanda de sustentação. Sustentar significa implantar, customizar, configurar, dar suporte, resolver problemas emergenciais, prestar ajuda aos usuários, fazer deploy, treinar e qualquer outro esforço que seja necessário para viabilizar o uso do produto pelo seu cliente. Scrum+XP é um excelente modelo para o desenvolvimento de produtos, mas não são métodos bem indicados para sustentação de produtos. Essa limitação leva muitas empresas a separarem seus processos de sustentação, dos processos de desenvolvimento. Elas acabam sendo ágeis para desenvolver, mas caóticas para sustentar. E você precisa fazer sempre as duas coisas mesmo tempo e com a melhor sincronia possível. Há uma relação sistêmica entre esses dois modelos de operações, quando elas não estão sincronizadas perde-se ganho global e isso afeta a sua qualidade e a sua produtividade.  Essa é uma área que até então não estava muito bem coberta pelo paradigma Ágil. Lean, e o KSE mais especificamente, podem contribuir muito para cobrir esse aspecto. Desenvolvimento ágil é sobre geração de valor e sustentação é saber lidar com desperdício. Toda a atividade de sustentação, na área de software, é essencialmente desperdício sob o ponto de vista Lean, e é fundamental sabermos lidar com esse desperdício em determinados cenários. Esse é um dos motivos pelo qual o KSE é aplicável inclusive a projetos que não são Ágeis. Ele vai ajudar a "Agilizar" aos poucos o projeto ao longo do tempo. O fluxo gerado vai evidenciar as perdas e isso vai direcionar as pessoas a saber quando, onde e porquê cada uma das técnicas ágeis precisa ser aplicada.  

Manoel Pimentel – Ao representar num Kanban todas fases de processos ou operações, não estamos estimulando o uso de um modelo waterfall em nosso ambiente? Ou você acredita que seja possível implementar e ter benefícios com o Lean mesmo em ambientes waterfall?

Alisson Vale  -  Sob o ponto de vista Lean, um dos grande problemas do modelo waterfall é o excesso de inventário que o modelo te induz a produzir. Quando você produz uma série de documentos com especificações de requisito up-front, você injeta isso em grandes lotes no sistema, gerando inventário (trabalho não-concluído). Quando esses documentos viram modelos UML, mais inventário é injetado e nada se produziu ainda em termos de valor agregado para o cliente. Em grandes empresas de software, o problema é ainda agravado por causa das medidas de eficiência utilizadas. Um analista é avaliado pela quantidade e pela qualidade da análise que ele faz, não pela quantidade e qualidade de software que ele ajuda a construir. Da mesma forma ocorre nas áreas de teste. A eficiência dos testadores é medida pela quantidade de testes que eles fazem e pelo tempo que eles gastam nessas atividades. Na medida que analistas, projetistas ou testadores vão ficando ociosos, eles vão sendo alocados para outros projetos, produzem cada vez mais inventário, que vai se acumulando nas mãos da equipe de desenvolvimento (que normalmente é compartilhada entre vários projetos). Com muito trabalho e pouco tempo, as questões de qualidade serão as primeiras a serem deixadas em segundo plano. Com menos qualidade, mais relatórios de bugs voltam dos testadores. Mais bugs para corrigir, menos tempo para processar o resto do inventário que está parado. O dia diminui e as noites vão gradativamente aumentando. O resto da história a gente já conhece. É a falácia das "Fábricas de Software".

Em resumo, quanto mais eficientes são analistas e testadores, mais inventário é produzido, mais pressão sofrem os desenvolvedores, e menos eficiente é o sistema como um todo. Essa prática leva as empresas a se comportarem em um modelo onde se estimula a criação de "ótimos locais". Segunda a Teoria das Restrições (TOC), ótimos locais não só não contribuem para um todo ótimo, como na maioria das vezes atrapalham.  A única maneira de evitar o caos é adotando longos leadtimes (muitos meses ou anos), processos altamente controlados e burocráticos e uma extensa folha de pagamento para lidar com as atividades que não agregam valor ao produto final. Assim, essa é uma das maneiras pela qual Lean e TOC explicam a ineficiência do modelo waterfall.

No que diz respeito ao Kanban, ele não te direciona para um determinado paradigma. Ele apenas viabiliza o fluxo. Há equipes que representam o ciclo de vida linearmente: análise, design, codificação e testes em seqüência. E trabalham com pessoal especialista em cada uma dessas fases. O kanban é utilizado então para fazer o requisito atravessar todas essas fases e sair do sistema como software funcional. Ou seja, mesmo utilizando fases, essa equipe consegue entregar software funcional freqüentemente, tanto quanto uma equipe Ágil conseguiria. Mas a questão fundamental é que o kanban limitará o WIP e viabilizará o fluxo, fazendo com que a equipe reproduza esse ciclo em horas ou dias, ao invés de meses. Se essa equipe trabalha assim é porque, ou por algum motivo qualquer ela não pode fazer do jeito Ágil, ou ela prefere desse jeito. Seja qual for o motivo, o kanban vai ser de grande utilidade nesse contexto, podendo inclusive abrir as portas para que o processo de melhoria contínua aponte para as práticas Ágeis adequadas de acordo com a necessidade de redução de desperdício evidenciada.

O fato de você ter um processo bem definido, não significa que você está deixando de ser Ágil. Você pode ter um processo muito bem mapeado e continuar sendo Ágil. O Kanban não interfere em como as coisas são feitas, ele apenas ajuda a manter o fluxo de criação de software compatível com a capacidade da equipe em produzi-lo. Isso pode ser de grande ajuda para as equipes Ágeis vencerem as dificuldades que têm dentro dos ciclos iterativos. Por outro lado, se você tem um processo totalmente caótico, o KSE pode ser o modo mais simples de sair do caos e começar a trabalhar com alguma organização. Ele vai te ajudar a estabelecer um ponto de partida para melhoria contínua à partir do processo existente, e não à partir de um modelo genérico montado para uma realidade diferente da sua.

Manoel Pimentel –  Uma das grandes visões que o Lean trouxe ao mercado, foi poder visualizar o tempo de valor agregado (Work Time) e tempo de perda (Waste Time) de cada atividade, que no caso de desenvolvimento de sistemas, esse tempo de perda está muito ligado ao tempo de espera que uma demanda sofre entre uma atividade e outra, então dado essa visão, como podemos representar isso num sistema Kanban? 

Alisson Vale  -  O tempo de espera para que uma demanda saia de um estado para outro não é necessariamente uma perda. A perda se dá não somente pelo tempo que ela leva para ser movimentada no kanban, mas principalmente pelo tempo que ela permanece em WIP sem que haja uma atividade de agregação de valor que a coloque no caminho de saída. Reduzir leadtime só vai ser bom se a qualidade se manter inalterada ou se for melhorada. Então não faz sentido tentar diminuir tempos de ciclo a qualquer custo. Multi-tasking, por exemplo, representa perda direta. Se você está trabalhando em mais de uma demanda ao mesmo tempo, ou se você interrompe uma demanda para começar outra mais emergencial, seu WIP aumenta. Muito WIP afeta o fluxo e os tempos de ciclo e, por conseqüência, o rendimento global do sistema. No kanban nós conseguimos acompanhar o volume de inventário que está em WIP, mas não é isso que o torna eficaz. O que torna o modelo interessante são os limites que são estabelecidos. Para que algo entre no sistema, alguma coisa tem que sair. É esse trade-off que faz você se concentrar em manter o foco naquilo que é mais importante naquele momento, pois qualquer coisa menos importante estará ocupando um espaço precioso do seu sistema. Em resumo, o kanban não só evidencia as perdas geradas pelo excesso de inventário, mas principalmente evita que elas aconteçam. 

Manoel Pimentel  Conte-nos um pouco sobre sua experiência com Agile e Lean em seu dia-a-dia? E como foi que o Lean ganhou espaço em seu contexto?

Alisson Vale  -  Nós começamos a trabalhar com Agile aqui na empresa em 2004. Desde então temos nos adaptado às dificuldades, tentando lidar com a complexidade que é desenvolver software. Utilizamos XP para desenvolver nosso produto e o resultado foi ótimo. Começamos, no entanto, a ter dificuldades à medida que o produto começou a entrar no mercado e a cartela de clientes cresceu. Nessa época, tentamos adotar Scrum, mas não funcionou bem. O Scrum melhorou nossa capacidade de evoluir o produto, mas afetou de forma negativa nossa capacidade de sustentar o produto. E não foi culpa do Scrum, foi nossa culpa não ter interpretado bem seus pressupostos e ter insistido em utilizá-lo em um cenário para o qual ele não foi concebido. Tentamos várias estratégias sugeridas para lidar com sustentação: equipes diferentes, percentual de tempo alocado, considerar as atividades de sustentação nas estimativas. Nada disso funcionou bem. Em 2007, começamos a estudar o modelo Kanban que o David Anderson estava propondo e nos identificamos com aquilo. Parecia fazer sentido dentro do nosso contexto. Levou um tempo até entendermos como operar com o novo modelo. 

Em 2008, todas as operações da empresa começaram a ser integradas em torno dos novos conceitos. O processo foi mapeado, o quadro Kanban foi modificado para representar o processo e o sistema puxado foi se estabilizando aos poucos. Como o kanban estava representando toda a nossa cadeia de valor, a operacionalização dos cartões na parede começou a incomodar, já que eram muitas operações todos os dias e isso começou a incomodar a equipe. No segundo semestre de 2008, desenvolvemos uma ferramenta eletrônica de controle visual para substituir o kanban na parede. Isso nos levou a eliminar um monte de desperdício que o controle visual manual gerava. E também nos deu informações muito mais precisas para gestão. Hoje, temos várias métricas importantes (como Cycle Time e Percentual de Desperdício) que são exibidas em tempo real para a equipe no quadro eletrônico.

Resolver o problema operacional com o Pull System foi como colocar a ponta dos pés no mundo Lean. As coisas começam a ficar muito mais claras depois que você começa a saber fazer as perguntas certas (mesmo que você ainda não saiba as respostas). Lean ainda é um aprendizado para nós, mas ele vem influenciando cada vez mais a maneira como executamos todas as nossas operações e os rumos para os quais temos nos planejado. À medida que você vai absorvendo os conceitos Lean, a sua distinção vai ficando mais nítida com relação a Agile.  Um exemplo disso é como lidar com melhoria contínua. O Kaizen, em termos Lean, é "atemporal", ou seja, o processo de melhoria contínua obtido com uma cultura Lean é muito mais amplo do que a simples execução e acompanhamento de reuniões periódicas. É preciso ir além dos métodos Ágeis para incorporar plenamente o paradigma Lean.

Manoel Pimentel – Comente um pouco sobre os resultados que sua companhia está obtendo através das aplicações das idéias Lean e Kanban?

Alisson Vale  -  No curto prazo, esse modelo gera um aumento na sua capacidade de auto-observação. Isso é valioso pois é o que alavanca o processo de melhoria contínua. Atualmente estamos em um momento onde estamos colhendo e avaliando os resultados operacionais do novo modelo, e isso está nos preparando para definir as estratégias de longo prazo que gerarão resultados mais profundos. Por exemplo, uma das coisas que eu aprendi a observar é que o fluxo é inibido quando há muita variabilidade nas operações, e a força negativa que essa variações impõem ao seu resultado final aumenta quando o nível de abstração necessário para execução dessas operações aumenta. Isso ajuda a justificar altos investimentos em design de software, por exemplo, que é uma atividade de alta abstração. Técnicas como TDD, DDD e Design Patterns, além de dar condições de manutenibilidade no produto, ajudam a conter essa variabilidade e, portanto, ajudam a nivelar o fluxo, reduzir leadtime e aumentar a eficiência global do projeto. 

O principal resultado de curto prazo que estamos tendo é que o modelo permite o aprendizado na arte de selecionar eficientemente a "coisa certa que precisa ser trabalhada em um dado momento", ou seja, ele ajuda a evitar que você crie desperdício trabalhando em coisas que não são importantes naquele instante do tempo. Esse é um dos motivos pelo qual iterações freqüentemente não são utilizadas no KSE. Iterações não se ajustam bem às atividades de sustentação, pois não lidam bem com a imprevisibilidade inerente a essas atividades. Um backlog de sustentação não se adapta a iterações time-box quando há muito esforço para sustentação e quando essa sustentação é realizada pela mesma equipe que continuará trabalhando para evoluir o produto. Iterações vão funcionar bem por outro lado, quando você tiver pouco ou nenhum esforço para sustentação, ou quando você estiver iniciando novos projetos. 

Um outro benefício importante é o ajuste da demanda. Seus clientes vão sempre pedir mais do que você pode fazer. Não há como intervir nisso quando você tem uma relação "Ágil" de confiança mútua com seus clientes. E quando você tem vários clientes independentes, eles estarão sempre competindo indiretamente pela alocação do recurso que você dispõe. Quando você consegue atender bem o que é mais importante, os clientes vão naturalmente aprendendo o seu ritmo e se ajustando a ele. De fato, ele abre mão de coisas menos importantes para obter aquelas que são mais importantes. Isso não significa que essas coisas não serão feitas, significa que elas só serão feitas quando forem de fato importantes. É esse o mecanismo que permite a relação de confiança mútua e de escopo aberto tão necessária para o modelo ágil em um ambiente de competitividade e interesses divergentes. 

Manoel Pimentel – Fale-nos um pouco de como será sua palestra no evento e que tipo de temas abordará?

Alisson Vale  - Minha palestra, se ela for confirmada, é claro, pois ainda depende de uma certa quantidade de inscritos para viabilizar a minha ida,  será basicamente sobre a nossa experiência prática na adoção do modelo. Há muitas formas de implementar um KSE. Acho importante que as pessoas conheçam como isso pode ser diferentemente aplicado a cenários diversos. O meu cenário é semelhante ao de milhares de empresas por aí que precisam sustentar grandes ERPs, com uma ampla variedade de cenários e realidades de negócio, e mão-de-obra limitada. Lean, KSE e o modelo Ágil em conjunto podem dar um caminho a seguir para essas empresas.  Praticamente tudo que fazemos está de alguma forma representado no conjunto de ferramentas que utilizamos (todas open-source ou desenvolvidas internamente). E esse será o enfoque: como nós organizamos nosso processo e como as ferramentas foram sendo acopladas para sustentá-lo. O destaque ficará por conta do Kanban Board eletrônico que será a base para demonstrarmos como estamos aplicando os conceitos em nosso ambiente.

Manoel Pimentel – Como está sua expectativa para o evento como um todo?

Alisson Vale  - O evento estará reunindo os principais nomes que estão trabalhando com KSE e Lean na área de software hoje na Europa e EUA. Será um aprendizado para todos. Além das palestras, teremos um dia inteiro de Open Spaces para discussões e outros momentos com keynotes de primeira linha. O evento é indicado não só para quem quer ampliar seu leque de possibilidades para treinamento ou consultoria Ágil, mas principalmente para quem passa pelos problemas que essa comunidade está tentando resolver. Um tema que será muito discutido também é o de como "escalar" Agile para grandes projetos ou para grandes empresas. O que está sendo discutido nessa área, é um modelo alternativo ao Scrum of Scrums, que hoje é o mais indicado pela comunidade Ágil. Há muita polêmica sobre o significado desse modelo em termos de Lean e, eu acho saudável que, como comunidade, estejamos sempre desafiando nossas pré-concepções sobre as práticas que defendemos baseado no feedback do mercado.

Manoel Pimentel – Há expectativa para a formação de uma nova comunidade no Brasil sobre esse assunto?

Alisson Vale  - Eu gostaria que isso acontecesse. Acho que o modelo KSE se encaixa perfeitamente dentro dos valores e princípios do Manifesto Ágil. Pessoas que valorizam mais práticas do que princípios talvez não o qualifiquem como "Ágil", já que é possível utilizá-lo em cenários que algumas metodologias ágeis não recomendam como cenários de alta especialização de membros da equipe, design up-front, documentação mais intensa, ausência de iterações e outros. Mas é importante saber diferenciar os cenários para o qual o KSE pode ser aplicado, dos seus fundamentos. O mérito do KSE está em dar condições para aqueles que não podem abrir mão de certas limitações práticas da sua própria realidade, mas mesmo assim querem começar a trabalhar desde já em direção ao Manifesto. A realidade é que as metodologias ágeis mais utilizadas atualmente tem dificuldade de dar condições de transição para o modelo Ágil. Se você não estiver seguindo o Manifesto, os métodos atuais sugerem praticamente um recomeço. O KSE pode ser então o ponto de partida que essas equipes precisam para começarem a se mover em direção a ele. Eu acredito, assim, que há muita gente por aí precisando desse tipo de resposta. É um modelo que pode trazer mais empresas para esse novo paradigma e impulsionar a força da indústria de software como um todo. Além disso, projetos Scrum também podem se beneficiar dessa abordagem por meio da otimização do trabalho que acontece dentro das Sprints. 

Nesse momento, estou escrevendo um artigo para colocar em português os principais elementos dessa abordagem e assim permitir que as pessoas discutam melhor sobre o assunto aqui no Brasil. Mesmo para quem lê em inglês, as informações sobre o KSE ainda estão muito espalhadas em blogs, listas de discussão e podcasts, e não é fácil reuni-las de maneira a entender o modelo com uma profundidade maior. Já há um livro sobre o assunto, mas podemos fazer mais. Uma lista no Yahoo Groups está aberta para os interessados, mas as discussões ainda não começaram. Acredito que quando eu liberar esse material, as discussões começarão a sair com mais naturalidade.

Manoel Pimentel – E para terminar, qual conselho ou mensagem de incentivo ou  mensagem de alerta você daria para o gestor que esteja interessado em melhorar seu processo de desenvolvimento de software através de Lean ou de Agile?

Alisson Vale - A mensagem é que não acho mais ser possível dissociar as questões de engenharia (ou o craftmanship) das questões gerenciais e econômicas quando se fala em desenvolvimento de software. Questões técnicas afetam significativamente as questões não-técnicas, e vice-versa. É aí que Lean e Agile tem seu papel complementar. Parece que o segredo não é só saber balancear as duas coisas, mas saber como uma coisa pode influenciar a outra positivamente ou negativamente. "Design para Testabilidade", por exemplo, parece ser fator essencial para aumentar, ou até, viabilizar o potencial de lucratividade de produtos de software hoje. E é uma questão muito técnica. Por outro lado, ritmo sustentável, colaboração, controle de variabilidade e leadtime são conceitos gerenciais importantes que afetam diretamente o modelo, o ritmo e a qualidade do que é produzido. Portanto, unir a natureza das questões em um único todo, unificando seu propósito, parece ser o caminho mais sábio a se seguir por agora.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

KSE no Scrum by Rodrigo Toledo

Olas,

EXCELENTE ENTREVISTA! Parabéns aos dois!

Alisson, você poderia falar mais sobre "projetos Scrum também podem se beneficiar dessa abordagem por meio da otimização do trabalho que acontece dentro das Sprints." ??

Talvez até um blog só sobre isso no Visão Ágil fosse o ideal...

[]s,
Rodrigo de Toledo

Re: KSE no Scrum by Manoel Pimentel (InfoQ Brasil)

Olá Rodrigo, Obrigado pelo comentário.

O Alisson poderá explicar melhor essa questão, mas particularmente, apliquei num contexto bancário (muito específico) onde presto consultoria, um fluxo de entrega (review) unitária de cada item do backlog ao P.O dentro uma Sprint, dessa forma através desse leadtime dentro uma Sprint, passamos a ter um feedback muito mais constante e dentro das expectativas que organização tinha acerca do projeto.

Grato,

Manoel Pimentel

Re: KSE no Scrum by Alisson Vale

Rodrigo,

Obrigado pelo feedback. A idéia do post é boa. Mas o que eu posso adiantar é que o sistema de sinalização do Kanban utilizado pelo Scrum pode ser adaptado às questões específicas do seu projeto quando você visualiza estágios de desenvolvimento que são dependentes entre si, ou quando seu processo precisa acomodar alguma forma de especialização. Não é tão fácil organizar o trabalho dentro de uma Sprint quando não há um nivelamento no fluxo de produção da equipe. Algumas questões que queremos responder com essa abordagem:

- Como organizar o trabalho quando você precisa sincronizá-lo com operações especializadas, como as que são realizadas por um Web Designer ou por um DBA, ou ainda por uma equipe de testadores?
- Como lidar com o seqüencialmente de atividades quando este é necessário?
- Como evitar que trabalho inacabado (inventário) alimente a iteração seguinte, diminuindo a capacidade de geração de valor da equipe?
- Como encaixar o meu processo dentro do modelo de gestão do Scrum, de forma a criar condições para uma implantação mais suave e sustentável a longo prazo?

Acho que o KSE pode ter boas respostas para essas perguntas.

[]s,
Alisson Vale

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT