terça-feira, 23 de dezembro de 2008

sexta-feira, 19 de dezembro de 2008

quarta-feira, 17 de dezembro de 2008

Pequenas empresas, grandes negócios - Software-livre

Como foi discutido na apresentação semi-final do grupo de rejuvenescimento, apresento aqui um vídeo falando sobre o crescimento de empresas empregando soluções de software-livre.

Note que é dito justamente o contrário ao que o grupo afirmou. O custo é muito menor em relação à softwares pagos...e nem precisa de tanto treinamento pois esses softwares-livre estão cada vez mais com uma interface similar aos demais.

terça-feira, 25 de novembro de 2008

Contrato de Escopo Negociável

Como foi discutido na nossa apresentação, e sugerido por Vinicius que nos deu o prazer de aparecer, aqui está o link para o contrato de escopo negociável feito pela ImproveIt. No site vocês ainda encontrarão um blog, um podcast e informações interessantes sobre Scrum e XP. Depois de corrigirmos alguns erros iremos postar a nossa apresentação aqui no blog.

quinta-feira, 20 de novembro de 2008

Relações entre as práticas do XP com os princípios e valores da Metodologia Ágil


Apenas uma imagem bacana que encontrei mostrando como estão organizadas as práticas XP dentro dos valores e princípios contidos no manifesto ágil

terça-feira, 18 de novembro de 2008

Evento sobre metodologias ágeis

Ocorrerá aqui em Aracaju um evento que falará sobre Metodologias Ágeis. Esse evento promovido pelo SergipeTec é muito interessante e vem sempre trazendo assuntos inovadores com uma abordagem bem dinâmica. Vale a pena conferir.

sexta-feira, 31 de outubro de 2008

A história do Ruby

Como foi dito durante a nossa apresentação o Ruby é uma linguagem de interpretada de script, orientada a objetos e dinamicamente tipada.

Ela foi criada por Yukihiro Matsumoto (Matz), em 1994, inspirada nas linguagens Python e Perl, com o objetivo de criar um linguagem poderosa, orientada a objetos, que fosse de fácil compreensão e fosse fácil de programar.

O Ruby é independente de plataforma, tendo diversas implementações, como por exemplo em Java (JRuby) e .NET (IronRuby e Ruby.NET), além das implementações para os sistemas operacionais mais utilizados (Windows, Linux e Mac).

As principais características das linguagem são:
  • A sintaxe é enxuta, quase não havendo necessidade de colchetes e outros caracteres.
  • Todas as variáveis são objetos, onde até os "tipos primitivos" (tais como inteiro, real, entre outros) são classes.
  • Estão disponíveis diversos métodos de geração de código em tempo real, como os "attribute accessors".
  • Através do Ruby Gems, é possível instalar e atualizar bibliotecas com uma linha de comando, de maneira similar ao APT do Debian Linux.
  • Code blocks (blocos de código), ajudam o programador a passar um trecho de instruções para um método.
  • Mixins, uma forma de emular a herança múltipla, sem cair nos seus problemas.
  • Tipagem dinâmica, mas forte. Isso significa que todas as variáveis devem ter um tipo (fazer parte de uma classe), mas a classe pode ser alterada dinamicamente.

quinta-feira, 30 de outubro de 2008

quarta-feira, 29 de outubro de 2008

Revista sobre processos ágeis

Durante nossa pesquisas encontramos uma revista que aborda o tema dos processos Ágeis, a Visão Ágil Esta revista está publica em formato eletrônico sob a licença creative commons, e vocês podem baixar todas as edições e distribuir livremente.
Neste site vocês também encontrarão um blog e uma lista de discussão bastante movimentados.

quinta-feira, 23 de outubro de 2008

Principais práticas das metodologias ágeis de desenvolvimento de softwares

Jogo do Planejamento – O desenvolvimento é feito em iterações semanais. No início de cada iteração a equipe se reune com o cliente para realizar o chamado Jogo do Planejamento. No Jogo o cliente propõe as funcionalidades que ele deseja, as chamadas estórias. Os programadores avaliam a dificuldade de implementar cada funcionalidade. Com essa estimativa o cliente prioriza as tarefas mais importantes para realizar na iteração.

Pequenas Versões – Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção. Com essa prática se busca a medição do cliente do quanto já foi feito; a possibilidade de que se o projeto não terminar, várias partes já foram desenvolvidas e são funcionais; e principalmente o feedback rápido do cliente para detectar problemas ou informar que uma funcionalidade não atendeu a real necessidade.

Projeto Simples – No desenvolvimento ágil a complexidade do sistema deve ser sempre reduzida. Usa-se as tecnologias, designs, algoritmos e técnicas mais simples que permitirão atender aos requisitos do cliente. Qualquer complexidade deve ser removida assim que descoberta. Qualquer design, processo ou código criado pensando nas próximas iterações devem ser descartados.

Equipe Coesa – No desenvolvimento ágil o cliente faz parte da equipe de desenvolvimento. A comunicação com o cliente é crucial em projetos ágeis. Em vários ramos de metodologias ágeis, é o cliente quem exerce o papel de gerente do projeto, resolvendo os problemas referentes as regras de negócio. Para evitar distorções nas informações os desenvolvedores devem sanar suas dúvidas diretamente com o cliente.

Refatoração – Não existe uma etapa isolada para modelagem, o código é a modelagem. O design é melhorado continuamente através de refatoramento. Passos de refatoramento melhoram, incrementalmente, a estrutura do código, sem alterar sua função. No desenvolvimento ágil os testes são obrigatórios, assim elimina o medo de que o sistema irá deixar de funcionar por causa de um refatoramento. Sempre que um desenvolvedor perceber uma complexadade ou inclareza no sistema, deve-se refatorar o código e criar os devidos testes.

Integração Contínua – Várias vezes ao dia o desenvolvedor deve integrar suas alterações, sincronizar ao repositório principal e executar todos os testes. A adoção dessa prática estimula design simples, tarefas curtas, agilidade, feedback sobre o estado atual do sistema e principalmente encontrar conflitos e erros de design rapidamente.

Metáfora – As equipes mantêm uma visão compartilhada do funcionamento do sistema. Para a padronização do sistema com os outros membros da equipe, são criadas analogias das funcionalidades que se refletem na escolha dos nomes de métodos, classes, campos, etc. Além de sempre buscar fazer analogias próximas a linguagem natural do cliente para facilitar a comunicação com o mesmo.

Desenvolvimento Orientado a Testes – Antes de digitar qualquer linha de código, o desenvolvedor deverá refletir sobre a implementação e escrever o devido teste para validá-la. 100% do código deve ser coberto por testes. O teste deve ser feito obrigatoriamente antes de qualquer codificação ou refatoração. Todos os testes são executados automaticamente, o tempo todo.

Ritmo Sustentável – O desenvolvimento ágil busca entregar software com o máximo de qualidade e satisfação do cliente, e para isso usa o máximo de produtividade dos desenvolvedores. Para isso o ritmo deve ser sustentável com 40 horas/semana, 8 horas/dia, sem horas extras. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

Programação em Par – A mais polêmica das práticas, no desenvolvimento ágil a programação é realizada sempre com uma dupla de programadores em um único computador. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado. Além disso a programação em par possibilita: simplicidade, coesão, padrão de codificação, refatoração, reflexão sobre a funcionalidade antes de codificá-la, aprimoramento do conhecimento técnico da equipe e a cobrança para que os testes sempre sejam escritos.

quarta-feira, 15 de outubro de 2008

Demoramos mas vamos começar!!!

Este é o primeiro blog que a maioria do nosso grupo está criando. Por isso estamos atrasados em relação aos demais colegas. Mas, como o nome do nosso grupo já diz, os "Ligeirinhos" vão correr atrás do prejuízo e bombardear este blog de conhecimento. Esperamos contribuir com todos os colegas e trazer muita informação para este nosso pequeno espaço.

Bem, nosso grupo vai passar para esse blog tudo que conseguirmos absorver sobre Metodologias de Desenvolvimento Ágeis. Conceitos, métodos de trabalho, áreas importantes de aplicação, aquilo que for de novidade nesta área. E para iniciar, vou transcrever os 12 princípios do desenvolvedor ágil. Estes princípios, todos podem encontrar na página http://agilemanifesto.org/. Lá, depois que mostrarmos para vocês um pouco das Metodologias de Desenvolvimento Ágeis, vocês se apaixonarão e com certeza assinarão esse manifesto.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity - the art of maximizing the amount of work not done - is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

PRONTO, É ISSO!!!