Eu desenvolvo software assim

Assuntos Gerais Agile
#1

Hoje temos acesso a vários posts e livros sobre metodologias de desenvolvimento e novos termos sendo criados para coisas que sempre fizemos.

Não é aceitável ouvir que uma metodologia é melhor que outra para qualquer tipo de projeto, ambiente, cliente, ou mesmo que uma metologia não mereça adaptações no dia-a-dia. O que mais se lê é: se você não está fazendo isso então alguma coisa está errada !!!

Não é aceitável ouvir que tudo o que você fez por vários anos da sua vida com sucesso não foi concebido da melhor forma porque a metodologia x ou y diz o contrário, ou a mesma coisa com outro nome.

Existe uma expressão do pessoal de ITIL que diz: Adote e Adapte. E com certeza isso é empregado no desenvolvimento de software.

O livro de Henrik Kniberg, Srum and XP from the Trenches ? How we do Scrum de 2007, me chamou atenção. Ele está disponível na internet e pode ser baixado pelo link http://www.infoq.com/minibooks/scrum-xp-from-the-trenches. Na verdade não foi só pelo conteúdo ou pela abordagem, mas sim pela exposição de como o autor faz funcionar o desenvolvimento de software na empresa dele.

Precisamos de mais publicações desse tipo. Como funciona na sua empresa ? Qual a sua história de sucesso ? Por que você precisa deixar de lado a sua experiência para implantar a de alguém ?

Agregaríamos mais valor ao mundo de desenvolvimento de software se os gerentes de desenvolvimento publicassem como fazem nas empresas, qual o índice de sucesso ?

Será que existe interesse em vender uma metodologia nova, livros, palestras, certificações e títulos ? Será que temos que comprar tudo que nos oferecem ?

Mudar para metodologia do momento é realmente se atualizar ou jogar fora o seu conhecimento ?
Será que eu preciso mudar ou posso agregar aquilo que achar interessante ?

Precisamos realmente levantar a bandeira de alguém ?

Quanto vale a sua experiência ?

Responda começando com: Eu desenvolvo software assim …

#2

Porque esse alguém paga seu salário?

[quote=vbomfim]
Agregaríamos mais valor ao mundo de desenvolvimento de software se os gerentes de desenvolvimento publicassem como fazem nas empresas, qual o índice de sucesso ?[/quote]

Gerentes não agregam nada para o desenvolvimento de software… no máximo para o gerenciamento dos projetos da empresa que geralmente não representam condições adequadas para construção de bom software, por vários motivos que dizem respeito aquela empresa apenas.

Eu não diria comprar. Mas vc tem que conhecer tudo sim, ler sobre elas, se informar.

Felizmente, parece que isso é temporário. Uma vez li em algum lugar que existe um momento na carreira que esse interesse por metodologias diminui. Acredito que seja porque vc desistiu e mudou de área, ou finalmente descobriu o que é ideal pra vc, e portanto não se importa mais com os vendedores de procesos/ferramentas. :wink:

#3

E qual metodologia está mais certa ou mais errada? Claro que, sem os padrões, teríamos verdadeiros hieróglifos de códigos, com um incontável número de especialistas em nada, afinal, cada um faria de seu modo.
Padrões de projetos são culturas diferentes. Não se pode criticar os tibetanos por sua cultura, tampouco os uruguaios pela deles. É preciso tentar entender que salvo todas as diferenças, ainda vale a regra do capitalismo, enquanto gera lucro, mantenha assim.

#4

Quando escrevi, eu me referi a como você entrega software e não como você implementa software. Quando digo entregar me refiro a conceber os requisitos, definir o escopo das iterações ou sprints, dar prazo, dividir em tarefas, organizar a equipe, testar, integrar, homologar, implantar, documentar, etc.
Para melhorar a leitura, assuma a posição de desenvolvedor ou arquiteto ou gerente técnico ou da equipe com a responsabilidade de entregar software e a liberdade de adotar metodologia.
Se você tem uma equipe coesa, trabalhando afinada e entregando, mas não utiliza a metodologia do momento, ela é pior do que outra ?

A idéia não é cada um fazer do seu jeito, até porque seria perda de dinheiro.
Mas ao invés de criarmos novas metodologias, vamos publicar práticas como: iterações, tamanho dos incrementos, design evolutivo, TDD, reuniões diárias, Pair Programming, etc.
E cada equipe adota o que melhor se adaptar e convier.

Abraços,

#5

Oi vbomfim,

O profissional tem que se esforçar para saber sobre as evoluções, metodologias e tecnologias e etc... que envolvem sua àrea, seja ela qual for, sem sombre de dúvidas.

Agora...se vc não for chefe, lider, gerente, dono ou seja lá o que for  com uma super conciência e uma bela bagagem fica difícil (não impossivel). O que mais tem no mercado são lideres que não tem formação em TI ou ao menos fizeram carreira nesta àrea. Muitas vezes assumiram o cargo por questões politicas, estratégicas, nepotismo ou até mesmo na cagada como já vi acontecer. Isto sem falar nos caras que fazem cursinhos de metologias rápidas, acha que entendeu e começa a transformar a àrea em um circo. E aí meu camarada, vc pega todos os livrinhos sobre metodologias e etc... e troca por um único livro COMO TRABALHOR PARA UM CHEFE IDIOTA. Este livro vai lhe dizer como entregar o software sem ser demitido, fritado, congelado, esquecido; se bobear pode até rolar melhora no salário.

Resumindo…a àrea de TI deveria ser mais cientifica mas infelizmente na prática ela é de longe muito mais política.

Desconsidere se não entendi direito o que vc falou.

flws

#6

[quote=drsmachado]Padrões de projetos são culturas diferentes. Não se pode criticar os tibetanos por sua cultura, tampouco os uruguaios pela deles. É preciso tentar entender que salvo todas as diferenças, ainda vale a regra do capitalismo, enquanto gera lucro, mantenha assim.
[/quote]

Olha, criticar é não só possível como necessário. Sem a crítica, não há evolução. Nenhuma cultura é homogênea a ponto de não haver divergências ou dissidências dentro dela. Esse conflito é saudável, porque gera idéias.

Quanto à regra do capitalismo, o lucro é, sim, essencial, mas nenhuma empresa que opera somente por lucro imediato tem durabilidade.

#7

[quote=vbomfim]Quando escrevi, eu me referi a como você entrega software e não como você implementa software. Quando digo entregar me refiro a conceber os requisitos, definir o escopo das iterações ou sprints, dar prazo, dividir em tarefas, organizar a equipe, testar, integrar, homologar, implantar, documentar, etc.
Para melhorar a leitura, assuma a posição de desenvolvedor ou arquiteto ou gerente técnico ou da equipe com a responsabilidade de entregar software e a liberdade de adotar metodologia.
Se você tem uma equipe coesa, trabalhando afinada e entregando, mas não utiliza a metodologia do momento, ela é pior do que outra ?

A idéia não é cada um fazer do seu jeito, até porque seria perda de dinheiro.
Mas ao invés de criarmos novas metodologias, vamos publicar práticas como: iterações, tamanho dos incrementos, design evolutivo, TDD, reuniões diárias, Pair Programming, etc.
E cada equipe adota o que melhor se adaptar e convier.

Abraços,[/quote]

A empresa do Jacobson desenvolveu uma biblioteca de práticas, chamada EssentialUP. Está disponível para download.

#8

[quote=vbomfim]Quando escrevi, eu me referi a como você entrega software e não como você implementa software. Quando digo entregar me refiro a conceber os requisitos, definir o escopo das iterações ou sprints, dar prazo, dividir em tarefas, organizar a equipe, testar, integrar, homologar, implantar, documentar, etc.
Para melhorar a leitura, assuma a posição de desenvolvedor ou arquiteto ou gerente técnico ou da equipe com a responsabilidade de entregar software e a liberdade de adotar metodologia.
Se você tem uma equipe coesa, trabalhando afinada e entregando, mas não utiliza a metodologia do momento, ela é pior do que outra ?

A idéia não é cada um fazer do seu jeito, até porque seria perda de dinheiro.
Mas ao invés de criarmos novas metodologias, vamos publicar práticas como: iterações, tamanho dos incrementos, design evolutivo, TDD, reuniões diárias, Pair Programming, etc.
E cada equipe adota o que melhor se adaptar e convier.

Abraços,[/quote]

Cada um tem o seu papel no desenvolvimento de software. O papel do gerente é não deixar interferências externas desviarem o foco da equipe. Gerentes nem precisam saber o que são metodologias de desenvolvimento de software.

Agora, se sua preocupação é entregar software, sem duvida, se preocupe em adaptar a metodologia para a sua necessidade, e não para a do vizinho.

#9

[quote=drsmachado]E qual metodologia está mais certa ou mais errada? Claro que, sem os padrões, teríamos verdadeiros hieróglifos de códigos, com um incontável número de especialistas em nada, afinal, cada um faria de seu modo.
Padrões de projetos são culturas diferentes. Não se pode criticar os tibetanos por sua cultura, tampouco os uruguaios pela deles. É preciso tentar entender que salvo todas as diferenças, ainda vale a regra do capitalismo, enquanto gera lucro, mantenha assim.
[/quote]

Padrões significam “minha linguagem acabou”.

#10

vbomfim,

Concordo contigo plenamente.
O que a mídia nos vende é a idéia de que antes da ditadura dos cursos MBA´s das esquinas, o mundo não sabia gerenciar projetos é era incompetente.

Postei á pouco tempo atrás minha opinião, onde critico o modismo das “novas” ferramentas e modismos nesse assunto.
http://asm51.eng.br/phpBB/viewtopic.php?t=11057

+++

#11