Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos)

Nossa última postagem apresenta o documento o Plano de Projeto de Software para produtos da Lacertae SW, desenvolvido na matéria de Gerência de Projetos do Departamento de Computação da UFS em 2017.2, ministrada pelo Prof. Doutor Rogério P. C. do Nascimento.
 

Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos) de Igor Costa

Os processos básicos do FDD (Feature Driven Development)

Como mencionado anteriormente, Jeff Luca foi o criador da FDD. Ele propôs uma solução que é uma mistura de 5 processos que abrangem: o desenvolvimento do modelo, sua listagem, design, planejamento e a implementação de das funcionalidades. Para facilitar o entendimento do FDD, o próximo post irá descrever os 5 processos básicos de FDD.

1º processo: desenvolvimento de um modelo geral

Neste primeiro processo, o FDD empurra equipes para construir um modelo de objeto do problema de domínio. Diferentemente de outras metodologias, a modelagem no FDD é uma atividade multifuncional, iterativa e colaborativa. Os membros da equipe (desenvolvimento, especialistas em domínio e programadores-chefe) trabalham juntos para compor um modelo para a área do domínio e são guiados por um arquiteto-chefe.

A ideia é ter equipes diferentes propondo modelos diferentes e, mais tarde, depois de serem revisados, seja escolhido uma opção de modelo ou misture-os. Finalmente, o modelo de área do domínio será incorporado no modelo geral. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.

Essa forma de concepção é uma ótima maneira de iniciar o projeto, pois permite que a equipe obtenha uma sólida compreensão do projeto, bem como uma comunicação sólida.

2º processo: criando a lista de recursos

Nesse processo a lista de funcionalidades pode ser comparada com o backlog do produto no scrum, e as funcionalidades seriam algum tipo de história de usuário. Depois de ter o modelo geral pronto, com base no conhecimento obtido durante essa fase, teremos que identificar as funcionalidades que são mais importantes para o cliente e que deverão guiar o projeto. As funcionalidades não devem levar mais do que duas semanas para serem concluídos e, se o fizerem, devem ser colocados em mais de uma funcionalidade. Elas geralmente são expressas como uma ação, resultado e objeto. O resultado desse processo é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).

 3º processo: planejando por funcionalidade

O terceiro processo, é mais ou menos sobre o planejamento em que ordem as funcionalidades serão implementadas, trata-se de organizar. Os conjuntos de tarefas que são atribuídas aos programadores. Também deve ser levado em consideração a prioridade e valor para o negócio/cliente. O resultado desse processo é um plano de desenvolvimento, com os pacotes de trabalho na sequência apropriada para a construção.

Obviamente, durante o planejamento, levamos em consideração aspectos diferentes, como riscos, dependências de complexidade, carga de trabalho da equipe, etc.

4º processo: detalhando por funcionalidade

Como durante todos os processos, utilizamos o conhecimento que recebemos do primeiro processo de modelagem. O programador chefe assume a responsabilidade de selecionar um grupo de funcionalidades que devem ser desenvolvidos a seguir. Ele também terá que determinar as classes de domínio que serão envolvidas. Depois que o grupo de funcionalidades for definido, todos começam a trabalhar juntos para fazer o trabalho, onde o especialista em domínio será responsável por analisar e projetar uma solução para cada funcionalidade. O resultado desse processo é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.

5º processo: construindo por recurso

Com base no trabalho realizado no processo de detalhamento da funcionalidade, os responsáveis pela classe atribuída na tarefa, terão de implementar todos os itens que são necessários para suportar os detalhes da funcionalidade. Dessa forma, trabalhamos no código que foi desenvolvido, realizamos testes unitários e inspeções de código para garantir que tudo esteja correto e seja aprovado pelo programador-chefe que dará o aval para sua entrega ao cliente. O resultado desse processo é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.

Fonte: https://apiumhub.com/tech-blog-barcelona/feature-driven-development/
https://pt.wikipedia.org/wiki/Feature_Driven_Development
https://imasters.com.br/artigo/13370/agile/fdd-um-metodo-agil-e-eficiente/

O que é Feature Driven Development(FDD)?

O lema do FDD é "Resultados frequentes, tangíveis e funcionais".

Em tradução livre: Desenvolvimento Guiado por Funcionalidades, é uma das seis metodologias ágeis originais do desenvolvimento de software. Essa metodologia situa-se numa posição intermediária entre as abordagens mais prescritivas (Processo Unificado, Cascata tradicional - Waterfall) e as abordagens Ágeis (XP - Programação Extrema, Scrum, Crystal, etc.).

O FDD foi criado por Jeff De Luca, um gerente de projetos australiano, no final da década de 90. Quando ele estava tentando fornecer uma solução de desenvolvimento de software para um grande projeto em Java para o United Overseas Bank em Singapura, entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos.

A primeira descrição oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999.

O FDD é um processo de desenvolvimento, que assim como todas as metodologias ágeis, é iterativo e incremental com o objetivo de entregar software funcional e que agregue valor para o cliente. Misturando as melhores práticas com o objetivo de focar no que é importante para o cliente. Isso significa que os desenvolvedores se concentram nos recursos que o cliente valoriza, as funcionalidades que eles esperam e precisam.

No FDD, as funcionalidades são tão importantes quanto as histórias de usuários são para Scrum. Já que elas ajudam os desenvolvedores no planejamento de seus trabalhos.

O FDD chama a atenção por algumas características:

• Propõem entregas de resultados úteis a cada duas semanas ou menos
• Utilização de blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados “Features”
• Planejamento detalhado e guia para medição
• Oferecer rastreabilidade e relatórios com precisão
• Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes, e até sugere a utilização da documentação como forma de comunicação dentro da equipe de desenvolvimento.
• Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos

O site oficial da metodologia é http://www.featuredrivendevelopment.com, incluindo um fórum de discussão onde as pessoas podem aprender mais sobre o tema.

Fonte: https://apiumhub.com/tech-blog-barcelona/feature-driven-development/

https://pt.wikipedia.org/wiki/Feature_Driven_Development

http://heptagon.com.br/fdd/fdd-oque/

https://imasters.com.br/artigo/13370/agile/fdd-um-metodo-agil-e-eficiente/

Time Scrum e suas peculiaridades

                     Time Scrum. Fonte: Bruno Barros

O Time Scrum é uma equipe de pessoas que estão juntas para atingir um objetivo em comum através do Framework Scrum. Ele é composto por um Product Owner, o Time de Desenvolvimento e um Scrum Master.  O modelo do Time Scrum foi projetado para otimizar a flexibilidade, a criatividade e a produtividade. Times Scrum intregam produtos de forma iterativa e incremental, maximizando o feedback dos seus clientes. Desta forma temos sempre uma atualização disponível daquele produto.

O Product Owner

O Product Owner é responsável por maximizar o valor do produto que é entregue pelo Time de desenvolvimento. Como isto é feito pode variar de acordo com a organização, time ou indivíduo.

Ele é uma pessoa e não um grupo. Suas decisões podem representar os ideais de um grupo, mas as responsabilidades, por exemplo a de gerenciamento do Backlog, são vinculadas somente ao Product Owner. 

Para que o Product Owner tenha sucesso, suas decisões devem ser respeitadas. Suas decisões devem estar visíveis por todos os envolvidos através do Product Backlog. Ninguem pode forçar o Time de Desenvolvimento a trabalhar em outros requisitos além dos que foram definidos pelo Product Owner.

Como o Product Owner é uma pessoa que gerencia o Product Backlog, eis aqui algumas das suas funções de gerenciamento:

-   Explicar claramente cada Item do Product Backlog;

-   Organizar os itens do Backlog para melhor atingir os objetivos e missões;

-   Otimizar o valor do trabalho executado pelo time de desenvolvimento;
-   Garantir que o Product Backlog esteja visível, transparente e claro para todos, e mostre o que será trabalhado mais adiante;
-   Garantir o entendimento dos itens do Product Backlog no nível necessário;

O Product Owner pode delegar as atividades mencionadas acima para o time de desenvolvimento, mas ele continua sendo o responsável por elas.

O Scrum Master

O Scrum Master é um servente-líder que possuí a responsabilidade de promover e dar suporte do Scrum para todo o Time Scrum. É ele quem leva a todos à entenderem a Teoria do Scrum, práticas, regras e valores. O Scrum Master ajuda aos que estão fora do Time Scrum a entenderem como devem interagir com o Time Scrum. Ele promove a mudança nas interações para maximizar o valor do produto criado ao final da Sprint.

O Scrum Master trabalha para o Product Owner de várias formas, eis algumas:

- Garantindo que todos do Time Scrum entendam as metas, escopo e produto da melhor forma possível;

- Encontrar técnicas para o efetivo gerenciamento do Product Backlog;

- Ajudar o Time Scrum a entender a necessidade de itens claros e concisos do Product Backlog;

- Compreender o planejamento do produto em um ambiente empírico;

- Garantir que o Product Owner saiba como organizar os itens do Product Backlog;

- Entender e praticar a agilidade;

- Facilitar a concretização dos eventos do Scrum conforme solicitado ou necessário;

O Scrum Master auxilia o Time de Desenvolvimento através de diversas maneiras, incluído:

-  Instruindo a equipe de desenvolvimento a ser auto-organizável e multifuncional;

- Ajudando a equipe de desenvolvimento a criar produtos de alto valor;

- Removendo impedimentos ao progresso da equipe de desenvolvimento;

- Facilitando eventos Scrum conforme solicitado ou necessários;

- Treinando o Time de Desenvolvimento em ambientes organizacionais em que Scrum ainda não está totalmente adotado e compreendido;


O Scrum Master auxilia a organização através das seguintes formas:

- Planejando implementações Scrum dentro da organização;

-  Ajudar os funcionários e as partes interessadas a compreender e promover o desenvolvimento de produtos Scrum;

- Criando mudanças que aumentam a produtividade do Time Scrum;

-  Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.

O Time de Desenvolvimento

O Time de Desenvolvimento é um grupo de pessoas que trabalham para entregar um incremento utilizável de um produto. O lançamento deste incremento deve ser mostrado durante a Sprint Review. Somente os integrantes do Time de Desenvolvimento é quem podem criar este incremento. O Time de Desenvolvimento deve ser capaz de gerenciar e organizar as o seu trabalho.

Quanto ao tamanho, é recomendável ter um time com três à nove pessoas. Com menos de três membros, a interação diminui e os ganhos em produtividade se tornam pequenos. Times de Desenvolvimento muito pequenos podem conter limitações de habilidades, isto leva a criação de um produto com pouca criatividade e qualidade. Tendo mais que nove membros, a complexidade de gerenciamento aumenta. Times muito grandes requerem um nível de gerenciamento de trabalho maior, sem contar que o controle dos processos empíricos se tornam impraticáveis. O Product Owner e o Scrum Master não fazem parte dentro do Time de Desenvolvimento.

O Time de Desenvolvimento possui as seguintes características:

- São auto-organizáveis. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como eles devem transformar o Product Backlog em um incremento lançável;

- São multi-funcionais. Ele possui todas as habilidades necessárias para a construção de um incremento lançável;

- Não reconhece títulos para membros do Time de Desenvolvimento. As pessoas não possuem títulos que denotem uma funcionalidade desempenhada naquela equipe; 

- Não reconhece subgrupos dentro do Time de Desenvolvimento, mesmo que estes estejam vinculados à tarefas específicas como testes, arquitetura, operações, análise de negócio e etc;

- Membros do Time de Desenvolvimento podem possuir habilidades específicas e áreas de especialização, mas a responsabilidade de entregar o incremento do produto é de todos.

Referências:

•  http://www.fabiocruz.com.br/valores-scrum/, acessado em 08/01/2018. 
•  Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2017, Creative Commons. 
•  https://www.scrum.org/, acessado em 27/12/2017 
•  PRESSMAN, Roger S. Engenharia de Software, Oitava Edição. Editora MCGrawHill: Porto Alegre, 2016. 

Siles da Apresentação dos assuntos do DevFlash

Segue os slides apresentados pelo grupo 4 - DevFlash.

Apresentação de Metodologias Ágeis de desenvolvimento gp4 por Carlos Alberto

Framework para desenvolvimento ágil Scrum

Framework Scrum - Fonte:Scrum.org

Scrum é um framework de desenvolvimento de tarefas complexas, de forma adaptativa e focada em melhoria contínua do produto e em aumentar o seu valor. Ele foi criado em 1990 por Ken Schwaber e Jeff Sutherland. Sua primeira definição formal tornou-se pública em 1995, durante a conferência de OOPSLA.

Ken Schwaber (à esquerda) e Jseff Sutherland (à direita).

Ele foi criado para ser leve, simples de entender e difícil de dominar. O Scrum é um framework para processos e pode muito bem ser utilizado no dia a dia de uma equipe de desenvolvimento. Ele não é um processo, técnica ou uma metodologia definitiva, mas sim um framework onde você pode empregar vários processos e técnicas afim de torná-lo mais robusto e adaptado a realidade do seu projeto.

Jogada Scrum do Rugby

Seu nome vem de uma jogada executada em uma partida de Rugby. Essa jogada é utilizada para dar o reinício do jogo, que acontece geralmente após a ocorrência de uma penalidade. Cerca de oito jogadores se unem e empurram outros oito jogadores do time adversário, o objetivo é avançar o máximo possível para marcar pontos.

A filosofia do Scrum está fundada sobre o processo de controle empírico, isto é, na maioria das vezes evitamos o uso de planejamentos detalhados por métricas abusivas para dar lugar ao "colocar a mão na massa" só depois tirar conclusões acerca do que fora feito. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões baseadas naquilo que sabemos. O Scrum aproveita-se disso empregando uma abordagem incremental e iterativa para otimizar a predição de riscos a media que o processo evolui. 

Pilares do processo Scrum - Fonte: Scrum.org.

Três pilares sustentam a implementação do processo de controle empírico presente no Scrum. São eles: transparência, inspeção e adaptação. 

• A transparência torna todas as informações acerca do projeto claras e visíveis a todos os envolvidos. Isto pode ser feito através do uso de dicionários para termos e siglas muito utilizadas no processo ou compartilhar uma definição comum de "tarefa finalizada". 
• A inspeção dos artefatos do Scrum deve ser feita por todos, com o objetivo de avançar até a meta da entrega e então observar se estão surgindo desvios indesejáveis. Não é aconselhável que as inspeções sejam executadas a todo o momento. A melhor forma é que sejam feitas por inspetores experientes e de forma que não atrapalhem o desenvolvimento do time.
• A adaptação deve ocorrer quando é notado um desvio da meta, geralmente apontado pela inspeção. Caso um desvio ocorra, rapidamente ele precisa ser ajustado para minimizar problemas futuros. O Scrum fornece alguns eventos para adaptação como o Sprint Review e Sprint Retrospective.

Valores do Scrum - Fonte: Scrum.org

Com os pilares sobre o processo, torna-se um terreno fértil para dar origem aos cinco valores que devem ser empregados ao Time Scrum. O Time Scrum poem estes valores em prática a medida que aprendem e exploram os papéis, eventos e artefatos do Scrum. Os cinco valores são:

• Coragem: o Time Scrum deve ter a coragem de fazer o que é certo e não ter medo de errar, afinal, é isto que o empirismo prega, o erro deve ser encarado como um ponto para se aperfeiçoar e corrigir.
• Foco: todo o time deve estar focado em uma unica Sprint e um conjunto de metas fornecidos pelo Sprint Backlog.
• Comprometimento: as pessoas se comprometem a alcançar as metas do Time Scrum.
• Respeito: o time deve ser capaz de respeitar a cada membro independente de suas habilidades, papéis e experiências.
• Abertura: O Time Scrum e os seus stakeholders devem estar abertos a fornecerem as informações necessárias ao trabalho, como também, fazer parte do dia a dia de desenvolvimento.

Para concluir, vimos a definição do framework Scrum, que é muito utilizado para o gerenciamento de processos de desenvolvimento de software. Vimos que o Scrum trabalha sobre o modelo empírico de processo, onde as decisões são melhor tomadas a medida que vão solucionando os problemas. Abordei os três pilares do Scrum que são a transparência, Inspeção e adaptação. Como também conversamos sobre os cinco valores que o Time Scrum deve desenvolver durante o processo: Coragem, foco, comprometimento, respeito e abertura. Com isso espero ter dado uma visão introdutória ao Scrum de forma que fique bem clara sobre os seus objetivos e o porque este framework é tão utilizado no mundo de desenvolvimento de software.

Referências:

•  http://www.fabiocruz.com.br/valores-scrum/, acessado em 08/01/2018. 
•  Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2017, Creative Commons. 
•  https://www.scrum.org/, acessado em 27/12/2017 
•  PRESSMAN, Roger S. Engenharia de Software, Oitava Edição. Editora MCGrawHill: Porto Alegre, 2016. 

Kanban vs Scrum

Figure 1 -  Kanban e Scrum

Scrum e Kanban são ferramentas de processo que, em certa medida, te ajudam a trabalhar de maneira mais eficaz, dizendo a você o que fazer. Java também é uma ferramenta, ela lhe fornece uma maneira mais simples de programa. 

Como quaisquer ferramentas, Scrum e Kanban não são perfeitos nem tampouco completos. Eles não lhe dizem tudo o que você precisa fazer, eles apenas lhes oferecem algumas restrições e orientações. Por exemplo, Scrum lhe restringe a ter iterações de tempo fixo e equipes multifuncionais, enquanto que Kanban lhe restringe a utilizar quadros visíveis e limitar o tamanho de suas linhas de produção. 

Podemos comparar ferramentas analisando quantas regras elas oferecem. Prescritivo significa “mais regras a seguir” e adaptativo significa “menos regras a seguir”. Prescritivo 100% significa que você não precisa usar seu cérebro, já há regra para tudo. Adaptativo 100% significa faça qualquer coisa, não existe nenhum tipo de regras ou restrições. Como podemos ver, os dois extremos da escala acabam se tornando ridículos.

Scrum e Kanban são ambos altamente adaptativos, mas falando relativamente, Scrum é mais prescritivo que Kanban. Scrum lhe dá mais restrições, por conta disso, deixa menos opções abertas. Por exemplo, o Scrum prescreve o uso de iterações de duração fixa, o Kanban não.

Kanban deixa quase tudo em aberto. As únicas restrições são: Visualize Seu Fluxo de Trabalho e Limite Suas Atividades em Andamento. Apenas a alguns centímetros de Faça Qualquer Coisa, mas ainda assim surpreendentemente poderoso.

Scrum ou Kanban?

Assim como o Scrum, o Kanban é centrado no valor entregado: as pessoas da equipe têm uma certa autonomia sobre suas responsabilidades, e essencialmente eles têm a mesma missão, que é continuamente eliminar desperdícios e remover obstáculos.

Kanban e Scrum compartilham alguns dos mesmos conceitos, mas têm diferentes abordagens. Eles não devem ser confundidos um com o outro. O quadro abaixo separa algumas diferenças que eles possuem.

Figure 1 - Diferenças Scrum x Kanban

O Kanban e o Scrum não são necessariamente relacionados para serem comparados, e nem são excludentes. Seus objetivos são complementares, e para uma melhor otimização muitas vezes eles são adotados juntos.

Algumas equipes misturaram os ideais do Kanban e scrum para o "scrumban." Eles tomam os sprints de extensão fixa e as funções a partir do scrum, e o foco nos limites de trabalho em progresso e tempo de ciclo a partir do Kanban. Porém, para as equipes que acabaram de começar com o agile, é altamente recomendável escolher uma metodologia ou outra e usá-la por um tempo. Você sempre pode iniciar aquela que for ideal mais tarde.

Referências:

https://www.infoq.com/br/minibooks/kanban-scrum-minibook#minibookDownload

https://br.atlassian.com/agile/kanban

http://blog.aspercom.com.br/2014/09/05/scrum-kanban-por-onde-comecar/