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