-
Notifications
You must be signed in to change notification settings - Fork 46
Como melhorar a comunicação da equipe
Se algum membro está contribuindo negativamente para o andamento do projeto, o Scrum Master não tem o poder de puní-lo. Uma boa prática é evidenciar os problemas ocorridos, convencer o membro que sua contribuição poderia ser melhor para o projeto e ser solícito para praticar as mudanças necessárias para uma melhoria na sua postura.
O daily meeting é definido pelo Scrum como o momento diário onde o time conversa sobre o que aconteceu no dia anterior, o que está acontecendo e quais os entraves para o andamento das atividades. É preciso entender que essa definição não pode ser encarada como os 15 minutos destinados à conversação em 8 horas de trabalho diário. O daily meeting não pode ser o único momento onde as pessoas conversam durante um dia de trabalho. Esse momento deve ser encarado como o momento onde toda equipe compartilha o estado atual de um determinado projeto.
Se os problemas forem detectados antes da hora marcada para o daily meeting, é fortemente aconselhável que eles sejam comunicados antes da reunião diária, para que medidas corretivas possam ser imediatamente tomadas. No momento da reunião diária esses problemas, previamente identificados, devem ser apenas tornados público para o restante do time e se já tiverem sido resolvidos, um breve relato da solução deve ser comentado. Uma boa prática que pode ser adotada pelo Scrum Master é, no ínicio de um dia de trabalho, conversar informalmente com cada membro do time na tentativa de identificar se há algum impedimento identificado. Problemas que são imediatamente identificados e tratados, não importando a sua complexidade, não comprometem o bom andamento dos sprints. Eles só passam a ser realmente problemas, quando há um retardo para sua comunicação após terem sido identificados.
No Scrum existe um momento especial para que os acertos sejam evidenciados e os erros sejam discutidos para que possamos tirar boas lições para o futuro. Esse momento é a Retrospectiva de Sprint. As retrospectivas inerentemente favorecem a Comunicação, proporcionando uma maior interação entre os membros do time.
Algumas premissas devem ser consideradas para que o processo de comunicação ocorra de forma natural durante esses momentos. A primeira premissa é que a retrospectiva não é um momento para eleger culpados por eventuais falhas ocorridas. Uma boa prática é evitar citar nomes durante esse momento, seja ao relatar casos de sucesso ou ao relatar problemas. Tudo que aconteceu durante o sprint deve ser responsabilidade do time como um todo, não importando as individualidades de cada integrante.
As equipes ainda veem no ScrumMaster um papel gerencial e tendem a se reportarem diretamente a este papel durante a reunião diária, quando, na verdade, a equipe deveria somente ter foco no que foi feito desde a reunião anterior e no que será feito a seguir, sendo uma cerimônia de sincronização da equipe e para a equipe.
Para evitar esta tendência das equipes:
- Se você é um ScrumMaster, não faça contato visual com quem estiver falando durante a reunião diária. Não manter este contato visual, contribui para que os comentários não sejam status direcionados somente ao Scrum Master.
- O Scrum Master pode faltar ocasionalmente da reunião e deixar um membro da equipe como facilitador ou permitir que a própria equipe se organize;
- Muitas equipes se reúnem em um círculo ou semi-círculo. O Scrum Master poderia se posicionar fora dessa formação; (ajuda a evitar o contato visual)
- O Scrum Master deve posicionar-se como um observador silencioso, informando a equipe que isso é um exercício para lembrá-los de que estão se auto-organizando e que a reunião diária do Scrum é quase que exclusiva da equipe.
EPS/MDS - FGA/UnB
Métodos de Desenvolvimento de Software
Gestão de Portfólio e Projetos de Software
RUP (Rational Unified Process)
Fase Elaboração (RUP) Planejamento(PMBOK)
Fase de Construção (RUP), Execução/Monitoramente e Controle (PMBOK)
Fase Transição (RUP), Finalização (PMBOK)
Acceptance Test Driven Development (ATDD)
Integração Contínua Deploy Contínuo
Automação de Ambiente com Docker
Orquestração de Containers com Docker Compose
Automação de Ambiente com Vagrant
Deploy Contínuo na Plataforma Heroku
Integração Contínua com Travis CI
Disponibilizando a Aplicação com o Proxy Reverso Nginx
Tutorial de Instalação do Ionic
Android Integração contínua com Circle CI
Configuração de Ambiente para React Native
Tutorial Instalação Ruby on Rails
Teste Automatizado Cucumber JS
Teste Automatizado Cucumber Rails
Testando AngularJS com Jasmine
Teste Automatizado com Selenium IDE
Configurar o SonarCloud para um projeto usando Jest
Configurar o SonarCloud para um projeto usando Pytest
Configurar o SonarCloud para um projeto usando Mocha e Istambul