Dúvida sobre implantação de metodologia ágil

[Straus Michalsky]

Olá Pessoal,

Estou precisando de uma ajudinha aqui =)

Comecei a trabalhar na Diretoria de Gestão da Tecnologia da Informação
do Instituto Federal de Educação, Ciência e Tecnologia Sul de Minas
Gerais.
Aqui o pessoal não tem um processo de desenvolvimento devidamente
definido, e pediram minha ajuda para a escolha/implantação de um.

Estou mostrando as vantagens dos processos de desenvolvimento ágeis e
pensando numa forma de utilizar alguma metodologia ágil aqui.

O principal problema que eu percebi é que os projetos normalmente são
pequenos então a equipe (que tem 7 pessoas) acaba levando vários
projetos diferentes ao mesmo tempo. Normalmente cada um cuida de um
projeto principal e ajuda os outros nos outros projetos.

Para não afetar muito o funcionamento aqui, teria alguma forma de
planejar e gerenciar uma equipe com mais de um projeto? Queria
melhorar o senso de equipe da turma aqui para depois poder mudar a
forma que eles coordenam os projetos.

Alguém tem alguma dica e/ou algo que possa ler nessa direção?
E algum exemplo de metodologia ágil em órgãos públicos?

Obrigado e desculpa por invadir esse espaço (mas achei que essa lista
era um bom lugar para issa discussão)


Abraços
Straus Michalsky
Doutorando em Ciência da Computação IME - USP

[Monna Cleide]

Oi Straus,

A última empresa que trabalhei, apesar de não ser pública, era exatamente assim: uma equipe de 7 pessoas com um monte de projetos pequenos. Usávamos o scrum por causa dos sprints e da equipe, daí cada semana um membro (ou mais) cuidava das tarefas de um projeto e depois ia trocando. Infelizmente o processo lá não deu certo por fatores externos (a empresa não era de TI e a pressão dos outros departamentos arruinava todo o planejamento).

Não entendo tão bem assiiiiiim de empresas públicas e métodos ágeis, mas dependendo da opinião dos outros talvez esse possa ser um ponto de partida.

Espero ter ajudado. Boa sorte!

Ps: você passou no teste de proficiência em inglês, parabéns. :P

[Alfredo Goldman]

Oi Pessoal,

   Muito legal a discussão que o Strauss está colocando. Também não tenho uma solução imediata, mas gostaria

de começar com boas práticas, tipo repositório compartilhado, testes e integração contínua. Eles já tem isso ?

Em seguida, eu tentaria ver se é possível separar o time em dois, um de desenvolvimento e um de manutenção.

De forma que um dos times começasse a aprender a desenvolver (aí sim usando boa parte das práticas que usamos).

Nas duas equipes seria bom ter backlog de tarefas, na de desenvolvimento tentar fazer um sistema por vez. Na

de manutenção tentar criar um ritmo sustentável, limitando as correções por interação.

  São apenas palpites iniciais :)

Abraço,

Alfredo

[Straus Michalsky]

Então...

Nem Repositório nem controle de versão eles usam.
Testes automatizados e integração contínua é tecnologia alienígena.

Gostei da ideia de dividir em 2 equipes, assim conseguimos colocar
essas práticas na equipe de desenvolvimento e vai passando para a
equipe de manutenção, até porque não sei o quanto eles estão abertos a
modificações em projetos que já estão funcionando.

Pareamento também e algo que acho que não vai dar para usar.

Mas to achando o desafio aqui bem interessante, estou discutindo
muitas coisas com a equipe aqui e já mostrei que uma metodologia ágil
pode ser a solução para muitos dos problemas atuais aqui.

Obrigado pela ajuda.

Abraços






Straus Michalsky
Doutorando em Ciência da Computação IME - USP

[Vinicius Pinheiro]

Porque pareamento não funcionaria? Imcompatibilidade de horários? Eu acho uma das metodologias ágeis mais eficientes no que se refere à qualidade de código (ficando atrás somente de testes).

Abraços e boa sorte,

Vinicius

2013/6/13 Straus Michalsky <stra...@gmail.com>

[Alfredo Goldman]

Oi Strauss,

   Vamos por partes, o essencial hoje é um ambiente sério de controle de versões. Em seguida

vamos ver se dá para colocar algo de testes (compre um livro do Aniche e dê de presente para 

a equipe :). Pareamento e integração contínua, ficam mais para o futuro.

   Tente começar com mudanças pequenas e graduais, um passo por vez.

Abraço,

Alfredo

[Paulo Meirelles]

Oi Straus e demais,

Minha dica/reflexão é mais abstrata. Acho que primeiro deve conversar com a equipe e ver o quão disposta ela está para mudanças. Assim, ir trabalhando primeiro a disposição dela em querer mudar.

Antes de tentarmos mudar algo nos outros, vamos avaliar o quão difícil é mudarmos algo em nós mesmo: por exemplo, será que conseguimos a partir de amanhã não tomarmos mais refrigerantes e comermos mais saladas/verduras? Sabemos que são duas medidas boas para nós e de suas vantagens, mas o hábito nos cria dificuldades para a mudança. Deve demonstrar que está consciente das dificuldades de uma mudança, por menos que seja, e que também pretende mudar junto com eles.

Pensando nas ações, o primeiro ponto será a curva de aprendizado para o uso de um controle de versão. Sem controle de versão não dará para você ir muito longe. Já aproveitaria isso para validar como eles aceitariam o pareamento, ou seja, aprenderem o uso de uma controle de versão em pares. Faria um kanbam só para as tarefas vinculadas ao controle de versão, para eles verem um exemplo do poder de um Kamban físico.

Diferente do Alfredo e concordando mais como Vinícius, penso que o pareamento irá ajudar com as demais práticas. Em especial, testes é algo difícil para eles tentarem fazer sozinhos, ainda mais quando a equipe tem dificuldades técnicas (se for o caso). Então, quando eles tiverem pareando bem, começaria a incentivar a automação de testes simples.

Esses seriam meus primeiros passos, mas na primeira oportunidade, eu faria uma retrospectiva e deixaria eles livre para falarem os problemas (sem você ter que apontar nada) e você tentaria nos encaminhamentos com eles encaixar algumas pŕaticas: pareamento, repositório, testes etc.

meus 2 cents!

P.S: Em que cidade do sul de Minas você está?

--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

[Alfredo Goldman]

Olá Pessoal,

   Primeiro, com um começo tão ponderado, nem achei que fosse o Paulo escrevendo, só depois

quando ele começou a discordar de mim, percebi que era ele mesmo :)

   De qualquer forma, tenho a impressão que o processo está tão desestruturado que qualquer prática

boa deve trazer benefícios imediatos :) Mas, sim, ouça bastante a equipe, não imponha as suas práticas

mesmo que sejam as melhores :)

Abraço,

Alfredo

[Paulo Meirelles]

Em 17 de junho de 2013 22:39, Alfredo Goldman <go...@ime.usp.br> escreveu:

Olá Pessoal,

   Primeiro, com um começo tão ponderado, nem achei que fosse o Paulo escrevendo, só depois

quando ele começou a discordar de mim, percebi que era ele mesmo :)

Como falei: mudar nós mesmo é tão ou mais difícil quanto mudarmos hábitos dos/nos outros... chegarei lá ;)

 

   De qualquer forma, tenho a impressão que o processo está tão desestruturado que qualquer prática

boa deve trazer benefícios imediatos :) Mas, sim, ouça bastante a equipe, não imponha as suas práticas

mesmo que sejam as melhores :)

 

Straus, concordo com o Alfredo (não é ironia).

abraços!