Arquivo por categoria Frameworks de desenvolvimento

A Documentação no XP

No framework XP a documentação é minimalista na maior parte dos casos apenas o código fonte e os testes a compõem. Para a XP um código claro, simples e bem estruturado facilita a compreensão e mudanças no futuro. Com o auxílio de comentários relevantes o código é a melhor documentação que um software pode ter, além de não se desatualizar. Embora não seja muito indicada, extrair a documentação a partir do código é uma opção utilizada pela XP. Além do código pouco material é produzido apenas os radiadores de informação e os cartões de história.

Os cartões de história são feitos de papel e servem para que os clientes e usuários descrevam funcionalidades que desejam no sistema. Os progaramadores utilizam-nos para direcionar a implementação. Os radiadores de informação por sua vez são graficos e cartazes que demonstram a produtividade da equipe. Estes devem ficar expostos onde todos os membros da equipe e os clientes possam vê-los. Dentre os radiadores de informação o mais importante está a adoção do quadro de tarefas inspirado no Kanban.

Tags: , , , , , ,

O eXtreme Programming (XP)

O Extreme Programming é um framework de desenvolvimento de software, criada por Kent Beck, nos Estados Unidos no final da década de 1990. É uma das frameworks ágeis mais conhecidas e utilizadas no mundo.

As ideias originais do que viria a ser o XP foram definidas por Kent Beck em 1996 através do livro “Smalltalk: best pratice pattners” no qual apresentava pontos positivos e negativos de projetos de software. No mesmo ano Beck foi chamado para conduzir, juntamente com Martin Fowler e Ron Jeffries, um projeto de alto risco na Crysler, o projeto C3. Beck selecionou um conjunto de práticas que haviam se mostrado eficientes em outros projetos e aplicou-as de forma intensiva. A equipe gerenciada por Beck não só conseguiu entregar o software antes do tempo estimado como também criou o  XP (BASSI FILHO, 2008).

Em alinhamento com as idéias do Manifesto Ágil o framework XP se baseia em cinco valores (BASSI FILHO, 2008) que  são:

  • Comunicação – para que um projeto atinja seu objetivo com sucesso a comunicação deve ser intensa entre membros da equipe e os stakeholders;
  • Feedback – as respostas as decisões tomadas e ou mudanças no projeto devem ser rápidas, eficientes e vizíveis;
  • Coragem – é necessário muita coragem para aceitar erros, mudar pontos de vista, se desfazer de antigas idéias;
  • Simplicidade – o sóftware, resultante do projeto, deve ser tão simples quanto possível. Além disso deve-se levar em conta que muitas vezes o que o cliente quer é bem mais simples do que o desenvolvedor imagina;
  • Respeito – todos tem seu valor dentro da equipe e as individualidades não só devem ser respeitadas como também ser valorizadas.

Referências:

BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. São Paulo: USP – Istituto de Matemática e Estatística da Universidade de São Paulo, 2008.

Tags: , , , , , ,

O Quadro Kanban

Uma característica significativa do Scrum é que assim como no XP o enfoque dado à documentação é pequeno. Na maioria das vezes se resume a uma série de histórias de usuário – similares a casos de uso – afixadas em um quadro Kanban. O quadro Kanban é originário de um método, homônimo, de fabricação, orientado à produção em série e serve para facilitar a gerência do fluxo de produção. O desenvolvimento deste método é creditado à Toyota. Ele surgiu dentro do contexto do Just In Time do qual faz parte (PEINADO, 1999). O termo Kanban é uma palavra japonesa que significa literalmente registro ou placa visível que são características básicas do quadro.

O  Quadro Kanban

Fonte: RAHAL JUNIOR, 2011

A Figura acima representa o fluxo de tarefas no quadro Kanban. Uma história de usuário ou item de backlog é quebrada em varias outras menores que são adicionadas a coluna a fazer. Um membro da equipe escolhe um cartão de história, muda-o para a coluna fazendo. Após implementar, executar dos devidos testes de integração e considerar a tarefa como pronta ele então muda o cartão para coluna feito. Feito isto ele pega outro cartão na coluna a fazer reinicia novamente o ciclo. Isso se repetirá até que a equipe mude todas as histórias para a coluna feito.

Muitas vezes pode ocorrer confusão, pois alguns autores chamam o quadro de tarefas de quadro Scrum, e na realidade ele é praticamente igual ao quadro Kanban. De acordo com Kniberg & Skarin (2009) a principal diferença entre eles é que o Scrum deixa a equipe livre para configurar o fluxo de tarefas no quadro como bem entender. Já o Kanban determina que não devem haver mais de duas histórias em andamento simultaneamente.

Referências:

KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum. InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches > Acesso em 14 nov. 2010.

KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos. InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrum-minibook> Acesso em 14 nov. 2010.

RAHAL JUNIOR, Nelson Abu Samra . Melhorando o Entendimento “Como fazer?”. Disponível em: < http://blogdoabu.blogspot.com/2010/09/melhorando-o-entendimento-como-fazer.html >  acesso em 04 abr. 2011.

PEINADO, Jurandir. O papel do sistema de abastecimento Kanban na redução dos inventários. Revista da FAE, Curitiba, v.2, n.2, p.27-34, maio/ago. 1999.

Tags: , , , , ,

Os frameworks Ágeis de Desenvolvimento de Software

A maioria dos conceitos adotados pelos frameworks ágeis nada possuem de novo. A principal diferença entre essas frameworks e  as metodologias tradicionais são o enfoque e os valores. As frameworks ágeis enfocam as pessoas e não os processos ou algoritmos como as metodologias tradicionais. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com a implementação. Propiciando assim maior interação entre desenvolvedores e clientes (ALVES, 2009).

O Manifesto Ágil

Percebendo que a industria de software apresentava um grande numero de casos de fracasso, alguns lideres experientes adotaram modos de trabalho opostos às metodologias tradicionais. Nesse sentido em 2001, durante uma reunião realizada por 17 desses lideres, concluiu-se que desenvolver software é algo complexo demais para ser definido por um único processo. O desenvolvimento de software depende de muitas variáveis e principalmente é realizado por pessoas em praticamente todas as etapas do processo (BASSI FILHO, 2008). Nesse encontro chegaram a um concenso quanto a alguns princípios que levavam a bons resultados. Entretanto concluiram que uma metodologia unificada seria incapaz de atender todas as particularidades (SOUZA NETO, 2004). Desse trabalho surgiu o Manifesto Ágil cujo foco era o cliente e a agilidade no desenvolvimento de softwares.

O Manifesto Ágil valoriza quatro principios centrais, que resumem bem o foco do novo processo (BEEDLE, 2001).

  1. Indivíduos e interação entre eles mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Após a divulgação do Manifesto Ágil surgiram e/ou ganharam destaque uma ampla gama de novos frameworks Ágeis. Dentre as quais as mais conhecidas são eXtreme Programming (XP), a Scrum e a TDD. Essas frameworks mantem, entre si, muitas características em comum e geralmente diferenças sutis. De acordo com Pressman (2006) essas frameworks ressaltam quatro tópicos-chave: são equipes de desenvolvimento pequenas, entre 2 e 10 membros, que se auto organizam; priorizam mais o desenvolvimento em detrimento da documentação; reconhecem aceitam a mudança além de valorizarem e estimularem a comunicação tanto entre os membros da equipe quanto entre a equipe e o cliente.

Outras características não citadas por Pressmam mas que merecem destaque são o fato de serem mais utilizadas em projetos pequenos, embora possam ser aplicadas em grandes projetos. Além disso, assim como no PU os agilistas adotam o desenvolvimento iterativo a fim de maximizar o feedback e minimizar riscos.

Referências:

ALVES, Sérgio de Rezende; ALVES, André Luiz. Engenharia de Requisitos em Metodologias Ágeis.  Goiânia: Universidade Católica de Goiás (PUC – Goiás), 2009. Disponível em: < http://www.cpgls.ucg.br/ArquivosUpload/1/File/V%20MOSTRA%20DE%20PRODUO%20CIENTIFICA/EXATAS/10-.PDF > acesso em: 04 abr. de 2011.

BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. São Paulo: USP – Istituto de Matemática e Estatística da Universidade de São Paulo, 2008.

SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Belém: Unama – Universidade da Amazônia, 2004.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível em: <http://manifestoagil.com.br/>. Acesso em: 28 fev. 2011.

Tags: , , , , ,

A Equipe e os Papéis do XP

Uma equipe XP deve reunir o máximo possível de habilidades técnicas e de negócio possiveis para desenvolver o software. A hierarquia entre os desenvolvedores deve ser rasa e não é recomendável estabelecer uma divisão de tarefas. Inicialmente as responsabilidades são distribuidas de acordo com as especialidades de cada um mas gradualmente, espera-se que essas especialidades sejam disseminada entre os membros da equipe para evitar a concentração de conhecimento e contribuir para o crescimento profissional de todos os membros da equipe. Apesar disso existem papéis que determinados membros da equipe podem assumir. Nesse sentido os papéis mais importantes do XP são:

• Os programadores que são maioria dos membros da equipe;
• O coach que geralmente é o programador mais experiente da equipe e deve assegurar que seus membros estejam executando as práticas propostas e garantir que a metodologia esteja sendo seguida;
• O tracker é o desenvolvedor responsável por prover informações referentes ao progresso do projeto e por mostrar pontos que devem ser melhorados. É da responsabilidade do tracker elaborar os radiadores de informação.
• Na metodologia XP o cliente é considerado parte da equipe visto que ele conhece as regras do negócio, consegue definir prioridades funcionais do software e além de prover feedback do processo de desenvolvimento. Recomenda-se que o cliente esteja presente o tempo todo. Quando isto não for possivel o coach assume o papel de cliente proxy, responsabilizando-se por repassar informações ao cliente real.

Tags: , , , , , , , , ,

A Equipe e os Papéis no Scrum

O framework Scrum é formado por times scrum e os papéis a estes associados, time boxes (eventos com duração fixa) artefatos e regras. Os times scrum são configurados de modo a otimizar a flexibilidade e a produtividade. Por esse motivo os membros de um Time Scrum são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada grupo possui três papéis:

  • o Product Owner(PO) que é o responsável por garantir o retorno sobre o investimento (return on investment – ROI) do projeto. Ele representa e defende os interesses do cliente, é ele quem cria, prioriza e mantém a lista de funcionalidades (Backlog de Produto) do projeto. Para exercer a função de Product Owner deve-se ter visão estratégica, disponibilidade, criatividade, poder de persuasão, ser comunicativo e conhecer bem as necessidades dos clientes  –  muitas vezes esse papel pode ser assumido pelo cliente ou um representante do mesmo;
  • o Scrum-Master que é o responsavel por garantir  o uso do Scrum, remover impedimentos e proteger a equipe das interferências externas. Ele auxilia o product owner no processo de priorização dos requisitos. Deve ser responsavel, facilitador, humilde, comunicativo, influente e organizado.;
  • o Time Scrum que deve estimar o tempo e o esforço envolvido nos itens de projeto e definir as metas das Sprints, visando produzir produtos com alta qualidade e valor para o cliente. Deve ser multidisciplinar, comunicativo, comprometido, autogerenciado e capaz de resolver conflitos; normalmente é composto de 5 a 9 pessoas.

Tags: , , , , , , ,