Slides de minha palestra no TDC 2014 São Paulo. Nesta palestra apresentei fatos que visam ajudar pessoas inexperientes na adoção de métodos ágeis e fiz um relato das minhas experiências. Como um time de novatos em métodos ágeis vivencia o processo terceirizado de desenvolvimento de um sistema. A cultura, os erros e os acertos sob a perspectiva de um desenvolvedor e servidor público.

1. A adoção e a adaptação
constantes em um projeto de um
órgão público
@rogerio_gentil

2. Sobre
● Técnico de TI na Secretaria de Informática da
UFSCar
● Desenvolvedor Java Web há 3 anos
● Matemático, desenvolvedor, rockeiro,
guitarrista, vocalista, esportista, palmeirense...
● 'Axpira' a agislista

3. Cenário em 2011
● Universidade com +10.000 alunos matriculados
na graduação
● 3 sistemas para controle acadêmico da
graduação (2 JSP/Servlet + 1 Delphi)
● MVC? DAO? Design Patterns?
● Bugs, problemas de performance, base sem
normatização ...
● Documentação escassa

4. Cenário em 2011
● Parte dos processos não automatizados
● Funcionalidades pendentes e novos requisitos
surgindo
● Miniequipe: 1 analista e 1 técnico de TI

5. Decisão: Terceirização
● Reengenharia dos sistemas existentes (temos
os códigos fonte → extrair regras de negócio)
● Reengenharia = engenharia reversa +
engenharia avante + novos requisitos
● Metodologia de desenvolvimento: SCRUM
● 2 P.O.s: 1 P.O. Técnico + 1 P.O. de Negócio
● Contratação de equipe de no mínimo 4
analistas

6. Decisão: Terceirização
● Licitação → Backlog de funcionalidades pré-
estabelecido para determinar valor ($$$) a ser
licitado
● Pagamentos facultados as entregas
homologadas

7. Resumo dos 1º e 2º Sprints
● Equipe de desenvolvimento remota da
terceirizada
1.Levantamento de requisitos (planning)
2.Desenvolvimento (basicamente de CRUDs) +
migração de dados (spring backlog )
3.Entrega para os stakeholders (review)
● Equipe da Sin + Stakeholders
1.Homologação do entregável

8. Retrospectiva dos 1º e 2º Sprints
● Sprints longos, acúmulo de débitos técnicos e
documentação extensa
● RUP? → hora de mudar:
● Enxugar documentação (“software em
funcionamento mais que documentação
abrangente”)
● Equipe da Sin → assumir tarefas em função do
melhor conhecimento do negócio

9. Resumo dos 3º e 4º Sprints
● Equipe da Sin
1.Levantamento de requisitos antecipado (planning)
2.Migração de dados
● Equipe de desenvolvimento remota da terceirizada
1.Refinamento dos requisitos levantados
2.Desenvolvimento (sprint backlog)
3.Entrega para os stakeholders (review)
● Equipe da Sin + Stakeholders
1.Homologação do entregável

10. Retrospectiva dos 3º e 4º Sprints
● Aumento no acúmulo débitos técnicos e
escassez de documentação
● SCRUP?! → Hora de mudar novamente...
● Aumentar integração entre equipes técnicas

11. Resumo do 5º Sprint
● Equipe da Sin + Analista de Negócios da terceirizada
1.Levantamento e validação de requisitos antecipados com
wireframes (planning)
● Equipe da Sin
1.Migração de dados
● Equipe de desenvolvimento remota da terceirizada
1.Desenvolvimento (sprint backlog)
2.Entrega para a equipe da SIn (review)
● Equipe da Sin + Stakeholders
1.Homologação do entregável

12. Resultado do 5º Sprint
● Boa documentação
● Perceptível falta de comprometimento dos
stakeholders (descrédito do produto)
● Muda de novo:
● Aumentar integração entre equipes técnicas ainda
mais (TV + Skype)
● Preocupação com marketing do projeto

13. O que veio a seguir...
● Problemas com homologação: escassez de
testes automatizados e muitos testes manuais
● Mudanças na equipe técnica e de negócio
● Acréscimo de prazo para término do projeto
● Escopo planejado diferente do escopo a ser
entregue

14. Contudo...
● Aparente redução de bugs na entrega
● Requisitos mais confiáveis

15. Avaliação no momento
● Falha no planejamento:
● da estimativa: empírica, resultado de pouca
experiência com metodologias ágeis + falha no
levantamento das funcionalidades para licitação
● Problemas para alterar funcionalidades já
homologadas (pagas)
● Tendência a “waterfall” nas crises

16. Tentamos (equipe da SIn)
sempre...
“Responder as mudanças mais
que seguir um plano”

17. Tentaram (equipe da terceirizada)
sempre...
“Colaborar com o cliente mais
que negociar contratos”

18. Conclusão
Ainda...
“Estamos descobrindo maneiras
melhores de desenvolver
software”

19. Para Repensar
● Iniciar a adoção com projetos menores (pilotos)
= menor impacto e expectativa → ganhar em
maturidade
● Scrum by the book não foi legal (adequações
são necessárias e não existe bala de prata)
● Comunicação é o pilar para qualquer processo
de desenvolvimento ágil → equipes remotas =
maior comunicação

20. … e repensar ...
● Melhor maneira de licitar: escopo aberto vs
escopo fechado?!
● Levantar requisitos para determinar custo de
licitação mesmo sabendo que os requisitos
serão modificados durante o processo de
desenvolvimento?
● Como estimar custo e prazo sem requisitos?

21. Para encerrar...
Perguntas?