segunda-feira, 26 de outubro de 2009

Implantando a Cultura Ágil no Ambiente de TI



Através de experiências com XP e estudos dos métodos ágeis em empresas, fiz uma analise de como implantar a cultura ágil no ambiente de TI.

Tanto numa fábrica de software ou empresa que não adote o modelo fábrica de software a cultura cascata geralmente esta em funcionamento. O modelo cascata tem origem de projetos da construção civil e difere da produção de software, portanto o modelo cascata não seria totalmente apropriado para produção de software.

O Software sofre mudança até quando já esta pronto, já um prédio depois de pronto não pode ser movido de leste para sul. Imagine ter quer cortar um andar depois de pronto, seria impossível.

O modelo cascata foi adequado a produção de software, mas nada impede do modelo cascata ser usado com métodos ágeis, aliás convém dizer que alguns equipes utilizam métodos ágeis e cascata e outras equipes utilizam somente métodos ágeis.

O importante num ambiente de fábrica de software ou empresa é não impor para equipes a cultura ágil e sim convencer. Como pode ser feito isto? Cursos da cultura ágil para todos os envolvidos e depois workshops no trabalho para colocar na veia a cultura ágil.

Muitas empresas que começaram a cultura ágil e não proporcionaram cursos no inicio, tiveram dificuldades na implantação da cultura ágil.

Saliento que não estou falando inverdade quando digo que uma fabrica de software pode aplicar cultura ágil, já vi várias fábricas usando métodos ágeis e com sucesso.

Mas imagine um ambiente silencioso não ágil tipo uma fabrica de software ou empresa. O ambiente ágil há muito interação entre equipe e cliente, isto vai incomodar num ambiente silencioso.
O recomendável é uma mudança de layout com quadros nas paredes que são necessários nos métodos ágeis para controle das tarefas, outra sugestão são divisórias para cada equipe. Assim uma equipe não atrapalha outra e todos ficam bem à vontade para interação com cliente e equipe. Proporcionando a união do equipe.

Também cito que já vim ambientes aplicando métodos ágeis sem divisórias entre equipes diferentes e funcionou normalmente. Claro que tinha quadro do controle das tarefas e Daily Meeting.

As mudanças provém com aprovação do presidente e diretores da empresa é claro.

Convencendo e estimulando todo ambiente à cultura ágil entra naturalmente e a motivação das equipes na execução de tarefas renderá frutos melhores.

Software de boa qualidade que satisfaça a necessidade do cliente com agilidade e colhendo bons frutos para empresa.

Bye see you next post

terça-feira, 20 de outubro de 2009

Scrum e Psicologia

brain-speaks-paralysis

Analisando a interação da equipe em torno do sprint, fatores psicológicos são importantes de serem analisados. Os profissionais deverão ser abertos as opiniões, criticas construtivas e darem suas sugestões.

Nas reuniões diárias os profissionais não devem omitir nada no relato do que fizeram ontem, o que vão fazer hoje e obstáculos. Senão sprint não anda.

Na verdade equipe deve vestir o scrum. Com foco no termino do sprint com qualidade. Deve haver motivação, entusiasmo, coragem, autogerenciamento, autoconfiança e auto-estima. Um profissional da psicologia ou ligado neurolingüística ajudará bastante o scrum master e equipe nas características citadas e outros fatores comportamentais.

Outro momento é do spring retrospectiva, onde Scrum Master junto à equipe revê o que funcionou bem e pode melhorar para próximo sprint. A equipe deverá ser aberta as sugestões de melhora. E pensar que errar é humano e consertar é um gesto humano e profissional.

Se equipe for composta por profissionais que sejam uma fogueira de vaidade, provavelmente não aceitaram críticas construtivas. Estes profissionais não serão adequado a cultura ágil com tanta interatividade entre a equipe.

"Determinação coragem e autoconfiança são fatores decisivos para o sucesso.
Se estamos possuídos por uma inabalável determinação conseguiremos supera-lós.
Independentemente das circunstâncias,devemos ser sempre humildes,recatados e despidos de orgulho." Dalai Lama

Vocabulário

Neurolingüística: é a ciência que estuda a elaboração cerebral da linguagem. Ocupa-se com o estudo dos mecanismos do cérebro humano que suportam a compreensão, produção e conhecimento abstrato da língua, seja ela falada, escrita, ou assinalada. Trata tanto da elaboração da linguagem normal, como dos distúrbios clínicos que geram suas alterações.


Bye see you next post

segunda-feira, 19 de outubro de 2009

Coach XP

O coach é profissional experiente em metodologia e nem tanto em tecnologia. Também é Habilitado há treinar a equipe na metodologia.


Geralmente o coach é contratado de outra empresa. Seu papel diminui com amadurecimento da equipe. Os trabalhos do coach num projeto XP são:
  1. Identificar as melhores habilidades de cada recurso da equipe;
  2. Sempre lembrar as regras do XP, quando esta caindo no esquecimento;
  3. Não desenha arquitetura do sistema, apenas identifica as possíveis melhorias;
  4. Pode participar da programação pareada.
Bye see you next post.

domingo, 18 de outubro de 2009

Scrum ou XP?

A escolha do Scrum e XP depende do cliente e a prestadora de serviço.
 
O XP novo comporta equipes maiores, assim pode ser voltado para projetos maiores.

Muitas equipes e prestadoras de serviços aplicam XP e Scrum. Porque que o Scrum é voltado para gestão de projetos e XP para engenharia do software(design, integração contínua, propriedade coletiva do código, refatoração, etc.). Mas digo que tem várias equipes e prestadores de serviços que aplicam somente Scrum ou somente XP.

A escolha deve ser baseada em fatores como a aceitação do cliente da cultura dos métodos ágeis e a experiência da prestadora de serviço em lidar com metodologias ágeis com cliente.

Outra alternativa é usar o Lean(fluxo contínuo) que pode ser usado sozinho, mas este é assunto para outro artigo. Se fosse visto como conjunto o Lean possui todas as práticas Agile.

Como Scrum é para gestão de projeto é necessário a parte de engenharia de software que temos no XP, neste caso aconselho adoção de Scrum e XP.

Bye see you next post.


sábado, 17 de outubro de 2009

Scrum Aplicado no Mercado Bancário e Financeiro

Vi um vídeo interessante do Blog Visão Ágil sobre Scrum aplicado no mercado bancário e financeiro.

Como trabalhei para bancos, posso afirmar que grande parte dos sistemas bancários e financeiros são de plataforma alta e menor parte de plataforma baixa.

Plataforma Alta - Mainframe

Geralmente a migração de um sistema bancário e financeiro é lenta, envolvendo negócios críticos. Sistemas que rodam há anos e consolidados. Isto acontece no mercado brasileiro e mundial.

A comunicação entre plataformas baixa e alta é uma forma de migração. Os negócios ficam na plataforma alta e a parte visual é remodelada na plataforma baixa.

A utilização do Scrum(gestão de projeto) implica em começar a migração por sistemas menores. Na migração sem Scrum também é iniciada por sistemas menores. Metaforicamente falando: é comer o mingau pelas beiradas.

O vídeo retrata a construção de um sistema menor e aplicação do Scrum: Entrevista sobre experiências com Scrum num ambiente Bancário/Financeiro

O legal deste vídeo é que mostra até a dificuldade de entregar um Sprint com todas tarefas concluídas e como conseguir resolver esta dificuldade. A solução aplicada foi entregar cada item concluído pelo team para PO antes de fechar a Sprint, usando Scrum juntamente com Lean e FDD.

Fonte: http://visaoagil.wordpress.com/

Vocabulário

Plataforma alta ou sistemas legados: são sistemas que rodam em mainframe, geralmente em cobol usando o mainframe da IBM ou Unisys.

Plataforma baixa: são sistemas intranet, client-server e internet.

Bye see you post next.

sexta-feira, 16 de outubro de 2009

ThoughtWorks: pé no Tecnopuc

ThoughtWorks: pé no Tecnopuc

Fonte:http://www.baguete.com.br/

Quadro do Scrum

Quadro do Scrum criado pela Bluesoft feito a tinta bem prático de ser implementado:

Bye see you next post

O que é Scrum?


É um método ágil. Usado para controlar e gerenciar desenvolvimentos de softwares e produtos de forma interativa e incremental.

Os pais do Scrum são:

Jeff Shutterland, Ken Shawaber e Mike Beeble.

O Framework Scrum é formado por três partes, que são elas:

  • Papéis do Scrum(Roles);
  • Artefatos Scrum(Artifacts);
  • Cerimônias Scrum(Cerimonies).
1.Ciclo do Sprint


Lembrando que Sprint leva entre 2 a 4 semanas. E todos dias tem reunião 15 a 20 minutos.
A equipe deve ser comprometida e motivada no desenvolvimento do produto, pessoas não comprometidas numa equipe Scrum não duram e podem causar o fracasso no desenvolvimento do produto.
A equipe deve ser integrada, mesmo a distância.

2.Papéis do Scrum

1)Product Owner

O Product Owner pode ser representado tanto pelo cliente como pelo analista de negócios.

As atribuições do Product Owner são:

  • Representa todos interessados no resultado do produto;
  • Aprova o reprova os resultados das tarefas do Sprint;
  • Definição de características e conteúdos do produto;
  • Priorização de tarefas conforme entrega;
  • Define data de término.
2) Equipe

As atribuições da equipe(5 a 9 pessoas no máximo) são:
  • Desenvolvedores;
  • Auto-Gerenciáveis;
  • Multifuncional.

3) Scrum Master

É um líder da equipe que deve trabalhar para que equipe mantenha o foco do Sprint.

A atribuição do Scrum Master:

  • Remover obstáculos que possam atingir o foco da equipe no Sprint que esta sendo trabalhado.

Obs.: É necessário manter o foco da equipe no Sprint,  porque se uma tarefa não terminar no tempo do Sprint, passa para outro Sprint. O Sprint não estica o tempo por causa de uma tarefa, porisso passa para outro Sprint conforme prioridade.

3. Artefatos

1)Product Backlog

É lista de funcionalidades definida pelo Product Owner e Cliente conforme prioridade de entrega, que poderão mudar dinamicamente.

Esta funcionalidades vão formar uma lista do que fazer.

2)Sprint Backlog

É definido no Sprint Planning.

Temos os seguintes passos para formação do Sprint Backlog:

O Product Owner apresenta as funcionalidades de maior prioridade. Então equipe seleciona as funcionalidades para compor o Sprint e quebra em tarefas. O Product Owner e equipe definem o Sprint Goal e é criado Sprint Backlog.

4.Cerimoniais

1)Daily Scrum Meeting(reuniões diárias com participação do Scrum Master) 

A equipe terá todos os dias reuniões de 15 a 20 minutos com hora certa para começar. É aconselhável fazer a reunião pela manhã. As seguintes questões serão reportadas por cada pessoa da equipe:

O que fez desde última reunião?

O que fará entre essa e a próxima reunião?

Há obstáculo para realizar a tarefa?

Dúvidas devem ser reportadas no decorrer do dia, não se deve deixar dúvida para reunião.

Após a reunião a equipe vai trabalhar os obstáculos.

Duas ferramentas que são necessárias no controle do Sprint:

a) O Kanban é forma de acompanhamento das tarefas do Sprint:

 

 

 

 

 

 

 

 

O Kanban mostra o fluxo das tarefas, aqui coloquei um exemplo simples com três colunas:

Não Foi Iniciada, Iniciada e Pronta.

Usei uma tabelinha do Word. Mas geralmente o mais comum é usar um quadro com posts coloridos e com mais informações. Por exemplo dados sobre: analise, desenvolvimento e teste.

Também existem softwares para Kanban.

b) O BurnDown é uma espécie de gráfico de amortização de horas de realização de um Sprint do inicio até fim(entrega):

 
 
As reuniões diárias com as ferramentas citadas diminuem  o atraso da entrega de um projeto, pois há mecanismo de entrega por Sprint com qualidade e controle diário. Sendo processo realizado de forma incremental. 

2)Sprint Review
 
No Sprint Review são apresentados os resultados do Sprint, após fechamento do ciclo de 2 a 4 semanas.
 
Apresentação é feita através do demo das novas funcionalidades.
 
Todos interessados participam da apresentação do Sprint que é informal.

3)Sprint Retrospective

Neste Sprint o Scrum Master junto a equipe revê o que funcionou bem e que pode melhorar para próximo Sprint.
Aconselho uma tabela para colocar estas informações e trabalhar com a equipe.


 
Bye see you post next




quarta-feira, 14 de outubro de 2009

Entrevista com Fábio Rilston sobre a adoção de metodologias ágeis no SERPRO

Métodos Ágeis

Estive lendo sobre métodos ágeis e lembrei na época que usei XP parcialmente numa empresa pequena.

Lembrando que XP em 2003, senão usasse tudo não era considerado XP. Digamos que havia um radicalismo. Mas tudo amadurece nesta vida.

O Aprendizado da faculdade sobre analise estruturada e outros não impedem de usarmos os métodos ágeis com algumas modificações e adequações de pensamentos. E derrubam certas práticas como calculo de ponto de função, geralmente por experiência já percebi que várias vezes não satisfazem as exceptivas dos clientes.

O motivo era quase sempre porque os clientes esperavam um tempo menor para entrega do produto e os prestadores de serviços aplicando todas variáveis de cálculos chegavam a um tempo maior para entrega o produto.

Na minha opinião nem clientes e prestadores de serviços são os culpados pelo ponto de função não funcionar e sim a forma de elaboração do cálculos tem algumas falhas. Porque nem tudo na informática é exato, temos vários fatores não exatos: como riscos e prever o futuro.

Para diminuir os riscos na entrega do produto em gerência de software é colocado um tempo maior(sobretaxa) na entrega do produto, uma das cinco doenças de gerência de software. Mas isto é outro assunto.

Métodos ágeis é um dia de cada vez e desenvolvimento de software é feito através interações curtas, temos verificações todos os dias das funcionalidades e desenvolvimento baseado em teste(o código do cliente).

Em métodos ágeis o produto de software é desenvolvido de forma incremental.

Os princípios básicos da metodologia ágil são:

  1. Interação da equipe;
  2. Software funcionando é mais importante que documentação, mas isto não elimina um bom projeto para desenvolvimento de um software;
  3. Cliente colaborando;
  4. Mudanças são bem vindas. Software totalmente dinâmico.

Vários encontros de métodos ágeis ocorrem no país e fora. O próximo tema será scrum.

Fontes: http://visaoagil.wordpress.com/
http://www.agilcoop.org.br/
Bye see you next post.