Scrum – Controles e papéis

Conforme falei no último post hoje continuo falando sobre Scrum. Desta vez somente sobre os controles e papéis utilizados na hora de aplicar o Scrum com uma equipe de projetos.

Controles utilizados

Um projeto de software gerenciado por meio do Scrum é controlado pelo estabelecimento, manutenção e monitoração de alguns parâmetros essenciais de controle descritos abaixo:

  • Backlog – identificação de todos os requisitos que deveriam ser implementados para a versão completa do produto.
  • Objetos e components – código reutilizável.
  • Pacotes – grupo de objetos que completam a implementação de um item do backlog.
  • Problemas – pendências que devem ser resolvidas para que um item do backlog seja implementado.
  • Questões – coisas que devem ser resolvidas e priorizadas em relação aos intens do backlog.
  • Soluções – resolução de uma questão ou problema.
  • Mudanças – as atividades que são realizadas para a resolução de um problema.
  • Riscos – o risco associado a um problema, questão ou item do backlog.

Todos esses controles deverão ser medidos, relacionados e rastreados durante o projeto. Entre eles, o backlog e os riscos são os principais controles e serão desenvolvidos e aprimorados durante o decorrer do projeto conforme as necessidades que se apresentarem.

Papéis

Existem apenas três papéis no Scrum: Product Owner, Team e ScrumMaster.

As responsabilidades de gerenciamento do projeto são dividas entre essas papéis.

1.Product Owner

O Product Owner representa os interesses de todos os envolvidos com o projeto e todos os que terão seu trabalho influenciado direta ou indiretamente pelo sistema resultante. Ele será responsável por criar a lista inicial de requisitos, chamada de Backlog, estabelecer os prazos e prioridades de cada Sprint e limites de custo do projeto.

2. Team

O Team representa a equipe que estará trabalhando no desenvolvimento do projeto. As equipes que trabalham com o Scrum deveriam ser auto organizáveis e auto gerenciáveis, portanto é de responsabilidade deles transformar os itens do Backlog em funcionalidades entregáveis nos vários Sprints realizados.

3. ScrumMaster

O ScrumMaster é o responsável por ensinar como se trabalhar com Scrum aos envolvidos no projeto, implementar as práticas de Scrum de acordo com a cultura da empresa e certificar que todos estão seguindo as regras e práticas do Scrum.

Scrum – Introdução

Quando eu estava na faculdade me perguntava o porquê da utilização de um processo de software. Organização, qualidade de software, definição de um processo foram algumas das justificativas que os meus professores me apresentaram nas aulas: tudo muito vago.
Se eles tivessem feito com que eu e os meus colegas de classe tivéssemos que desenvolver um projeto em conjunto, no qual cada parte fosse interdependente, teriam nos convencido e nos ajudado a entender a necessidade da utilização de uma metodologia de desenvolvimento.
No último evento de TI que participei – TDC 2008 – ouvi falar muito de Scrum e achei que se encaixava perfeitamente com o objetivo do blog por ser um framework que centra a maioria das atividades na colaboração entre os membros da equipe de do projeto.
Mesmo para quem já utiliza um processo de desenvolvimento, o Scrum traz várias técnicas interessantes para otimizar o teamwork e a utilização de processos iterativos.

Uma pequena introdução

Scrum é o uso conjunto de um processo de desenvolvimento de software iterativo e incremental com métricas utilizadas como controle do processo de desenvolvimento.
Foi apresentado à OMG em 1996 por Jeff Sutherland e Ken Schwaber  trazendo como diferencial dos processos iterativos e incrementais já existentes a utilização do controle empírico das atividades de projeto.
A escolha deste modelo de controle é baseada no fato de que a construção de um software apresenta, na maioria das vezes, um problema de alta complexidade com necessidade de altos níveis de precisão. Com isso, o processo de desenvolvimento de software traz inúmeras possibilidades e restrições tornando-se algo imprevisível e impossível de ser controlado por processos de controle definidos.

Regras e características principais

As regras e características do Scrum remetem a simplificação de cada atividade do processo de desenvolvimento de software.
Para o sucesso da sua utilização deve-se: sempre ter um produto que pode ser teoricamente entregue, falar uma única língua dentro da equipe de desenvolvimento e testar continuamente as versões do produto que vão sendo geradas em cada iteração.
Seus princípios chave são a maximização da comunicação utilizando-se de pequenas equipes de trabalho, adaptabilidade às exigências do mercado e do usuário procurando entregar o melhor software possível e geração freqüente de versões unida a teste, ajuste e documentação de cada uma delas.

Hoje vou terminar por aqui… no próximo post pretendo escrever sobre os controles utilizados e os papéis no Scrum

Barcamp na terra dos leões

Deixando de lado a brincadeira dos leões, hoje ouvi no rádio algo sobre as reuniões que têm sido feitas pelo G8 e G5 sobre o aquecimento global. Pois é… G5!!! Eu não sabia que havia um grupo para os ‘semi-deuses’ no atual olimpo geopolítico que vivemos. E o mais legal, na minha opinião, é que há um país Africano neste grupo: a África do Sul.
E para concluir com as decobertas deste dia, ouvi dizer que foi realizado o 2º Barcamp em Johannesburg – África do Sul.
Como todos os Barcamps, o intuito era reunir pessoas interessadas em compartilhar conhecimento em um ambiente aberto.
O evento pôde ser seguido via twitter (@BarCampJozi) e teve como principais sessões:
* Seaside, o framework web “herético”
* Enviando emails onde cada email é muito importante (ex: não em uma mailing list)
* Rich Internet Applications
* Empreendedorismo social

Levando em consideração a realidade e contexto da África (continente no qual acontecem o maior nºde guerras civis, multiplicidade étnica e cultura, altas taxas de mortalidade infantil e analfabetismo) é muito intrigante ver que o tema de empreendedorismo social entou na pauta.
Acredito que seja mais um sinal dos tempos, que o mundo, as pessoas tendem à fraternidade e não ao egoísmo como nos transmite a maioria dos meios de comunicação.

Para conferir as fotos: TMS Ruge
Blogs que fizeram a cobertura do evento: Startup Africa, Cyphafrica, Danieroux, Mark Clarke, Paul Cook

Quem nunca escreveu e-mails que atire o primeiro chip…

Atualmente, a grande parte da comunicação de uma empresa, seja interna, seja com os clientes é feita pelo correio eletrônico.
Mais do que isso, os emails têm sido usados como formalização de conversas realizadas por telefone, ou pelos corredores da empresa, fazendo parte inclusive da documentação dos projetos.
Decisões, mudanças, problemas… o histórico de cada projeto fica registrado nas dezenas (às vezes centenas) de emails trocados entre colaboradores e clientes.
Partindo da importância deste meio de comunicação no mundo corporativo de hoje pensei que seria interessante reunir algumas dicas sobre como redigir um email de trabalho.
Como premissa temos que ter em mente que do outro lado há uma pessoa que irá ler o que escrevemos. Uma pessoa que não vai ouvir nosso tom de voz, que pode estar irritada com alguma coisa, que pode estar triste, que pode ter ganho na loteria, ou seja, que pode ler as palavras com a intonação e significado que ela quiser. Portanto seguem algumas dicas:

  • usar uma linguagem objetiva e clara
  • repreensões e más notícias devem ser sempre dadas pessoalmente
  • quando estiver alterado ou nervoso peça para alguém que não esteja envolvido no projeto ler o seu email antes de enviá-lo
  • procure manter o equilibrio entre o formal e o informal: não é bom terminar o email usando ‘Beijos’, por exemplo.
  • emails com texto maior do que a tela serão deixados para ler depois, portanto se for urgente procure ser o mais suscinto possível
  • utilize o revisor ortográfico e gramatical
  • releia o email antes de clicar em enviar
  • o primeiro email do dia deverá ser iniciado por uma saudação: bom dia, boa tarde

Para concluir, gostaria de lembrar também que é muito importante ter em mente que o email não substitui as reuniões e conversas com os colegas de trabalho. É saudável, e utilizado em várias empresas, que seja instituido um dia no qual não se usa email, msn e outros meios digitais de comunicação. Este tipo de ação aumenta a interação entre os funcionários e ajuda a manter o equilibrio entre virtual e real.
Caso alguém tenha mais dicas sobre o assunto deixe um comentário 😉