[ATPS]

ATPS – Engenharia de Software

Etapa 1

FAC 3

Nome: Anderson Ricardo Paublo RA:0901381748

Nome: Felipe Augusto Aparicio RA: 0916396398

Nome: Hildebrando Pedroni RA: 1001757638

Analisamos os requisitos necessários para uma clinica veterinária, e chegamos à conclusão que um software para tal área necessita dos seguintes requisitos:

Cadastro
- Clientes

- Fornecedores

- Funcionários

- Animal

Produtos
- Estoque de produtos completo com fotos e estoque para venda

- Ficha técnica

- Preços

Vendas
- Entrada e saída de estoque

- Contas a pagar

- Baixa em contas a pagar

Senha
- Permite que o proprietário monitore o acesso de seus funcionários
Opções de filtragem
Gráficos
Fluxo de caixa previsto e realizado

Consultas

- Agendamento de consultas

- Agendamento de cirurgias

- Relatórios e históricos de consulta

Características das metodologias.

	CASCATA	PROTOTIPAÇÃO	SCRUM
Exige extensa documentação:	P	P	PP
Software é facilmente modificado / expansível	PP	P	P
Gerar um protótipo / beta:	NP	P	P
Cálculo do fator risco:	NP	NA	P
Fácil cálculo do tempo de entrega do software	PP	NA	P

Vantagens e desvantagens das metodologias propostas.

	VANTAGENS	DESVANTAGENS
CASCATA	Baixo overhead: Não se gasta tempo em planejamento, documentação, garantia da qualidade e outras atividades - o enfoque único é na codificação; . Não exige muita experiência dos desenvolvedores.	Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe; logo no inicio é difícil estabelecer explicitamente todos os requisitos; demora para a entrega do produto.
PROTOTIPAÇÃO	Cliente tem interação com um protótipo no meio do processo; o protótipo pode servir para levantamento de requisitos.	Cliente acaba usando apenas o protótipo como produto final; desenvolvedor freqüentemente faz uma implementação comprometida, e acaba se familiarizando e usando os mesmos recursos para o produto final.
SCRUM	Clientes se tornam parte da equipe de desenvolvimento; Transparência no planejamento e desenvolvimento;	Necessita de bons programadores; Product Owner ausente; Desvio de Blocks; Falta de requisitos

Depois de uma série de conclusões optaremos pelo método cascata, pelo fato de darmos o enfoque total a codificação e pelo fato de não exigir muita experiência dos desenvolvedores. Esse modelo foi alinhado junto às expectativas do cliente e foi dado o de acordo para a iniciação do projeto.

ATPS 1ª ETAPA




























Tiago Ap. Pessoa Ra: 0911345828

Wesley S.Dia RA: 0959532446
Evandro D. Oliveira Ra:0919435437
Marcio S. Oliveira RA: 0920349523







Trabalho apresentado para avaliação na disciplina de Engenharia de Software e análise de projeto de sistema, do curso de Ciência da Computação, período noturno, da Universidade Anhanguera de Campinas FAC III, ministrado pela professora Tânia Ramires.
















Opções de metodologias de processo









• FDD (Feature Driven Development )
• CASCATA
• SCRUM













Processo FDD


É uma metodologia ágil para gerenciamento e desenvolvimento de software

Vantagens

Recomendado para qualquer tipo de desenvolvimento.
Foco em características de valor para o cliente
FDD prioriza aquilo que o cliente prioriza
FDD possui requisito maus formais


Desvantagens

Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção


Funcionalidade

Pequena o suficiente para ser implementada no máximo
em 2 semanas
Oferece valor para o cliente
Às vezes pode ser o próprio caso de uso
Conceito muito próximo ao de um requisito funcional
Exemplos: Calcular o total de uma venda
Autorizar uma transação com cartão de um cliente












Processo CASCATA



O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.




Vantagens


O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas.

Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;

∙ Não suporta modificações nos requisitos;
∙Não prevê a manutenção;
∙Não permite a reutilização;
∙É excessivamente sincronizado;
∙Se ocorrer um atraso todo o processo é afetado;
∙ Faz aparecer o software muito tarde.


Desvantagens

O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.









Comparação com o modelo em cascata

O desenvolvimento ágil tem pouco em comum com o modelo em cascata. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no planejamento, seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.





Processo SCRUM

Na indústria de software, devido á alta complexidade e ao desenvolvimento, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, quando os processos definidos eram menos adequados para obter a alta produtividade e qualidade no produto final, verificou-se que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.
As empresas de software começaram a estudar essa metodologia, que propõe novos métodos em substituição aos métodos praticados tradicionalmente, pois o mercado de tecnologia da Informação está cada vez mais competitivo.
Os métodos ágeis, como uma alternativa aos processos tradicionais em decorrência da insatisfação dos profissionais de desenvolvimento de software, com a rigidez e resultados limitados obtidos através do uso de práticas tradicionais de gestão de projetos. Tais projetos partem da premissa de que se devem permitir mudanças nos requisitos a qualquer tempo.
• Interação entre indivíduos é mais importante que processos e ferramentas;
• Produto em funcionamento mais que documentação extensa;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
.


Ciclo do Processo do Scrum

No início de um projeto Scrum, mesmo que ainda se tenha uma visão superficial no principio, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. A partir dessa visão inicial, elabora-se uma lista enxuta dos principais itens; cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia ou infraestrutura. Esta lista é denominada Product Backlog.
Podemos traduzir Product Backlog como uma lista de prioridade de entrega que indica o quanto de valor ele gera para o negócio. Esta lista não precisa estar completa logo no começo, ela pode ganhar outros itens no decorrer do projeto, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto.


No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.
O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos, ou um gerente de projeto, ou um patrocinador do projeto, um membro da equipe de marketing ou um cliente interno. Estas equipes recebem o nome de Scrum Teams. A preparação dos trabalhos é denominada Sprint Planning.
Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são Sprint Goal e Sprint.
O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. No início de cada iteração a equipe seleciona os itens do Product Backlog, de acordo com as suas prioridades e o prazo previamente combinado, este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico Sprint.
É importante que a equipe identifique os itens e tamanho do Sprint Backlog, porque ela estará comprometida a finalizar tais tarefas. Os seus membros são quem deverão escolher com o que irão se comprometer e deverá mantê-la e organizá-la de tal forma a atender os objetivos. Nesse momento as tarefas maiores são subdivididas em partes menores.
Logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado com o total previsto anteriormente no Product Backlog. Caso haja uma diferença significativa, a equipe Scrum deve negociar novamente com o cliente o número correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso.
Este método de liderança é exercido através de recorrentes tipos de reunião:
• Scrum Planning Meeting: É o início de uma Sprint, onde o Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento e a oportunidade de atualizar a priorização dos itens do Product Backlog e definir juntamente com a equipe um Product Increment a ser entregue ao cliente ao final do Sprint.
Esta reunião é realizada com a presença do Product Owner, Scrum Master (líder facilitador do projeto), de todo Scrum Team (equipe), e quaisquer interessados, diretores ou representantes do cliente. Durante a reunião o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, e este faz as perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint Backlog.
A reunião Sprint Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. O Scrum Team reúne-se separadamente para discutir o que foi dito e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer.
• Daily Scrum Meeting: O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Scrum Daily Meeting é a resposta para promover a comunicação da equipe. É um encontro diário realizado pela equipe e o Scrum Master onde os membros discutem aquilo em que trabalharam, no que irão trabalhar e possíveis impedimentos que estejam atrapalhando o progresso do trabalho. Esta reunião é uma maneira eficiente de manter os membros cientes dos objetivos e impedir que o projeto “saia do rumo”.
São tipicamente rápidas e objetivas, realizadas em pé, preferencialmente pela manhã, duram de 15 a 30 minutos, para responder a importantes perguntas:
• O que eu fiz desde a última Scrum Daily Meeting até agora?
• O que eu vou fazer hoje?
• O que pode me impedir?
As Daily Scrum Meeting não representam uma forma de cobrança vinda de um gerente de projetos, mas é uma maneira de sincronizar a equipe às tarefas e relatar os impedimentos que podem estar interferindo no bom andamento do Sprint.
• Criação do Product Increment: A finalização das funcionalidades definidas para um determinado Sprint marca a realização de um Product Increment. Os membros da equipe trabalham de maneira colaborativa de forma a realizar todas as metas definidas para aquele Sprint.
• Sprint Review: é uma reunião tipica de final de Sprint, neste momento a equipe exibe o Product Increment, potencialmente utilizável que foi construído, ao Product Owner, que é responsável por validar e/ou solicitar ajustes para que o projeto se torne adequado aos anseios do cliente. Os participantes desta reunião incluem tipicamente: o Product Owner, o Scrum Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos. O ideal é que a equipe tenha concluído todos os itens do Product Backlog alocados para o Sprint.


• Sprint Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Acontece apos a revisão do Sprint, o Scrum Master faz uma reunião de retrospectiva com a equipe. Esta objetiva identificar os pontos positivos e negativos do Sprint que entregou o último Product Increment e busca corrigir os problemas encontrados com o propósito de aperfeiçoá-los.

Nessa reunião é debatido o que funcionou na Sprint, o que precisa ser melhorado e quais ações devem ser tomadas para colocar as melhorias em prática. Geralmente o Sprint Retrospective tem de três a quatro horas de duração.

• Atualização do Product Backlog: O Product Owner é responsável por re-priorizar toda lista de itens do Product Backlog para que um próximo Sprint possa ser iniciado de acordo com os itens mais prioritários.
Os principais artefatos produzidos no processo do Scrum são o Product Backlog, Sprint Backlog, Burndown Chart e o TaskBoard.
O Burndown Chart é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo.
Com o Burndown Chart podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído.
Este dado estimativo pode ser comparado com o prazo que o Scrum Master definiu para que possamos saber se o projeto vai acabar ou não no prazo.
Este é um dos mais importantes trabalhos que o Scrum Master terá que fazer e o Burndown Chart é o indicador perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento.
O taskboard é um grande painel onde podem ser colocadas várias informações importantes para o acompanhamento do Sprint. O Sprint Backlog, ou seja, as atividades não iniciadas, as que estão em andamento e as concluídas ficam sempre visíveis e disponíveis para todos os interessados no projeto.
Algumas características das equipes de desenvolvimento são:





Processo





Ciclo de Trabalho













SCRUM FDD CASCATA

REUNIÃO P P P

DOCUMENTAÇÃO P P P

A.REQUISITOS P P P

MUDANÇAS / PLANEJAMENTO PP P PP


PRAZO E CUSTO
NP NP P













Vantagens Desvantagens
Cascata O modelo em cascata só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. Pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.

FDD Recomendado para qualquer tipo de desenvolvimento.
Foco em características de valor para o cliente
FDD prioriza aquilo que o cliente prioriza
FDD possui requisito maus formais Questionamento a eficácia aplicabilidade de FDD
Controvérsias sobre o tamanha mínimo de um time FDD
Manutenção

Scrum Velocidade.
Motivação maior dos programadores.
Evita surpresas com os resultados.
Diminuição dos Bugs. Prioridade podem ser alteradas.
Funcionalidade que agregam valor, veem primeiro. Sensação de informalidade;
Prazo.
Falta planejamento de escopo

[ATPS]

ATPS - Etapa 1

	eXtreme Programming	Espiral	V-Model
Documentação	P	P	P
Prototipagem	P	P	P
Feedback	P	NP	NP
Release Curtos	P	NA	P
Código Coletivo	NA	NA	P
• P – para possui
• NP – para não possui
• PP – possui parcialmente
• NA – para não se aplica

	Vantagens	Desvantagens
eXtreme Programming	O código produzido tem muito mais qualidade, pois o programa é revisado e questionado pelo colega desde o primeiro momento. Faz o desenvolvedor conhecer todas áreas do negócio e torna-o mais versátil.	Times pequenos de desenvolvimento.
Espiral	· As interações inicias do projecto são as mais baratas, permitindo que as tarefas de maior risco sejam levadas com o mínimo de custos. · Cada iteração da espiral pode ser customizada para as necessidades específicas de cada projecto.	· É complexo e requer atenção e conhecimento especiais para o levar a cabo.
V-Model	Enfatização de testes antes do termino do processo.	Difícil seguir o fluxo sequencia do modelo.

Nome:	Paulo Sergio Carvalho Junior	RA:	0943476492
Nome:	Bruno Casella da Cunha Rossetto	RA:	0901346766
Nome:	Bruno Augusto Mariano	RA:	0907348978
Nome:	Thiago Crisante Dias	RA:	0934457670

[ATPS] Atps etapa 1

ESTEVAN CAETANO
CARLOS GALVÃO
Etapa 01
Passo 01
Clivet Serviços Veterinários
(Apresentação da empresa)
A Clivet está há mais de 20 anos atendendo seu animalzinho com muito amor e carinho, que é como eles merecem ser tratados. Nosso centro cirúrgico é um dos mais modernos e bem equipados da região. Temos as melhores instalações, equipamentos e produtos de última geração, profissionais altamente gabaritados e tudo o que o seu animal de estimação precisa para ter saúde e beleza. Trabalhamos 24 horas para poder atendê-los em emergências da melhor forma possível.
Oferecemos serviços como:• clínica médica;• vacinas para cães e gatos;• atendimento a animais silvestres, como aves, répteis e ferrets;• cirurgias;• anestesia inalatória;• tratamentos odontológicos;• emissão de atestados de saúde guia de transporte animal para viagem (GTA);• farmácia veterinária;• exames laboratoriais;• internações;• pet shop completo com rações, petiscos, brinquedos e acessórios nacionais e importados;• banhos, hidratação de pêlos e tosas de cães e gatos.
Nosso Telefone: (11) 55426523Nosso Endereço:
Av. Professor Vicente Ráo, 1909 - Jardim Petrópolis - São Paulo –SP

Reunião com o cliente
Depois de algumas argumentações o cliente expôs as suas necessidades para um programa ágil e eficiente para a sua empresa.
Proposta feita:
Desenvolvedora Contratante Usabilidade
DESENVOLVIMENTO
VENDAS
USO
Redução de custo
Aumentar rendimentos
Aumentar eficácia
Poupar desenvolvimentos de custos
Aumentar
Transações Compras
Aumentar Taxa de sucesso
Poupar o desenvolvimento de tempo
Aumentar vendas de produtos
Reduzir erros de usuários
Reduzir a manutenção de custos
Aumentar trafego
Aumentar a produtividade do usuário
Poupar custos de redesign
Reter Clientes
Aumentar a satisfação do usuário

Atrair uma parcela de mercado
Aumentar a satisfação do empregado

Aumentar a facilidade de uso

Aumentar a facilidade de aprender

Aumentar a confiança no sistema

Diminuir custo de suporte

Diminuir custo de treinamento

Passo 2
Foi apresentada três opções de metodologias e suas características para o desenvolvimento do software:

Prototipação
Cascatas
Spiral
Comunicação com o cliente
P
PP
P
Planejamento
P
P
P
Analise de riscos
PP
PP
P
Projeto rápido

P

P
Especificação
P
P
p








Passo 3


Vantagens
Desvantagens
Prototipação
Rápida entrega do sistema;

Compromisso do usuário com o sistema; especificação,

Desenho e implementação interligados;

Sistema desenvolvido como uma série de incrementos ao usuário;
Para o produto final o desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que esta pronto)com o objetivo de produzir um protótipo depois de um tempo ele familiariza com essas escolhas,e esquece que elas não são apropriadas.

Cascatas
A fase única de requisitos leva à especificação antes do projeto;
· O uso de revisões ao fim de cada fase permite o envolvimento do usuário;
· Cada passo serve como uma base aprovada e documentada para o passo seguinte;
Desvantagens deste tipo de ciclo de vida:
· O fluxo seqüencial proposto por ele geralmente não é seguido em projetos reais;
· Requisitos devem ser completamente verificados no inicio do projeto;
· Aplicação deve ser compreendida pelo desenvolvedor desde o inicio do projeto;

O fluxo seqüencial proposto por ele geralmente não é seguido em projetos reais;
· Requisitos devem ser completamente verificados no inicio do projeto;
· Aplicação deve ser compreendida pelo desenvolvedor desde o inicio do projeto;
· Uma versão executável só é disponibilizada no fim do projeto

Spiral
· modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
· Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.
· Adequado quando os requisitos não podem ser completamente especificados de inicio;
· O uso do sistema pode aumentar o conhecimento sobre o produto e melhorar os requisitos.

Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
· A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso.
· É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
· O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

[Seminário]

Engenharia de Software



Nomes: RA:
Cinara Saraiva Cardoso 0901345894
Kivia F. Azevedo Ramos 2507415553







Campinas, São Paulo – Fevereiro 2011




SCRUM - Erros Comuns na tentativa de implantar SCRUM em time Ageis.
Na implatação do Scrum não é dificil de percebermos alguns fatores que podem atrapalhar a entrega e o insucesso dos projetos.Lembrando que todo metodologia a ser desenvolvidade deverá seguir suas caracteristicas senão concerteza iremos ter contratempos.
Principais problemas:
Product Owner ausente;
A não presença de um Product Owner pode acarretar varios blocks (bloqueios) no decorrer do desenvolvimento do projeto e atrasar a entrega do mesmo.
Geralmente isso ocorre devido nao disponibilizarmos de profissionais capacitados alocados nesta função, geralmente um unico Product Owner atende varios projetos ao mesmo tempo, devido a isso pode ocorrer demora nas soluções do blocks.
É necessario ter um product Owner presente em todas as reuniôes diarias e principalmente nas Planning , pois é nelas que todas as dúvidas sobre as regras de negocios sao esclarecidas.
Desvio de Blocks:
É quando o time vem trabalhando em ritmo acelerado e acontece um desvio de dois ou tres dias, ficando impossibilitados de trabalhar devido a falta de dados necessarios para que possam cumprir as tarefas designadas.
Solução recomendada:
O SRUM Master trabalhar mais proximo do Product Owner , na função de auxiliar e conseguir informações necessarias para desbloquear o time.
Falta de requisitos:
Também afeta e envolve diretamente o trabalho do Product Owner são requisitos mal escritos, eles possuem um papel fundamental no SCRUM. As estorias servem como base para o trabalho tanto durante o desenvolvimento quanto para os testes de software e a validação e homologação.
Elas devem ser feitas resumidamente , mas não podem deixar de conter as informações necessarias para o bom entendimento para que possam ser base para os testes.
Podemos levar dois pontos em questão que podem levar a estoria ser mal escrita são:
*Estoria com descrição muito longa;
O ideal é a mesma ser como um Checklist, para que possa ser discutida durante a Planning Meeting.
*Confundir criterios de aceitação com casos de testes.
Varias Estorias em desenvolvimento :
One Piece Flow é a ideia mais utilizada nos processos ageis, eles utilizam a tatica de atacar todos juntos um unico problema.
Utilizamos esta tatica para poder ser um ponto de atenção para o não cumprimento das metas.
Estimativas Otimistas:
Um ponto que nunca levamos em consideração é que podemos ter estimativas erradas dentro dos projetos ageis, onde as estimativas são sempre positivas mas os resultados podem ser catastroficos.Por isso é importante lembrar durante planning meeting que o esforço de acabar um projeto é do time, o Scrum Master e o Product Owner são apenas facilitadores e esclarecedores das duvidas existentes.

Conclusão:

Neste trabalho apresentamos alguns problemas que podem ocorrer no processo de implantação do SCRUM em projetos visando assim obter um melhor desempenho do time e apresentar um software de qualidade e a satisfação do cliente.

[ATPS] ATPS - Etapa 1

ATPS de Engenharia de Software

Etapa I

Introdução

Tentamos agendar duas reuniões com o cliente CLIVET, para discutirmos as características do projeto, como necessidades e tempo de entrega do mesmo, porém, como o mesmo estava muito ocupado, ambas reuniões não puderam ser realizadas.

Devido a tal fato, e a nossa vontade e competência em entregar um produto que agregue mais valor aos serviços da CLIVET e, à maior ou total satisfação de nosso cliente, resolvemos trabalhar com algum método/metodologia que nos permita entregar: ou protótipos ou fazer com quem nosso software seja facilmente modificado.

Mediante à impossibilidade de entrevistarmos nosso cliente, perguntando ao mesmo sobre as características desejadas do software, complexidade, integração com qual tipo de banco de dados (se necessário), tamanho da base de dados do mesmo, necessidade (ou não) de ser acessado via web, ser expansível para possíveis filiais, vontade do mesmo em ter um software que possa ser atualizado facilmente, etc, resolvemos seguir nossa intuição, e trabalharmos com algum método que nos permita entregar um protótipo ou então, que possa ser facilmente modificado (não temos um escopo inicial por parte de nosso cliente).

Desenvolvimento

Diagramamos duas tabelas, para a apresentação ao nosso cliente; mesmo ele não podendo comparecer às reuniões e discutir sobre tais metodologias, nós resolvemos escolher entre as 3 metodologias inicialmente propostas, a que julgamos ser melhor pelo comportamento de nosso cliente, e pelo que julgamos que o cliente quer / espera do software.

Tabela I

	Clássico (cascata)	Prototipação	Metodologia Ágil / Scrum
Exige extensa documentação:	P	P	PP*
Software é facilmente modificado / expansível:	PP	P	P
Gerar um protótipo / beta:	NP	P	P
Exige excelentes/experientes programadores:	NA**	NA**	P
Cálculo do fator risco:	NP	NP	P
Fácil cálculo do tempo de entrega do software	PP	NA	P

Onde: P = possui; PP = possui parcialmente; NA = não se aplica ;NP = não possui.

* = se o cliente desejar, é feito; porém não é uma característica da metodologia

** = a menos que a empresa já conte com excelentes programadores; em teoria, não é necessário.

Vamos, agora, apresentar uma tabela comparativa entre as três metodologias:

Tabela II

	Vantagens	Desvantagens
Clássico (cascata)	*É antigo; *É muito utilizado; *Minimiza o tempo de planejamento; *Funciona bem com equipes tecnicamente mais fracas; *É linear.	*Perde-se muito tempo com documentações, nem sempre necessárias; *Projetos chegam a levar muitos meses para serem concluídos; *Cliente só vê o programa em funcionamento ao final de todo o processo; *Não necessita de uma equipe bem integrada, o que pode gerar falhas ou incapacidade do programa ser atualizado; *Não tem análise de risco.
Prototipação	*Trabalha com um protótipo do software; *Cliente recebe uma versão protótipo do mesmo, para utilização e testes; *Pode ser utilizado quando a comunicação com o cliente não é completa; *Facilmente atualizável; *Bom para softwares com mudanças de requisitos constantes.	*Cliente pode se contentar com o protótipo, e esquecer a versão final; *Impossível determinar com exatidão o tempo que o processo vai durar; *Não há formas de saber o número de iterações necessárias; *Mutias vezes, o protótipo acaba atrapalhando o desenvolvimento da versão final; *Não há análise de risco..
Ágil / Scrum	*É ágil; *Utiliza análise de risco; *Focado na negociação interna e com clientes; *Agrega muito valor ao produto e ao cliente; *Geralmente, traz alto grau de satisfação do cliente com o produto; *Time pequeno.	*Necessita de um time bem entrosado; *Necessita de bons programadores; *Ambiente que facilite a fácil comunicação entre os membros; *Quebra de paradigmas é complicado; *Difícil de gerenciar projetos que precisam de muitas pessoas.

Conclusão

Resolvemos optar, mesmo não sendo excelentes programadores, pelo método Scrum, pois temos uma boa comunicação, um time pequeno, e visamos a total satisfação de nosso cliente, em um curto período de tempo, visando, também, um software que possa ser facilmente atualizável, e, sem uma extensa documentação.