Roteiro Ágil para Desenvolvimento Java/Web na Serpro

Roteiro Ágil
Java/Web
Integrando princípios
ágeis para a melhoria
do desenvolvimento
em grandes empresas

Palestrante: Fábio Rilston 28/03/2009

Maré de Agilidade Bahia 2009 – Case Serpro

A Empresa Serpro

 Maior empresa pública de TI da América Latina
 Mais de 3.500 desenvolvedores
 Presente nas áreas de Desenvolvimento, Comunicação
e Tecnologia da Informação
 Cases de Sucesso: Receita-Net, SIAFI, SISCOMEX,
Renavam, SIAPE, CPF, dentre outros
 Alguns clientes Serpro

Secretaria do
Tesouro
Nacional


Contexto

 O Serpro possui um processo de software (PSDS)
executado por todos os desenvolvedores
 O PSDS é baseado em referenciais de mercado como o
CMMI®, Rational Unified Process® e USDP
 O Serpro é uma empresa Nível 2 do CMMI e, em
algumas unidades, busca aderência ao seu Nível 3
 O PSDS mudou o panorama de gestão e engenharia do
produto, trazendo maior maturidade para os ciclos de
gestão e produção


Contexto

Contudo…
… Algumas categorias de projeto possuem peculiaridades
que requerem tratamento diferenciado (ex. Web, DW,
Portais Web, Projetos Sumários, etc.)

… O PSDS não consegue atender a todas as necessidades
específicas de desenvolvimento das unidades

… O foco em resultados (produtividade) precisa ser
reforçado

… Algumas atividades do PSDS são complexas se
analisadas no contexto de um projeto


Solução Idealizada

Assim, a solução ideal DEVE…
… disponibilizar guias específicos para cada categoria de
projeto e para contextos diferenciados.

… garantir uma linguagem comum de comunicação entre
desenvolvedores e estabeleça padrões mínimos de
qualidade em temas específicos

… agilizar a utilização do processo, tornando-o mais
flexível em termos de controle e evidenciação (menos
burocrático)

… ser capaz de apoiar a gestão e execução de projetos,
considerando a diversidade de clientes e plataformas
existentes no Serpro


Trabalhando com ROTEIROS

O desenvolvedor vê e
executa apenas atividades
da categoria e contexto do
seu projeto


Modelos de
Referencial
referência e CMMI, Catedral, Bazar, Manifesto ágil...
paradigmas
teórico

Modelo de
Processo Unificado, Ciclos de Vida,...
Processo
Exemplos
RUP, XP, Scrum, Open UP, Test Driven Process
de Processo
Negócio
Cultura,

PSDS
Processo
Padrão
(ativos)
Base Histórica
Adaptação Reuso
Modelo de Ciclo
Tecnologia
de Vida, Critérios
Critérios de adaptação Características gerais
de Adaptação,
Tecnologia.
Métodos de Trabalho

Equipe
Cliente...

Roteiros
Manutenções
Iterativo Componentes Cascata ...
Sumárias
Roteiro
Sub-Processos Ágil
(adaptados) Java-Web
1 2 3
laridades

Sub-Processo
Projeto 1 Projeto 2 Projeto 3 Projeto ...
Particu

(instanciado
ou definido
para o projeto)

Estrutura de um Roteiro


Métodos Ágeis e o Desenvolvimento JAVA

Equipes de desenvolvimento em JAVA necessitam de
um processo que…

… seja mais adequado ao ciclo iterativo com entregas
parciais

… dê suporte ao atendimento rápido de demandas, com o
mínimo de Engenharia e Gestão necessários

… seja mais flexível em termos de controle e evidenciação

… permita uma passagem mais tranquila para o
desenvolvedor dos requisitos para a implementação


Métodos Ágeis e o Desenvolvimento JAVA

Então, queremos uma solução que…
… privilegie ciclos de vida iterativos com entregas curtas
e úteis

… assegure a disponibilidade e o compatilhamento de
informações, dando visibilidade a todos os
interessados nos diversos níveis organizacionais

… melhore o suporte arquitetural

… tenha um foco maior em validação do produto gerado,
otimizando sua qualidade

… aumente a produtividade do desenvolvimento


Embate de Gigantes

Ágil, Ágil, Ágil !! Modelos, Processo,
Planejamento detalhado!!
[Agile-Driven Team]
[Plan-Driven Team]


Solução Adotada (Bohem)

Plan-Driven Agile
Approaches Methods

Win-Win
Solution


Métodos Ágeis de Referência

OpenUP
=
+

XP Scrum Roteiro
JAVA/WEB


Estrutura de Melhoria do PSDS

Malheiros, V.; Paim, F.; Mendonça, M. Continuous Process Improvement at a Large Software
Organization. Software Process Improvement and Practice, 13, 1-16, 2008


Fórmula do Crescimento

100kg Sponsor
100mg Trabalho Cooperativo
200mg Teoria Ágil
50mg Envolvimento de GEs
1 Evento de Fechamento das
Idéias
10mg Páginas HTML

Leva-se ao forno por 2 meses e
apresenta-se em forma de site.
Deixar descansar em Projetos
Pilotos.


Práticas Ágeis no Serpro

Expectativa com a adoção de princípios ágeis
 Agilização do ciclo de desenvolvimento
 Menor time-to-market (múltiplas entregas)
 Melhor admin. da complexidade (ciclo iterativo)
 Maior visibilidade do projeto para o cliente
 Maior envolvimento da equipe (Whole Team).
 Menor burocracia: o que pode simplificar no
PSDS?
 Cuidado com a arquitetura, adoção de padrões
para minimizar riscos.
 Maior aderência ao ciclo de projetos JAVA.

Quando Utilizar Ágil ?

Fatores de Risco a um Projeto Ágil
 Equipes grandes e distribuídas.
 Cliente indisponível.
 Arquitetura do projeto não claramente definida.
 Equipe do projeto não experiente na plataforma.
 Integração com muitos sistemas


Práticas Ágeis Pré-selecionadas

Desenvolvimento Incremental
Integração Contínua
Planning Game
Simplicidade de Projeto
XP
Testes de Aceitação pelo Cliente



Backlog de Produto
Backlog do Sprint
Daily Scrum (≅ Stand-Up Meetings)
Scrum
Planning Poker



Desenvolvimento Iterativo e
Incremental
Micro-incremento
Integração Contínua
OpenUP Foco na Arquitetura ANTES
Balanceamento entre Prioridades


Ciclo de Vida Ágil no Serpro


Práticas Ágeis Adaptadas

Desenvolvimento Iterativo e Incremental
 O projeto é dividido em Releases de 2 ou 3 meses.
 Releases são divididas em Iterações de 2 ou 3 semanas.
 Iterações são planejadas em tarefas de 1 ou 2 dias.



Planning Game
 Planejamento de um release
 O cliente descreve o trabalho a ser feito. Os
desenvolvedores então traduzem esse interesse em
uma especificação de requisitos de nível inicial.
 O cliente prioriza as funcionalidades identificadas.
 O cliente escolhe as funcionalidades que serão
executadas no próximo release com base nas
estimativas realizadas e no tempo disponível,
compondo um Plano de Release.



Planning Game
 Planejamento de cada iteração
 A equipe decompõe cada estória em tarefas de
engenharia, estima cada tarefa e faz um ‘sanity check’
para garantir que todas as tarefas ‘cabem’ no tempo
disponível, com base em seu desempenho anterior.
 Se há tarefas demais, o cliente retira uma ou mais
funcionalidades do escopo
 Se há tarefas de menos, o LP pode resgatar
funcionalidades seguintes



Planning Poker



Planning Poker
 As cartas estão disponíveis no site do Roteiro.
 Os times recebem consultoria da área de processo para
executarem as sessões.
 A equipe é envolvida num grau antes não praticado.
 Discrepâncias entre estimativas são discutidas para
chegar-se a um termo comum na equipe.
 A calibragem da estimativa evolui com a sucessão de
jogadas. Equipe desenvolve um senso crítico comum
sobre a complexidade de tarefas.


Exemplo de Planning Poker



Backlog de Produto
 Os objetivos do cliente são geridos por uma planilha
constantemente atualizada.
 A cada iteração, o planejamento é acompanhado em
termos de:
 Custo
 Esforço
 Alocação de Recursos
 Metas de Entrega
 O gráfico de Burning-Down auxilia na análise rápida da
performance da iteração.



Backlog de Produto
 Quando necessário, replanejamentos são realizados
para realocação das atividades.
 O Quadro de Atividades ajuda no acompanhamento da
execução de tarefas. Equipe é motivada pelo
andamento dos Post-it nas colunas.


Exemplo de Quadro de Atividades



Balanceamento entre Prioridades
 A priorização é feita pelo Líder de Projeto, buscando
maximizar os benefícios para o Cliente, considerando
as restrições impostas ao projeto, como:
disponibilidade de recursos e tempo, retorno de testes,
riscos manifestados, restrições tecnológicas, etc.
 Requer o consenso dos envolvidos sobre: o problema a
ser solucionado, as restrições relativas à equipe do
projeto e as restrições relativas à solução
 Trade-off entre benefícios (requisitos) e custo (solução
arquitetural)



Integração Contínua (IC)
 À medida que componentes do produto são testados
com sucesso, estes vão sendo integrados ao conjunto
de ativos previamente gerados da solução.
 Foi criado um Ambiente de integração Contínua (AIC)
em suporte às equipes de desenvolvimento. O AIC é
gerido por uma estrutura escalar de Arquitetos de
Software.
 Plataforma altamente automatizada libera
desenvolvedores para o trabalho mais específico de
design e implementação.



Integração Contínua (IC)
 Ferramentas que integram o AIC:

 
Maven PMD
 
Selenium Cobertura
 
Continuum Jdepend
 
CheckStyle Findbugs
 
Dashboard Ounce Maven
 
Archiva CPD



Stand-up Meetings
 Todos os dias, à mesma hora, o Líder de Projeto tem
uma breve reunião com a equipe. O propósito é eliminar
qualquer impedimento à execução do projeto conforme
planejado.
 Cada participante deve responder a 3 perguntas:
O que você fez desde a última reunião?
O que você fará entre esta e a próxima reunião?
Existe alguma coisa impedindo você de executar o
que foi planejado?



Sprint Review
 Preparo e realização da apresentação do build final de
cada iteração para os Clientes
 Avaliação de resultados
 Feedback dos clientes (perguntas, comentários, sol. de mudança)
 Atualização do Backlog do Produto

 Coleta de lições aprendidas
 Ajustamento do Plano do Release
 Itens incluídos/excluídos/re-estimados, mudanças de prioridade,
mudança na velocidade da equipe



Sprint Retrospective
 Discussão
 Cada membro da equipe é convidado a opinar sobre o que foi bom e o
que foi ruim na aplicação do processo ao projeto
 São coletadas Lições Aprendidas para retroalimentação em próximas
iterações

 Definição do Plano de Ação
 A equipe propõe melhorias e define prioridades
 O LP adiciona as ações de melhoria ao backlog do produto


Experimentando a Agilidade

SIF - Sistema de Informações Fiscais
Unidade Fortaleza-CE

Cliente STN

Equipe 08 pessoas

Duração 18 semanas
Piloto 01
Iterações 6

Situação Finalizado

Acompanhamento CETEC: acompanhamentos quinzenais,
(3 revisões presenciais)


Avaliação

Resultados alcançados:

Processo menos burocrático – redução de artefatos e


informação, sua complexidade e esforço requerido

Time coeso e fortalecido. O conceito Whole team


funciona

Diminuição do tempo de gestão em 56% *


A estrutura do roteiro está clara, acessível e simplifica o


entendimento

* O planejamento de cada piloto durou 3,5 dias. Outros projetos normalmente demandam 8 dias de planejamento


Avaliação

Resultados alcançados:

A equipe se sente integrada ao projeto e co-responsável


pelo seu sucesso

Testes dentro do ambiente são mais robustos => nível


quase zero de erros no produto final

LP tem controle total das atividades do projeto


Cliente satisfeito: “entregas constantes”,


“validações frequentes”,
“atendimento das metas”


Avaliação

Oportunidades de melhoria identificadas:

 Iteração de 1 semana separada para planejamento
(=Iteração Zero) e de 3 semanas para Construção.

 Após algumas iterações, as “stand-up meetings” não
precisam ser diárias. 3 por semana são suficientes.

 Quadro de Atividades (Kanban) é uma boa prática,
pouco burocrático e mantém a equipe motivada.

 Planning poker e uma boa prática de estimativa, maior
comprometimento da equipe e maior precisão nas
estimativas.


Avaliação

Oportunidades de melhoria identificadas:

Melhorar a compatibilidade entre o Framework Serpro e


o ambiente de integração contínua (AIC). Somente
testes de integração usavam a estrutura do AIC.

Ajustar forma de interação dos desenvolvedores com


grupo de arquitetos.

Melhorar descrição de atividades de Gestão de


Configuração.



SGC - Sistema de Gestão de Concursos

Unidade Fortaleza-CE

Cliente ESAF

Equipe 10 pessoas
Piloto 02
Duração 39 semanas (previsão)

Iterações 13 (previsão)

Situação Elaboração (projeto + plano de testes)




O2C - Operações Oficiais de Crédito

Cliente ESAF

Equipe 06 pessoas

Piloto 03

Situação Planejado




Resultados preliminares

 A não interação direta da equipe com o cliente pode
comprometer o uso de uma abordagem ágil

 A gestão de projetos ágil pode ser interessante para
outros projetos, mesmo os que ainda não adotam o
Framework Serpro. Intercâmbio com PSDS.

 O gráfico “burning down” tem se mostrado um efetivo
instrumento de acompanhamento de projetos

 Indícios que o planejamento do projeto pode ser ainda
mais simplificado (planejamento estratégico)

 A antecipação de riscos foi fundamental para o
andamento do projeto


Prêt-à-Porter na Experimentação

RECEITANET - Consulta a Declarações de Contribuintes

Cliente RFB

Equipe 10 pessoas



Situação Planejado
Piloto 04
Acompanhamento CETEC: acompanhamento inicial,

(1 revisão presencial)


Resultados preliminares

 Gestão de Projeto ainda mais simplificada. Artefatos
afetados: Cronograma, Plano de Projeto, GPAG.

 O uso de ferramenta ScrumWorks® pode garantir uma
gestão mais limpa, eficiente e automatizada do projeto.

 Recursos de Documentação em Java auxiliam a reduzir
a carga de trabalho em Requisitos

 Participação de projetistas de teste em especificação da
aplicação reduz o gap entre documentação e Casos de
Teste.

 Expectativa: Liberação do Roteiro Ágil para uso
nacional na release 6.7


Dúvidas ?

Dúvidas ?
Dúvidas ?

Dúvidas ?
fabio-rilston.paim@serpro.gov.br


Roteiro Ágil para Desenvolvimento Java/Web na Serpro

Recommandé

Recommandé

Contenu connexe

Similaire à Roteiro Ágil para Desenvolvimento Java/Web na Serpro

Similaire à Roteiro Ágil para Desenvolvimento Java/Web na Serpro (20)

Plus de Manoel Pimentel Medeiros

Plus de Manoel Pimentel Medeiros (20)

Roteiro Ágil para Desenvolvimento Java/Web na Serpro