Protesto!!!

Pessoal, infelizmente essas coisas acontecem. Venho aqui deixar o meu protesto pela falta de compromisso da Universidade com o curso de Comunicação Social da instituição.

Click na imagem para ser direcionado ao blog do movimento e entendam o porque!

=/

"Getting Real"

Ai pessoal, pra quem quer começar a abrir a mente para as metodologias ágeis, recomendo a leitura do livro Getting Real da 37signals, já tem a versão traduzida para o português. =]

Segue o link pra vocês: Getting Real

Boa leitura. xD

Termos do Scrum - Artifacts

Terminando esse assunto abordando os "Termos do Scrum", falaremos agora sobre os Artefatos utilizados nesse método de desenvolvimento.

• Product Backlog

É uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

• Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

Bom,

Acho que sobre Scrum é isso. =]

Fonte: Product Backlog e Sprint Backlog

xD

Como funciona o Scrum:
O Scrum Master é um facilitador para Scrum Team quando este encontra impedimentos no decorrer de uma Sprint.

Termos do Scrum - Meetings (parte 2)

Continuando ...

• Sprint Review Meeting

"Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint".

• Sprint Retrospective

"O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar".



Na foto, ta o Sprint Retrospective depois da nossa primeira sprint. Fizemos numa folha A4 e escrevemos (cada membro do Scrum Team) as coisas boas e ruins ocasionadas no decorrer do desenvolvimento dessa primeira sprint.

P.S. >>> Qualidade da foto horrível. xD

Fonte: Sprint Review Meeting e Sprint Retrospective

CPU 2009 - VII Edição

O Campeonato de Programação Universitário – CPU é um campeonato realizado pela Empresa Júnior de Computação da UESC – TecnoJr, destinado aos alunos do curso de graduação na área de Computação e afins (Ciência da Computação, Engenharia de Computação, Sistemas de Informação, Matemática, etc.) com o objetivo de:

• Estimular o interesse pela programação de computadores.
• Aumentar a integração aluno‐empresa.
• Proporcionar a prática nas disciplinas de programação.
• Proporcionar desafios aos estudantes das Faculdades ou Universidades da região.
• Estimular o trabalho em equipe.

Esse ano o CPU ocorrerá no dia 04 de maio na Universidade Estadualde Santa Cruz (UESC), em paralelo com a ERBASE que ocorrerá entre os dias 4 e 8 de maio.

Mais informações no site do evento.

O Scrum Master

=]

Termos do Scrum - Meetings (parte 1)

Continuando com os termos utilizados no Scrum, hoje falaremos sobre as Reuniões (Meetings) que as equipes que utilizam essa metodologia participa.
Vamos lá:

• Daily Scrum

"A cada dia do Sprint a equipe faz uma reunião diária (Daily Scrum). Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia".

De uma forma "ideal", essas reuniões deve ser feitas logo pela manhã, seguindo o mesmo horário sempre. Isso é feito pra que se possa estabelecer as atividades do novo dia de trabalho. No nosso caso (eu, Pablo e o nosso orientador Carlão), fazemos nossas reuniões em dias alternados na semana sempre no horário da noite, isso porque você deve adaptar a sua equipe de desenvolvimento ao melhor horário cabível aos membros.

Essa reunião serve para deixar todos os membros da equipe ligados no que está acontecendo no projeto e não para resoluções de problemas. "Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas":

• O que você fez ontem?
• O que você fará hoje?
• Há algum impedimento no seu caminho?

No nosso caso as perguntas são:

• O que você fez?
• O que você fará até a próxima reunião?
• Quais os impedimentos?

Perceba que as perguntas seguem o mesmo padrão, a diferença que existe é porque nossas reuniões não são "diárias".

Assim "a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível".

• Sprint Planning Meeting

"O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner (Sr. Manoel da padaria), o Scrum Master (Pablo) e todo o Scrum Team (eu, Pablo e Carlão), bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting (falaremos mais tarde) em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer".

Fonte: Daily Scrum e Sprint Planning Meeting

ERBASE 2009

9ª Escola Regional de Computação Bahia-Alagoas-Sergipe

Data: de 04 a 08 de maio de 2009
Local: Universidade Estadual de Santa Cruz - UESC - Ilhéus, BA

Maiores informações podem ser encontradas no site oficial.

Termos do Scrum - Roles

Várias funções são definidas no Scrum. Essas funções podem ser relacionadas com os Roles (Papéis), Meeting (Reuniões) e Artifacts (Artefatos).

Hoje falaremos sobre os Roles:

• Product Owner

"O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos."

• Scrum Master

"O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Srum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe."

• Scrum Team

"O Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações."

Fonte: Product Owner, Scrum Master e Scrum Team

Scrum Process

Como falamos, o "Srum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo":

Fonte: Improvit

Scrum

Scrum é um método ágil para Gerenciamento de Projetos.

Inicialmente, ele foi criado para gerenciamento de projetos em empresas de automóveis e bens de consumo. Foi concebido por Takeuchi e Nonaka no artigo "The New New Product Development Game".
A base desse método, é que a utilização de equipes pequenas e multidiciplinadas, produziam melhores resultados do que vinha acontecendo comumente.

"A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como eXtreme Programming (XP) e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento".

Fonte: Wikipédia

eXtreme Programming: Visão Geral (parte3)

Bom pessoal,
Seguindo o que temos falado sobre o XP, além dos valores citados no post abaixo, temos também algumas práticas:

• Cliente Presente
• Jogo do Planejamento
• Stand Up Meeting
• Programação em Par
• Desenvolvimento Guiado por Testes
• Reafactoring
• Código Coletivo
• Código Padronizado
• Design Simples
• Metáforas
• Ritmo Sustentável
• Integração Contínua
• Releases Curtos

Vale ressaltar que essas práticas são as ideiais para esse tipo de metodologia de desenvolvimento de softwares, mas se por acaso a programação em par por exemplo não funcionar com sua equipe, aborte essa prática e posteriormente, tente aplica-la no conjuto das práticas que você já usa. Não force sua equipe a trabalhar com algo que não surte efeito, lembre-se: a "satisfação dos membros da sua equipe, vale mais do que ferramentas ou métodos utilizados".

Ahhh, falaremos mais sobre essas práticas em outros posts. =]

eXtreme Programming: Visão Geral (parte2)

Continuando com a visão geral sobre o XP, veremos agora que ele baseia-se em 4 valores fundamentais:

• FeedBack
• Comunicação
• Simplicidade
• Coragem

Falamos no post anterior que o cliente aprende com a suas necessidades a partir do momento que ele passa a manipular o sistema sendo desenvolvido. Com isso, ele gera o nosso primeiro valor (FeedBack).
O FeedBack é o mecanismo fundamental, onde o cliente conduz o desenvolvimento do sistema de forma que a equipe direcione as suas atenções e ações para aquilo que o cliente acha que tem mais valor.
Assim, para que o cliente possa compartilhar do seu aprendizado no decorrer do desenvolvimento com a equipe, é necessario que haja um canal de comunicação entre eles. Essa comunicação "permite que todos os detalhes possam ser tratados com a atenção e agilidade que merecem". Portanto, a comunicação deve ser da forma mais direta e eficaz, buscando aproximar os indivíduos envolvidos no processo.
O outro ponto de valor crucial para que tudo possa ocorrer bem com o desenvolvimento, é a simplicidade. Com ela nós podemos garantir que o cliente possa aprender durante o projeto gerando assim um feedback rápido. É necessário aprender que o valor da simplicidade nos ensina que devemos implementar apenas aquilo que é suficiente para atender a necessidade do cliente. Traduzindo de um outro modo, devemos implementar somente aquilo que resolve o problema de hoje, problemas futuros devem ser resolvidos no futuro.
Por último, nossa "equipe precisa ser corajosa e acreditar que. utilizando as praticas e os valores do XP, será capaz de fazer o software evoluir com segurança e agilidade". Isso porque o sistema é feito de forma incremental, a equipe diverssas vezes irá realizar manutenção do software criando outras funcionalidades. Assim, pode ocorrer de alterar algo que já vinha funcionando com precisão, o que leva a riscos e falhas.

eXtreme Programming: Visão Geral (parte1)

Extreme Programming, mais conhecido como XP, é um processo de desenvolvimento de software que tem como meta a criação de softwares de alta qualidade, econômica, de uma forma ágil e flexível.
Ele concentra esforços da equipe para o desenvolvimento de atividades que geram resultados rapidamente na forma de um software que foi criado e testado segundo as necessidades impostas pelos usuários. Este modelo de desenvolvimento, elimina atividades redundantes reduzindo assim os riscos de atraso e estouro de orçamentos, priorizando a interação com o cliente de forma a estabelecer uma relação de confiança.

Este processo de desenvolvimento é voltado para softwares que:

• seus requisitos são vagos e mudam com frequência.
• desenvolvimento orientado a objetos.
• equipes pequenas, no máximo até 12 membros.
• desenvolvimento incremental, onde o sistema começa a ser implementado logo no início do projeto, ganhando novas funções no decorrer do tempo.

A premissa na qual o XP segue é que o "cliente aprende sobre as suas necessidades, na medida que é capaz de manipular o sistema que está sendo produzido". Assim o cliente a cada dia que passa, re-avalia o sistema seguindo a suas necessidades e orienta os desenvolvedores (feedback) segundo as mudanças necessárias que devem ser incorporadas no software.
"O XP busca assegurar que o cliente receba o máximo de valor a cada dia que passa."

Manifesto Ágil - O começo de tudo

O manifesto ágil foi assinado em 2001 pelos principais profissionais veteranos na área de desenvolvimento de softwares. Eles se uniram para discutirem uma nova forma para melhorar a velocidade no desenvolvimento de seus sistemas tendo como base as suas experiências de anos programando.

Dentre os envolvidos nesse manifesto, encontra-se:
• Kent Benck - Criador do eXtreme Programming*
• Ken Schwaber - Criador do Scrum*

Embora muitos desenvolvedores sejam contra esta metodologia, pois pode causar confusão dependendo do tamanho da aplicação, muito já são adeptos dos 4 principais conceitos do desenvolvimento ágil.

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

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Mais informações sobre esse movimento, você pode encontrar no site oficial do manifesto.

* Falaremos mais tarde sobre eles

Início

Bom pessoal,

Meu nome é Hebert e sou graduando em Ciências da Computação.
Comecei agora a ter contato com metodologias ágeis e por isso resolvi criar esse blog para que assim possa consolidar conhecimentos sobre este movimento que vem crescendo muito.

Claro que aqui não será nada de profissional, teremos assuntos voltados para essa área assim como comentários relacionados com a experiência que estou tendo adotando essa metodologia no meu projeto de conclusão de curso.

É isso ai...

Att