BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

O membro "Do Not Disturb"

| por Vikas Hazrati Seguir 0 Seguidores , traduzido por Pedro Mariano Seguir 0 Seguidores em 10 mar 2010. Tempo estimado de leitura: 4 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

Diversos desenvolvedores gostam de trabalhar isoladamente, por algum tempo, senão sempre. O XP recomenda uma organização da área de trabalho chamada "Caves and Commons" (cavernas e comuns). Áreas comuns servem para maximizar a comunicação. Cavernas servem para facilitar o isolamento para determinadas atividades como verificar email pessoal, chamada de telefones ou um rápido estudo. Contudo, podem existir situações onde vários membros do time ou um em particular deseja se isolar de uma forma exagerada.

Jacob mencionou uma situação no Grupo de Desenvolvimento Scrum onde, durante as retrospectivas, um membro do time quis  que houvesse um tempo de isolamento, no estilo "Do not Disturb" (não perturbe), durante o sprint. De acordo com o desenvolvedor, ele estava sendo interrompido tantas vezes que sua produtividade não estava boa. Ele sugeriu que houvesse um período de 2 horas por dia de isolamento. Durante esse tempo ele não falaria com o time. De acordo com Jacob, o time achou isso um ato anti-agile e um detrimento a comunicação. Esse membro do time é um engenheiro sênior e Scrum Master sem contar que ele é um dos sócios da empresa.

Alan Dayley sugere que interrupções são dependentes do tipo. De acordo com Alan,

Se a interrupção estiver totalmente relacionada com o que ele está atualmente fazendo? Bem, então esse tipo de interrupção será bem vinda! E se duas ou mais pessoas, senão o time inteiro estiver trabalhando na mesma coisa? Então essas interrupções não serão bem interrupções, elas serão o trabalho em si, o que deveria ser feito!

Kurt Hausler apoia o desenvolvedor quando ele diz que alguns desenvolvedores precisam de um ambiente isolado e pode não ter nada de errado nisso. Ele menciona que podem existir outras razões do que o óbvio para isso, ele diz:

Se ele está sendo interrompido a cada 15 minutos, mesmo quando o resto do time sabe que isso dificulta o seu trabalho, isso pode ser um indício que as pessoas que estão fazendo o trabalho não são as mesmas pessoas que possuem a informação para realizar o trabalho.

Kurt também mencionou que olhando pelo lado positivo, é muito legal ver a postura do time dado que uma coisa dessas começou a ser discutida na retrospectiva.

Da mesma forma, Elisabeth Shendrickson diz que um cenário desses pode ser um belo treinamento. Elisabeth sugere que podem haver várias causas para isso e a manifestação pode ser apenas um sintoma de uma Sindrome do Herói ou falta de aplicação das Práticas Agile ou visibilidade insuficiente ou colaboração ou mesmo falta de pensar em equipe , falta de incentivos organizacionais, etc. É necessário se aprofundar mais na causa e analisar a mesma.

Roy Morien também comentou que, mais do que apenas "Do Not Disturb" isso parece um problema de multiplos papéis que o desenvolvedor está exercendo.

Johanna Rothman, tem a opinião de que esse desenvolvedor não deve estar no time. De acordo com Johanna,

Tire essa pessoa do time. Ele não está no time de qualquer forma. Deixe ele fazer o que ele deseja em seu canto, não nesse projeto. A velocidade do time condiz ao *time* e não a velocidade pessoal. Se o resto das pessoas precisam discutir, ele precisa discutir com os outros e não trabalhar sozinho. Eu não consigo entender como uma pessoa pode ser, ao mesmo tempo, um bom engenheiro sênior, scrum master e o sócio da empresa. Ele está fazendo escolhas por si mesmo.

Adram Sroka também possui uma visão similar, ele menciona que,

Alguém que não gosta de ser interrompido não deveria ser ScrumMaster. O título de ScrumMaster serve para servir o time. Ele deve estar disponível para o time durante o dia inteiro. Esse é o trabalho dele. Se algo é mais importante então ele não é um ScrumMaster de fato. Sendo assim, deixe ele ser um sênior que ele quer e encontre alguém que poderia servir o time, e ai sim, intitular este como ScrumMaster.

Siddharta Govindaraj, faz uma interessante observação ao sugerir que algumas situações são maduras nas organizações quando você está movendo da visão tradicional para a visão Agil de trabalhar. Ele diz,

*Idealmente*, você queria que o time colaborasse o tempo todo. Mas as vezes você precisa balancear as coisas para que o seu ambiente suporte a transição. A coisa engraçada sobre o cone do silêncio é que ele vai contra vários príncipios agéis. Mas ele pode ser útil em um contexto particular.

Siddharta diz que em seu projeto, ele usa o cone do silêncio uma vez por semana. Esse dia todo mundo trabalho sozinho enquanto os outros 4 dias são colaborativos. Eventualmente com o tempo e a maturidade do time eles perderão a necessidade de utilizar o cone do silêncio.

Deste modo muitos membros da lista ficaram estusiasmados com o conceito de "Do Not Disturb". Entretanto, existem integrantes que acreditam que deve haver um ótimo balancemento entre colaboração e isolamento. O que funciona para os seus times e o que você faria em uma situação como essa?

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens dessa discussão

O membro "Do Not Disturb" by Fernando Cézar

Eu acho que o Scrum Master está na equipe para ser interrompido, seja pela equipe, ou seja pelo PO, ou qualquer outro fator externo. Se tem alguém que pode ser interrompido, é o SM, a equipe tem que ter paz para trabalhar e tocar o projeto.
Se o SM está reclamando de ser interrompido pela própria equipe, ele não está fazendo o seu papel corretamente e não foi bem claro nos objetivos do sprint.
Considero o SM o elo de ligação entre a equipe e o "mundo lá fora".
Esse SM em questão, está acumulando muitas funções e não está conseguindo lidar com isso.
Eu reavaliaria a posição dele na equipe.

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

1 Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT