domingo, 29 de abril de 2012

Engenharia de Software para Concursos - Parte 4 - Metodologias Ágeis

Existia a visão predoimante que o desenvolvimento de software deveria ser cuidadosamente planejado. A aplicação de todos os métodos de controle no desenvolvimento de softwares pequenos ou médios causava mais problemas do que solução. O desenvolvimento ficava muito demorado e caro. A insatisfação com o excesso de métodos tradicionais deu origem ao processo de desenvolvimento ágil.

Os métodos ágeis buscam flexibilizar o desenvolvimento de software, diminuir a burocracia, tornar o desenvolvimento mais rápido e permittir respostas rapidas às mudanças, que são o grande fator de falha nos projetos tradicionais.


Focam no código e não no projeto.
São baseados em abordagens iterativas.
Entrega-se o software de qualidade funcionando o mais breve possível.

Manifesto Ágil (2001) - Filosofia de qualquer método ágil
"Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho passamos a entender que:

Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e detalhada.
Colaboração com o cliente é mais importante do que negociação de contratos .
Adaptação a mudanças é mais importante do que seguir o plano incial.

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda."

A comunicação entre as pessoas é muito mais importante do que seguir uma linha de comando, processos burocráticos ou ferramentas específicas. A comunicação entre a equipe e os clientes é fundamental.

Sistemas que sofrem muita pressão por alteração atrasam pela demora em manter a documentação atualizada ou até mesmo para que ela seja criada. Depois de pronta, as vezes já está defasada.

"A verdade está no código"

Existem os processos orientados a planos e os processos de desenvolvimentos orientados ao valor agregado (métodos ágeis são value-driven e não plan-driven). O plano detalhado não funciona quando o sistema sofre muita pressão por mudança, então, não adianta ter um plano detalhado e um contrato todo amarrado. É melhor que exista colaboração mútua entre as partes e que o projeto seja adaptável, já que as mudanças são inevitáveis.

Para o manifesto ágil, detalhes de processos, documentação, contratos e planos e etc são importantes, claro, mas são menos importantes do que os itens colocados em negrito e explicados acima.

Hoje, sabe-se que os métodos ágeis podem ser adaptados e utilizados em projetos de qualquer tamanho, mas quanto maior o projeto, maior serão as adaptações "burocráticas" (itens da direita).

Métodos ágeis não são caóticos, são flexíveis. Existem controles, métricas, regras e etc. O foco é direcionado para as coisas que agregam valor e não para o que é determinado por um contrato ou processo de gerencia. Você pode ter documentação, mas somente sobre o que é importante.

Principais modelos ágeis (são considerados uma família de métodos)

Extreme Programing (XP)
Scrum
FDD
Lean Software Development
Crystal Family

Extreme Programing (XP)
Kent Beck utilizou o XP pela primeira vez para fazer a folha de pagamento da Chrysler e ele disse:

"Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança."

Em grande projetos as equipes costumam crescer e ter a comunicação prejudicada, dessa forma criam-se várias equipes pequenas e médias.

A melhor maneira de esclarecer requisitos vagos é implementando e mostranto ao clinte. A palavra  Extreme, no XP, trás a ideia de levar TODAS as boas práticas ao EXTREMO. NO XP, se algo é bom, deve ser feito sempre.

Práticas do XP

Metáforas
Utilizar uma estória e termos que todos os programadores, clientes e gerentes possam contar para explicar como o sistema funciona. Facilita a comunicação entre os interessados. Conceitos complicados devem ser explicados por analogia utilizando-se metáforas.

Exemplo:  Planejar um projeto XP é como dirigir um carro, a todo momento você corrige o rumo ao volante. É preciso corrigir a rota a todo momento.


Projeto Simples
O código está, a qualquer momento na forma mais simples que passe todos os testes. O programador deve se perguntar: Existe uma forma mais simpels para atender o requisito? Para fazer o código passar no teste? Se não estiver da forma mais simples possível, deve ser feito refactoring.

Pequenas Versões
As entregas são feitas em pequenos releases de software funcionando. A verdade está no código, não existe documentação entregue sem software. Isso dá confiança ao cliente em relação ao progresso do sistema. Tipicamente as iterações são de um mês.

Refactoring
O código deve ser constantemente melhorado tornando-o mais simples e mais genérico, removendo redundâncias e duplicidades. Melhorar a estrutura interna de um código sem alterar o funcionamento externo. Para que o projeto seja simples é necessário refatoração para que haja evolução do projeto, de outra forma, o código ficaria com problemas arquiteturais ou coisas do tipo.

Programação em Pares
Os programadores trabalham em pares e validam o trabalho um do outro. Aqui entra o conceito de REVISÃO AO EXTREMO, a todo momento. Uma máquina, um mouse, um monitor e dois programadores. Assim o código é revisado a todo momento e diversos erros são corrigidos dessa forma.

Propriedade Coletiva do Código
Todos são responsáveis por todo o código e qualquer pessoa está autorizada a alterá-lo. Isso evita as ilhas de conhecimento. O conhecimento fica compartilhado por toda equipe.

Padrão de Codificação
Todo código é gerado seguindo um estilo e formato consistente. É criado um padrão de codificação. A linguagem java já possui muitos padrões, o que facilita. No XP isso é ampliado também aos padrões de projeto e arquitetura.

Ritmo Sustentável
Cada programador trabalha 40 horas por semana, no MÁXIMO. Quando o programador trabalha muitas horas por semana a longo prazo, fica cansado e a qualidade do código é reduzida por causa do cansaço.

Reuniões em Pé
Reuniões rápidas e diárias com a equipe, em pé, para discutir apenas o essencial a respeito do projeto. Os programadores falam sobre os problemas que estão acontecendo e sobre soluções. A recomendação é que as reuniões ocorram sempre no mesmo horário e não passem de 15 minutos. Isso garante que não haverá enrolação.


Cliente Sempre Presente
Um representante do cliente, com conhecimento do negócio, deve estar presente em tempo integral para a equipe do desenvolvimento. O cliente integra a equipe de desenvolvimento.

Desenvolvimento Orientado a Testes (TDD)
Os testes unitários e automatizados são implementados antes mesmo das funcionalidades. Os testes já podem ser escritos a partir do momento em que se conhece os requisitos. Dessa forma, o código é que deve passar no teste. Um teste feito para aprovar um código possui mais chances de ser feito de forma mais relaxada.

Integração Contínua
Os códigos são integrados o mais cedo possível para evitar problemas de integração no futuro. Na prática, a cada commit (envio de código), os testes rodam automaticamente. Isso evita que um código escrito hoje quebre algo que foi feito ontem

Planejamento Incremental
O XP é um método iterativo e incremental. Os requisitos e funcionalidades são registrados como estórias dos usuários e são priorizados para serem incluídos em uma iteração futura. Cada iteração implementa alguns desses requisitos. Você não detalha e especifica tudo antes da hora, detalha apenas o que for escolhido para a próxima iteração.


Valores do XP

Comunicação - valorizar a comunicação criando formas de construir e disseminar conhecimento.
Simplicidade - começar sempre pela solução mais simples que funcione.
Feedback - receber retorno do cliente e da equipe.
Coragem - coragem para aplicar as práticas do XP, como design simples e refatoração. Não são coisas fáceis de fazer e damanda coragem da equipe.
Respeito - entre a equipe e os usuários. Se o membros da equipe não se importam com o projeto nem com os outros membros do time, o XP não vai funcionar.

Desenvolvimento Ágil com SCRUM
Derivado de uma atividade em um jogo de Rugby.

"É um framework de processo dentro do qual podem ser empregados outros processos e técnicas variadas." Em provas de concurso o Scrum é tratado como metodologia ou processo de desenvolvimento e não como framework de processo.

Framework é uma estrutura básica e incompleta por trás de um conceito, algo que precisa ser extendido e adaptado para funcionar em alguma realidade. Metodologia é algo mais prescritivo, diz o que deve ser feito.

Por ser um framwork de processo é possível adicionar papéis, artefatos, atividades e outros tipos de controle de acordo com a necessidade e pode ser aplicado em qualquer contexto em que pessoas trabalhem juntas para atingir um objetivo

É um framework mais gerencial do que técnico, não existe prática de engenharia de software (ESW) propriamente dita descrita no Scrum, por isso, se adqua a qualquer técnica de ESW. Normalmente o é utilizado em conjunto como XP. O Scrum foca no gerenciamento e o XP na parte técnica.

Características do Scrum

As equipes se auto-organizam para melhorar a comunicação e dimunir a supervisão. A equipe escolhe a melhor forma de realizar o trabalho. Isso não é ditado por alguém de fora. Equipes de 5 a 9 pessoas (número cabalistico).

É iterativo e incremental e o produto evolui de uma série de sprints. Uma iteração é chamada de Sprint. Um período delimitado que dura de duas a quatro semanas (outro número cabalístico) para incremento do produto.

Os requisitos são listados em um backlog do produto. É uma lista de funcionalidades. Tudo o que deve ser feito no produto fica listado neste backlog. Para levantar os requisitos, pode ser usada a técnica do XP (estórias do usuário), mas também é possível usar casos de uso ou qualquer outra técnica para que seja determinado o backlog do produto.

O Scrum não define nenhuma prática de engenharia específica. É um framework gerencial que pode ser adaptado a qualquer processo de engenharia de software.


Funcionamento



Tudo começa com o backlog do produto, que é a lista de coisas a fazer. Com isso em mãos você faz uma reunião que é chamada de Planejamento do Sprint. Nessa reuião é selecionado o Backlog do Sprint, que são as tarefas a serem implementadas durante o Sprint. As tarefas são DERIVADAS
do Backlog do Produto. Cada item do backlog do produto pode gerar uma ou mais tarefas para no Backlog do Sprint.

Depois de definido o Backlog do Sprint, a equipe executa este Sprint em um "timebox" de duas a quatros semanas com reuniões diárias para um balanço do que está acontecendo naquela iteração.

As Reuniões acontecem no mesmo horário, no mesmo local e de pé. O que foi feito ontem? O que você fará hoje? Existe algum problema no seu caminho? São as perguntas respondidas nesta reunião.

O Scrum Master é a pessoas responsável por resolver os problemas que estejam atrapalhando o bom andamento do projeto, caso existam. No final é gerado um incremento potêncialmente utilizável (implantável) do produto.

Backlog do Produto
Lista ordenada de tudo o que é necessário para o produto (funcionalidades) e para gerar essa lista você pode usar qualquer ténica de engenharia de software. Desde estórias do cliente (xp) até casos de uso conforme UML.

A ordenação é feita de acordo com a prioridade DO CLIENTE. Essas prioridades devem ser dadas de acordo com o valor que o software ira produzir para o usuário.

O Backlog do Produto é um artefato dinâmico, nunca está completo. A priorização pode mudar. Ele pode aumentar ou diminuir de acordo com a necessidade e vontade do cliente. Acontece um replanejenamento do Backlog no início de cada Sprint, afinal, se os requisitos mudam, as prioridades também mudam.

Backlog do Sprint
Uma lista de TAREFAS que a equipe se compromete a terminar dentro do Sprint. Não são funcionalidades, são tarefas. O cliente não tem acesso a este backlog. É algo muito técnico. Essas tarefas são derivadas do Backlog do Produto. São propostas pelo cliente e aceitas pela equipe durante o planejamento do Sprint. Cada funcionalidade do produto pode gerar uma ou mais atividades.

São considerados: a prioridade que o cliente deu aos itens, o tempo e esforço estimados pela equipe de desenvolvimento para completar as tarefas. É a equipe que estima o tempo e o esforço para os itens e não o cliente, nem o Scrum Master.

Papéis do Scrum

Product Owner (PO) - É o dono do produto, define funcionalidades (scopo) do produto (backlog). É o representante do cliente. É ele quem prioriza o Backlog do Produto de acordo com as prioridades da empresa e aceita ou rejeita o resultado do Sprint. Reponsável por todo o macro-gerencimanto de um projeto Scrum. É uma pessoa específica e não um comitê ou um grupo.

Team (Equipe)
Cuida do micro-gerenciamento do projeto: atividades técnicas, reuniões diárias e coisas do tipo. Contém de 5 a 9 pessoas, é multi-funcional e auto-ogrnizável. As pessoas somadas devem ter todas as habilidades para gerar o produto do Sprint e os membros precisam de dedicação integral ao projeto. É aceitável que apenas DBA seja compartilhado. Não existem títulos dentro da equipe, todos podem fazer tudo, os profissionais devem ser multi-disciplinares e por se auto-organizável, a equipe é quem decide como trabalhar.

A troca de membros da equipe só deve ocorrer durante a mudança de Sprints e nunca no meio de um. O Sprint costuma ser muito focado e uma troca iria atrapalhar o progesso.


Scrum Master
Reponsável pelo processo: aplicação dos valores, regras e práticas do Scrum. Esse framework possui poucas regras, mas elas são rígidas. É esse cara quem remove os obstáculos e facilita trabalho da equipe. O Scrum Master NÃO é um gerente de projeto, ele não possui autonomia para interferir na forma de funcionamento interno da equipe. Ele também é responável por blindar a equipe em relação ao ambiente externo e assim garantir o pleno funcionamento do time.

Exemplos de obstáculos a serem removidos:

"Meu PC quebrou, preciso de um novo"
"Preciso de ajuda para configurar o ambiente, que parou de funcionar"
"Preciso de ajuda para aprender tal coisa"
"O cliente não está disponível, existe uma dúvida e estou parado porque não sei o que deve ser feito"
"Um gerente de outro projeto quer remover uma pessoa da equipe para outro projeto"

Ele precisa arruma um jeito para resolver o problema. Não precisa ser a pessoa mais capacitada técnicamente, mas precisa achar alguém que entenda dos problemas técnicos que ele não sabia como resolver. Se alguém não sabe fazer tal coisa, ele pode ir atrás de quem saiba para ensinar, pode marcar as reniões com o cliente, procurar um cliente que saiba sanar uma dúvida e coisas do tipo.

Eventos do Scrum

1) Planejamento do Sprint
Os itens do Backlog do Produto são selecionados para serem feitos neste momento. As tarefas são identificadas e estimadas. Planeja-se tudo que deve ser feito no Sprint.

Para um Sprint de 4 semanas, um reunião colaborativa com toda a equipe (PO, Scrum Master e Equipe) costuma levar 8 horas. Na primeira parte da reunião acontece o planejamento estratégico define-se O QUE deve ser feito. O PO propõe uma meta (itens do backlog do produto) para a equipe fazer.

Na segunda parte acontece o planejamento tático, define-se COMO FAZER. É um trabalho focado na equipe de desenvolvimento, mas todos os papéis participam. O PO fica disponível para dúvidas. A equipe discute como fazer o que foi proposto e se é possível fazer tudo que foi proposto pelo PO.

2) Reuniões Diárias (Daily Scrums)
Reuniões diárias apenas com os membros da equipe, necessariamente sem o PO. Acontecem todos os dias, no mesmo lugar, na mesma hora e em pé, no máximo por 15 minutos. Pergunta-se: O que você conseguiu fazer? O que você vai fazer? Existe algum obstáculo prejudicando suas atividades?

3) Revisão do Sprint
No fim do Sprint acontece a apresentação dos resultados obtidos. Por resultado entende-se: aquilo que foi IMPLEMENTADO e pode ser demonstrado para o cliente. É um evento informal e o time inteiro participa. A preparação para o evento não deve demorar mais do que duas horas. O foco é em mostrar as coisas funcionando. Se algo não foi terminado, se existe um débito técnico, deve ser dito neste momento e pode ser necessário ajustar o Backlog do Produto, o que não foi terminado terá que retornar para lá.

Não utilizar apresentações em slides (PPT).

4) Retrospectiva do Sprint
Acontece depois da revisão do Sprint e antes da próxima reunião de planejamento. Inspeciona-se o processo e não o produto. O produto foi inspecionado na Revisão do Sprint.

A equipe verifica as relações entre as pessoas, os processos e ferramentas que foram utilizadas, analisa se o tempo escolhido para o Sprint está bom, se a equipe precisa de pessoas com habilidades diferentes e etc.