menu

Entrevista com Ken Schwaber – IT Martini

Por

 

Ken Schwaber

Ken Schwaber, um dos criadores do Scrum, concedeu uma entrevista aberta para a revista digital IT Martini pelo LinkedIn, onde os participantes do grupo poderiam fazer perguntas para ele. Tive a oportunidade de fazer três perguntas.

Esta informação é oferecida por meio do IT Martini.  Toda semana, líderes em tecnologia e suas perpectivas na indústria são publicadas no “IT Martini Weekly”. No momento, dezenas de milhares de profissionais de TI estão conectados com o IT Martini – tanto pela rede quanto em pessoa.

Terreece M. Clarke: Aqui vai a primeira pergunta: Qual é o maior equívoco de compreensão em relação ao Scrum que os profissionais de TI tem?

Ken Schwaber: O maior equívoco é o de que o Scrum resolve os problemas quando tudo o que ele faz é tornar os problemas visíveis, de forma que possam ser tratados. O Scrum tira as pessoas de TI de seus estados de inconsciência elevando-as a um estado de consciência.

Atul Paradkar: Nossas histórias são geralmente funcionais. Por exemplo, criar um campo de formulário no site também requer uma nova coluna no banco de dados para armazenar o valor. As histórias tratariam das validações e regras de negócio. Então, como tratar usabilidade/design e tecnologia (gravar no banco de dados) usando histórias?

Ken Schwaber: Sempre que possível, tenha qualquer requisito não funcional ligado a alguma funcionalidade (mesmo que pequena). A funcionalidade prova que o desenvolvimento funcionou e permite às pessoas verem a tecnologia em ação.

Beth Bleimehl: Estou procurando alguns casos de estudo sobre gerenciamento de projeto/PMO e a adoção de Agile – especialmente Scrum. Com o que o gerenciamento de projeto/PMO se parece depois que a empresa passa a adotar o Scrum? O gerenciamento de projeto/PMO continua a operar como fazia no passado? O que muda?

Ken Schwaber: Não conheço estudos específicos. Contudo, a questão do gerente de projetos tem sido vastamente comentada. O gerente de projetos pode se tornar um  scrum master, um product owner, ou dentro de uma equipe Scrum. O papel de gerente de projetos não é parte do Scrum. O PMO normalmente se transforma para organizar o backlog do produto, tanto para os product owners quanto para as equipes de desenvolvimento. Apesar de não criar itens no backlog do produto (nem priorizá-los ou estimá-los), o backlog de produto tem várias facetas. Estas incluem o software de sistema, fluxos de trabalho, funcionalidades, decomposições e estruturas de negócio. Estas devem ser desenvolvidas e gerenciadas de forma que os product owners possam tomar as melhores decisões sobre qual o próximo item a ser feito.

Raazi Konkader (CSM): Os pontos de função (Cosmic por exemplo) são uma medida de tamanho/esforço valida no Scrum?

Ken Schwaber: Os pontos de função são uma medida de funcionalidade de software tão válidas no Scrum quanto em qualquer outro lugar.

Leonardo Campos: Onde trabalho, cada equipe é responsável por uma série de produtos diferentes. O PO normalmente prioriza histórias de cada um destes produtos em cada Sprint, tornando difícil criar uma meta decente de sprint. O PO simplesmente argumenta que as histórias são a meta (sem um propósito é difícil motivar). O que você pensa sobre este problema e qual você considera ser a melhor abordagem para tratá-lo?

Ken Schwaber: Eu trabalharia com o product owner para agrupar os backlogs dos produtos de forma que eles tratassem um objetivo de negócio ou estivessem na mesma área do software. Mostre para ele quanto seu trabalho seria facilitado, portanto a produtividade é maior, tornando o trabalho mais barato.

Leonardo Campos: O Kanban é projetado para ser muito pouco intrusivo e poder ser aplicado sobre outros frameworks, metodologias etc. Quão compatível você considera ser o Kanban em relação a sua aplicação com Scrum? Você consideraria viável ter uma “meta de sprint” em uma implementação de “Scrum-ban”?

Ken Schwaber: Não implemento Kanban por si só, de forma que não sei a respeito de metas de sprint.
O que eu realmente aprecio é usar o Kanban para ajudar equipes de desenvolvimento a aprender novas práticas, com raias como:
1. Desenvolver testes de aceitação
2. Desenvolver o design de projeto
3. Desenvolver testes automatizados, codificar e documentar
4. Testar de forma integrada para verificar se todos funcionam juntos
5. Corrigir a falhas
e por aí vai

Raazi Konkader (CSM): Quais são alguns indícios de que uma equipe seguindo as práticas, mas sem entender a teoria por trás de métodos ágeis com Scrum, XP ou Kanban? Como tratar isso de forma geral?

Ken Schwaber: A equipe tem um problema e não sabe como melhor tratá-lo. Se você entende a transparência, ajuda as pessoas a atingir o melhor delas, e entende a arte do possível (todas atitudes que vêm do empirismo e Lean), você consegue tomar decisões muito boas. Caso você não as conheça, suas decisões não tem base e são frequentemente contra-produtivas.

Leonardo Campos: Você tem planos para vir ao Brasil nos próximos 12 meses?

Ken Schwaber: Não, não nos próximos 12 meses. Ainda estou me recuperando de toda comida que comi da última vez.

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

2 comments

  1. Anselmo

    As raias mencionadas pelo Ken tem o mesmo objetivo de criar tarefas que deixem claro a criação de testes, documentação, criar design, etc. para cada estória, certo?

    Quanto a meta do Sprint, para o cenário, quanto menor o Sprint mais fácil contornar o problema. Mas convencer o PO a agrupar os backlogs dos produtos, eventualmente priorzando uma história que entrega menos valor que outras “apenas” para permitir uma meta, precisa de muito argumento. O ganho de produtividade compensaria mesmo?

    Abraço

    Posted on abril 19, 2012
    • Leonardo Campos

      As raias mencionadas tem apenas fundo didático, mas entendo que elas devam ser abandonadas assim que o time adote as práticas introduzidas.

      Já em relação à meta, sim um Sprint menor facilitaria, mas em compensação gera um overhead na quebra de histórias para que elas sejam pequenas o suficiente para ocupar o sprint e ao mesmo tempo serem todas terminadas DENTRO do sprint.

      Quanto ao ganho, eu realmente não sei. Penso que não há de fato um estudo por parte dos POs em relação ao Business Value de cada história de forma a possibilidar a avaliar o custo/benefício de se agrupar as histórias.

      Posted on abril 19, 2012

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top