Fluxo do Processo de Desenvolvimento Ágil
Objetivo do Processo de Desenvolvimento Ágil
O objetivo deste processo é definir atividades, produtos, responsabilidades, ferramentas, métodos e técnicas para apoiar a execução de trabalhos de atendimento de necessidades de desenvolvimento, sustentação e manutenção de sistemas do TJES. Esses trabalhos são originados de demandas cadastradas no sistema Assyst ou priorizadas conforme Processo de Gestão de Demandas.
O processo implementa conceitos de métodos ágeis com Scrum para executar trabalhos previstos e priorizados, por exemplo, implantar releases de sistemas com funcionalidades novas ou modificadas.
O processo pode também ser adaptado com conceitos de Kanban para executar trabalhos contínuos não previstos, por exemplo, remover bugs de sistemas em produção, tirar dúvidas, etc.
As adaptações possíveis do Processo de Desenvolvimento Ágil estão descritas na Estratégia de Adaptação de Processos.
O processo é composto de três etapas principais: Planejamento, Execução e Acompanhamento do Trabalho.
Planejamento do Trabalho
O planejamento do trabalho de desenvolvimento, sustentação e manutenção de sistemas do TJES é realizado por meio da elaboração de um Product Backlog e Sprint Backlog.
Product Backlog
O Product Backlog é uma lista priorizada de necessidades ou demandas originadas do Assyst.
Os itens colocados no topo da lista do Product Backlog são os mais prioritários para serem atendidos. A priorização de demandas deve ser feita utilizando a técnica de GUT (Gravidade-Urgência-Tendência)
[to-do incluir link para o GUT].
O tamanho ou complexidade de todos os itens de um Product Backlog devem ser estimados utilizando uma ou mais Técnicas de Estimativa.
Recomenda-se ter um Product Backlog único para cada sistema do TJES.
O Product Backlog deve ser mantido pelo Product Owner, isto é, a pessoa com conhecimento no domínio do sistema do TJES e autoridade para aprovar e priorizar demandas de desenvolvimento, sustentação ou manutenção.
O Product Owner deve definir também junto com o Coordenador de Desenvolvimento, as Releases ou marcos de liberação de versões do sistema de acordo com as necessidades identificadas. Por exemplo, demandas de novas funcionalidades mais críticas para serem implantadas devem fazer parte das primeiras releases.
Uma Release pode ser definida também como um conjunto de ações executadas periodicamente com um objetivo comum, por exemplo, executar ações de processamento mensal de folha de pagamento.
As necessidades e as Releases devem ser registradas no Plano da Operação. Este plano é desenvolvido e mantido pelo Coordenador de Desenvolvimento junto com o Product Owner. Opcionalmente, podem participar do planejamento das releases, o Scrum Master e o Time.
O Plano de Operação inclui também a identificação e análise de potenciais riscos da operação, bem como o planejamento de ações para tratamento dos riscos de acordo com a Estratégia de Gerência de Riscos.
O Plano de Operação também deve incluir a identificação das métricas de acompanhamento dos trabalhos de acordo com o Plano de Medição.
No fluxo do processo de desenvolvimento ágil, e elaboração do Plano da Operação é realizada na atividade Manter Plano da Operação. A definição do Product Backlog e o planejamento das Releases são realizados na atividade Release planning.
Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product Backlog pelo Product Owner para serem executados em um período entre 1 e 4 semanas também chamado de Sprint.
Os itens ou demandas que compõem uma Sprint Backlog devem ser especificados pelo Analista de Negócio por meio da elaboração da especificação funcional e não funcional de requisitos de software capazes de atender a demanda contendo pelo menos uma descrição da História de Usuário e os Critérios de Aceitação.
A especificação funcional deve ser avaliada para obter a aprovação por um par do Analista de Negócio responsável pela elaboração da especificação. Caso não seja aprovada, a especificação deve ser ajustada para em seguida ser novamente avaliada até obter aprovação do par do Analista de Negócio.
Após aprovar a especificação funcional, o Product Owner deve priorizar os requisitos ou histórias e planejar pelo menos as próximas 4 sprints para implementação desses requisitos. Os critérios de prontidão (definition of done) devem ser definidos e acordados pelo Time, bem como o tamanho das histórias devem ser pontuadas.
O Product Owner pode a qualquer momento refinar a demanda ou mudar a prioridade de uma história.
O Sprint Backlog é opcional para trabalhos não previstos, como remoção de bugs de sistemas. Neste caso, as demandas do Product Backlog podem ser incluídas diretamente na lista do que fazer (To Do) para atendimento imediato pelo Time.
No fluxo do processo de desenvolvimento ágil, a especificação da demanda é realizada na atividade Elaborar especificação funcional dos requisitos funcionais e não funcionais. A aprovação da especificação é realizada na atividade Aprovar especificação funcional e a definição do Sprint Backlog é realizada na atividade Sprint planning. Mudanças no detalhamento ou prioridade de uma história são realizadas na atividade Backlog grooming.
Execução do Trabalho
A execução do trabalho de desenvolvimento, sustentação e manutenção de sistemas do TJES é realizado por meio do planejamento das tarefas necessárias para executar o trabalho, bem como da execução dessas tarefas e validação das tarefas executadas.
Planejamento das Tarefas (To Do)
O planejamento das tarefas ou definição da lista do que fazer (To Do) para o Time atender uma demanda é realizado por meio do detalhamento das histórias da Sprint Backlog em tarefas menores possíveis de serem executadas em no máximo 1 dia de trabalho, preferencialmente.
O esforço em horas para execução das tarefas deve ser estimado e registrado na tarefa.
A definição das tarefas e estimativa do esforço são realizados pelo Time junto com o Scrum Master.
Um quadro de tarefas e gráfico de burndown deve ser construído pelo Time junto com o Scrum Master.
O planejamento das tarefas é opcional para trabalhos não previstos, por exemplo, chamados que requerem pequenas modificações no banco de dados, dúvidas ou criação de scripts de consulta. Neste caso, os trabalhos incluídos diretamente na lista do que fazer (To Do) devem ser analisados pelo Time para estimar o esforço necessário para executar o trabalho e definir uma data de entrega do trabalho. Caso seja necessário realizar um desenvolvimento como parte da execução do trabalho, deve-se criar uma Demanda e o trabalho é encerrado. Caso contrário o trabalho segue para execução.
No fluxo do processo de desenvolvimento ágil, o planejamento das tarefas é realizado na atividade Sprint Planning 2. Já a análise de demandas não previstas é realizada na atividade Analisar chamado.
Execução das Tarefas (Doing)
As tarefas de especificação técnica dos requisitos funcionais e não funcionais são executadas pelo Time.
O Time também elabora ou atualiza a estratégia de integração, verificação & validação do sistema.
A especificação técnica e a estratégia de integração, verificação & validação devem ser avaliadas para obter a aprovação por um par do Time responsável pela elaboração da especificação e estratégia. Caso não seja aprovada, a especificação e/ou estratégia devem ser ajustadas para em seguida serem novamente avaliadas até obter aprovação do par do Time.
Após aprovar a especificação técnica e a estratégia de integração, verificação & validação, o Time deve executar as tarefas de codificação, testes unitários e integração.
Para cada requisito, o Time deve avaliar a cobertura dos critérios de prontidão. Estes critérios são definidos e mantidos pelo Time.
Para trabalhos não previstos, a demanda é executada pelo Time.
No fluxo do processo de desenvolvimento ágil, a elaboração da especificação técnica e estratégia de integração, verificação & validação são, respectivamente, realizadas nas atividades Elaborar especificação técnica dos requisitos funcionais e não funcionais, e Elaborar / Atualizar Estratégia de Integração, Verificação & Validação. A aprovação da especificação técnica e estratégia de integração, verificação & validação é realizada na atividade Aprovar Especificação Técnica e Estratégia de Integração, Verificação & Validação. A execução das tarefas de codificação, testes unitários e integração é realizada na atividade Codificar, Testar e Integrar.
A execução de um trabalho não previsto (chamado) é realizada na atividade Executar chamado.
Validação das Tarefas (Done)
Quando todas as tarefas de codificação e testes unitários de uma história tiverem sido executadas pelo Time, o Product Owner deverá validar o atendimento da história verificando a cobertura dos critérios de aceitação da história.
Caso um ou mais critérios de aceitação não estejam cobertos, então o Product Owner deve registrar um comentário na história indicando os critérios de aceitação não cobertos. Em seguida, as tarefas de codificação e testes unitários devem ser reexecutadas pelo Time.
Trabalhos não previstos (chamados) são resolvidos pelo Time e validados pelo usuário através do Service Desk.
No fluxo do processo de desenvolvimento ágil, a validação das histórias é realizada na atividade Validar história com base nos critérios de aceitação. A resolução e validação de trabalhos não previstos são realizadas na atividade Resolver chamado.
Acompanhamento do Trabalho
O acompanhamento do trabalho é realizado por meio de acompanhamento diário e acompanhamento em marcos realizado ao final da Sprint (revisão da Sprint e análise retrospectiva).
Acompanhamento Diário (Daily Meeting)
O acompanhamento diário (daily meeting) tem como objetivo avaliar o progresso do trabalho por meio de reuniões de no máximo 15 minutos envolvendo o Time e o Scrum Master. Opcionalmente, o Product Owner pode também participar da reunião diária de acompanhamento do trabalho. Neste acompanhamento, cada membro do Time reporta o que foi executado no dia anterior, o que vai ser executado no dia e os impedimentos ou interrupções para finalizar as tarefas. Esses impedimentos ou interrupções são discutidos e novas tarefas são criadas e estimadas para resolver o impedimento. O gráfico de burndown também deve ser atualizado no acompanhamento diário.
Revisão da Sprint (Sprint Review)
Primeiramente é realizada a revisão da Sprint no qual o Time e o Scrum Master se reúnem com o Product Owner para apresentar as histórias desenvolvidas na Sprint. Opcionalmente, o cliente/keyuser podem também participar da revisão da Sprint. Na revisão da Sprint, é recomendado que o Product Owner valide se as histórias estão passando nos critérios de aceitação. O foco da revisão da Sprint é no produto entregue.
Análise Retrospectiva (Retrospective Review)
Depois da revisão da Sprint, é realizada a análise retrospectiva da Sprint, onde o foco é identificar melhorias no processo. O Time deve se reunir junto com o Scrum Master para identificar o que foi bom, o que não foi tão bom, quais melhorias podem ser feitas já para a próxima Sprint e quais devem entrar no Backlog do Projeto de Melhoria. Opcionalmente, o Product Owner pode também participar da análise retrospectiva da Sprint.
Reporte Mensal da Operação
Mensalmente, um Relatório de Monitoração da Operação com a situação dos trabalhos planejados e executados no período é elaborado e disponibilizado para todos os envolvidos pelo Coordenador de Desenvolvimento.
No fluxo do processo de desenvolvimento ágil, o acompanhamento diário é realizado na atividade Daily meeting. A revisão da Sprint é realizada na atividade Sprint Review. A análise retrospectiva da Sprint é realizada na atividade Sprint Retrospective. E a elaboração do relatório da operação é realizada na atividade Elaborar Relatório da Operação.
Reporte Mensal da Auditoria de Qualidade
Mensalmente, um Relatório de Auditoria de Qualidade [incluir link] é elaborado pelo Analista de Qualidade, contendo o resultado da avaliação dos processos e produtos executados no período com relação à aderência aos padrões e procedimentos definidos. O Analista de Qualidade deve disponibilizar o relatório finalizado para todos os envolvidos comunicando-os dos problemas encontrados.
O Analista de Qualidade deve cadastrar cada um dos problemas de qualidade encontrados como tarefas no quadro do Trello de cada equipe com prazo máximo de 5 (cinco) dias para resolução. Caso a tarefa não seja resolvida no prazo, o Analista de Qualidade deve escalar a tarefa para o Coordenador de Desenvolvimento apoiar a resolução do problema no prazo máximo de 5 (cinco) dias. Caso a tarefa não seja resolvida no prazo, o Analista de Qualidade deve novamente escalar a tarefa para o Diretor de Desenvolvimento apoiar a resolução do problema no prazo máximo de 5 (cinco) dias.
Reporte de Análise de Causa e Resolução
Mensalmente, um Relatório de Análise de Causa e Resolução [incluir link] é elaborado pelo Scrum Master, contendo a análise de causa-raiz de resultados selecionados de demandas. Por exemplo, pode-se elaborar um Gráfico de Pareto para ajudar a selecionar os tipos de defeitos, falhas ou não-conformidades que representam a maior parte dos problemas identificados nas demandas. Para cada resultado selecionado, deve ser analisada a causa-raiz usando métodos como Gráfico de Ishiwawa ou Espinha de Peixe, bem como devem ser definidas ações para tratar essas causas, evitando a ocorrência dos problemas em novas demandas. O reporte deve incluir também uma análise da efetividade da execução de ações passadas para tratar a causa-raiz de resultados selecionados em demandas anteriores. Caso as ações tenham sido efetivas, deve-se cadastrar uma tarefa de melhoria no quadro do Trello do Projeto de Melhoria para garantir que os problemas não voltem a ocorrer em demandas futuras.
Orientações para Implementação do Fluxo de Desenvolvimento Ágil
Criando um Quadro de Tarefas
O quadro de tarefas contem as listas de tarefas de trabalho do Time. É recomendado que sejam criadas as seguintes listas: lista de histórias do Product Backlog, lista de histórias selecionadas do Sprint Backlog, a lista de tarefas planejadas para fazer (To Do), a lista de tarefas em execução (Doing) e a lista de tarefas concluídas (Done).
Para demandas não previstas, devem ser criadas listas separadas de tarefas para fazer (To Do), tarefas em execução (Doing) e tarefas concluídas (Done). É recomendado que essas listas sejam criadas em um quadro de tarefas diferente do quadro de tarefas de Sprint.
A figura abaixo mostra exemplo de listas e tarefas.
Construindo e Atualizando um Gráfico de Burndown
No eixo Y deve ser informado o total de tarefas ou o total do esforço em horas para execução das tarefas planejadas para todas as histórias da Sprint. No eixo X, devem ser informados os dias úteis até a data de finalização da Sprint. Uma linha reta descendente deve ser criada ligando o total de esforço no dia 1 com o valor de esforço zero no último dia da Sprint.
Nas reuniões de acompanhamento de progresso, as estimativas de esforço em horas das tarefas planejadas para todas as histórias da Sprint são revistas e o gráfico de burndown é atualizado desenhando uma linha relacionando o esforço necessário para concluir a Sprint e o dia da atualização. Dessa forma é possível avaliar continuamente a capacidade de finalizar todas as histórias da Sprint no prazo.
A figura abaixo mostra um exemplo de gráfico de burndown.
Construindo e Atualizando um Gráfico de Burnup
No eixo Y deve ser informado o total de tarefas planejadas para todas as histórias da release atual. No eixo X, devem ser informados os dias úteis até a data da liberação da Release.
Primeiramente, deve ser criada uma série com o total de tarefas que faz parte do escopo da release. Essa série deve ser atualizada diariamente como forma de acompanhar a evolução do escopo da release.
Em seguida, deve ser criada uma outra série com o total de tarefas executadas até o dia da atualização do gráfico.
Nas reuniões de acompanhamento de progresso, o total de tarefas do escopo da release, bem como o total de tarefas executadas até o dia da reunião de acompanhamento são contabilizados e o gráfico de burnup é atualizado. Dessa forma é possível avaliar continuamente a capacidade de finalizar todas as histórias da release no prazo.
A figura abaixo mostra um exemplo de gráfico de burnup.
Planejando a Operação
O Plano da Operação deve conter as informações do escopo da operação (serviços de desenvolvimento, sustentação e manutenção realizados pelas equipes de desenvolvimento), bem como a definição da estrutura das equipes, papéis e responsabilidades de cada pessoa (Time, Scrum Master e Product Owner), além da identificação dos responsáveis por cada sistema (cliente/keyuser).
O Plano da Operação deve conter também o planejamento de Releases de cada sistema incluindo a identificação das necessidades de cliente para cada release (proposição de valor), bem como o planejamento das Sprints (data de início e fim da Sprint, estimativa da capacidade de esforço em horas do Time).
O Plano da Operação deve ser continuamente atualizado com o planejamento de novas Releases e Sprints, bem como devem ser atualizadas as informações das Sprints concluídas e Releases entregues.
Elaborando o Relatório da Operação
O Relatório da Operação deve conter a situação de todas as tarefas em andamento e realizadas no período.
Devem ser informados no Relatório da Operação, os dados de métricas coletadas de acordo com o Plano de Medição, incluindo a quantidade de tarefas não iniciadas, quantidade de tarefas em andamento, quantidade de tarefas realizadas, gráfico de burnup e diagrama de fluxo acumulado das Releases, reaction time, cycle time e lead time.
Outras informações relevantes para incluir no Relatório da Operação são a situação dos riscos da operação, incluindo a efetividade da execução das ações de mitigação e contingenciamento de riscos segundo a Estratégia de Gerência de Riscos.
Descrevendo uma História de Usuário e Critérios de Aceitação
História de usuário é uma forma simples de escrever requisitos funcionais e não-funcionais de software.
A descrição de uma história de usuário deve conter informações sobre para quem, o que e por que a história está sendo criada.
Um exemplo de história de usuário é “Como um cliente, preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar, com o objetivo de facilitar os pagamentos.”