Arquivo de maio de 2010

SCRUM em 2 minutos

segunda-feira, 10 de maio de 2010

O texto abaixo foi criado por Paulo Fernandes (eu) e Jefferson Lira como parte do artigo Como atender os requisitos arquiteturais de software usando métodos ágeis como SCRUM e XP.

O SCRUM é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto, a quem diga que esta mais para um framework que uma metodologia, ou até mesmo mais para atitude que um processo.

Para que o SCRUM seja utilizado com êxito, cada pessoa envolvida deve cumprir com seu papel, seguindo corretamente todos os processos, e a fim de viabilizar, utilizar como apoio algumas das ferramentas que lhe são oferecidas. Entretanto, para que seja possível seguir corretamente todos os processos, primordialmente é necessário que todos estejam de acordo com a cultura envolvida.

Segue abaixo uma breve descrição sobre os três papeis relacionados ao SCRUM:

Product Owner: responsável por garantir o retorno de investimento, este deve conhecer as necessidades do cliente;

Scrum Master: responsável por remover os impedimentos do time e garantir o uso do SCRUM;

Time (Equipe): equipe de desenvolvimento multidisciplinar e auto-gerenciável, responsável por produzir produto com qualidade e valor para o cliente.

As ferramentas como: Product Backlog, Sprint Backlog, Burndown Chart e Scrum Board são de grande utilidade durante o ciclo de vida do SCRUM. Para um melhor entendimento, segue abaixo uma breve descrição:

Product Backlog: uma lista com todos os requisitos que o Product Owner deseja, sem muitos detalhes técnicos, essa lista é ordenada por prioridade pelo Product Owner;

Sprint Backlog: contém uma lista com as tarefas decompostas sobre os itens extraídos do Product Backlog que foi definida no Sprint Planning Meeting e que deverá ser entregue ao Product Owner.  Estas atividades não devem durar mais de 2 dias ou 16 horas;

BurnDown Chart: gráfico que mostra o trabalho da equipe dia a dia, avaliando assim se o Sprint está atrasado ou não. Caso o gráfico demonstre que a equipe acabará o Sprint antes, o Product Owner é consultado e novas funcionalidades são incorporadas àquele Sprint;

Scrum Board: é um quadro onde deverá contemplar todas as tarefas que serão realizadas dentro de um Sprint e listadas de acordo com as prioridades de cada item.

Existem três tipos de cerimônias no SCRUM, Sprint Planning Meeting, Daily Scrum Meeting e Sprint Review Meeting, estes três tipos de evento caracterizam bem o ciclo de vida de cada Sprint: início, meio e fim. Segue abaixo uma breve descrição sobre as cerimônias:

Sprint Planning Meeting: encontro para planejar o que será feito no Sprint. A equipe acessa o Product Backlog e detalha de forma mais ampla as atividades que serão executadas no Sprint de acordo com suas prioridades, avaliando tempo e complexidade. Após definido o que será feito, o Sprint Backlog é gerado;

Daily Scrum Meeting: encontros diários, com duração em média de 15 minutos, a idéia de ser uma reunião em que cada membro da equipe deve responder 3 perguntas: O que fiz ontem? O que farei hoje? O que está impedindo de que alcance o objetivo? Essa reunião é liderada pelo ScrumMaster;

Sprint Review Meeting: encontro realizado quando o Sprint chega ao fim. Este encontro é dividido em duas partes, na primeira parte é demonstrado ao ProductOwner quais atividades definidas no Product Backlog foram realizadas, o Product Owner lidera esse encontro e pode chamar todos os interessados no projeto. Após a demonstração o Product Owner e os interessados no projeto atualizam e repriorizam o Product Backlog, definindo assim o próximo Sprint. Finalizada essa primeira parte o ScrumMaster toma a liderança e começa uma reunião com a equipe, onde a equipe avalia o que foi realizado positivamente e negativamente no Sprint, também avaliam o que poderia ser mudado para melhorar o próximo Sprint.

O Sprint é um conjunto de tarefas a serem executadas em um determinado tempo. A Figura 1 ilustra o ciclo de vida do SCRUM.

Ciclo de Vida do SCRUM

Ciclo de Vida do SCRUM

Tags:, , ,
Publicado em Metodologia | 1 comentário »

Arquitetura de Software em 2 minutos

segunda-feira, 10 de maio de 2010

O texto abaixo foi criado por Paulo Fernandes (eu) e Jefferson Lira como parte do artigo Como atender os requisitos arquiteturais de software usando métodos ágeis como SCRUM e XP.

A arquitetura do software é um ponto de extrema importância no desenvolvimento e deverá ter uma maior atenção quando sua existência é de grande complexidade para o sucesso do software, pois a definição desta poderá não ser a mais apropriada para o negócio. A má escolha de uma arquitetura de software fará com que o projeto possa ser um desastre, já a melhor escolha propicia uma maior chance para o sucesso do projeto. Abaixo evidenciamos definições sobre o que é a arquitetura de um software.

A arquitetura de software de um programa ou de um sistema é a estrutura ou estruturas do sistema, que incluem elementos de software, propriedades externas e as suas relações.

A arquitetura de software define a estrutura básica do sistema. A arquitetura é modulada em um alto nível de funcionalidades do sistema, gerenciamento e distribuição de dados, qual plataforma será usada, etc.

Arquitetura de software é a estrutura dos componentes do sistema/programa, seus relacionamentos, princípios e diretrizes para o projeto e sua evolução.

Devido as definições citadas acima, formalizamos que não existe uma definição mundial sobre o que é a arquitetura de software. As definições no geral enfatizam que a arquitetura é a descrição do sistema e a soma de pequenas partes dele, e como essas partes se relacionam e cooperam entre si para executar o trabalho do sistema. A qualidade e longevidade do software são determinadas pela sua arquitetura.

Não podemos confundir a arquitetura do software com o design. A arquitetura se preocupa com a seleção de elementos arquiteturais, suas iterações e restrições, já o design são as atividades que se preocupam com a modularização e detalhamento de interfaces, algoritmos, procedimentos e tipos de dados que darão suporte satisfatório a arquitetura.

Um software tipicamente contempla requisitos funcionais e não funcionais, sendo que muitas das vezes um deverá refletir o comportamento do outro. Os requisitos funcionais descrevem as funções que o software deve ser capaz de realizar. Já os requisitos não-funcionais descrevem as qualidades e restrições de como o sistema realiza suas funções. Um software, portanto, deve exibir atributos de qualidade que atendam aos seus requisitos.

O ideal é que os atributos de qualidade do software sejam identificados e qual a sua influência na arquitetura, por fim relacionar estes atributos as decisões arquiteturais que os proporcionam.

Com um modelo de apoio para definir e organizar os atributos do software importantes para a avaliação de sua qualidade existe a norma ISO 9126. Esta norma é um padrão internacional para avaliação da qualidade do software. Os atributos utilizados para avaliar a qualidade do software são os seguintes:

Funcionalidade: é a capacidade do software realizar as funções que foram especificadas;

Confiabilidade: é a capacidade do software ser seguro e tolerante a falhas;

Usabilidade: é a medida da facilidade do usuário executar alguma funcionalidade do sistema;

Eficiência: é a capacidade do sistema alcançar a resposta dentro do período de tempo especificado, está relacionado tanto ao desempenho quanto aos recursos usados;

Manutenibilidade: é a medida de quanto o software é fácil ser alterado;

Portabilidade: é a medida da facilidade do software ser portado para outro ambiente.

Tendo definido as decisões e informações arquiteturais, seja performance, escalabilidade, arquitetura de referência, segurança, ou outros itens, estas devem ser armazenadas em um documento. O documento mais comum que encontramos é o DAS (Documento de Arquitetura de Software). Este documento é de grande utilidade para guiar a equipe de desenvolvimento.

Tags:,
Publicado em Arquitetura | Nenhum comentário »

eXtreme Programming (XP) em 2 minutos

segunda-feira, 10 de maio de 2010

O texto abaixo foi criado por Paulo Fernandes (eu) e Jefferson Lira como parte do artigo Como atender os requisitos arquiteturais de software usando métodos ágeis como SCRUM e XP.

Extreme Programming ou XP como é chamado é um processo de desenvolvimento de software baseado em valores de simplicidade, comunicação, feedback e coragem. O objetivo do XP é assegurar que o cliente receba o máximo de valor a cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.

Os quatro valores fundamentais em que o XP se baseia são:

Feedback: fazer com que o cliente conduza o desenvolvimento diariamente a fim de garantir que a equipe direcione toda a sua atenção para aquilo que de fato irá gerar mais valor;

Comunicação: evitar o gasto de um valioso esforço na tentativa de trocar informações por meios de extensos documentos escritos que freqüentemente são interpretados de forma incorreta ou incompleta;

Simplicidade: garantir que seja desenvolvido apenas o suficiente para atender as necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial;

Coragem: devido ao XP ser uma metodologia de software que se baseia em diversas premissas que contrariam os processos tradicionais de desenvolvimento de software, é preciso que todos da equipe tenham coragem para adotá-las e acreditar que, utilizando as práticas e valores do XP, serão capazes de fazer com que o software evolua com segurança e agilidade.

O XP tem alguns pontos fortes que auxiliam no processo de desenvolvimento, a citar:

Cliente Presente: a presença objetiva viabilizar a simplicidade dos processos, facilitar a comunicação com os desenvolvedores e permitir um ciclo continuo e rápido de feedback;

Jogo do Planejamento: reunião com o cliente a cada nova release a fim de definir quais funcionalidades devem ser implementadas de acordo com suas priorizações;

Stand Up Meeting: reunir com a equipe de desenvolvimento a cada manhã para avaliar o trabalho que foi executado no dia anterior e priorizar aquilo que será implementado no dia que se inicia;

Refactoring: é utilizado para manter sempre o software o mais simples possível de ser manipulado sem que estas alterações no código possam afetar as funcionalidades que já estão implementadas;

Código Coletivo: a idéia é que o código seja comunitário a todos os desenvolvedores, permitindo assim que todos possam alterar o código quando necessário sem ter que pedir autorização de outra pessoa;

Código Padronizado: a fim de permitir que o sistema seja o mais homogêneo possível, a equipe deve estabelecer padrões de codificação, viabilizando assim a facilidade de qualquer manutenção futura;

Metáfora: técnica para transmitir idéias de formas simples, através de uma linguagem comum que é estabelecida entre a equipe e o cliente;

Ritmo Sustentável: é recomendável que os desenvolvedores trabalhem apenas 8 horas por dia a fim de garantir o máximo de rendimento e permitir a produção de software com a melhor qualidade possível;

Design Simples: optar sempre pela simplicidade do design, viabilizando a agilidade durante o desenvolvimento, dado que o feedback deve ser rápido ao cliente;

Integração Contínua: a equipe de desenvolvimento deve garantir a integração de seus códigos com o restante do sistema diversas vezes ao dia;

Releases Curtos: visa à disponibilidade de funcionalidades rapidamente ao cliente para que ele possa utilizar o software no dia-a-dia e se beneficiar dele.

Desenvolvimento Guiado pelos Testes: visa o desenvolvedor escrever testes para cada funcionalidade antes mesmos de começar a codificá-las, possibilitando eles aprofundar o entendimento das necessidades do cliente;

Abaixo a Figura demonstra as práticas e os principais ciclos do XP:

Práticas e princípios do XP

Práticas e princípios do XP

A idéia da utilização do XP é voltada para projetos cujos requisitos são vagos e mudam com freqüência, desenvolvimento de sistema orientado a objeto, equipes pequenas e de preferência até 12 desenvolvedores. Este desenvolvimento deverá atender o modo iterativo ou incremental, objetivando que o sistema comece a ser implementado logo no início do projeto e ao longo do tempo adquirindo novas funcionalidades.

Tags:, , ,
Publicado em Metodologia | Nenhum comentário »