Improvecasts 
Improvecast 17 - Entrevista com Bruno Siqueira na Série Experiências Ágeis (21/07/2007)
Arquivos: Podcast RSS iTunes
Há pouco mais de um mês eu e minha esposa fomos a uma festa onde encontramos com um velho amigo em comum, Bruno Siqueira. Embora o Bruno, minha esposa e eu tenhamos todos formação na área de TI, nós nos conhecemos em outro contexto completamente diferente: a dança de salão. Então, raramente conversamos com o Bruno sobre Informática. Porém, dessa vez acabamos falando um pouco sobre isso e fiquei sabendo que ele tinha saído, há pouco tempo, de uma empresa que implantou ISO, MPS.BR e CMMI. Hoje em dia ele trabalha com Scrum. Uma mudança significativa que, obviamente, merecia ser discutida em um novo Improvecast.
Clavius Tales, da Fortes Informática, falou, no último podcast, sobre a experiência de ter passado pelo MPS.BR e depois abandoná-lo em prol do XP. Dessa vez é o Bruno que conta como foi deixar para traz ISO, MPS.BR e CMMI. Atualmente, ele trabalha com Scrum no Tecgraf, Grupo de Tecnologia em Computação Gráfica, criado em 1987 em parceria com o Cenpes (Centro de Pesquisas da Petrobras).
Nessa entrevista, Bruno afirma que aprendeu bastante com os modelos de qualidade, mas depois de ter a oportunidade de trabalhar com Scrum, acredita que está obtendo resultados iguais ou superiores ao que tinha antes, porém com maior velocidade e muito menos esforço. Se depender dele, modelos de qualidade, tais como o que ele tinha que usar no passado, permanecerão sendo apenas parte do seu passado.
Esses foram alguns dos assuntos tratados no Improvecast 17:
- Você trabalhou durante alguns anos em uma empresa que passou pela implantação da ISO, MPS.BR nível F e CMMI nível 3. Na sua opinião, o que motivou a empresa a buscar essas certificações?
- Quando você foi trabalhar nessa empresa, qual era o tamanho da equipe de desenvolvimento?
- Qual o perfil das pessoas?
- Que tipo de projeto vocês estavam fazendo?
- Que plataforma de desenvolvimento era utilizada?
- Qual foi o primeiro modelo adotado?
- Quanto tempo levou a adoção da ISO?
- Qual era a participação dos desenvolvedores no que se referia à ISO?
- O que é o TABA e para que você o utilizava?
- Qual foi o modelo adotado a seguir?
- Quanto tempo levou a adoção do MPS.BR?
- Qual foi a participação dos desenvolvedores durante o processo de implantação do MPS.BR?
- Em que o MPS.BR afetou a vida de vocês?
- Em que o MPS.BR contribuiu para a melhoria da qualidade dos sistemas.
- Como o MPS.BR afetava a motivação dos desenvolvedores?
- Qual a sua visão sobre a avaliação do MPS.BR? O que você observou?
- Depois do MPS.BR, veio o CMMI, certo?
- Quanto tempo durou a implantação?
- O que você identificou de diferente na implantação do CMMI, em relação ao MPS.BR?
- Qual a sua visão sobre a avaliação do CMMI? O que você observou?
- Quais os benefícios, para a empresa, que você identificou com a implantação desses modelos?
- Quais os benefícios, para você, como desenvolvedor?
- Como eram tratadas as mudanças nesses modelos?
- O avaliador tem que ser um exímio desenvolvedor de software para se tornar um avaliador?
- Modelos como o MPS.BR e o CMMI são complexos. Desenvolvimento de software, pela sua natureza, já é uma atividade bastante complexa. É correto tentar atacar essa complexidade intrínseca com mais complexidade?
- Você enxerga alguma situação em que modelos de maturidade como esses sejam realmente válidos?
- Recentemente, Marcos Pereira, desenvolvedor de software do Recife, nos concedeu um depoimento sobre a implantação do MPS.BR na empresa em que trabalha. Entre outras coisas, ele relatou:
- Dezoito meses gastos para obter o nível G.
- Pouca ou nenhuma participação dos desenvolvedores.
- Dezoito meses com grande preocupação com o processo, muito artefato para alimentar o processo, porém na visão dele, pouca contribuição para desenvolver software melhor.
- Outra coisa que ele observou é que quem define o processo não vive as conseqüências dele.
- Além disso, quem tem que seguir o processo, conhece pouco dele, portanto, sente dificuldades em propor melhorias.
- Ele também relatou que houve alta rotatividade dos desenvolvedores durante a implantação do MPS.BR. Ou seja, o MPS.BR, ao menos na empresa dele, não ajudou a reter pessoas.
- Dificuldade e lentidão para incorporar mudanças.
- Ele se queixou de que o processo não era voltado para tratar do aspecto humano do desenvolvimento. Segundo ele, o objetivo era sempre alimentar o processo, ao invés de alavancar o potencial das pessoas.
- Comitê formado por gerentes e pessoas da área de qualidade. Não havia desenvolvedores envolvidos. Pouquíssima participação dos desenvolvedores ao longo da definição do processo.
- Burocracia impele as pessoas a não mudarem de rumo. Então, como atingir qualidade? Na Toyota, por exemplo, qualidade é obtida através de melhoria contínua, ou seja, milhões de pequenas mudanças sendo feitas continuamente. Mas, que incentivos as pessoas têm para mudar em um ambiente considerado burocrático?
- Você também teve essas percepções trabalhando com esses modelos de qualidade?
- Por que você saiu da empresa que usava os modelos de qualidade?
- Agora que você está no Tecgraf, trabalhando com Scrum, quais as principais diferenças?
- Qual o tamanho das iterações?
- Vocês têm feito as reuniões diárias?
- Vocês têm um quadro com post its?
- Então trata-se de uma equipe autogerenciável, certo?
- Lá vocês estão trabalhando com desenvolvimento orientado a testes?
- Como é o processo de integração contínua?
- Na sua opinião, quais são as principais diferenças entre a filosofia por trás do MPS.BR e a das abordagens ágeis?
- O que mudou com a sua ida para o Tecgraf em termos de satisfação pessoal?
- Qual a sua percepção sobre a qualidade do seu trabalho?
- Você voltaria a trabalhar na empresa anterior?
- Você acha que é necessário ter uma avaliação para se produzir software com qualidade?
Arquivos: Podcast RSS iTunes
Comentários (0 até o momento)