Metodologia de Desenvolvimento de Software - MDS

 

A Metodologia de Desenvolvimento de Softwares (MDS) desenvolvida na Secretaria de Tecnologia da Informação reúne boas práticas ágeis de mercado, em especial Scrum e Kanban, bem como de desenvolvimento e testes de softwares, tais como: Integração, Entrega e Implantação Contínuas, Testes Automatizados e Desenvolvimento Orientado a Testes (TDD). Ela define, de forma clara, responsabilidades, prazos e locais dos envolvidos no desenvolvimento de softwares, de modo que todos saibam como proceder em cada uma das atividades dentro do processo.

 

Para compreender um pouco mais sobre a Metodologia de Desenvolvimento de Softwares, conheça as principais definições empregadas:

Scrum Team: time multifuncional, composto por número suficiente de pessoas com habilidades necessárias e responsabilidades específicas sobre um produto para criar e entregar valor a cada Sprint. Em geral, times menores são mais ágeis, visto que se comunicam melhor e são mais produtivos. Por isso, estabeleceu-se o número mínimo de três Developers no time.

Sprints: o trabalho de desenvolvedores é dividido por iterações que, nesta metodologia, são denominadas Sprints. Possuem duração fixa e pré-definida, proporcionando cadência nos ciclos. O conjunto de atividades necessárias para transformar ideias em valor são agrupadas e, nesse sentido, inspeções e adaptações frequentes ocorrem ao longo do desenvolvimento do produto. Na STI, estabeleceu-se o padrão de duas semanas para duração das sprints.

Developer: membro do time que tem habilidades certas para desenvolver e realizar o projeto – não está associado ao cardo de desenvolver enquanto codificador. É responsável por criar o Sprint Backlog, realizar o trabalho ao longo da Sprint e adaptar o plano diariamente em direção à meta da Sprint.

Product Owner – P.O.: pessoa que detém a autoridade sobre o produto e o domínio das regras e processos de negócio, ou que representa as necessidades dos stakeholders. Colabora com a equipe para garantir e maximizar o retorno sobre o investimento no produto para clientes do projeto. É responsável por: gerenciar o Product Backlog, mantendo-o atualizado e priorizado, desenvolver e comunicar a meta do produto, gerenciar as entregas dos incrementos do produto, criar e comunicar claramente os itens do Product Backlog.

Scrum Master: pessoa que orienta o time na execução do processo levando em consideração os princípios e valores das práticas ágeis. Atua como promotor da eficácia do time, viabilizando que as práticas sejam melhoradas dentro do framework Scrum. Ele é responsável por: proteger a equipe de interferências externas, permitindo que mantenham o foco no desenvolvimento do produto, remover impedimentos ou obstáculos que possam interferir na produtividade da equipe e facilitar a colaboração entre Stakeholders e o time.

Stakeholders: pessoas e/ou organizações que podem ser afetadas pelo projeto direta ou indiretamente, tendo influência sobre determinadas tomadas de decisão ao longo do processo.

Definição de Pronto: descrição formal do estado do incremento quando atende às medidas de qualidade exigidas para o produto. Para que um item de Backlog seja considerado pronto na Secretaria, realizam-se testes unitários em atendimento a critérios específicos.

Iniciativa: o recebimento e o registro da iniciativa marcam o início da execução do desenvolvimento de software. A partir do objetivo traçado, metas menores e intermediárias são fixadas para que o escopo seja melhor entendido e alinhado com o Gestor Negocial, delimitando-se o Product Backlog inicial. Assim, o Scrum Team estipula seu alvo para planejar o trabalho.

Product Backlog: lista priorizada de itens necessários para o desenvolvimento do produto. A atualização dessa lista é de responsabilidade do Product Owner, considerando o valor de negócio de cada item em prol do alcance da meta do produto.

Release Planning: determina os resultados esperados para uma ou mais entregas, atuando como dispositivo de comunicação e mostrando, de forma incremental, como a meta do produto será alcançada.

Sprint Planning: para planejar o trabalho realizado durante a Sprint, o Scrum Team se reúne com o propósito de definir o que pode ser entregue e como, o que é geralmente representado como meta da Sprint.

Sprint Backlog: conjunto de tarefas decompostas dos itens do Product Backlog selecionados que torna visível o que será realizado na Sprint e como o trabalho será realizado em direção à meta estabelecida.

Daily Scrum: evento de 15 minutos, aproximadamente, em que é compartilhado o andamento dos trabalhos, bem como se foram encontrados impedimentos, para inspecionar o progresso em direção à meta da sprint e adaptar o Sprint Backlog de acordo com as necessidades.

Implementação: por meio da utilização do Desenvolvimento Orientado a Testes (TDD), ocorre a codificação das funcionalidades a partir de testes unitários, proporcionando feedbacks mais rápidos e em prol da melhoria da qualidade do produto. Durante a implementação, é possível que haja integração com as Divisões de Administração de Dados e de Engenharia de Software.

Sprint Review: reunião, com duração máxima de duas horas, em que o Scrum Team e as partes interessadas inspecionam os itens desenvolvidos ao longo da Sprint em relação ao atingimento da meta. Como resultado, obtém-se o feedback sobre a demonstração do Incremento do Produto produzido durante a Sprint, de modo a modificar o Product Backlog para Sprints futuras, se necessário.

Quality Assurance: após a Sprint Review, há integração com a Divisão de Qualidade para indicar que o Incremento do Produto criado pela sprint está preparado para a fase de qualidade.

Sprint Retrospective: reunião de retrospectiva, em que o Scrum Team revisa a execução dos processos e ferramentas de modo a planejar maneiras de otimizar a qualidade e a eficácia dos trabalhos.