Grupo de Usuários de Métodos Ágeis do Pará

Não! O Tá safo! não mudou de nome e nem vai fechar as portas. O bagulho tá bão demais, sô!

Resumindo a história, a SUCESU-PARÁ resolveu formalizar o apoio à implantação de métodos ágeis nas organizações.  Com a iniciativa do Evandro Paes (da PRODEPA), Artur Tupiassu (do SERPRO) e Mauro Brito (da própria SUCESU-PARÁ) o negócio deslanchou e o Tá safo! abraçou o projeto para mostrar que a fase de desconfiança no Desenvolvimento Ágil já passou.

Agora podemos mostrar com nossas próprias experiências que temos alternativas eficazes aos modelos de gestão e desenvolvimento tradicionais.  E que empresas de qualquer porte podem implementar gradualmente processos e boas práticas de gestão de projetos e engenharia de software.  Isso tudo sem abandonar processos tradicionais. É tudo questão de mudança cultural, assunto aliás bastante debatido no 1º encontro.

O GUMA-PA é a consolidação de um sonho antigo nosso. O de reunir academia, empresas e sociedade na busca de soluções sustentáveis para a classe de TIC, que trabalha muito e que muita vezes é colocada em segundo plano.

Continuar lendo

#NoSummit em Belém

NoSummit é um evento social colaborativo. Um espaço aberto e descentralizado para compartilhamento de conhecimento.  Qualquer pessoa que queira colocar um assunto em discussão tem liberdade para comandar as atividades como achar melhor, sem perder o foco.

Em Belém a temperatura tende a subir com os diversos pontos de ebulição, locais de concentração para discussão torno de temas específicos.

Quer tirar o sábado para compartilhar conhecimento e levantar discussões sobre assuntos relevantes da área de tecnologia? Confira os horários, temas e locais onde o #NoSummit vai rolar neste sábado, 22, em Belém:

Mangal das Garças, 9h30 da manhã
Tema: “Gestão no século XXI”, com Fábio Aguiar (confirmado!)

Mulatas da Estação das Docas, 15h00 da tarde
Tema: “CakePHP, Selenium ou Node.js”, com Marcelo Andrade e Luiz Sanches (confirmado!)

Bar Nosso Recanto, 16h00 da tarde
Tema: “DevOps” (desenvolvedores+operadores), com Luiz Sanches e Marcelo Andrade (confirmado!)

IESAM José Malcher, (não confirmado)
Tema: “Computação em nuvem”, com Carlos Natalino

SERPRO Perimetral, (não confirmado)
Tema: “Governança de TIC”, com Mariana de Nazaré

Saraiva MegaStore Boulevard, (não confirmado)
Tema: “Regulamentação da área de TI no Brasil”, com Adriano Ohana

Compareça e prestigie!

ATUALIZAÇÃO 1: Infelizmente nem todas as atividades foram confirmadas. 😦

ATUALIZAÇÃO 2: Luiz Sanches e Marcelo Andrade estarão presentes em suas atividades em conjunto.

PS: A previsão do tempo para o horário dos eventos é: céu nublado com possibilidades de video-streaming.  Fique ligado no Twitter do @tasafo.

TáSafo em Ação com Alexandre Magno

Alexandre Magno junto com a galera do TáSafo!

Alexandre Magno vai estar em Belém e participará junto com a comunidade do nosso encontro Tá Safo em Ação.

Tema da palestra: Sou gerente de nerds. E agora?

O mundo do trabalho mudou. Agora grande parte do que tem que ser feito dentro das organizações depende da competência dos profissionais do conhecimento. Essa necessidade traz um grande desafio para os gerentes que, de uma hora para outra, vêem que as boas práticas ensinadas nos best-sellers de gestão não mais funcionam e devem ser abandonadas. A Gestão 3.0, popularizada pelo livro Management 3.0 de Jurgen Appelo, foca justamente nestes pontos. O que fazer para motivar esses profissionais? Como atraí-los e mantê-los na sua empresa? Como dar poder a eles e não transformar o trabalho em caos? Como desenvolver suas competências? Qual meu papel de gerente se não controlá-los? Essas e outras questões serão discutidas nessa palestra, que irá lhe colocar pra pensar sobre como mudar o seu ambiente de trabalho, e talvez o mundo.Se você é gerente de profissionais do conhecimento, não deixe de vir. Se você é um nerd, não deixe de trazer seu chefe.


Data:
 23 de maio de 2012 (Quarta-feira).
Local: Livraria Saraiva – Espaço Benedito Nunes, 2} piso, loja 233. Boulevard Shopping.
Horário: 19:00 hs.

Esperamos por vocês lá. A entrada é franca.

O que rolou no #tasafoemacao com Rafael Prikladnicki

No dia 24 de Novembro, aconteceu em Belém um evento que abalou muita gente. Não foi a chuva torrencial no fim da tarde. Foi mais um #tasafoemacao. Desta vez, Rafael Prikladnicki marcou presença no Auditório do Cesupa e deu uma verdadeira aula sobre Agile.

A evento estava previsto para começar às 19:00 horas, porém começou 19:30. Como o próprio Rafael enfatizou, sempre há mudanças nos requisitos. E este foi um dos temas mais discutidos em sua palestra. Continuar lendo

Tá Safo em Ação com Rafael Prikladnicki

Pessoal, está se aproximando o dia de mais um Tá Safo em Ação especial, agora com a presença de Rafael Prikladnicki que estará em Belém participando do II WPTS –  Workshop Paraense de Tecnologia de Software. E como quem vem ao Pará, está sempre convidado a participar do nosso encontro Tá Safo em Ação, Rafael nos dará a honra de estar em ação junto com a comunidade Tá Safo, compartilhando sua experiência e conhecimento de agilidade e comunidade (GUMA).

Mauro à esquerda, Rafael no meio e Marcelo à direita

Tema de sua palestra: Cinco motivos para não usar metodologias ágeis no desenvolvimento de software

Resumo: A adoção do paradigma ágil no desenvolvimento de software tem sido um assunto amplamente debatido. Ao mesmo tempo, muitas empresas têm utilizado as metodologias ágeis sem fazer uma reflexão sobre os reais benefícios que elas podem trazer para seus projetos. Além disso, muitos projetos têm falhado em função do não entendimento e da aplicação errada dos princípios ágeis. Nesta palestra vamos apresentar cinco motivos que fariam uma equipe de projeto não adotar metodologias ágeis no desenvolvimento de software. Vamos apresentar as motivações e explicar cada um dos motivos. Vamos também discutir, a partir da experiência prática do palestrante, em quais situações metodologias ágeis podem e devem ser utilizadas.

Rafael Prikladnicki

Pós-Graduação em Ciência da Computação da PUCRS, com doutorado e mestrado em Ciência da Computação pela PUCRS e estágio de doutorado na University of Victoria no Canadá. É professor do Programa de Pós-Graduação em Ciência da Computação da PUCRS, instrutor e coach de metodologias ágeis, qualidade de software, gerência de projetos e desenvolvimento distribuído de software, coordenador do Grupo de Usuários de Métodos Ágeis (GUMA) da Sucesu-RS e foi coordenador geral da Agile Brazil 2010.

Data: 24 de novembro de 2010 (Quarta-feira).

Local: Auditório do CESUPA da Unidade da José Malcher.

Horário: 19:00 às 22:00 hrs.

Esperamos por vocês lá. A entrada é franca.

Com certeza será mais um TáSafo em Ação imperdível!!!!

@tasafo


Resumo: Tá Safo em Ação especial com Rildo Santos

Com um mini-workshop Scrum Product Owner – Delírios de um PO em um dia de verão aconteceu mais um #tasafoemacao que foi um sucesso! A comunidade presente, bom nível de discussão do assunto e todo apoio de infraestrutura fornecido pelo CESUPA.

Primeiramente o Fábio Aguiar apresentou o Tá Safo de uma forma bem diferente ligando a idéia do post no blog do Tá Safo: Quem vai ao Pará, parou! Tomou açaí, ficou no Tá Safo em Ação! Que trata-se de um convite para quem quiser participar do Tá Safo e ser um #tasafoemacao.

Quem veio ao Pará, parou! Tomou açaí, ficou no Tá Safo em Ação!

Continuar lendo

Scrum Overview

Recentemente escrevi meu artigo de conclusão de curso de Sistemas de Informação (IESAM) sobre gerenciar de forma ágil uma implantação de sistemas ERP com Scrum. Com isto resolvi postar um resumo sobre Scrum para aqueles que ainda não o conhecem.

Figura 01

Figura 01

1. Scrum
Scrum é um framework com conjunto de práticas objetivas, papéis bem definidos e totalmente adaptáveis, seu ciclo de vida se resume em interações e funcionalidades incrementais, é um método ágil voltado para gerenciamento de projetos. Com isso, permite um melhor acompanhamento do que está acontecendo durante o projeto, facilitando o ajuste durante o projeto e fazendo com que possamos alcançar os objetivos do projeto de forma ágil. Ou seja, Scrum não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados.

2. Ciclo do processo Scrum
O Scrum é baseado em interações bem definidas, com duração de uma a quatro semanas, também chamados de Sprint. Antes de cada Sprint é realizado todo planejamento inicial do objetivo que o cliente almeja. A partir desse momento é criado o Product Backlog, baseado na visão de negócio do cliente, com todos os requisitos a serem implementados. Depois de preparado todo Product Backlog, é realizada a primeira reunião de planejamento do Sprint, onde são selecionados os itens pelo Product Owner e o Scrum Master a serem desenvolvidos que agregarão mais valor ao negócio do cliente naquele momento e depois colocado na ordem de maior prioridade, em seguida realizamos a segunda reunião de planejamento do Sprint, onde a própria equipe estima o esforço das tarefas, faz a divisão das tarefas entre os diferentes membros e compromete-se a concluir as tarefas no final da interação e define de quanto tempo vai ser a Sprint. A partir desse momento é criado o Sprint Backlog que são as tarefas selecionadas pela equipe para ser executada na Sprint.
A próxima etapa é a execução do Sprint com base nos itens do Sprint Backlog, durante a execução as tarefas são acompanhadas por reuniões diárias que não podem passar 15 minutos e a equipe deve responder três perguntas diante dos envolvidos: O que você desenvolveu até o momento? O que você irá desenvolver? Quais impedimentos você está tendo? Com base nessas perguntas o Scrum Master consegue ter uma visão de como está o andamento do projeto, conhecendo os impedimentos que estão acontecendo.
No final da Sprint é realizada uma reunião de Revisão da Sprint, com o objetivo, de mostrar ao Product Owner e todas as partes interessadas as funcionalidades que foram concluídas. A equipe apresenta os resultados obtidos durante o Sprint e possíveis modificações nos itens do Product Backlog. Logo após é realizado outra reunião de Retrospectiva do Sprint, onde é feito uma “lavagem de roupa suja”, onde os membros da equipe devem responder duas perguntas: O que aconteceu de positivo durante esse Sprint? O que pode ser melhorado para o próximo Sprint?

Figura 02

Figura 02

3. Papéis
No Scrum temos três papéis principais: Product Owner, Scrum Master e a Equipe, abaixo a figura 2 que representa a responsabilidade que esses três papéis têm em relação ao Scrum:

3.1. Product Owner
É o dono do produto, geralmente é representado pelo o cliente. Ele é responsável por definir as características do produto a ser desenvolvido, identifica os requisitos do produto, tira dúvida da equipe quanto ao entendimento dos requisitos. É o único que define a ordem em que esses elementos serão desenvolvidos, de acordo com o valor apresentado pelos clientes e usuários de cada negócio, alimenta o Product Backlog para o planejamento da Sprints. E define as metas e toma decisões relativas Release planejamento. Uma pessoa que desempenha esse papel deve ter as seguintes competências:
– Bom conhecimento de negócio.
– Ser capaz de demonstrar uma liderança, respeitado pelos interessados externos (clientes e usuários). – Ser capaz de tomar decisões no momento certo (não muito cedo, nem muito tarde). – Flexível a mudanças. – Boa comunicação com a equipe. – É importante que ele esteja disponível para responder às perguntas da equipe.

3.2. Scrum Master
É responsável pelo andamento do projeto, pela aplicação das práticas do Scrum. Levando para o lado tradicional é o Gerente de Projeto. Durante o desenvolvimento, ele acompanha a equipe no dia a dia, retirando os impedimentos e ajudando a equipe a se auto-gerenciar, buscando melhor resultado da equipe. Para conseguir isso ele executa as seguintes tarefas:
– Tem como objetivo através das reuniões do scrum animar e motivar a equipe.
– Eliminar impedimentos, tendo em consideração os acontecimentos ocorridos em qualquer momento do projeto, a fim de resolvê-los o mais rápido possível, ao mesmo tempo proteger a equipe e priorizar o comprometimento da equipe com o projeto.
– Certifique-se de que a equipe permanece centralizada no projeto com objetivo proposto inicialmente, que é desenvolver os Itens do Backlog e estreitar colaboração com o Product Owner, e permanece produtivo.

3.3. Equipe
É composta por seus membros (desenvolvedores), que é capaz de realizar todas as diversas tarefas para as quais ele tem responsabilidade coletivamente durante cada Sprint. É capaz de determinar o que precisa ser feito para alcançar o sucesso do Sprint, a equipe deve ser capaz de executar as diferentes tarefas para as quais assume responsabilidade coletivamente durante o Planejamento do Sprint. Isto significa que devem ser de amplo conhecimento, tais como análise, projeto, codificação, testes e outras tarefas. A equipe é geralmente feita de 3 a 10 membros.

3.4. Stakeholder
São aqueles que não participam diretamente do projeto, mas podem influenciar no produto a ser desenvolvido, ou seja, não participa do desenvolvimento, mais está interessado no desenvolvimento do produto e pode ter valores que podem influenciar no crescimento do produto.

4. As práticas do Scrum (Conceitos, Artefatos e fases)

4.1. Product Backlog
A partir de uma reunião inicial com todos os envolvidos e interessados do projeto, são levantadas todas as implementações a serem desenvolvidas a partir da necessidade do negócio do cliente, contém uma lista de requisitos a serem desenvolvidos durante o projeto. É visível a todos, e regularmente atualizado. É apresentado na primeira reunião de Planejamento do Sprint, uma vez aprovado, temos os itens necessários para compor o Sprint Backlog.

4.2. Reunião de Planejamento do Sprint
A reunião de planejamento se divide em duas partes:

4.2.1. Primeira Reunião de Planejamento do Sprint
Com duração de no máximo quatro horas, o Product Owner junto com a Equipe discutem os itens do Product Backlog, são selecionadas neste momento as tarefas que tem mais prioridade para o cliente.

4.2.2. Segunda Reunião de Planejamento do Sprint
Com duração de quatro horas, a Equipe define as tarefas necessárias, estima o esforço das tarefas, a própria equipe faz a distribuição das tarefas entre os membros da equipe, o Product Owner deve está presente para esclarecimento de dúvidas e por fim a Equipe compromete-se em concluir as tarefas.

4.3. Sprint Backlog
São as tarefas que foram selecionadas na reunião de planejamento do Sprint pela Equipe junto com o Product Owner e Scrum Master, é o ponto inicial de cada Sprint.

4.4. Sprint
São pequenas séries de interações que podem ter uma duração de uma a quatro semanas, no final da interação a equipe tem que ter alcançado o objetivo inicial do Sprint, onde a equipe está focada em não como fazer, mas sim em vamos fazer. A equipe executa as tarefas compõem o Sprint Backlog. O objetivo final de cada Sprint é ter um produto incremental e funcional para o cliente. É a fase principal do Scrum, pois é nesta hora que ocorre a execução das tarefas, depois de todo o planejamento inicial. É importante que os restantes das Sprint tenham o mesmo tamanho da inicial para que não causem perda de ritmo da Equipe. É imprescindível que no primeiro Sprint alcance o sucesso, pois é um período delicado, pois as partes envolvidas e interessadas estão com expectativa muito grande em cima do resultado (produto incremental).

4.5. Reunião Diária do Sprint
Reuniões diárias que ocorre todos os dias durante a execução do Sprint, com duração em média de 15 minutos. O grande objetivo dessa reunião é que todos os envolvidos tenham conhecimento de como está o andamento do projeto e também fazer com que cada um relate os impedimentos que estão enfrentando ao executarem as suas respectivas tarefas.
O Scrum Master é o responsável pela condução da reunião, é muito importante que todos envolvidos no projeto estão participando principalmente a equipe, basicamente a equipe responde com clareza a três perguntas durante a reunião:
a. O que foi concluído desde a última reunião? (Neste momento o Scrum Master registra as tarefas que foram concluídas e as que ainda estão pendentes).
b. Quais impedimentos estão tendo durante a tarefa? (O Scrum Master registra os impedimentos relados por cada membro da equipe, e após o termino da reunião irá propor solução para os problemas citados).
c. Qual será a próxima tarefa a ser executada? (Neste momento todos ficam sabendo quais tarefas cada membro da equipe está executando).
O Scrum Master tem como objetivo nessa reunião não deixar com que a reunião perca seu foco, basicamente responder as três perguntas, ter uma visão que a equipe não perdeu o objetivo final do Sprint, e gerenciar os impedimentos que vão acontecendo durante a execução da Sprint. O ponto forma desta reunião é responder apenas as perguntas feitas pelo Scrum Master e ponto.

4.6. Produto Incremental
No final de cada Sprint há uma entrega parcial do produto. O principal resultado de um Sprint é a entrega incremental e funcional de um produto, os impedimentos para entrega dessa etapa e os novos requisitos adicionado durante o desenvolvimento deste Sprint.

4.7. Reunião de Revisão da Sprint
Esta reunião é realizada no último dia do Sprint com duração de no máximo 4 horas e de responsabilidade do Scrum Master, a Equipe não de gastar mais de uma hora na preparação da reunião. Neste momento é apresentado o resultado da Sprint que é o produto incremental com suas funcionalidades pela Equipe e o Scrum Master para Product Owner e os envolvidos do projeto (cliente). Analisaram junto se foi alcançado o objetivo inicial do Sprint, e já discutem novas funcionalidades para atualizar os itens do Product Backlog que vão sendo identificada ao final de cada Sprint.

4.8. Reunião de Revisão da Sprint
É realizada logo após a reunião de revisão do Sprint com duração de no máximo 3 horas com a participação da Equipe, Scrum Master, Product Owner e os envolvidos e interessados. Os membros da Equipe devem responder a duas perguntas?
a. O que aconteceu de bom durante o último Sprint?
b. O que pode ser melhorado para o próximo Sprint?
O Scrum Master registra as respostas e prioriza na ordem que deseja discutir as melhorias e tem como papel também facilitar ao time melhores formas de aplicar as práticas do Scrum.
Por ser uma reunião de lavagem de roupa suja, deve se ter cuidado para não levar pontos pessoais, pois podem ser fundamentais para prejudicar a aplicação das práticas do Scrum. Essa reunião é fundamental para o progresso e sucesso do projeto, é fundamental a clareza e objetividade para que os participantes alcancem o sucesso da reunião.

FabioGr.com