Não foi possível carregar o Diqus. Se você é o moderador, por favor veja o nosso guia de problemas.
Artista! Eu sou sua fã!
The Po!nt: Just admit it. Nothing serves customers better than a little honesty following a faux pas.
Este artigo faz um excelente compêndio da metodologia e case de aplicação do desenvolvimento Ágil de Projetos.
Flammarion Cysneiros
ICOMUNI Conusultoria
flammarion.wordpress.com
www.icomuni.com.br
Muito bom Akita! Valeu
Chegou o momento onde na economia é necessario para sobreviver criar organizações que aprendem ao inves de organizações que obedecem, ou tranformar as que já existem para o novo paradigma do trabalho.
Ontem foi numa reunião e me recomendaram Linked novamente, vou precisar leer urgentemente!
Abraços,
Juan.
Mesmo sendo de um universo técnico não-rails, agradeço por esse compartilhamento de reflexões, que pode ajudar qualquer desenvolvedor a pensar em algumas coisas.
Valeu, muito proveitosa a leitura deste artigo!
Akira, ótimo artigo! Aprendi muito.
Tenho uma correção ao artigo: A natureza não privilegia sempre a meritocracia; na verdade, como demonstrado no livro 'O Cisne negro' e em 'Derrubando mitos', muito do sucesso de muita gente se deve ao acaso, e muita gente de talento acaba não tendo sucesso, embora seja muito melhor acreditar na meritocracia.
Mas a capacidade, obviamente, tem alguma influência no sucesso: pelo menos nos expõe a melhores possibilidades de sucesso (e, é claro, o acaso fará o seu papel - para pior ou para melhor).
Akira, ótimo artigo! Aprendi muito.
Tenho uma correção ao artigo: A natureza não privilegia sempre a meritocracia; na verdade, como demonstrado no livro 'O Cisne negro' e em 'Derrubando mitos', muito do sucesso de muita gente se deve ao acaso, e muita gente de talento acaba não tendo sucesso, embora seja muito melhor acreditar na meritocracia.
Mas a capacidade, obviamente, tem alguma influência no sucesso: pelo menos nos expõe a melhores possibilidades de sucesso (e, é claro, o acaso fará o seu papel - para pior ou para melhor).
Excelente texto! Só tenho a ressalvar a parte sobre Marx. Que se discorde - os clássicos estão aí para isto - porém com conhecimento de causa: "tirar dos ricos e dar aos pobres" é uma simplificação brutal - e falsa - da teoria marxiana. De resto, parabéns pelo artigo.
Acima da média esse post!
SOFTWARE É ENGENHARIA!
Como Engenheiro (Eletricista) preciso defender a classe, né ;)
Software de fato é Engenharia. O que o texto parece não entender é que ENGENHARIA É ARTE!
Bons engenheiros são como bons desenvolvedores: artistas. Por outro lado, engenheiros ruins são como desenvolvedores ruins: nem deveriam ser chamados de engenheiros/desenvolvedores...
Para mim, a associação de Desenvolvimento com a Engenharia é perfeita! E por que não também com Artistas?!
Desenvolvedor de software, engenheiro de software ou artista de software são sinônimos :)
Ou vocês acham que também não existem artistas ruins?
As pessoas (medíocres) costumam ter a idéia de que Engenharia está ligada às ciências exatas, como a Matemática, por exemplo... É uma idéia completamente equivocada.
Mudando de assunto, quanto ao Perl, bateu até uma saudade da época em que começei a desenvolver para web. A única tecnologia que consegui encontrar para desenvolver com hospedagem gratuita foi o Perl. Na época foi meu primeiro contato com linguagem interpretada. E devo dizer que fiquei fascinado na época. Era a melhor tecnologia para desenvolvimento web da época. Depois veio Ruby (um Perl melhorado) e frameworks como Rails e Merb. Aí realmente fica difícil continuar defendendo o Perl :)
Grande abraço e parabéns pelo artigo, novamente, Fábio.
Infelizmente creio que não conseguirei o apoio para ir ao Rails Summit. Algo me diz que meu pedido (que já faz uns 2 meses e ainda não foi respondido) não será aprovado. É uma pena :(
Bom proveito para vocês que irão,
Rodrigo.
Parabéns Akita!
Bom post e muito boa a observação sobre desenvolvimento Ágil e do burocrático.
Parabéns pelo artigo. Muito bom e esclarecedor. Uma metodologia, diferente de uma tecnologia, precisa de muito mais que dinheiro. Precisa cultivar essa cultura. Acredito que a grande sacada está na escolha das pessoas para fazer parte desta cultura. Existem pessoas que não conseguem executar suas tarefas se não tiverem um supervisor próximo. Outras preferem a liberdade para criar. Seja qual for o perfil, todas se encaixam nessa idéia, desde que tenham o tempo necessário para se adaptarem.
Cara....
Demais!
Concordo plenamente. Vou espalhar o post onde puder. Isso tem que chegar à muita gente que ainda pensa errado!
Olá Akita,
realmente acredito que o software hoje deve ser construído como uma obra de arte, e não como engenharia ou fábrica de software.
Atualmente está complicado para os profissionais que estão entrando no mercado entenderem estas idéias, mas principalmente para empresas mais antigas é difícil visualizar a idéia de desenvolvimento ágil e tudo que a envolve. Até mesmo profissionais que estão entrando ou saindo de níveis de graduação acabam sendo levados pelo processo de engenharia, que são os métodos ainda ensinados no decorrer da grande maioria dos cursos.
Um grande abraço e parabéns pelo artigo!
Carlos.
ps.: talvez uma pequena correção: "Ele divulga seu projeto internamento" > seria "internamente"?
Olá Akita,
Trabalho há muito tempo trabalho com modelo fábrica de software, CMM, waterfall etc etc. Tinha uma crença fixa de que software é uma engenharia e não arte. Que nosso processos de software deveriam ser disciplinados, controlados e medidos (CMM...). Nesses anos constatei que esse modelo tinha algum problema. Que essa forma de pensamento tinha algum "furo" mas não conseguia entender qual.
Depois que comecei a estudar Rails e toda a cultura "Getting Real", descobri esse onde estava o "furo". Hoje não acredito mais em Fábrica de Software. Estamos usando a ferramenta errada. Como você disse software não é uma engenharia. É arte!
Mas pensei: "Não temos só bons desenvolvedores em nossas equipes. Uma fábrica de software seria uma forma nivelar o service level e com isso garantir a rentabilidade." Nada mais Gaussiano!
Agora entendo porque fábricas de software estão fadadas ao fracasso (para fazer software de qualidade, não para fazer consultoria ganhar dinheiro) e o quanto elas são mediocres.
Parabéns Akita pelos seus artigos!!! São realmente muito bons!
Tomara que essa cultura contagie o mundo ABAP um dia.
Abraços!
Flávio Furlan
Ótimo, parabéns @kita, grande abraço
Muito bom. Sempre adorei a idéias envolvidas na teoria do caos e teoria da complexidade, pra mim refletem a realidade humana mais do se supõem pelos seus nomes. Não conhecia o Taleb, procurarei lê-lo. Durante a leitura, ocorreu-me que o modelo das redes scale-free serve como boa inspiração para um "profissional generalista", ele não precisa conhecer tudo, basta escolher algumas boas "áreas-hubs" e criar uma ampla rede de conhecimentos em torno delas, usando os 20/80 de forma recorrente... Enfim, o curioso é que semana passada escrevi um post que fala de motivação e agilidade em equipes de desenvolvimento (com um leve toque de comida francesa...). Acho que a primeira frase dá uma idéia, "O que um diretor ganhador do Oscar e um dos melhores chefs de cozinha dos EUA podem dizer a um desenvolvedor de software sobre motivação?". Muita, muita coisa compatível com o que você diz aqui (por sinal, citei uma tradução sua). Abraço!
Parabéns Akita!!!! Muito bom o artigo.
O artigo parece excelente como todos os off-topics
Vou ler amanhã!
Perfeito, estou gostando muito dessa série de artigos Akita. Tudo reflete perfeitamente, não só no mundo da tecnologia, e sim em qualquer área.
Parabéns.
"O ponto mais óbvio é que “Bell Curves” (curvas em forma de sino) como a Normal/Gauss, exigem eventos independentes, isolados, como jogar dados ou tirar cara ou coroa em uma moeda não viciada."
Cara ou coroa segue uma distribuição binomial (que pode ser aproximada pela distribuição normal). Para os eventos serem independentes, não é necessário que a moeda seja não-viciada.
@Felipe tem razão, já troquei :-) Valeu!
Excelente artigo. Vi poucos artigos com essa qualidade falando de Agile. Só uma correção nos valores do manifesto ágil não fica muito legal traduzir como "em vez de". Isso gera muitos desentendimentos e dificulta a disseminação dos valores. O correto seria "mais que". Ex:
Individuos e Interações "mais que" Processos e Ferramentas. ;)
Grande abraço
Opa Akita, muito bom, concordo com tudo que você já vem falando nesse ramo a muito tempo, e realmente me irrita muita as pessoas insistirem na zona de conforto (que é oque eu mais vejo) e as empresas insentivarem isso. Parabéns pelo artigo.
"O difícil é cultivar uma cultura. Muitas empresas reclamam que profissionais de boa qualidade pedem demissão e procuram outras empresas. Óbvio: pessoas realmente inteligentes não aceitam uma cultura gaussiana por muito tempo. Nós não gostamos da mesmice, não gostamos de pensamento retrógrado e falta de atitude. Verdadeiros artistas precisam de ambientes de inspiração para serem criativos.
O cubículo da maioria das empresas é um péssimo lugar para se criar"
Exelente colocação. Parabens!
Parabéns Akita! Excelente. Completo.
Ah eu adorei o 5o elemento!!!!!
Bom post, mas uma dica, leia esse artigo: http://arxiv.org/abs/0809.0692
Apesar de analisar artigos de astronomia, os resultados são facilmente interpretados em outras áreas, inclusive em blogs.
[]s
Muito bom, parabéns!
Explêndido.
Excelente artigo Akita.
Comentario totalmente atrasado (=D), mas de qualquer forma parabens por esse texto! Excelente!