Universidade Federal do Rio Grande do Sul

Disciplina EE0S16

Aluno(s): Cludia Bert Goetz e Octavio Fernandes Professora: Karin Becker

Tarefa 3 Porto Alegre

1. A SITUAO ATUAL
O RXPC um projeto de desenvolvimento e implantao de um sistema de controle de pagamentos de contas solicitado por um cliente situado no Mxico. O cliente um fornecedor de gs muito grande no seu pas, e possui suas prprias agncias para recebimento dos pagamentos. Eles expressaram a necessidade e o desejo de contar com um sistema informatizado que controlasse todo o processo de pagamentos por parte de seus clientes. Atualmente, o projeto RXPC enfrenta enormes dificuldades. Desde as atividades gerenciais, at o desempenho do time de desenvolvimento, diversas falhas vm se sobressaindo a cada dia. Dentre as principais causas, foram identificadas: Requisitos mal organizados O levantamento de requisitos junto ao cliente se d atravs de diversas formas de comunicao, e no h um repositrio central bem estruturado e padronizado para o registro dos requisitos. s vezes os requisitos so definidos e discutidos atravs de conversas em emails, outras vezes atravs de chats e reunies, e ainda algumas vezes so registrados em uma ferramenta de Issue Tracking (JIRA). Isso resulta em um pssimo controle da informao e em erros de interpretao, pois na maioria das vezes os gerentes do projeto explicam para os desenvolvedores as informaes sobre os requisitos a serem implementados atravs de conversas informais. Dificuldade em estimar prazos e cumpri-los O cliente tem reclamado que a equipe de TI deles e os prprios usurios encontram muitos defeitos no software aps cada release. Devido a este e a outros motivos, o cliente no est muito satisfeito com o trabalho da nossa empresa. Para tranquilizar um pouco o cliente, os nossos representantes comerciais e analistas de negcio acabam prometendo entregar para o cliente na prxima release muito mais do que a equipe de desenvolvimento consegue produzir. Desta forma, cria-se um ciclo vicioso, e a tendncia natural que a prxima release fique novamente abaixo da expectativa do cliente. Dificuldade de comunicao entre a equipe A equipe de desenvolvimento integrada por diversos tipos de funcionrios. Alguns trabalham em turno integral. Outros, os estagirios, trabalham em um turno apenas. Alguns de manh, outros de tarde. Aliando-se isso ao fato de que constantemente cerca de 50% da equipe est super atarefada e correndo contra o tempo, diversas decises de projeto que deveriam ser discutidas acabam sendo adiadas, e o membro responsvel acaba decidindo fazer sua maneira. Esta a origem de um dos mais graves problemas no projeto: a falta de convenes e padres entre a equipe de desenvolvimento. Outro grave problema que se origina desta dificuldade de comunicao a grande demora para resolver problemas e impasses que, com uma comunicao mais fluente, seriam resolvidos de forma muito mais rpida, com mais troca de conhecimento entre os integrantes.

M distribuio das tarefas Como no h um controle eficiente do gerenciamento das tarefas, frequentemente ocorre de um membro da equipe estar muito sobrecarregado de tarefas, enquanto outro est ocioso, esperando receber uma nova tarefa para trabalhar. Em certas ocasies, so os prprios desenvolvedores que tem que realizar os testes de software. Outro problema grande decorrente dessa m distribuio a ocorrncia de pessoas com multi-tarefas, quando surgem problemas de ltima hora para serem resolvidos para uma release, pedidos feitos pelo cliente que, por engano, no haviam sido includos no escopo da entrega. Nestas ocasies, os gerentes do projeto costumam entrar em pnico e comeam a distribuir essas atividades emergenciais para qualquer membro da equipe de desenvolvimento, desviando eles das tarefas nas quais eles estavam trabalhando. Perodos de baixa motivao Juntando-se o caos que se instaura nas semanas que antecedem uma nova release, com o sentimento de desolao quando se inicia o planejamento para a prxima release, o funcionrio acaba se sentindo frequentemente desmotivado, com a sensao de que est sempre correndo contra o tempo e de que nunca consegue realizar algo realmente produtivo. O sentimento entre os membros da equipe de que eles esto sempre "tapando furos do passado". Eles sentem que, se as coisas tivessem sido feitas de forma correta desde o incio, eles poderiam dedicar maior parte de seu tempo ao desenvolvimento de features que realmente fariam a diferena e impressionariam o cliente.

2. PONTOS IMPORTANTES DO SCRUM

O SCRUM um framework, ou um conjunto de prticas, cuja finalidade auxiliar a gesto do desenvolvimento de um projeto. Quando aplicado area rea de desenvolvimento de software, o foco do SCRUM produzir software que agregue valor ao negcio no menor tempo possvel eliminando os custo e excesso de trabalho e mantendo apenas o necessrio para atingir um produto de excelente qualidade com simplicidade e sem burocracias, ou seja, um mtodo orientado a resultados que foca em produzir software operacional para ser avaliado rapidamente e repetidamente, em ciclos de 2 a 4 semanas. Neste modelo, o cliente define as prioridades e o time assume o compromisso e se organiza para definir a melhor forma de entregar as funcionalidades de maior valor. Do ponto de vista do cliente, os principais benefcios agregados pelo SCRUM integrar so entregar valor mais rapidamente e permitir ao cliente redefinir prioridades e requisitos mais rapidamente. Do ponto de vista de gerenciamento do projeto, o SCRUM traz um melhor controle da mo-de-obra, maior visibitidade do processo de gerenciamento do projeto, e maior motivao aos integrantes da equipe. Para o produto, o SCRUM traz melhor qualidade, melhorando a credibilidade com os clientes e aprimora a capacidade de estimativa de suas entregas.

3. PRATICAS A ADOTAR
Curto Prazo Adoo do Product Backlog Como no existe um modelo padro para o Product Backlog ns sugerimos a utilizao de uma planilha eletrnica com determinadas colunas que vm ao encontro das necessidades do cliente. As estrias do cliente sero armazenadas em uma planilha eletrnica que estar disponibilizada na Wiki da empresa para todos os integrantes da equipe. Neste arquivo sero mantidos os requisitos de cada release de maneira simples e objetiva. A criao do Product Backlog visa resolver alguns gargalos da organizao: O problema de m definio e documentao dos requisitos: Centralizando os requisitos neste repositrio, ser mais fcil recorrer s suas informaes.
-

O problema da dificuldade de estimar prazos: Os requisitos ficaro armazenados neste repositrio centralizado de acesso a todos e sero classificando de acordo com sua importncia e esforo. Isto facilitar a tarefa de estimar prazos para as tarefas.
-

As colunas sugeridas para o Product Backlog so conforme estrutura que segue: Nome: Nome do requisito ou ttulo Descrio: Descrio do requisito Importncia Nvel de importncia do requisito para o cliente Estimativa Estimativa (pode ser em horas ou em pontos apenas) do tamanho do requisito Notas outros comentrios

Sente a equipe junta Sentar a equipe junta um ponto importante a ser considerado quando se deseja ter uma equipe motivada. Este simples gesto de aproximar todos os membros da equipe e faz-los trabalharem no mesmo ambiente e prximos uns dos outros pode auxiliar em alguns pontos importantes que algumas vezes so deixados de lado e que vo ajudar inclusive num melhor entrosamento e comunicao entre o time. A definio de Juntos resume-se aos 3 itens que seguem: Audibilidade: Qualquer um da equipe pode conversar com o outro sem gritar ou sair da sala. Visibilidade: Todos da equipe podem ver todos os demais. Isolamento: Pequenas discusses sobre um determinado tema de trabalho podem ser mantidas dentro do ncleo da equipe sem perturbar os demais colegas de outros times.

Esta simples medida pode, a curto prazo, minimizar principalmente o problema de m comunicao entre a equipe e pode refletir tambm em uma melhor distribuio de tarefas. Mdio / Longo Prazo Reunies de Planejamento do Sprint O planejamento do Sprint deve servir para organizar o que entra e o que no entra um release, em uma nova verso de software que ser entregue ao cliente. Por este motivo esta reunio to importante. Nesta reunio ser definido o objetivo da Sprint, quem participar da Sprint, quais os requisitos que inicialmente sero desenvolvidos para a verso em questo e data final da Sprint. Com isto a dificuldade de estimar prazos ir diminuir, pois isso trar uma visibilidade de quando a prxima verso ficar pronta. O ideal que as Sprints fossem pequenas para que houvesse entregas mais rpidas e no se encontrassem tantos defeitos, j que no existe ainda um processo de testes na empresa. O Product owner deve participar das reunies de planejamento.