4) Ciclo de vida: do modelo cascata ao ciclo de vida associado ao Scrum
Em geral, uma das metas da engenharia de software é definir uma abordagem ou processo. Isto é, definir a maneira como o software será construído, incluindo as boas práticas a serem seguidas durante a construção.
Um processo de engenharia de software tem como objetivo garantir a produção de software de alta qualidade e de acordo com as necessidades de seus usuários finais, com um cronograma e custo previsível.
Normalmente, esse processo é composto por um conjunto de atividades seguindo um modelo de ciclo de vida, bem definidas, com dependências entre si e ordem de execução, responsáveis e artefatos de entrada e saída. É desejável, ainda, que as atividades tenham uma descrição sistemática das tarefas a serem realizadas.
4.1 Modelo cascataO modelo cascata assume a execução sequencial das atividades e, em geral, se mostra adequado apenas para projetos pequenos (por exemplo, envolvendo menos de 200 horas) . Isso porque presume que é possível realizar toda a especificação de uma só vez, validar essa especificação e, então, seguir para a atividade seguinte. Na prática, essa natureza sequencial raramente consegue ser seguida em projetos de médio ou grande porte.
4.2 Modelo incrementalO modelo incremental apresenta uma alternativa ao cascata. No modelo incremental, os requisitos são segmentados em uma série de incrementos. A cada incremento, é produzida uma versão operacional do software. O processo se repete até que um produto completo seja produzido.
A segmentação de requisitos é usualmente planejada a priori. Dessa forma, menor custo e menos tempo são necessários para se entregar a primeira versão. Além disso, os riscos associados ao desenvolvimento são menores, devido ao tamanho reduzido de cada incremento.
O número de solicitações de mudança nos requisitos também pode diminuir, devido ao curto tempo de desenvolvimento dos incrementos.
-
4.3 Modelo evolutivoNo modelo evolutivo, versões parciais são desenvolvidas, atendendo aos requisitos conhecidos inicialmente. A primeira versão é, então, usada para refinar os requisitos para uma segunda versão, e assim por diante. A partir do conhecimento sobre os requisitos, obtido com o uso, continua-se o desenvolvimento, evoluindo o produto. Veja:
Esse ciclo de vida tende a se mostrar adequado quando os requisitos não podem ser completamente especificados de início e o uso do sistema pode aumentar o conhecimento sobre o produto e melhorar os requisitos.No entanto, é preciso ter cuidado na sua aplicação. Além de poder gerar muito retrabalho, os usuários podem não entender a natureza da abordagem e se decepcionar quando os resultados não são satisfatórios.A figura a seguir ilustra a dinâmica do modelo evolutivo. Nela, um pintor faz evoluções recorrentes em uma pintura completa. Note que cada entrega é uma evolução da versão anterior.
4.4 Ciclo de vida associado ao ScrumO ciclo de vida associado ao Scrum é o mais utilizado atualmente. Por essa razão, tendo em vista a formação objetiva e focada no mercado, será o mais detalhado nesta disciplina. De fato, a segunda aula abordará o Scrum em detalhes, descrevendo seus papéis, cerimônias e artefatos. Neste momento, estamos focados em compreender a dinâmica geral do ciclo de vida associado ao Scrum. O Scrum é um framework de gestão ágil que é, ao mesmo tempo, iterativo, incremental e evolutivo.
Uma diferença do ciclo de vida associado ao Scrum é que ele utiliza tempo fixo (sprints), em vez de escopo fixo, para determinar seus incrementos ou evoluções. Cada sprint corresponde a uma iteração que entrega incrementos e/ou evoluções de um software, conforme prioridade planejada para agregar valor ao negócio.
A gestão ágil tem como base o backlog do produto, que pode ser visto como um conjunto de requisitos, mantido e priorizado pelo product owner, responsável por conhecer as necessidades do cliente. O Scrum envolve a entrega de um conjunto fixo de itens do backlog a cada sprint. Os itens do backlog que serão tratados em cada sprint (backlog do sprint) são definidos em uma cerimônia de planejamento do sprint, que é conduzida pelo Scrum master e deve contar com a participação do product owner e da equipe de desenvolvimento, podendo, ainda, envolver outras pessoas interessadas (por exemplo, do lado cliente).
Durante o sprint, ocorrem breves reuniões diárias, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e se há algum impedimento para seguir avançando.
A missão da equipe ágil, como um todo, é produzir a cada sprint um incremento de produto potencialmente entregável. Ao final de um sprint, ocorre a revisão do sprint e a retrospectiva do sprint, cerimônias em que todos os membros da equipe revisam a entrega e refletem sobre o sprint passado.