Projetizando a Vida

Oi pessoal,

 Segue um post referente a um definição curta e rápida do que é Scrum.

 

Segundo Ken Schawber [Schwaber 2004], “Scrum simplesmente oferece um framework e um conjunto de práticas que guardam tudo visível. Isto permite aos praticantes do Scrum saber exatamente o que está acontecendo e fazer no local os ajustes para manter o projeto na direção dos objetivos desejados”.

A primeira experiência com o Scrum ocorreu em uma fábrica de automóveis, em que se constatou que a utilização de equipes pequenas e multidisciplinares produzia melhores resultados. Em analogia a essas equipes, associou-se a formação do Scrum a de um jogo de Rugby. A partir de 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

 

 Figura 1. Formação chamada Scrum em jogo de Rugby

 Martin Fowler, um dos maiores estudiosos em desenvolvimento de software, comenta em seu artigo A Nova Metodologia [Fowler 2008] que: “Nos últimos anos, vem crescendo rapidamente o interesse em metodologias ágeis (ou ‘leves’). Também caracterizadas como um antídoto contra a burocracia ou uma licença para ‘hackear’.

Estas metodologias despertaram os interesses em toda a extensão da indústria do software”.

Dentre as técnicas de utilização do Scrum, há a entrega de produtos em períodos de tempo pré-estabelecidos, nunca inferiores há uma semana ou superiores há trinta dias. Para estimular o contato entre empresa e cliente, os projetos são revistos em períodos regulares de tempo, a essas ações dá-se o nome de Sprint. Ao término de cada Sprint, o cliente recebe um conjunto de funcionalidades desenvolvidas e prontas para serem utilizadas. A melhor maneira de comprovar se o software atende às necessidades é fazer com que o cliente o utilize, apontando as qualidades e o que falta ser aperfeiçoado.

É importante destacar que a participação ativa do cliente no processo de desenvolvimento de software faz com que sejam atribuídas a ele algumas responsabilidades como definição das funcionalidades do produto, decisão quanto às datas de lançamento de conteúdo e ajuste de funcionalidades. Em desenvolvimento ágil a empresa não vê seu cliente como mero comprador de software, mas como um parceiro na pesquisa e no desenvolvimento do produto. E o Scrum é apenas um dos meios para alcançar esse objetivo.

 

Referências

Schwaber, Ken (2006) “Desenvolvimento Ágil utilizando SCRUM”, FAQ.

Fowler, Martin. (1991) “A Nova Metodologia”, http://simplus.com.br/artigos/a-nova-metodologia/#N2A3

Rahal, Nelson Abu Samra Junior e Santos, Marcelo dos (2008) “Você sabe o que é Scrum”, http://www.knowtec.com/index.php?m=ver&id_item=18

 

 

 

 

Obrigado Edmundo e um abraço a todos,

 

Abu

http://blogdoabu.blogspot.com/

http://www.abuzitos.com.br/

Já ouvi muita gente colocar o Agile Software Development como uma metodologia alternativa ao PMBOK, quando vejo isso fico em dúvida se dou risada ou se choro…

Primeiro porque não existe “Agile Management”,  Agile Software Development é na verdade um conjunto de metodologias de desenvolvimento, e dentro de cada uma delas, se quisermos ter sucesso precisaremos gerenciá-las da melhor forma possível.

Em segundo lugar porque o PMBOK não é, nunca foi e nunca vai ser uma metodologia, ele é um guia das melhores práticas de Gerenciamento de Projetos.

Ele é um livro que se for usado com bom senso será ume excelente base para a criação de uma metodologia de gerenciamento que poderá sim ser ágil e adequada ao Agile Software Development.

Querem um Exemplo Prático ?

Uma das metodologias ágeis que eu mais gosto é o SCRUM.

Por curiosidade, SCRUM é aquela formação que os jogadores de Rugbi fazem onde os dois times se apóiam ombro a ombro para lançarem a bola, não sei porque e nem quando, mas a estrutura é aquela e chama-se SCRUM…

Explicando de forma hiper-super-extremamente resumida, na metodologia SCRUM, o projeto é dividido em pequenos entregáveis, de forma que o sempre tenha algum módulo entregue e aprovado na pior das hipóteses a cada quinzena, o ideal é que essa entrega seja semanal.

Diariamente a equipe se reúne, numa reunião em pé,  na frente de um quadro negro (atualmente quadro branco, com pinceis ao invés de giz), com duração de 15 minutos para responder a apenas 3 perguntas:

* O que fiz desde ontem?

* O que estou planejando fazer até amanhã?

* Existe algo me impedindo de atingir minha meta?

Terminada essa reunião cada um já sabe o que tem que fazer, e todos vão ao trabalho.

Alem disso existem algumas características adicionais nos projetos de SCRUM:

* Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);

* Entregas freqüentes e intermediárias de causam reuniões freqüentes com os stakeholders (todos os envolvidos no processo) ;

* Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;

* Transparência no planejamento e desenvolvimento;

* Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;

Por isso deixo uma pergunta: Onde é que o SCRUM (assim como outras metodologias Ageis) está confrontando com o PMBOK?

Na minha opinião usar uma abordagem de Agile Software Development sem o Apoio do PMBOK é partir para um “Desenvolvimento Cowboy”,  ou seja,s e o bandido mexer, você  saca e atira, e torce pra ele não sacar mais rápido…

Mas voltarei a falar mais sobre SCRUM e vou convidar um amigo Nelson Abu Samra Rahal Junior, o Abu, especialista em SCRUM  e autor do Blog do Abu para fazer parte da  Equipe do Projetizando a vida, escrevendo com mais propriedade sobre o assunto.

Já trabalhei em Vários Projetos de em Empresas que tinham ou estavam implementando o CMMI e, invariavelmente, tive atritos com o “pessoal”  do CMMI.

Quem me conhece sabe que sou uma pessoa crítica, isso não quer dizer que sou “do contra”, que dizer apenas que não sou uma pessoa passiva, não aceito as coisas como elas são simplesmente por que são assim, quero saber porque são, isso faz parte do processo de aprendizado, pois somente assim podemos melhorar as coisas, e acredito que é assim que um Gerente de Projetos deve se portar, invariavelmente, entender as coisas, antes de aceitá-las ou recusá-las.

Mas voltando aos meus atritos com o “pessoal do CMMI”,  bom o primeiro atrito é com a existência de um “Pessoal do CMMI”, apesar “deles”acharem que sou contra o CMMI, sou um dos maiores entusiastas do CMMI, desde que sua implementação seja verdadeira, e para que ela seja verdadeira, ela deve ser implementada pela empresa toda e não pelo “pessoal do CMMI”, portanto sua existência já é, a meu ver, um sinal de algo errado, em segundo lugar na maioria dos locais onde vi sua implementação percebi um erro conceitual importantíssimo e por isso fui um crítico duro.

O CCMI, para quem não conhece é, a grosso modo,  um modelo que define a maturidade dos processos de desenvolvimento de software. Ele define 5 níveis de maturidade sendo que o nível 1 significa TOTALMENTE IMATURO, ou seja Caos Total, ou processos inexistentes, portanto o CMMI inicia-se no nível 2- Processos Repetitivos, passa pelo Nível 3 - Processos Definidos, Nível 4 - Gerenciado e finalmente Nível 5 - Otimizado.

Não existe uma obrigatoriedade das empresas escalarem os níveis 2, 3, 4 e 5, uma empresa pode (se for louca o suficiente, e trabalhei em uma que tentou isso) implantar direto o nível 5, normalmente as empresas iniciam na 2, escalam para a 3 e então pulam para a 5 (não conheço nenhuma  que tenha tirado o nível 4).

O grande problema quando se cria a “Turma do CMMI”  é que normalmente não existe ninguém da “Turma de Gerentes de Projeto” nesse grupo e “pequenos”  erros conceituais costumam acontecer.

O Pior deles é muito comum: O Objetivo do CMMI é PADRONIZAR PROCESSOS, e o que muitas vezes acontece é que as empresas acabam padronizando PRODUTOS. Ou seja, tornar os produtos IGUAIS.

OPS… Vamos fazer um Rewind, retomar a definição de projeto: “Projeto é um empreendimento TEMPORÁRIO que tem por objetivo produzir um PRODUTO ÚNICO, com um ORÇAMENTO previamente definido.”

Se vamos produzir PRODUTOS ÚNICOS, como é que vamos fazer PRODUTOS IGUAIS???

Podemos concluir que CMMI e Projetos são incompatíveis? Não, de forma alguma. O que podemos concluir é que precisamos envolver Gerentes de Projetos EXPERIENTES na definição dos processos de implementação do CMMI ou pelo menos permitir que os mesmos critiquem os mesmos durante a sua implementação, sem que sejam considerados anti-CMMI.

Vou Abrir uma categoria nova para os Textos do CMMI e voltarei a falar, futuramente, sem uma freqüência pré-determinada,  sobre cada um dos Processos, fazendo um paralelo sobre os Processos/Grupo de Processos do PMBOK.

Existem alguns documentos que deveriam ser tratados com mais seriedade, não apenas, mas principalmente em projetos, mas especificamente em projetos um dos documentos mais desprezados é o  Project Charter, ou o termo de Abertura do Projeto.

Quando terceirizamos um Projeto normalmente esse documento é feito, pois como praticamente todas as metodologias dizem que ele é obrigatória, ele consta no contrato, e portanto ele é feito, mas muitas vezes é feito “nas coxas” e na grande maioria das vezes (aprendi a nunca falar SEMPRE) ele é feito e depois ignorado, a menos que se tenha auditorias freqüentes (por exemplo de CMMI) quando então se lembra que ele existe, mas apenas isso…

Quando se fala num Projeto Pessoal então, ele é praticamente inexistente…

E não são apenas Gerentes iniciantes esquecem dele, querem um exemplo prático?  Esse blog não tem um Project Charter…  Ops!!! *rs

Pois é, e sua falta acabou trazendo problemas, por isso ele ficou abandonado um tempão, mas agora que resolvi retomá-lo, e com força total, começarei como deveria ter começado, farei um Project Charter (o nome em inglês parece impor mais respeito…*RS),  ele será colocado numa página a parte, em breve, ma hoje quero falar livremente sobre o que me levou a isso…

Por não ter esse plano o blog fugiu do controle, acabei seguindo o PMBOK a risca, nada contra ele, mas isso, além de deixar o blog ligeiramente chato  é desnecessário, existe o próprio PMBOK para isso, além de centenas de outras fontes,  vou finalizar a serie sobre o grupo de processos para não deixar algo inacabado,  mas tomarei outra linha daqui pra frente (que será refletida no Project Chart),  falarei sobre técnicas, metodologias e ferramentas, sobre situações práticas e meu objetivo será criar uma comunidade de Gerenciamento de Projetos, para isso abrirei o blog para outros Gerentes de Projeto que desejarem escrever, estou planejando um Forum de Discussões e mais alguns elementos para Transformar o Projetizando em uma Comunidade.

A Primeira Ação nesse sentido foi o lançamento do Domínio próprio:  PROJETIZANDO.COM.BR, este post está sendo replicado neste domínio e no domínio antigo projetizando.blgoprofissional.com.br, que a partir de agora deixa de ser o domínio principal, como ainda  tem bastante assinantes de feeds, postarei resumos periódicos, mas sempre direcionando para o novo endereço…

Enfim, esperem bastante novidades e muita informação em 2009.

Bons Projetos para todos.