Segue abaixo nossa apresentação para obtenção da aprovação na disciplina Gerência de Projetos.
terça-feira, 3 de março de 2015
sexta-feira, 20 de fevereiro de 2015
terça-feira, 20 de janeiro de 2015
As boas práticas do Extreme Programming
A estrutura do xp também é constituida de práticas que são sustentadas pelos valores já citados na postagem anterior. Antes de qualquer coisa, é necessário ter confiança nestas boas práticas
e consciência de que elas devem ser aplicadas em conjunto. Quando
aplicadas isoladamente, elas não trazem os mesmos resultados por que os
pontos fracos de cada prática são protegidos pelos pontos fortes das
outras práticas. As práticas são:
- O jogo do planejamento: entre o cliente e os técnicos são estimuladas reuniões usando quadros brancos, com o objetivo de captar e definir as "user stories" e também para poder estimar o tempo ideal das interações, o projeto como um todo, elaborar estratégias e tentar prever as contingências para projeto.
- Releases pequenas: cada release deve ser tão pequena quanto possível, contendo apenas os requisitos mais importanter para o negócio.
- Metáfora: a intenção é oferecer uma visão geral do sistema em um formato simples, que possa ser compartilhada por clientes e programadores, a ideia da metáfora é que seja feita uma analogia entre o sistema que está sendo desenvolvido e um sistema que todos entendam, com o objetivo de obter um "vocabulário comum".
- Projeto Simples: o código está, a qualquer momento, na forma mais simples e mais clara, conforme os padrões definidos pela equipe de desenvolvimento, facilitando a compreensão e possível continuidade por qualquer um de seus membros.
- Testes constantes: os testes no xp são feitos antes da programação. Existem os testes funcionais e os de unidade, os testes de unidade são feitos para verificar tudo que possa dar errado e os funcionais são usados para verificação junto ao cliente do sistema como um todo.
- Refatoramento: são constantes melhorias no projeto do software para aumentar sua capacidade de se adaptar a mudanças.
- Programação em pares: todo o código produzido em xp é escrito por um par de programadores sentados lado-a-lado e olhando para o computador. Um parceiro será responsável pela codificação e o outro observa o código e pensará mais estratégicamente em como melhorá-lo e torná-lo mais simples.
- Propriedade coletiva do código: uma vez aplicados a programação em pares, a equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo, mantendo claro, um padrão prático de comunicação da equipe.
- Integração contínua: os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de implementação da solução
- Semana de quarenta horas: trabalhar por longos períodos é contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de trabalho de todos da equipe, criando condições favoráveis ao uso da carga normal de trabalho. É necessário deixar a equipe livre para relaxar, brincar, ou fazer o quem bem entender para equilibrar o trabalho mental e físico. Existe até uma frase que diz: trabalhe a 100% durante as 40 horas e descanse a 100% no resto. Se algum deles não for feito com 100%, um afetará o outro.
- Cliente no local: Constante disponibilidade do cliente para colaborar em dúvidas, alterações, e prioridades em um escopo, ou seja, dando um dinamismo ativo ao projeto
- Padrões de codificação: todo código é desenvolvido seguindo um padrão, qualquer que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe terão a mesma visão do código.
segunda-feira, 19 de janeiro de 2015
XP: Vantagens da Programação em par
“Quando há olhos suficientes, todos os erros são óbvios” - Eric S. Raymond
Como funciona
Durante a implementação, um programador digita o código e outro revisa o que está sendo digitado, apontando problemas e pensando na solução como um todo).
Vantagens
Compartilhamento do conhecimento
Como todo o código produzido é visto por, pelo menos, duas pessoas é menor o risco de existir a figura do “responsável pelo código do produto X”. O conhecimento pode ser ainda mais compartilhado, principalmente se os pares forem revezados com frequência.
Isso é, obviamente, bom para o projeto. Mas também é muito bom para os desenvolvedores. Afinal de contas, é comum desenvolvedores que não podem tirar férias pois caso contrário o projeto onde eles trabalham não pode ser mantido.
Ser o responsável único por determinado projeto, ou parte dele, quase sempre é um fardo pesado demais que faz com que o desenvolvedor seja levado ao esgotamento.
Correção de falhas
Com duas pessoas olhando o código, as falhas e erros de lógica são detectados (e corrigidos) mais cedo. Isso faz com que o trabalho seja mais fluído, uma vez que é mais difícil aquela situação onde o programador perde horas realizando o debug do código para encontrar uma falha de lógica, por exemplo.
Manutenibilidade
Um código escrito à quatro mãos é, naturalmente, mais simples de sofrer manutenção. Afinal de contas, durante a escrita do código sua clareza já estava sendo testada pelo co-piloto, que questionará sempre que não entender determinado trecho.
Confiança
Como o código é desenvolvido em pares, os desenvolvedores tem mais confiança no resultado final, uma vez que ele foi validado por, pelo menos, mais uma pessoa. Os possíveis erros e problemas também são divididos, o que faz com que o time como um todo passe a enxergar o código como propriedade coletiva. Nesse formato, todos estão sempre dispostos a ajudar, pois o sucesso ou fracasso pertencem a todos os membros da equipe.
Amadurecimento
Durante o ciclo de desenvolvimento há uma constante relação aluno-professor entre o par, sendo que esse papel é constantemente revezado de acordo com o nível de conhecimento de cada um no caso específico.
Pressão do Par
Quando há uma outra pessoa junto fazendo o trabalho, a tendência é que o desperdício de tempo diminua consideravelmente. Qualquer pessoa fica constrangida ao acessar e-mails, mensagens instantâneas ou mesmo atender celular na presença de terceiros. Além disso, como o trabalho é compartilhado, há um maior sentimento de compromisso e ninguém gosta de ser responsável pelo fracasso de outro.
Velocidade
Um código com menos bugs, onde as soluções são discutidas e há a pressão do par para que o resultado saia, faz com que as soluções fiquem prontas mais rapidamente e com mais qualidade.
Dificuldades
Existem, é claro, algumas dificuldades para a adoção da programação em par. A primeira delas diz respeito a personalidade os desenvolvedores envolvidos.
Eles devem entender que o código produzido é coletivo, e não sua propriedade. Devem também aceitar sugestões e críticas ao seu trabalho, entendendo que isso decorre do fato de a propriedade do código ser coletiva.
Outra grande dificuldade é convencer “quem paga a conta” que vale a pena. No entanto, isso pode ser feito utilizando-se a prática. Realizando alguns experimentos com programação em par, comparando o resultado com programação solo, normalmente chega-se a conclusão de que a programação em par é extremamente vantajosa.
Fonte: fonte
Valores e princípios do Extreme Programming
O Extreme Programming é um processo de desenvolvimento de software que adota os valores de comunicação, simplicade, feedback e coragem, que a partir desses valores são geradas as
práticas, esses valores são as diretrizes da metodologia, eles definem as atitudes das equipes e as prioridades a serem seguidas. Os valores são detalhados a seguir:
- Comunicação: é obrigatória para que não haja lacunas em processos e problemas entre equipe, cliente e fornecedor já que o XP foca em construir um entendimento pessoa-a-pessoa de problema, com o uso mínimo de documentação formal e com o uso máximo de interação "cara-a-cara".
- Simplicidade: é necessária desde a forma como se levanta requisitos até a codificação e os testes da solução desenvolvida já que o XP sugere que cada membro da equipe adote a solução mais fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente em que o custo de mudanças futuras seja baixo.
- Coragem: por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para: desenvolver software de forma incremental, manter o sistema simples, permitir que o cliente defina prioridades, fazer desenvolvedores trabalharem em pares, investir tempo em refactoring, investir tempo em testes automatizados estimar estórias na presença do cliente, expor código a todos os membros da equipe, integrar o sistema diversas vezes ao dia, adotar ritmo sustentável de desenvolvimento, abrir mão de documentos que servem como defesa, propor contratos de escopo variável, propor a adoção de um processo novo, assumir em relação ao cliente possíveis atrasos e problemas de implementação, colocar desenvolvedores e clientes frente a frente, implantar uma nova versão do sistema no cliente semanalmente, apostar em seus colaboradores aumentando suas responsabilidades, modelar e documentar apenas quando for de extrema necessidade.
- Feedback: é a pratica fundamentada em retornar informações entre os membros da equipe e também na relação com o cliente, desde responder e-mails, telefonemas bips e demais meios. Devido a isso, é um mecanismo para melhorar a prática de comunicação explanada acima.
http://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498
http://javafree.uol.com.br/artigo/871447/Apresentando-XP-Encante-seus-clientes-com-Extreme-Programming.html#valores
http://www.cin.ufpe.br/~gamr/FAFIC/Desenvolvimento%20de%20sistemas/XP.pdf
domingo, 18 de janeiro de 2015
Conhecendo os Papéis do Scrum
a) ScrumMaster: É aquele que faz com que a equipe siga as práticas,
valores e regras do Scrum.
b) Product Owner: O Product Owner determinar os itens que compõe o
Product Backlog, também priorizando os itens da mesma, qualquer repriorização
deve passar pelo Product Owner e para que isso funcione corretamente, suas
decisões devem ser respeitadas por todos os envolvidos no projeto.
c) O Time ou Equipe: São as pessoas que realizam todos os itens do
Product Backlog, finalizando e entregando uma parte dele em cada Sprint.
d) Time Boxes: São os eventos com duração fixa, como as Reuniões de
planejamento de Sprints e Release, Daily Scrum(Reuniões diárias), Revisão da
Sprint, Retrospectiva da Sprint, e a própria Sprint.
e) Reunião de Planejamento da Release: Nas reuniões de planejamento da
release são estabelecidos os planos e metas com a equipe Scrum e o restante da
organização, buscando encontrar as melhores maneiras de atingir ou até superar
as expectativas do cliente, bem como o melhor retorno sobre o investimento.
f) Sprint: Trata-se das iterações definidas previamente, as quais têm
duração fixa, e trata-se do momento que são executadas as tarefas estabelecidas
para essa iteração.
g) Reunião de Planejamento da Sprint: Como o próprio nome define é o
momento para planejar a Sprint, tendo seu tempo fixado de acordo com o tamanho
da iteração, onde, uma iteração de duas semanas leva em torno de 4 horas para
realizar uma Reunião de Planejamento da Sprint.
 |
| Exemplo de Planejamento dos itens do Product Backlog. |
h) Revisão da Sprint: A revisão
da Sprint trata-se de uma reunião que ocorre ao final da sprint, para que todos
da equipe possam conversar sobre o que foi ou não foi feito nessa iteração.
i) Retrospectiva da Sprint: A
retrospectiva ocorre após a revisão de sprint, com uma duração de 3 horas para
sprints de um mês, sendo proporcionalmente diminuída para sprints menores.
j) Daily Scrum: Ocorrem todos
os dias, deve ter uma duração de 10 a 15 minutos, não mais que isso,
onde cada membro da equipe vai explanar para
os outros membros:
1- O que realizou desde a última reunião.
2- O que vai fazer antes da próxima reunião.
3- E se existe algum obstáculo.
O ScrumMaster deve garantir que a reunião ocorra todos os dias, e que os
membros da equipe sejam breves em suas explicações.
Fonte: http://www.uniedu.sed.sc.gov.br/wp-content/uploads/2013/10/Wilian-Vargas-de-Lima.pdf
Fonte: http://www.uniedu.sed.sc.gov.br/wp-content/uploads/2013/10/Wilian-Vargas-de-Lima.pdf
Os Papéis e Modelos do Scrum
O Scrum é basicamente divido por Equipes Scrum com seus
membros tendo papéis definidos, pelos Times Boxes que são as reuniões de
planejamento, releases, sprints e por fim os Artefatos e Regras.
De acordo com Schwaber e Sutherland (2010, p.4) as Equipes
de Scrum tem em sua formação três papéis:
O Product Owner: define os itens que devem ser realizados
pela Equipe Scrum.
O ScrumMaster: assegura que a equipe vai seguir as práticas
e processos do Scrum.
A Equipe Scrum: são as pessoas que realmente colocam a “mão
na massa”, que executam o trabalho e tornam os requisitos em um produto.
A partir dos Times Boxes é que se tem uma regularidade no
projeto, os
quais são os elementos fixos como: Reunião de Planejamento
da Release, reunião
de Planejamento da Sprint, a Sprint em si, as Reuniões
Diárias(Daily Scrum), a
Revisão da Sprint e a Retrospectiva da Sprint.
Dentre todas as Times Boxes a Sprint pode-se considerar a
mais importante, pois é a iteração previamente definida, em que durante esse
período é feito o esforço para o desenvolvimento do que foi planejado para essa
iteração e sendo uma parcela do produto final busca-se que sejam partes
funcionais.
As sprints funcionam uma após a outra, e mesmo que um produto não
tenha sido concluído em sua iteração estipulada, pode continuar sendo
trabalhada na próxima. Como definem Schwaber e Sutherland (2010) os artefatos são
formados por:
Product Backlog – Trata-se de uma lista contendo as
funcionalidades desejadas.
Sprint Backlog – É uma lista de tarefas feita a partir do
Product Backlog para ser desenvolvida dentro da Sprint.
Burndown de Release – mensura o Product Backlog ao longo do
tempo.
Burndown de Sprint – mensura os itens da Sprint Backlog
restante ao longo das sprints.
Já as Regras, funcionam como o próprio nome
determina, são regras para manter todos os pontos funcionando bem e ligados.
Como exemplo, uma regra do Scrum diz que “somente membros do Time - as pessoas
comprometidas em transformar o Product Backlog em um incremento - podem falar
durante uma Daily Scrum”. (Schwaber e Sutherland, 2010, p. 5).
Assinar:
Postagens (Atom)