Vitor Pamplona

Innovation on Vision: Imaging , Enhancement and Simulation

Engenharia de Software e Reproducibilidade

 Não é de hoje que eu ando desiludido com área de engenharia de software e suas sub-áreas, principalmente falando em pesquisa. A engenharia de software, tal qual é difundida, remete à busca de uma verdade absoluta (mesmo que temporária) e de uma certa perfeição na arte de conduzir pessoas. No entanto, neste caso, esta verdade global não existe, não pode ser consolidada e muito menos reproduzida. Não é ciência, é arte. A perfeição depende de tantos fatores que a torna inviável no caso geral. E, apesar de saberem disso, diversos autores remetem a suas criações como verdades absolutas, apresentando algumas pequenas assumptions que ofuscam alguns requisitos bem maiores. Foi assim com XP, Scrum e RUP e será assim, por muito tempo.

Por exemplo, Kent Beck é bem claro ao dizer que XP serve para equipes pequenas. No entanto, esquece de mencionar que não é qualquer equipe pequena. É uma equipe pequena, motivada, atualizada (provavelmente jovem) e com Kent Beck como coach. Veja bem, XP, Scrum e RUP não são nada. Eles podem funcionar ou não, em qualquer lugar, qualquer mesmo, só depende das pessoas, do perfil, de sua motivação. Então, o que é mais importante, o coach ou a metodologia? Um projeto de software não falha ou tem sucesso por causa da metodologia. O projeto falha por causa do coach, do líder, do gerente e de sua equipe. Quantas vezes é mais difícil manter uma equipe motivada do que implementar de fato a XP? Muitas. Então, se o coach e suas ações são o mais importante, não faria mais sentido focar nele ao invés do processo usado por ele?

A reproducibilidade das teorias criadas é outro fator que me incomoda. Em computação gráfica, por exemplo, se eu apresento uma tese e alguns resultados, independente se há pessoas envolvidas ou não, sou obrigado a descrever as condições exatas que aqueles resultados foram obtidos, permitindo que outras pessoas possam gerar o mesmo resultado. Não estou dizendo que existe uma " Silver Bullet " em computação gráfica, por isso mesmo deixamos claro as limitações das técnicas, as variantes envolvidas e os possíveis reflexos de uma implementação que não segue a risca o que foi descrito. A diferença entre as áreas aparece quando alguém tenta seguir a risca o que está escrito, em uma você tem sucesso, a outra, fracasso. Não estou dizendo que deve haver uma solução para todos os problemas, mas para que dado um problema específico, muito específico, exista uma solução que não falhe.

Até hoje, eu ainda não encontrei uma única empresa que implemente a XP tal qual descrita pelo Kent Beck. Todas elas fizeram adaptações, algumas funcionaram outras não. Isto significa que: (i) Kent Beck não descreveu completamente seu " ambiente de execução " por isso ninguém consegue reproduzí-lo (e não conseguiriam mesmo que ele descrevesse) ou (ii) a metodologia não é um caso geral, mas sim específico, pois só funciona onde foi criada (se realmente funciona). Se ela necessita de adaptações, de um Kent Beck como coach, por que não foi descrito no documento publicado? A primeira versão do XP Explained o Kent não falava sequer em adaptação, nem a do RUP (Tanto que deu muita discussão por aí sobre quem pode dizer que está usando XP). Adaptação de metodologias surgiu quando RUP começou a cair. Aí o povo se tocou que há muito mais por trás do desenv. de software do que uma simples metodologia.

No mais, é impressionante a quantidade de " casos de sucesso " que são publicados e apresentados. Casos de sucesso não são mais do que propaganda positiva para o líder daquela equipe. Veja bem, daquela equipe. Se você tentar replicar as condições daquele caso de sucesso, você e seu projeto falharão. Se o próprio líder repetir o projeto, com a mesma equipe, também vai falhar. Engraçado, não? Para que estudar algo que não poderá ser utilizado? Imagino que as pessoas que vão para essas palestras, ou leem estes documentos, procuram desculpas para também usar a metodologia ou a ferramenta em discussão. Algo como uma aposta: " se ele usou e funcionou, porque não iria funcionar comigo? " Aparentemente querem copiar o caso de sucesso de alguém, mas, lá no fundo, já sabem que não vai funcionar. Não vai funcionar porque o mundo já mudou, as ferramentas que ele usou só funcionarão com a liderança exata que ele exerceu. E estas condições, não podem ser medidas.

Se manter atualizado com os recursos a disposição é importante, porém não mais importante do que manter elevada a sua capacidade de entender e conduzir as pessoas. Eu gostaria de ver a Engenharia de Software ser sempre apresentada como ferramenta, e não como uma solucão.

PS: Da forma como está descrito hoje, o Scrum, por exemplo, não prevê saída para problemas como esse.

Posted in Dec 4, 2008 by Vitor Pamplona - Edit - History

Showing Comments

É... trabalhamos juntos em um projeto, e você conhece minhas frustrações.

Não existe e eu acredito que nunca existirá uma receita perfeita para a produção de software. Para cada etapa do desenvolvimento de software teremos artefatos com qualidades adaptadas ao momento em que vivemos, trocando em miúdos... se tudo vai bem com a equipe, melhor ainda será software.

:)


- - lcmetzger

- - Posted in May 18, 2008 by 201.24.123.198

Não entendi o seu ponto. De verdade. Você quer dizer que não dá para criar uma metodologia de desenvolvimento? Ou você quer dizer que não precisa de metodologia, basta ter um bom coach? E se esse cara morrer? E quando a equipe for mais inteligente que ele (então apenas não é bom coach?)?

"? " aos montes. Mas vamos lá:

1. XP e Scrum funcionam bem, de verdade, sem precisar do Kent Beck, porque elas contemplam princípios fundamentais para se trabalhar em grupo, como comunicação e melhoria (Reflection no XP, Restrospectivas no Scrum). Ou seja, não é o processo perfeito, mas tem, explicitamente, um modo de melhoria. Não que você vá concordar comigo, mas melhoria continua, especialmente em ciclos curtos, é uma ferramenta muito poderosa. Mesmo.

2. XP e Scrum não cobrem questões motivacionais, mas alguns resultados têm impacto. Qualidade, Get Things Done, Confiança e Comunicação são alguns deles. Outras questões como salários e benefícios estão FORA de QUALQUER metodologia de DESENVOLVIMENTO DE SOFTWARE e tanto XP quanto Scrum foram espertas o suficiente para não tentar abraçar mais do que deveriam.

3. Peopleware já explica faz um bom tempo que a maior causa de fracasso (e sucesso) dos projetos de software não tem a ver com questões técnicas, mas de pessoas, então acho que você focou no ponto errado de tentar criticar a parte técnica (as metodologias de desenvolvimento) sem tentar apresentar uma contrapartida para lidar com as pessoas - que são o que realmente importa. Desenvolver software É sobre pessoas, como qualquer outro trabalho que envolva... pessoas.

4. O coach é importante, mas é mais do que a equipe? O que é melhor, um coach medíocre com uma ótima equipe, ou uma equipe medíocre com um ótimo coach? Minha resposta é: " nenhum de nós é mais esperto do que todos nós ".

5. O ponto sobre reproduzir o modo de trabalho me lembrou esse texto do Spolsky: http://brazil.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.html

valeuz...

- - Marcos Silva Pereira

- - Posted in May 19, 2008 by 189.70.20.145

1 - É bem disto que estou falando. Esta melhoria contínua não vai funcionar se a equipe não quiser. Quem tem que fazer a equipe querer insessantemente isso é o Coach. Portanto, se o Coach falhar, não há metodologia que funcione.

2 - Se não cobrem, então eles não resolvem sozinhos, apesar de falarem que resolvem. É disto que estou falando. A metodologia não passa de, sei lá, 20%, da solução de como gerenciar um bom projeto.

3 - Não estou criticando a parte técnica. Estou criticando a forma como ela é divulgada.

4 - Um ótimo coach faz o que quiser, independente da equipe.

Em suma, uma metodologia não apresenta como o Coach deve se comportar, apesar de requerer um. É como eu mostrar como se faz a massa de um bolo, mas não dizer como se faz o recheio.

- - Vitor Pamplona

- - Posted in May 19, 2008 by 143.54.13.190

1. Se a equipe não quiser, vai adiantar o coach tentar " fazer a equipe querer incessantemente "? Você está superestimando o papel do coach e criando um problema que XP e Scrum NÃO devem resolver. Não é mais sobre o projeto, é sobre a empresa, cultura, benefícios e por aí vai.

2. Você confundiu os Princípios com as Praticas. " Economics " é um Princípio de XP, mas não lembro de já ter visto algum livro sobre XP ensinando fluxo de caixa. XP explica os Princípios para que as práticas tenham fundamento e razão de ser, Vitor. Sobre ser 20% da solução de como gerenciar um projeto: http://pt.wikipedia.org/wiki/Principio_de_Pareto

3. E como a divulgação deve ser feita?

4. Sério? Que tal então o seguinte cenário: projeto para criar uma engine de realidade virtual (vai requerer um monte de matemática, álgebra e ciência da computação de verdade, como vc sabe bem melhor do que eu). O melhor coach que vc encontrar. A equipe é formada por analfabetos. E aí?

- - Marcos Silva Pereira

- - Posted in May 19, 2008 by 189.70.245.163

Poxa, Vitor, eu acompanho seu blog e concordo com a maioria dos seus textos. Mas nesse acho que erraste, e erraste feio. XP, RUP não são teorias. Não tome essa palavra em vão... Porque fazer uma teoria implica formular um modelo que possa ser usado para fazer alguma previsão, que possa ser validado através de experimentos ou observação empírica, e estes ainda precisam ser reproduzidos de forma independente (isso tu deves saber melhor do que eu, claro). Quem disse que XP, RUP são teorias? Não são. Essa coisa de " reproducibilidade " não se aplica. Ponto.

- - Bruno Zanchet

- - Posted in May 19, 2008 by 201.22.216.132

1 - Não acho que eu esteja superestimando o papel do coach. Esse é o trabalho dele. É para isso que ele deve ser treinado. XP e Scrum não devem resolver mas eles dizem que resolvem. Qualquer livro de XP ou Scrum apresenta o conteúdo como uma forma aumentar drasticamente os resultados e comparam com RUP e outras técnicas. O fato é que eles não podem fazer esta comparação. Pois o RUP também pode aumentar drasticamente os resultados, basta ser implantado pela pessoa certa na equipe certa.

2 - Não entendi a resposta.

3 - Deve ser feita junto com um plano maior ou, pelo menos, apontar planos maiores, diretivas para o Coach e a equipe que vão fazer a XP funcionar. A XP sozinha, da forma como é descrita, não serve para nada.

4 - Se eles souberem programar até eu consigo fazer esse projeto.

- - Posted in May 19, 2008 by Vitor Pamplona

Outro detalhe - e esse é uma citação do próprio xp explained, do kent beck: " This book is my personal take on what it is that good software development teams have in common. I've taken things I've done that have worked well and things I've seen done that worked well and distilled them to what I think is their purest [..] form ".
Então, não entendo quando dizes que " não estou criticando a parte técnica - estou criticando a forma como ela é divulgada ". Que forma?!

- - Bruno Zanchet

- - Posted in May 19, 2008 by 201.22.216.132

Oi Bruno,

Exato, não são teorias, mas são vendidas como se fossem.

Sobre a reproducibilidade, ela deve que ser aplicada a qualquer texto que possua um mínimo de qualidade. Se até a Psicologia consegue publicar textos e experimentos " reprodutíveis ", por que a engenharia de software não conseguiria?

[] s

- - Posted in May 19, 2008 by Vitor Pamplona

" No entanto, [kent beck] esquece de mencionar que não é qualquer equipe pequena. É uma equipe pequena, motivada, atualizada ".

No livro: " Tecchnique also matters. [...] The pursuit of excellence in technique is critical in a social style of development. [...] XP demands that participants learn a high level of techinique in service of the teams goals.
[...]
XP teams play full out to win and accept responsibility for the consequences. [...] In XP you don't prepare for failure. Keeping a little distance in relationships, holding back effort either through underwork or overwork, putting off feedback for another round of responsibility diffusion: none of these behaviors have a place on a XP team "
(p. 4)

Puxa, se isso não é dizer que o time precisa ser / estar motivado e atualizado... Então não sei.

- - Bruno Zanchet

- - Posted in May 19, 2008 by 201.22.216.132

... Tá, mas quem vende como se fosse algo reproduzível? Critique o vendedor, não o RUP ou o XP!:)

É claro que existem trabalhos de engenharia de software com resultados reproduzíveis. O que não existe é uma receita (por exemplo, para fazer software que funcione, dentro do prazo). Existem também trabalhos de psicologia com resultados reproduzíveis. Mas não existem receitas (por exemplo, para fazer com que uma criança se torne um adulto honesto).

Então, não entendo o sentido de direcionar a crítica para as metodologias - nem mesmo os seus autores propõe que elas resolvam tudo isso que estás supondo!

- - Bruno Zanchet

- - Posted in May 19, 2008 by 201.22.216.132

A meu entender esta parte introdutória fala apenas das coisas que " não se encaixam " com XP. Não vi nenhuma frase dizendo algo como:

" The coach needs a certain expertise in relationship managements. He must act as a motivator and hold the team productivity up. We recommend to follow the instructions of X, Y and Z psychological methods during the project development... "

- - Posted in May 19, 2008 by Vitor Pamplona

Usei a metodologia que mais conheço como um exemplo. Como eu falei antes, a crítica não é em relação a metodologia, mas sim em como ela e muitos outros trabalhos da engenharia de software são apresentados.

- - Posted in May 19, 2008 by Vitor Pamplona

Impressionante.

Vim para responder esse post esperando algo como, um post reclamando de metodologias que não servem para nada e que deve-se mesmo é deixar os programadores fazerem os trabalhos deles.

Li também o link que foi citado no artigo do Bruno Carvalho. Não conheço o local de trabalho do Bruno, mas se é comum que os funcionários atrasem mais de uma hora pro trabalho e isso evidentemente está atrapalhando no trabalho da empresa. eu posso com certeza dizer que NENHUMA metodologia e nem mesmo um bom coach irá resolver o problema.

É óbvio que o XP, SCRUM e o RUP não tratem destes problemas. Eles não devem mesmo tratar deles. Não é um problema técnico e sim um problema estrutural da empresa (Talvez mudar a empresa para um lugar onde o trânsito não influencie tanto no horário dos funcionários)



- - Ricardo Cardim

- - Posted in May 19, 2008 by 201.45.184.69

Outro ponto importante.

Na engenharia civil existem métodos conhecidos e validados (!) sobre como construir casas. Então porque após séculos de engenharia ainda se constroem prédios excelentes e com a mesma metodologia alguns prédios apresentam rachaduras, problemas estruturais diversos e até caem?

Será que o problema realmente é da metodologia?

A metodologia existe como um guia. Ao gerente cabe entender o que deve ou não ser implementado. Alguém como um gerente ou consultor deve conhecer várias metodologias e saber tirar o melhor dela e também conhecer sua equipe e tirar o melhor dela.

O sucesso depende sim de processos mas não exclusivamente deles. Parte-se de uma suposição de que melhorar o processo irá melhorar o produto e aceita-se que é suficiente.

Melhorar o processo é essencial mas não suficiente. Tem que se ter em mente as pessoas, ferramentas e tudo mais que possa influenciar na organização.

O caos não é a solução para 99% dos problemas, com certeza.

- - Ricardo Cardim

- - Posted in May 19, 2008 by 201.45.184.69


Vitor,

nao concordo com o que vc escreveu...

Alguns pontos:

- " E, apesar de saberem disso, diversos autores remetem a suas criações como verdades absolutas,... " Nenhum autor de nenhuma metodologia agil que eu tenha lido ate agora coloca sua " criacao " como verdade absoluta. Tanto que por isso todos falam que as metodologias devem ser adaptadas ao ambiente sendo utilizado, que eh outro ponto que vc critica. Entao nao entendi se vc queria que fossem verdades absolutas ou nao.

- Quanto a reproduzibilidade, nao da para comparar desenvolvimento de software com a computacao grafica, justamente pq em desenvolvimento de software o principal problema eh o resultado que o cliente quer, o que eh muito dificil de captar, e introduz uma grande variabilidade no sistema. Isso ja foi discutido em varios lugares, mas a principal referencia que me lembro eh o capitulo " No Silver Bullet ", do Mythical Man Month. Isso tambem remete a velha discussao sobre engenharia civil x engenharia de software sobre o qual escrevi no meu blog, caso alguem esteja interessado (http://franktrindade.wordpress.com/2008/04/06/software-engineering-or-development /).

- Quanto ao problema citado pelo bruno, concordo com um dos comentarios acima. Nao eh Scrum, Xp ou qualquer outra coisa que vai trazer o comprometimento da equipe. Se as pessoas nao tem o minimo respeito com o horario, mesmo sabendo que eh importante (assumindo que esse seja mesmo o caso), existem problemas muito maiores a serem tratados do que a metodologia sendo utilizada.

Um abraco,
Francisco Trindade
ThoughtWorks UK
http://franktrindade.wordpress.com



- - Francisco Trindade

- - Posted in May 19, 2008 by 90.212.24.131

Oi Ricardo

Sobre o Coach. A função de um Coach é conduzir um time ao sucesso. Apesar de existirem bons treinamentos para isso, o coaching é muito mais uma característica genética do que um treinamento (o que não quer dizer que o treinamento seja dispensável). Que me desculpem os Coaches que estão lendo este post, mas se não são capazes de conduzir um time ao sucesso, se não são capazes de trabalhar o time para cumprir o objetivo proposto, não são bons Coaches. Encontrar um bom Coach é uma coisa muito rara.

Concordo com a frase: " É óbvio que o XP, SCRUM e o RUP não tratem destes problemas. Eles não devem mesmo tratar deles ". Mas isso não significa que eles não devam citar estes problemas. Existem várias condições para que cada uma destas metodologias funcione e elas não estão escritas nos livros, nem são citados pelos seus autores.

Não conheço muito a engenharia civil, mas até onde eu sei, não existem metodologias lá. Existe um conjunto de normas e métodos, mas o texto que os descreve, pelo menos até onde sei, é bem diferente de um texto de metodologia da nossa área. Me corrijam se eu estiver errado.

Oi Francisco,

A primeira versão do XP Explained o Kent não falava em adaptação, nem a do RUP. Adaptação de metodologias surgiu quando RUP começou a cair. Aí o povo se tocou que há muito mais por trás do desenv. de software do que uma simples metodologia.

Também não existe a " Silver Bullet " em Computação Gráfica, por isso mesmo deixamos claro as limitações das técnicas, as variantes envolvidas e os possíveis reflexos de uma implementação que não segue a risca o que foi descrito. A diferença entre as áreas aparece quando alguém tenta seguir a risca o que está escrito, em uma você tem sucesso, a outra, fracasso. Não estou dizendo que deve haver uma solução para todos os problemas, mas para que dado um problema específico, muito específico, exista uma solução que não falhe. Alguns trabalhos de ES tentam resolver este problema muito específico, no entanto falham em definir claramente as condições.

[] s

- - Posted in May 19, 2008 by Vitor Pamplona

Oi Vitor,

acho que a principal questao eh que reproduzir os resultados nao eh e nunca sera o objetivo. A grande diferenca quando se fala em desenvolvimento de software eh que grande parte do resultado depende das pessoas que fazem parte da equipe e de como elas interagem. E isso nao eh reproduzivel. O maximo que se consegue eh ditar alguns valores, principios e praticas que devem ser adaptadas a cada contexto.

Como seria esse cenario especifico de que vc esta falando: " Uma equipe de 10 pessoas, 1 gerente te projeto, 1 coach, 6 desenvolvedores, 2 QA's, sendo que o gerente de projeto tem 1 ano de experiencia na tecnologia X, 2 na Y, gerenciou Z projetos, de W, Q, A meses de duracao, bla, bla bla... ". Espero que tenha dado para entender o ponto.

Francisco Trindade
ThoughtWorks UK
http://franktrindade.wordpress.com

- - Francisco

- - Posted in May 20, 2008 by 217.150.124.10

Concordo contigo, Pamplona... Ainda mais agora que estou fazendo a cadeira de Eng. SW. aqui da graduação e já te contei o que a gente aprender por lá, né? ^ ^

Cara, vou aproveitar pra dizer que adoro teu Blog, só não comento muito dizendo isso pq (i) não tenho tempo e (ii) fica chato responder só " Tri o post, até mais " = P

Enfim, continue em frente;)

p.s: Vou começar também a usar a idéia do rádio que tu deu no post anterior;)

- - Zacarias

- - Posted in May 20, 2008 by 189.63.170.157

Oi Francisco

Como eu disse antes, se a psicologia e a psiquiatria, que são muito mais " cognitivas " que a engenharia de software, conseguem expor resultados reprodutíveis, por que a ES não consegue? Ou você acha mesmo que bolar uma teoria de tratamento para psicopatas, por exemplo, é mais fácil que liderar um time. Talvez o pessoal de ES precise buscar de outras áreas formas e métodos para validar suas teorias.

[] s

- - Vitor Pamplona

- - Posted in May 20, 2008 by 143.54.13.190


Oi Vitor,

nao posso comentar sobre a psicologia e a psiquiatria pq realmente nao sei como funciona nessas areas. O que eu nao concordo ainda eh pq tu tanto quer reproduzir experimentos. Essa necessidade por uma resposta exata eh o que tem prejudicado a engenharia de software (e muitas outras areas) ao longo do tempo.

Tava vendo uma palestra agora do Ricardo Semler (http://mitworld.mit.edu/video/308 /), e me lembrei exatamente desse ponto quando ele fala que em para muitos, " nao importa se estamos errados, mas temos que estar precisamente errados ".

O ponto aqui eh que desenvolvimento de software, por ser uma tarefa de equipe, e uma atividade extremamente avancada, onde tecnologia de ponta e muitas vezes nao estavel eh utilizada, nao tem como ser reproduzido em uma receita, justamente pq existe um grau de incerteza no processo que nao vai ser solucionado. Por isso que as metodologias nao podem focar em expor os detalhes de como desenvolver software, pq os detalhes (e as vezes nao so os detalhes) nao sao os mesmos para diversos contextos.

[] s
Francisco

- - Francisco Trindade

- - Posted in May 20, 2008 by 217.150.124.10

Vitor,

toda essa discussao me motivou a escrever outro post, sobre incerteza. Caso queira dar uma olhada:
http://franktrindade.wordpress.com/2008/05/20/uncertainty /

Um abraco,
Francisco Trindade
ThoughtWorks UK
http://franktrindade.wordpress.com

- - Francisco

- - Posted in May 20, 2008 by 217.150.124.10

A questão não é o líder estar certo ou apostar ou não na intuição. A questão é que a publicação TEM que estar correta. O líder faz o que quiser depois.

- - Vitor Pamplona

- - Posted in May 20, 2008 by 143.54.13.190

Vitor,

Para a publicação estar " correta " ela tem que ser " reproduzível ". Só que experimentos que são " reproduzíveis ", em desenvolvimento de software, trazem resultados e conclusões quase sempre inúteis (melhor dizendo: óbvios).

A publicação tem que estar correta se, e somente se, ela for científica, certo? O que não quer dizer que deixando de ser científica passará a ser inútil.


- - Bruno Zanchet

- - Posted in May 20, 2008 by 201.22.214.224

Vitor,

Parabéns pelo Blog e pelo Tema. Dá pra ver como as pessoas se interessam pelo assunto e sinceramente para mim tem uma explicação simples: ainda não sabemos desenvolver software.

E nesse ponto você levanta muito bem a questão. Livros são escritos de forma que parece uma verdade absoluta. Acima de se eles estão certos está a idéia de que algo só funciona (ou só seria validado) caso funcionasse em diversos ambientes diferentes.

Isso praticamente nunca foi testado.

Outro dia li que RUP deixou de ser usado porque exige muita documentação: Ora, RUP não exige que você faça toda a documentação. Ele te mostra todas as alternativas. Nem seria muito inteligente querer usar todas (algumas até se sobrepõe.

Os métodos ágeis fazem a documentação após o projeto (o que seria muito bom se as pessoas realmente fizessem isso).

Mas a maneira certa depende de cada empresa e de cada projeto. Acredito que uma metodologia deve ser seguida mas o gerente do projeto (uma papel que eu desvincularia do coach no momento) deveria ter a possibilidade e a habilidade (que como você disse, essa habilidade não se ensina na escola) de saber o que deve ou não ir para o projeto em questão.

Por isso que eu gosto tanto de software. Porque desenvolver acaba sendo diferente a cada projeto, mas não acredito que de forma nenhuma isso seja arte e sim ciência. O problema é que é uma ciência que ainda está engatinhando.

Também não entendo de Engenharia Civil, mas se o que eles tem são apenas normas e métodos (acho que vc está certo e deve ser assim mesmo) ela também seria uma arte? ACho que nesse sentido talvez mas eu prefiro ver como ciência (talvez por eu ter me formado em ciências da computação eu queira justificar o nome do meu curso, rsss)

Essa é uma discussão que via longe. Parabéns pelo blog. Vou te add lá no meu RSS. Continue postando que essas discussões são boas mesmo.



- - Ricardo Cardim

- - Posted in May 20, 2008 by 201.45.184.69

Oi Bruno,

As conclusões são óbvias depois que se lê. Antes de ler, não são tão óbvias assim.

Qualquer publicação deveria estar correta, concorda?

Oi Ricardo,

Um dia ainda vou conseguir " levantar muito bem a questão " sem precisar de tantos comentários:)

[] s

- - Posted in May 20, 2008 by Vitor Pamplona

Vitor, quando a gente clica pra ver os comentários aquela barrinha que fica em cima pra navegar entre as páginas some. Você poderia deixar a barrinha lá. Só um comentário para facilitar a navegação na página: D

- - Eu

- - Posted in May 21, 2008 by 200.198.212.195

Vitor, não concordo não! Porque " correto " não é um termo absoluto. E como mesmo escreveste, nem sempre podemos descrever completamente o contexto para dizer que os resultados estão " corretos " (e assim podem ser reproduzidos). Por exemplo, o que tem de errado em o XP Explained ser apenas " my personal take on what it is that good software development teams have in common "? Não quer dizer que seja correto. Não quer dizer que não seja.

O que queres dizer, afinal, é que o kent beck deveria ter deixado explícito que são necessários - imprescindíveis, até - um bom coach e uma boa equipe? Ou que deveria explicar - em detalhes - como conduzir e motivar as pessoas?

- - Bruno Zanchet

- - Posted in May 21, 2008 by 201.22.216.223

Deveria apontar técnicas para conduzir e motivar além de comentar sobre o coach e a equipe. Na verdade, a meu ver, isso é o mínimo que ele precisa fazer.

- - Posted in May 21, 2008 by Vitor Pamplona

Para aplicar a engenharia de software é necessario um minimo de conhecimento de conceitos. Tem que saber usar a ferramenta.

- - pedro

- - Posted in Sep 18, 2010 by 201.88.25.39

Entendi seu ponto de vista e concordo Vitor.
Eu sou fã de engenharia de software mas sei que não é a solução pra todos os problemas. Software depende muito mais das pessoas do que das metodologias e ferramenta. Mas uma boa metodologia com uma boa equipe traz resultados muito legais.
Sem metodologia, as pessoas, apesarem de ser boas, podem estar correndo uma pra cada lado. A metodologia não é silver bullet mas ajuda sendo como melhor estratégia para atingirem um resultado.

- - Ed Pichler

- - Posted in Nov 18, 2010 by 189.86.74.114

Add New Comment

Your Name:


Write the code showed above on the text below.