Scrum Gathering: Scrum para Desenvolvimento Interno e para Produtos de Software

Antes de mais nada, confiram o relato do próprio palestrante aqui.

Quando cheguei na palestra o Rodrigo já havia começado, mas acredito que ainda peguei a palestra no começo.

Fez um panorama do Agile hoje, que conta com:

• TDD – Test-Driven Development
• Design e arquitetura emergente: somente uma parte dos desenvolvedores sabem desenvolver de forma emergente.
• Documentação forte e executável
• Ajuda de muitas ferramentas

Discutiu-se sobre a fama que os métodos ágeis, em especial o XP, que eles são contra a documentação. Ele lembrou que na verdade é o contrário. Nos métodos ágeis a documentação é tão rígida, tão formal, que até o compilador entende. Ele diz isto porque temos todo o sistema documentado em testes unitários.

Tipos de Empresas de software

Ele classificou as empresas de softwares em 3 tipos:

• Tipo 1: Que fazem software para fora.
• Tipo 2: Que fazem para elas mesma, ou que estão alocadas no cliente para quem trabalham.
• Tipo 3: Desenvolve produto para o mercado.

Ele utilizou esta classificação para falar dos problemas em cada um dos tipos. Aonde você se enquadra?

Papéis do Scrum

Antes de continuar, conceituou os papéis do Scrum.

Que papéis precisamos para fazer software?

• Desenvolvedores
• Um cara de negócio, um cliente

E no Scrum, o que temos?

• Product Owner: Quer produto funcionando, quer resultado. E de preferência, da maneira mais fácil e rápida.
• Time: Quer o melhor ambiente possível para trabalhar e quer entregar o projeto com qualidade.

Os interesses do Product Owner e do Time são, por definição, conflitantes. A única coisa em comum entre eles é o fato de querer entregar o projeto.

O Scrum Master lidera tanto o time quanto oP.O.(Product Owner). Ele auxilia e freia o P.O. Ele tem que balancear este conflito de interesses. O time vai querer gastar mais e fazer menos e o PO ao contrário. Tem que chegar no melhor para o projeto, sem tomar partido de ninguém.

Falando no PO, se não acharmos um bom PO, o projeto corre riscos. O PO é orientado a ROI (Retorno de Investimento). Ele só pensa nisso! Afinal, o software tem que trazer dinheiro para o bolso de alguém.

O PO faz um meio campo entre o time e os stakeholders. É alguém capaz de controlar a demanda. E o PO é importante, porque a pior coisa é colocar desenvolvedor para resolver ROI.

Um bom PO é formado depois de ser responsável por pagar a conta. Ele quer ver aonde foi o dinheiro. E o PO precisa por dinheiro no bolso de alguém. Ao fim de uma sprint, temos que mostrar aonde foi gasto o dinheiro. Para maiores informações sobre o PO, leia este artigo do palestrante.

Feita esta excelente conceituação sobre os papéis, vamos aos tipos de empresas e o scrum:

Tipo 1 – Fábricas de software e o Scrum

Muita dificuldade nestes ambientes:

• A forma de contrataão normalmente é de escopo fechado.
• O ambiente, os clientes, não buscam o contrato aberto.

É difícil achar um PO:

• O Cliente vai lá, compra e esquece do sistema até que tenha chego prazo para entrega. Só vê ao final do projeto.

É um modelo em declínio, afinal, o cliente está insatisfeito. Este modelo tem sido substituído pelo Body Shop. Lá fora existem fábricas de software ágeis, como a famosa ThoughtWorks. Aqui temos a CI & T e o pessoal da OnCast, de Florianópolis.

Tipo 2 – Empresas com desenvolvimento interno ou body shops

É mais fácil:

• é mais fácil achar um PO.
• aceitam o escopo negociável
• estão melhorando suas arquitetura e práticas de engenharia

Problemas para o desenvolvimento interno:

• PO não está envolvido e o dinheiro não sai do bolso dele.
• Muitas vezes o projeto vai indo, sem o devido cuidado.

Tipo 3 – Desenvolve Produto para o Mercado

É muito fácil implementar neste ambiente. Estruturas simples, enxutas e orientadas a resultados.

• O PO adora este papel.
• Equipes menores e mais unidas.
• Muitos já são iterativos.
• Busca boas práticas de engenharia e arquitetura.

Problemas ISVs:

• O desenvolvimento é mais complexo.
• Carregam um legado pesado.
• Não possuem boas arquiteturas.
• Ainda há muito em melhorar nas práticas de engenharia.

Conclusão do Palestrante

Se você quer ser agile, terá que ir para os tipos 2 ou 3. No 1, no momento atual, é muito difícil. Você precisa ter boas práticas de engenharia, pense em teste e automação. Desta forma, você estará apto a dsenvolver e implantar as mudanças de forma ágil.

Cuidados com o Scrum

Tenha cuidado com seu ambiente:

• Pense na definição de pronto
• Tem testes automatizados? E/ou um especialista olhando o código? Tem uma clara documentação?
• O que você faz com os resultados de suas perspectivas?

Lembre-se do que disse Ken Schwabber: “O Scrum é tua sogra: É bom para dar visibilidade, afinal ele joga o problema na sua cara o tempo todo.”

Se você faz um sprint de 1 mês e não entrega nada funcionando, tem algum problema:

• Pessoal não qualificado.
• Arquitetura fraca ou não é flexível.
• Falhas ao atacar os riscos.
• Falta de fluídez no ciclo de desenvolvimento.
• Problemas de infra-estrutura.
• Equipe desmotivada.

O Scrum não resolve nada, o seu sucesso estará na forma como irá resolver os problemas. Por exemplo, se um projeto tem práticas ruins de engenharia, deve ser detectado e corrigido após a retrospectiva. Se não corrigirmos, temos uma falha do time.

Scrum funciona bem como a porta de entrada no mundo ágil. o fim seria tudo casado com as práticas de XP.

Voltar para o resumo do primeiro dia

Tags: Eventos, product owner, Scrum, scrum master, time