A programação do evento pode ser conferida aqui, e para maiores informações sobre o evento acesse aqui.

O mesmo pode ser baixado, de graça aqui.

Vi aqui.

Uma das coisas que mais dificultam para quem está començando no agile é o fato de não haver nenhum manual dizendo exatamento o que você deve fazer. Você tem que experimentar e continuamente adaptar o processo até que ele se encaixe na sua situação específica.

Este livrooferece a voc6e um ponto de início, através de um conto detalhado sobre como uma empresa sueca implementou Scrum e XP com um time de aproximadamente 40 pessoas e como ele continuamente melhoraram seu processo ao longo de 1 ano.

Sob a liderança de Henrik Kniberg eles experimentaram diferentes tamanhos de time, diferentes tamanhos de sprint, diferentes definições para “feito”, diferentes formatos para o product backlog, diferentes estratégias de testes, diferentes modos de realizar demonstrações, diferentes modos de sincronizar múltiplos times de Scrum, etc. Eles também experimentaram práticas XP – diferentes modos de fazer builds contínuos, programação em par, test driven development, etc e também omo combinar tudo isso com Scrum.

As restrições de seu time podem ditar formas diferentes de configuração das práticas (e até mesmo comprometimento), mas aqui está um exemplo de como alcançar o processo de “melhoria contínua” que fará seu processo ágil o melhor para você.

Descrição retirada do site InfoQ.

O download pode ser feito aqui, basta se registrar no site InfoQ.

Bom mas o que tudo isso quer dizer?

Fazendo um ganho ao post de James Shore, onde relata sobre o declínio do movimento ágil. Falando bastante sobre Scrum, que graças ao Scrum Aliance e a WEB, virou o buzzword ou o hype como queira chamar, sempre que alguém pensa em ágil vem a cabeça Scrum, ou seja Scrum passou ser o caminhão chefe do movimento ágil, por sua mídia estar em alta.

Porém nem sempre estar em alta é bom, principalmente falando em tecnologias, metodologias e ou práticas.

Vamos ao caso do declínio do movimento ágil, citado por James Shore, que segundo ele o problema é muito simples, as pessoas querem direto o resultado, sem ter mério te alcançar eles. O buzzword do Scrum é visível, da noite para o dia empresas passaram a adotar, especialistas começaram a surgir dos lugares mais obscuros, rápidamente. Os projetos passaram a aplicar, metodologias ágeis, ter iterações, mettings. Porém não são algumas etapas que fazem aplicar uma metodologia de gerenciamento de projetos, e sim o conjunto delas que leva ao sucesso.

Ou seja, essas empresas que resolveram aplicar rapidamente nos seus projetos, uma metodologia ágil, estão pagando um preço caro agora, por não conseguir aplicar todas etapas, logo os resultados de sucesso que estão descrito em diversos post’s e artigos ao longo da internet, não chegaram para essas empresas, logo a culpa é do movimento agile!

E é o mesmo que a empresa aplicar os conceitos do PMBOOK, só por ter um PMP no seu grupo de trabalho, ou seja, não adianta falar e não fazer.

No software temos a liberdade de desenvolvermos da forma que quisermos, logo o Scrum entrou com bons olhos, já que para aplicar XP teria que seguir algumas técnicas, como desenvolvimento orientado a testes, programação em pares. O Scrum sendo focado apenas no gerenciamento, deixa livre para aplicar as técnicas que se quiser no desenvolvimento do projeto, porém do que adianta termos técnicas para gerenciar o projeto e o desenvolvimento continuar sendo voltado a bug’s, gambiarras e a abaixo de pau.

Resumindo, não sou ninguém para estar comentando sobre, porém a pouco tempo me vi, assim como muitos, apaixonado pelo hype Agile, acompanho a algum tempo o movimento, e me identifiquei bastante por achar que o padrão normal (cascata) de desenvolvimento não se aplica a software.

Em uma tentativa frustrada tentei levar para a empresa o Scrum, o porque frustrada?

Recebi o aval dos patrões para aplicar o mesmo no projeto que estava e junto com o gerente do meu projeto comecei a passar a idéia para ele de como deviamos proceder, o que iria mudar…

Tudo estava lindo, tínhamos montado um bom project plan, o product backlog estava montado, e passamos para o gerente de projeto, passar para junto com o cliente aplicar a priorização, e juntos montarmos o primeiro Sprint.

Primeiro Sprint pronto, e voltamos ao modelo antigo, novos requisitos entrando e tendo que ser feito, sem a possibilidade de cancelar o Sprint que começará, logo o que estava sendo aplicado?

Nada, era uma salada de fruta que começou só a atrapalhar as coisas, resolvi mudar, nada mais de Scrum.

Conclusão, Scrum como ele mesmo descreve, precisa da participação de todos ao longo do desenvolvimento, e nós não estávamos aplicando Scrum, e sim apenas alguns processos do Scrum.

Podia eu culpar o Scrum, mas sei que ele é bom e funciona e não desisti de tentar aplicar o mesmo, só aguardo o dia que esteja em uma posição que consiga envolver os outros ou que meu gerente de projeto, assuma o papel de project master.

São alguns deles:

• Cliente é de outro país, ou seja contato do cliente com o desenvolvedor é impossível;
• Os “gerente de projetos”(são as pessoas que tem contato com o cliente) são de outro país também;
• Recursos realocados, ou seja não existe recursos fixos nos projetos eles são sempre realocados conforme demanda e conforme a prioridade;
• Infra-estrutura, complica como na utilização do Dashboard, os times não estão reunidos em um mesmo local físico, logo não conseguem compartilhar o mesmo Dashboard, assim como para fazer as reuniões diárias;
• Reuniões diárias, está difícil de ocorrer devido a nem todos estarem comprometidos em aplicar a metodologia ou assim como falta de entendimento da mesma;

Porém no final das contas nem tudo está sendo negativo apesar de existir alguns fatores que estão complicando um pouco a maioria está ajudando muito no desenvolvimento do projeto.

Normalmente na organização a qual participo, não existia estimativas e resultados rápidos ou seja, o gerente de projeto, mesmo sem falar com a equipe já tem definido o dead line do projeto, assim como quem serão os recursos. Acontece com isso que, muitas vezes o dead line imposto pelo gerente de projeto, não atende a necessidade, ocorre “correria” entre os desenvolvedores que passam a aumentar sua jornada diária assim como abrir mão de finais de semana, e por conseqüência de tudo isso a qualidade do software passa a ter quedas drásticas, as famosas gambiarras, surgem e tem quaze 100% de chance de continuar a ficar no código até o encerramento do projeto, assim como pelo resto da existência desse software.

Porém no projeto que estamos trabalhando, e utilizando algumas práticas de Scrum, criamos inicialmente a lista de funcionalidades o famoso Product Backlog, e enviamos para o gerente de projeto que repassou para o cliente o mesmo estimou e conversou junto com o gerente de projeto o que era prioridade para esse projeto. Definido isso o gerente de projeto repassou para nós esse documento, e equipe que no início do projeto na parte de desenvolvimento era composta apenas de uma pessoa(eu), estimou as funcionalidades que estavam marcadas como alta na prioridade e que se julgou capaz de fazer em um período de 15 dias úteis, por desconhecer um pouco da tecnologia a ser utilizada, a estimação acabaram ficadas um pouco erronias, e colocamos para a primeira interação, preparamos então o primeiro Sprint, quebrando as funcionalidades em tarefas a serem feitas.

Durante o primeiro Sprint, diversas dúvidas sobre o projeto foram surgindo e as mesmas não estavam esclarecidas no brifieng preparado pelo gerente de projeto junto com o cliente, logo definimos que todas as dúvidas existentes que pudesses serem um empecilho para continuidade de uma tarefa, deveria ser anotada e mandada para o Gerente de Projeto, esse deveria repassar para o cliente para ele conseguir saciar essas nossas dúvidas. Esse atividade foi muito funcional, as coisas foram ficando mais esclarecidas, junto de uma prática que resolvemos aplicar, toda sexta-feira uma nova versão da aplicação em desenvolvimento é posta em um servidor que o gerente de projeto assim como o cliente tem acesso, com isso eles recebem um feedback de como as coisas estão indo e como estão sendo feitas. Isso nos ajudou muito a não perder o foco do Sprint, pois as dúvidas repassadas para o cliente poderia se tornar sim requisições de novas funcionalidades, e com as versões sendo mostradas para ele, era possível perguntar sobre o que realmente o queria naquela funcionalidade, mantendo o foco na interação.

Chegamos ontem ao fim do primeiro Sprint, todas tasks listadas neles foram completadas, as estimações como falei foram um pouco erradas pois o prazo de término era hoje, que nos daria um total de 8horas para fazermos mais tarefas. Porém mesmo assim foi muito satisfatório, já é possível usar boa parte do site, o cliente ficou feliz com o primeiro resultado, pediu algumas mudanças que serão feitas, e algumas novas funcionalidades, nada fora do comum. Todas elas foram postas no Product Backlog, e estão aguardando para o próximo Sprint.

Vamos ver como segue essa aventura, agora que o time de desenvolvedores por sua vez também aumentou, agora são 2 pessoas a desenvolver, em um total de 6 pessoas envolvidas no projeto. Com isso a comunicação aumenta, vamos ver como vamos conseguir controlar isso. Porém tenho boas esperanças de o projeto se sair muito bem, e de conseguirmos convecer de o Scrum fazer parte da vida da empresa.

Conteúdo Programático:

• A utilização prática de Scrum;
• A essência de como conduzir um projeto da forma correta;
• Como criar um Product Backlog;
• Porque um Gerente de Projetos não pode simplesmente gerenciar cronogramas;
• Como liderar times experientes e novatos;
• Como escalar Scrum em projetos multi-sites com times com milhares de participantes envolvidos;
• Dicas de como conduzir a aplicação de Scrum na sua empresa;

Instrutor:

Alexandre Magno é líder de projetos de software onde utiliza principalmente metodologias e processos ágeis. Atua na área de software há mais de 15 anos, já tendo participado de projetos de variadas dimensões de lead time, escopo e investimento. Foi o primeiro, e atualmente único, CERTIFIED SCRUM TRAINER do Brasil, possuindo ainda certificações dos fornecedores IBM e Borland, e dos grupos OMG e PMI. Magno é o fundador do grupo Scrum-Brasil e atualmente é responsável pela área de Agile da Caelum. (retirado do blog de Alexandre Magno).

Eu já fiz minha inscrição, considero uma boa oportunidade de adquirir conhecimento sobre um framework para gerenciamento de projetos, principalmente para aqueles profissionais que atuam na área de desenvolvimento de software, e o melhor que não é sempre que ocorre esse tipo de treinamento na região sul do Brasil.

Eu indico passar essa leitura para seu chefe, para ajudar a convecer ele que Desenvolvimento de Software não é igual a Engenharia Civil. E desenvolvimento rápido e contínuo, é o que o cliente espera, ou seja resultados rápidos focados no que o cliente realmente quer. E com o Scrum por não ter uma abordagem técnica, é possível tentar convecer o seu chefe de que é possível utilizar ele ou passar a ideologia para uma pessoa que consiga convecer ele.

Para chegarmos nos Sprints é definido um Product Backlog pelo cliente que no Scrum é chamado de Product Owner. O resultado do trabalho do Product Owner é o Product Backlog, que é uma lista de tarefas que devem ser feitas, sendo essa lista constantemente alterada e redefinida as prioridades a serem feitas.

Antes de cada Sprint as prioridades definidas pelo Product Owner é passada para o Sprint Backlog. Recebendo esse Sprint Backlog o Scrum Team que é consistente de 2-9 pessoas, discutem sobre o mesmo entre eles e junto com Product Owner, determinando e priorizando as funcionalidades a serem feitas, e quebrando ela em diversas tarefas para serem executadas. Sendo essas tarefas auto-organizáveis ou seja não existe uma delegação de quem deve fazer a tarefa, qualquer membro do time pode delegar uma tarefa para si mesmo.

Para manter o jogo na ordem nada melhor que um treinador, no Scrum o treinador é o The Scrum Master, ele trabalha ao pró do projeto, não deixando que nada possa atrapalhar o mesmo, assim como auxiliando alguma dificuldade que venha a aparecer. Priorizando sempre que o Scrum Team consiga realizar as tarefas dos Sprint. Esse papel “The Scrum Master“, é o que chega mais perto do que temos hoje de Gerente de Projetos.

A cada Sprint realizado pode ser adicionado novas funcionalidades e melhorias no produto, para chegar ao resultado que o cliente espera, para isso é redefinido o Sprint Backlog e recomeçado um novo Sprint para chegarmos ao resultado que o cliente deseja.

A essência do Scrum é simples e real, o mundo sofre mudanças constantes e projetos não é diferentes, dificilmente temos escopos fixos, os escopos sempre tem que ser mudados. Principalmente no desenvolvimento WEB, onde grandes projetos normalmente não passam de idéias dos clientes, não tendo todos os requisitos necessários para começarmos um projeto utilizando outras metologias, como o PMI. Não que não seja possível, é tão possível que é utilizado, porém o trabalho do gerente do projeto, fica muito complexo, alterações na documentação do projeto são constantes, assim como os riscos do projeto é alto, e por fim muitas vezes os resultados que são gerados não é o que o cliente esperava.

Scrum de uma maneira simples e rápida, tenta evitar esses tipos de frustrações ele prioriza no que é preciso, o resultado esperado pelo cliente, e trabalha em cima desse resultados de maneira constante, em pequenos pedaços (Sprint’s), vai chegando ao produto final, tal como o cliente esperava.

Pretendo dar sequência nos post’s, sobre gerênciamento de projetos e Scrum e nos dos Scrum detalhar mais, esse foi apenas para conhecer um pouco sobre o Scrum.