O que é qualidade de software?

[Alexandre Valente]

Oi pessoal,

Como a outra thread, que era sobre TDD acabou caindo neste assunto, acho que isto merece uma thread própria. 

Na outra o pessoal fala que "eu não entrego software sem qualidade". Mas todos concordam que qualidade é subjetiva. Todos concordam tbm que todo software tem bug. Então o que é qualidade? O que, para cada um de nós, é qualidade de software?

Para iniciar, eu coloco a minha visão. Qualidade pra mim é cliente e usuários satisfeitos. Usuário vai estar satisfeito se o sistema for simples de entender e usar e obviamente funcionar com o mínimo de bugs possível. Isto é valido especialmente nos caminhos comuns de navegação, ou seja, se um sistema é feito pra vender ingressos, um bug no processo de compra normal é tido como inaceitável pelos usuários (já que se isto é o mais comum, pq não conseguimos pegar o erro antes de entregar, certo?). Já um bug em áreas obscuras ou em caminhos menos usados normalmente tem menor impacto sobre a satisfação do usuário.

Para o cliente, satisfação está ligada à satisfação dos seus usuários mas também ao custo de desenvolvimento/manutenção. Um software bug-free que custa uma fortuna provavelmente vai ser tão rapidamente detonado quanto um software cheio de bugs e barato.

Sei que alguns olham o lado interno, como arquitetura, facilidade de manutenção etc. como sendo parte da avaliação de qualidade do sistema. Pra mim isto é muito relativo, já que eu não acho que software é um fim em si mesmo, e eu vejo isto como somente um dos componentes do custo. Eu já vi grandes sistemas pessimamente construídos que tinham um excelente feedback de todos os usuários; o custo maior de manutenção era absorvido pelo cliente sem problemas. No meu caso, o uso de frameworks e padrões de desenvolvimento acabam, felizmente, gerando sistemas muito parecidos internamente, então isto nem é um problema.

Outras opiniões/visões?

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

[Daniel Moreira Yokoyama]

2009/11/15 Alexandre Valente <alexandre...@gmail.com>

Para iniciar, eu coloco a minha visão. Qualidade pra mim é cliente e usuários satisfeitos.

 

Para mim a satisfação do cliente e dos usuários não determinam o PROCESSO DE QUALIDADE que eu aplico no meu software, e sim o inverso. O processo de qualidade determina a satisfação deles. Um sistema feito sob um processo de qualidade mal-definido ou nenhum processo de qualidade tem uma chance enorme de causar insatisfação do cliente, por que quanto melhor o processo de qualidade, maior o número de bugs (críticos ou não) identificados antes da entrega. Daí, o ideal seria aprender as lições (por que tais coisas não foram identificadas antes da entrega?) e evoluir o processo de qualidade a partir daí.

 

 

Sei que alguns olham o lado interno, como arquitetura, facilidade de manutenção etc. como sendo parte da avaliação de qualidade do sistema. Pra mim isto é muito relativo,

 

E décadas de evolução no processo de desenvolvimento caem por terra.

 

já que eu não acho que software é um fim em si mesmo, e eu vejo isto como somente um dos componentes do custo.

 

Arquitetura, facilidade de manutenção, são componentes do seu custo. Por que é você que vai pagar quando o mesmo cliente pedir as alterações. É você que vai abrir o código e se xingar pela falta de coesão, pelo excesso de acoplamento, por ter que retestar cada método refatorado, etc etc.

 

Eu já vi grandes sistemas pessimamente construídos que tinham um excelente feedback de todos os usuários; o custo maior de manutenção era absorvido pelo cliente sem problemas.

 

Eu tenho um nome pra isso: "Pilantragem"

 

É um velho problema, muito comum entre os brasileiros: Se aproveitar da ignorância do cliente para sugar dinheiro que ele gasta pra você fazer o que já deveria ter feito no começo. A manutenção do sistema deve servir para cobrir situações que no momento da sua concepção eram inesperadas. Mas alguns acham que um contrato de manutenção é só uma desculpa pra enviar a primeira entrega pro cliente debugar e gastar as horas de manutenção pra corrigir os bugs que o cliente identifica. Se o feedback era bom, imagina ainda se ele tivesse sido bem construído.

 

PS: Eu sou uma pessoa que reconhece ser muito difícil de se lidar. Acho que já comentei isso aqui antes: qualquer coisa que lhe possa soar como de caráter pessoal, ou até mesmo ofensivo, ignore. Tenho minha forma de colocar os pingos nos 'i's e nem sempre consigo expressá-la de forma polida. Por default, tente ler cada parágrafo como se eles sempre começassem com IMO.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

[Alexandre Valente]

Rsrsrs..... Ainda bem que vc se reconhece desta forma, realmente seu texto é no mínimo "agressivo".... Mas ok, vou abstrair e tentar só colocar um ponto....

A sua visão (e de muitos outros em maior ou menor aspecto) aparenta que vc olha o software como um trabalho acadêmico, fora do contexto de quem está vendendo (seu empregador) e do negócio do seu cliente. Fazer software desta forma é possível, desde que vc encontre um ambiente propício para isto (iniciativas open source, meio acadêmico, pesquisa em grandes empresas etc.).

Mas no cenário mais comum, de pequenas e médias empresas que fazem software como negócio, um mindset como este é tão destrutivo quanto uma má entrega. Eu jamais teria em minha equipe alguem com este tipo de atitude. Pq até acredito que seu cliente possa ficar feliz se vc conseguir entregar, porém grandes chances é que, se vc não tomar cuidado, vc vai estourar seus orçamentos ou vai fazer algo tão caro que ninguém irá conseguir vender, com resultados desastrosos pra sua empresa.

Assim, ok, respeito a sua visão. Mas não concordo nem de longe. E se como vc falou, a satisfação do cliente é resultado do processo de construção, então o meu está muito bom! :-). E finalmente, não consigo julgar como pilantragem algo sem saber exatamente o que motivou aquela situação. Mas enfim, é só a minha opinião.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/11/15 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Denis Ferrari]

Alexandre,

Na outra o pessoal fala que "eu não entrego software sem qualidade". Mas todos concordam que qualidade é subjetiva. Todos concordam tbm que todo software tem bug. Então o que é qualidade? O que, para cada um de nós, é qualidade de software?

Qualidade é atender a todos os requisitos funcionais e não-funcionais.
Qualidade é pensar no próximo fornecedor que irá trabalhar com o código construído (que pode ser você).
Qualidade é fazer que a o cliente não precise gastar rios de dinheiro para fazer alterações simples.
Qualidade é deixar portas abertas no sistema para futuras implementações.
Qualidade é usar padrões e regras lógicas no sistema, e não sair colocando nomes de pokemos como variáveis.

Para iniciar, eu coloco a minha visão. Qualidade pra mim é cliente e usuários satisfeitos. Usuário vai estar satisfeito se o sistema for simples de entender e usar e obviamente funcionar com o mínimo de bugs possível. Isto é valido especialmente nos caminhos comuns de navegação, ou seja, se um sistema é feito pra vender ingressos, um bug no processo de compra normal é tido como inaceitável pelos usuários (já que se isto é o mais comum, pq não conseguimos pegar o erro antes de entregar, certo?). Já um bug em áreas obscuras ou em caminhos menos usados normalmente tem menor impacto sobre a satisfação do usuário.

Concordo, mas não acho que qualidade seja "só" (dá trabalho conseguir) isso.

Para o cliente, satisfação está ligada à satisfação dos seus usuários mas também ao custo de desenvolvimento/manutenção. Um software bug-free que custa uma fortuna provavelmente vai ser tão rapidamente detonado quanto um software cheio de bugs e barato.

Em nenhum momento dissemos que sempre construímos sistemas para bases nucleares. Não adicionamos requisitos, só construímos os requisitos elicitados da melhor forma possível.

Como empresário posso dizer que não é fácil viver no mercado que estamos hoje com minha postura de qualidade, porém, desde que assumi essa postura não tive uma série de outros problemas que eu tinha. Quem quiser desenvolver sistemas com sobrinhos e primos que desenvolva, não quero esse mercado.

Como arquiteto não posso ter uma opinião diferente, é minha resposabilidade buscar qualidade no projeto.

Acho que minha opinião já é de entendimento de todos que leram essa thread e os exemplos da outra. Afinal de contas são perspectivas diferentes que segmentam o nosso mercado.

Abraços!

Denis Ferrari

Microsoft MCP, MCTS, MCPD e MCT
http://desenvolvimento.denisferrari.com
http://twitter.com/denisferrari

2009/11/15 Alexandre Valente <alexandre...@gmail.com>

[Denis Ferrari]

Daniel,

PS: Eu sou uma pessoa que reconhece ser muito difícil de se lidar. Acho que já comentei isso aqui antes: qualquer coisa que lhe possa soar como de caráter pessoal, ou até mesmo ofensivo, ignore. Tenho minha forma de colocar os pingos nos 'i's e nem sempre consigo expressá-la de forma polida. Por default, tente ler cada parágrafo como se eles sempre começassem com IMO.

Prefiro ter alguém na equipe que não seja político e trabalhe direito que um boa praça que baixe a qualidade do projeto.

Abraços!

Denis Ferrari

Microsoft MCP, MCTS, MCPD e MCT
http://desenvolvimento.denisferrari.com
http://twitter.com/denisferrari

2009/11/15 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Marcello Vasconcelos Felipelli]

Oi Alexandre!

Qualidade é o resultado de um processo bem definido e executado com
extrema disciplina e comprometimento.

Jogando no google....
O que é um processo de desenvolvimento?
Define quem faz o que, quando e como, para atingir um certo alvo.

Agora eu queria entender o porque não podemos trabalhar como uma linha
de produção? Por que é inviável financeiramente coordenar as atividades
mencionadas tanto no Scrum como em XP, FDD que visam a qualidade do
software?

Essa é a parte que eu menos entendi:

"A sua visão (e de muitos outros em maior ou menor aspecto) aparenta que
vc olha o software como um trabalho acadêmico, fora do contexto de quem
está vendendo (seu empregador) e do negócio do seu cliente. Fazer
software desta forma é possível, desde que vc encontre um ambiente
propício para isto (iniciativas open source, meio acadêmico, pesquisa em
grandes empresas etc.)."

Claro que uma coisa é pegar um projeto do início, mas se existem
softwares cuja a manutenção seja calçada na satisfação do cliente,
tamanha bagunça, pelo amor de Deus ... nossa ... no mundo perfeito e
acadêmico e talvez mais franco seja o melhor caminho discutir a
reconstrução do sistema, por que em algum momento "isso vai dar merda",
overtime, stress, desgaste, etc. (rsrs)

Como vc fala, o cliente não quer ter a menor a idéia de como vc vai
fazer o software, assim como os moradores do prédio do Sérgio Naia, que
tiveram o fim que tiveram, não estavam preocupados com o ferro e o
concreto utilizado. Mas será que esse é o fim queremos para os nossos
clientes/usuários?

Quando melhor trabalharmos, quando melhor for apurada a nossa capacidade
de abstração, e visão de que o negócio do cliente sofre alterações e que
o quanto formos mais sinceros e jogarmos limpo com o cliente mais
contratos teremos. Dentro de um mesmo projeto, outros novos projetos
podem ser descobertos. (Talvez esse seja o mundo perfeito)

Abs.

Marcello

[Pedro Reys]

2009/11/15 Marcello Vasconcelos Felipelli <marcello.v...@gmail.com>

Agora eu queria entender o porque não podemos trabalhar como uma linha
de produção?

 

Simplesmente pq a metáfora não se aplica. Não se desenvolve software com um processo repetitivo de juntar sempre as mesmas partes, da mesma maneira, para chegar sempre ao mesmo resultado. Desenvolvimento de software está ligado ao desenvolvimento de um novo produto, não da produção do mesmo.

[Marcello Vasconcelos Felipelli]

Pedro,

Mas o resultado, pensando de forma BASTANTE genérica, não é o mesmo? Não
é um artefato que será testado e principalmente utilizado por alguém?

Abs

Marcello Felipelli

[Daniel Moreira Yokoyama]

2009/11/15 Alexandre Valente <alexandre...@gmail.com>

Rsrsrs..... Ainda bem que vc se reconhece desta forma, realmente seu texto é no mínimo "agressivo".... Mas ok, vou abstrair e tentar só colocar um ponto....

 

Somente quem lida comigo acaba se acostumando a esse meu jeito. Mas vamos lá... tentando não repetir a agressividade:

 

A sua visão (e de muitos outros em maior ou menor aspecto) aparenta que vc olha o software como um trabalho acadêmico, fora do contexto de quem está vendendo (seu empregador) e do negócio do seu cliente. Fazer software desta forma é possível, desde que vc encontre um ambiente propício para isto (iniciativas open source, meio acadêmico, pesquisa em grandes empresas etc.).

 

Não fora do contexto... mas criando o meu próprio contexto e buscando que este contexto também seja considerado por parte deles. Uma via de duas mãos. E não trabalho com iniciativas open source, nem no meio acadêmico, nem em setor de pesquisa. Trabalho com projetos de software para atender o mercado como a maioria de todos aqui.

 

Mas no cenário mais comum, de pequenas e médias empresas que fazem software como negócio, um mindset como este é tão destrutivo quanto uma má entrega.

 

Mais comum para você. Reconheço que o mercado não é de todo adepto, mas entendo que a maior parte do mercado se preocupa com a satisfação do cliente.

 

Eu jamais teria em minha equipe alguem com este tipo de atitude. Pq até acredito que seu cliente possa ficar feliz se vc conseguir entregar, porém grandes chances é que, se vc não tomar cuidado, vc vai estourar seus orçamentos ou vai fazer algo tão caro que ninguém irá conseguir vender, com resultados desastrosos pra sua empresa.

 

Prometo que se um dia isso acontecer eu te aviso.

[Daniel Moreira Yokoyama]

2009/11/15 Pedro Reys <pedr...@gmail.com>

Simplesmente pq a metáfora não se aplica. Não se desenvolve software com um processo repetitivo de juntar sempre as mesmas partes, da mesma maneira, para chegar sempre ao mesmo resultado. Desenvolvimento de software está ligado ao desenvolvimento de um novo produto, não da produção do mesmo.

 

O Software muda. O processo não. No máximo, amadurece.

[Pedro Reys]

2009/11/15 Daniel Moreira Yokoyama <moreira....@gmail.com>

2009/11/15 Pedro Reys <pedr...@gmail.com>

Simplesmente pq a metáfora não se aplica. Não se desenvolve software com um processo repetitivo de juntar sempre as mesmas partes, da mesma maneira, para chegar sempre ao mesmo resultado. Desenvolvimento de software está ligado ao desenvolvimento de um novo produto, não da produção do mesmo.

 

O Software muda. O processo não. No máximo, amadurece.

IMO o processo muda sim. Talvez porque eu ainda não encontrei este super "one size fits all process". E acho meio difícil de encontrar isso um dia.

[Pedro Reys]

2009/11/15 Marcello Vasconcelos Felipelli <marcello.v...@gmail.com>

Pedro,

Mas o resultado, pensando de forma BASTANTE genérica, não é o mesmo? Não
é um artefato que será testado e principalmente utilizado por alguém?

O fato do resultado ser um produto que será testado e utilizado por alguém não é o suficiente para validar a metáfora.  O processo não é repetitivo. São duas coisas completamentes diferentes.

[Leandro Daniel]

Bom dia a todos!

 

Pessoal, convido-os a lerem a série de posts que estou escrevendo em meu blog sobre o Visual Studio 2010. Comentários são bem-vindos!

 

http://reverb.leandrodaniel.com/reverb/?tag=/visual+studio+2010

 

Também podem me acompanhar pelo Twitter: @leandronet

 

Abraços,

 

Leandro Daniel

MCAD, MCSD, CSM
http://reverb.leandrodaniel.com

con...@leandrodaniel.com

 

 

[Felipe Oriani]

Eu penso semelhante a alguns colegas aqui...  onde qualidade é determinada pela facilidade de se manusear o software de forma geral, desde atender aos requisitos do usuários de forma eficaz/direta até a organização do projeto (relação no time, arquitetura, código-fonte, bd, facilidade em manutenção, etc...)

2009/11/15 Pedro Reys <pedr...@gmail.com>

--
______________________________________
Felipe B. Oriani
fbor...@gmail.com | www.felipeoriani.com.br

"...Examina o sentido, o modo e a direção de tuas palavras, antes de pronunciá-las.." por Emmanuel

[Chan Valle]

Assunto complicado em ....
Bem a meu ver a qualidade é diferente para os diversos pontos
existentes.
Se você perguntar para o cliente o a qualidade vai ser uma coisa, se
perguntar para o usuário vai ser outra, para o programador outra e
assim sucessivamente.
Creio que a satisfação do cliente e do usuário não é suficiente para
se ter qualidade de software, já vi clientes ficarem satisfeitos com
softwares que não funcionavam, ou funcionavam meia boca, mas eram
bonitos, e clientes insatisfeitos com um que era bem rápido, bem
arquitetado e funcionava que era uma blz ... (no fim trocaram por um
lento, meia boca, mas bonito).
Então qualidade envolve muito mais coisas, creio que se o software
atender todos os lados a que se destina o software é o mais próximo de
se chegar à qualidade de software.

On 16 nov, 09:29, Felipe Oriani <fbori...@gmail.com> wrote:
> Eu penso semelhante a alguns colegas aqui...  onde qualidade é determinada
> pela facilidade de se manusear o software de forma geral, desde atender aos
> requisitos do usuários de forma eficaz/direta até a organização do projeto
> (relação no time, arquitetura, código-fonte, bd, facilidade em manutenção,
> etc...)
>

> 2009/11/15 Pedro Reys <pedror...@gmail.com>
>
>
>
> > 2009/11/15 Marcello Vasconcelos Felipelli <marcello.v.felipe...@gmail.com>

>
> >> Pedro,
>
> >> Mas o resultado, pensando de forma BASTANTE genérica, não é o mesmo? Não
> >> é um artefato que será testado e principalmente utilizado por alguém?
>
> > O fato do resultado ser um produto que será testado e utilizado por alguém
> > não é o suficiente para validar a metáfora.  O processo não é repetitivo.
> > São duas coisas completamentes diferentes.
>
> --
> ______________________________________
> Felipe B. Oriani

> fbori...@gmail.com |www.felipeoriani.com.br

[Leo D]

As respostas vão variar dependendo do que a pessoa vê como "objetivo
final" na produção de software. Se é prioritariamente técnico ou se é
atender ao negócio. São dois focos diferentes.

Quem tem perfil estritamente técnico vai dizer que qualidade é a adoção
de "boas práticas" (usar a última palavra em determinada tecnologia ou
aquilo que está na moda), e a satisfação do cliente será uma
consequência disso.
Quem tem visão comercial entende qualidade como a satisfação do cliente
primeiro, e a adoção de "boas práticas" não é algo religioso ou
dogmático, mas sim feito para atender aos objetivos comerciais que estão
em jogo.

[]s

[Henry Conceição]

O livro "Lean Software Development, an Agile Toolkit" tem uma parte
legal sobre essa diferença entre processo de desenvolvimento e
processo de produção, e pq a criação de software está mais para o
primeiro do que para o segundo.

On 15 nov, 23:11, Pedro Reys <pedror...@gmail.com> wrote:
> 2009/11/15 Marcello Vasconcelos Felipelli <marcello.v.felipe...@gmail.com>

[Denis Ferrari]

Leo,

As respostas vão variar dependendo do que a pessoa vê como "objetivo
final" na produção de software. Se é prioritariamente técnico ou se é
atender ao negócio. São dois focos diferentes.

Acredito que a qualidade final do projeto é a junção de todos os pontos de vista coletados. O projeto não pode ser bom só para o cliente pois ele não entende de desenvolvimento e não terá competência para realizar uma série de avaliações assim como o projeto não pode ser bom só para o arquiteto.

Abraços!

Denis Ferrari

Microsoft MCP, MCTS, MCPD e MCT
http://desenvolvimento.denisferrari.com
http://twitter.com/denisferrari

2009/11/16 Leo D <l...@codigofluente.com.br>

[Rafael Noronha]

Alexandre,

Para mim qualidade deve ser medida através de aspectos técnicos, sim.
Mas este tipo de qualidade por si só jamais determinará o sucesso de
um projeto.

É aqui que eu vejo que o pessoal pode quebrar a cara.

De que adianta entregar um software seguindo as melhores técnicas e
ignorar uma determinada limitação de projeto (prazo, custo...)

Alguém aí me responde essa?
Seu cliente vai te agradecer por um software que o Fowler assina
embaixo, mas que estourou prazo e custo?

Talvez vocês só coloquem o pescoço em projetos perfeitos, onde o custo
trazido pela "garantia de qualidade" não representa qualquer tipo de
problema para o cliente.

Não estou defendendo fazer as coisas de qualquer jeito, mas vejo uma
enorme limitação em profissionais que só conseguem enxergar o lado
técnico da coisa.

[Giovanni Bassi]

Cada projeto é diferente. O processo, em vez de traçar o caminho, deve apenas indicar o destino. (Estou poético)
O caminho é responsabilidade do time. E a experiência anterior vai dizer o que entra ou não, do framework usado nos outros projetos.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/15 Pedro Reys <pedr...@gmail.com>

[Giovanni Bassi]

Aí que está Rafael, eu não faço projetos com essa tal de determinada limitação de prazo. Se eu sei que não sei quanto tempo vai levar pra fazer o projeto, deixo isso claro. Lembre-se do cone da incerteza. Ele é fatal, e vai alcançar-nos todos, queiramos ou não.
A maior falácia do mercado de software é assumir que é capaz de estimar com precisão, o que é um absurdo, já que estimativa, segundo o dicionário, significa "calculo aproximado".
Não é.

Estimativa  == Cálculo aproximado

"You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one's impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)
Does this sound like what you are asked for when you're asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better."

Primeiros parágrafos do livro "Software Estimation: Demystifying the Black Art", da Microsoft Press, que você compra aqui na Amazon por meros 50 reais.

Compromisso é diferente de estimativa.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/16 Rafael Noronha <rafan...@gmail.com>

[Giovanni Bassi]

Qualidade é você entregar o que você prometeu. Simples assim. Se você prometeu que 95% do software ia funcionar, e funciona, então você tem qualidade. Se 94,99% funcionam, você não tem.
Se você sabe que todo software tem bugs, então não se comprometa com 100% de funcionamento. Se seu processo só entrega 70% de confiança, venda esse percentual. Se você entregar 71%, você tem qualidade.

Qualidade é fim, não é meio. A melhor maneira de atingir esse fim, a mais barata, é seguindo boas práticas. Isso significa iterações curtas, TDD, padrões, pareamento, etc, onde aplicável.

Uma empresa pode ignorar as boas práticas e ter qualidade. Isso não significa que ela é eficiente. E o mercado de TI ainda permite que empresas ineficientes funcionem. Mas não para sempre. Eu achei que essa crise apertaria o mercado o suficiente para pressionar esse tipo de empresa e o darwinismo resolveria o resto. Eu estava errado. Esse cofre é mais fundo do que pensei. Fato é: práticas ágeis e boas práticas em geral floreceram na crise, enquanto o "processo tradicional" perdeu espaço. O mercado está percebendo que não vale a pena investir no passado.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/15 Alexandre Valente <alexandre...@gmail.com>

[Henry Conceição]

Rafael,

Acho que você mesmo respondeu sua pergunta: Qualidade != Sucesso.

Acho que tendo um bom padrão de qualidade, as chances do projeto ter
sucesso aumentam. Mas nada impede que um projeto de qualidade inferior
obtenha o sucesso.

[Juan Pedro A. Lopes]

<flame>
http://tecnologia.terra.com.br/interna/0,,OI4085835-EI4801,00-Windows+e+um+sucesso+de+mercado+segundo+analistas.html
</flame>


--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

"E se o mundo não corresponde em todos os aspectos a nossos desejos, é culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl Sagan

[Phillip Calçado]

Oi,

2009/11/16 Marcello Vasconcelos Felipelli <marcello.v...@gmail.com>:

> Agora eu queria entender o porque não podemos trabalhar como uma linha
> de produção?

Porque uma linha de produção produz mil carros IGUAIS por dia. Eu já
trabalhei em "fábricas de software" mas nunca as vi entregando o mesmo
software mais de uma vez.

> Por que é inviável financeiramente coordenar as atividades
> mencionadas tanto no Scrum como em XP, FDD que visam a qualidade do
> software?

Por que inviável?

[]s

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br

[Phillip Calçado]

Oi,

2009/11/17 Rafael Noronha <rafan...@gmail.com>:

> De que adianta entregar um software seguindo as melhores técnicas e
> ignorar uma determinada limitação de projeto (prazo, custo...)
>
> Alguém aí me responde essa?

Existem escolhas que devem ser feitas quanto ao nível de qualidade de
qualquer coisa, seja o software quanto um carrinho de bebê. Você pode
escolher o carrinho de bebê com menos qualidade -que talvez só dure
três anos ao invés de,digamos, 5- mas não ficaria feliz se o
fornecedor te entregasse um carrinho que se desgoverna ou joga a
criança no chão. Existem limites mínimos para qualquer coisa ser
considerada um trabalho profissional e até mesmo aceitável.

Mas gostaria de inverter a pergunta: por que seguir as melhores
práticas fariam com que seu prazo ou preço estourasse? Será que
estamos trabalhando com prazos e/ou preços realistas?

[Phillip Calçado]

Oi,

2009/11/16 Alexandre Valente <alexandre...@gmail.com>:

> A sua visão (e de muitos outros em maior ou menor aspecto) aparenta que vc
> olha o software como um trabalho acadêmico, fora do contexto de quem está
> vendendo (seu empregador) e do negócio do seu cliente. Fazer software desta
> forma é possível, desde que vc encontre um ambiente propício para isto
> (iniciativas open source, meio acadêmico, pesquisa em grandes empresas
> etc.).

Engraçado, eu não entendi isso no email do Daniel. O que eu entendi
ele dizendo é que qualidade interna tem sim muita importância para o
cliente, já que afeta o TCO do software. O problema é que clientes não
conseguem ver esta qualidade e os "pilantras" se aproveitam disso para
entregar qualquer coisa que quase-funcione. Bem pouco acadêmico e bem
realista.

Este é um ponto que sempre bati: isso de "o cliente não se importa com
a qualidade interna" é uma falácia. O cliente não se importa tanto
quanto eu não me importo se meu avião possui um tanque de combustível
50% cheio ou 10% cheio quando pousa. Eu passo a me importar quando a
empresa aérea me diz que para abastecer o avião vão ter que atrasar em
duas horas o meu vôo.

Eu não entendo nada de aviação mas estou pagando caro para que alguém
que teoricamente entenda me leve de um lugar X a um lugar Y em um
determinado tempo. Se isto não for feito não me importa se é porque o
pátio está lotado, o avião ainda está sendo limpo ou porque o bugfix
requer que 200 arquivos que foram copiados e colados sejam
modificados.

[Alexandre Valente]

Oi Phillip,

Então, eu acho engraçado como o termo "pilantra" é usado... Vcs realmente encontraram gente na vida de vcs que falaram "ah, eu sei fazer melhor mas como eu quero enganar este cliente, vou entregar um lixao".... Eu nunca....

E por incrivel que pareça, o pior sistema que eu já vi, em termos de bagunça interna e facilidade de manutenção, foi um que foi criado por um arquiteto bem conhecido no mercado (sem nomes! :-)). E tenho certeza que ele não fez por mal, começo com uma boa itenção e foi pessimamente executado.

E todos os casos de sistemas complexos de manter pra mim sempre foram um dos dois casos: ou quem fez não sabia o que estava fazendo direito (e aí eu não chamaria de pilantra), ou a decisão foi tomada para se seguir daquela forma por algum motivo.

Como já foi citado um exemplo aqui, imagine um cliente pedindo um prototipo pro dia seguinte para fechar um negocio que se não for dia seguinte nao serve. Que trocas seriam feitas para atender o prazo? Eu faria quase todas. E eu não chamaria de alguem que fez nesta situação de pilantra..... 

O pessoal fala direto que o "custo de manutenção" é alto. Com base em que? Será que alguem realmente consegue saber o quanto baixou de custo por uma ou outra tecnologia no decorrer dos anos? Tenho muitas dúvidas. E eu tenho muitos exemplos do contrário, algo feito rápido pra um objetivo, que mesmo considerando o custo de refatoração (ou reconstrucao completa depois) com certeza foi mais lucrativo do que algo que tivsse perdido um prazo ou objetivo inicial.

E mesmo para as grandes empresas que o pessoal fala que são "pilantras", eu não seria tão rápido em chamar assim. Muitas vezes colocar estagiários é a única maneira de fazer a conta de um projeto fechar. Ai nao seria muito mais pilantra qem contrata sabendo que isto vai acontecer assim?

Por visao academica eu quis dizer pessoas que estao olhando pro software e não para o negócio. Eu acho que software nunca é o objetivo de nada, e só no meio academico ou em áreas de pesquisa de grandes empresas vc tem o luxo de fazer isto. Claro que concordo que software deve ser feito com o maximo de qualidade possível. Mas o que é isto? O meu eu sei bem qual é o padrão nível e que eu acho que é muito bom.... Mas para cada cenário, cada pessoa o conceito de qualidade varia, então, do que estamos falando? 

Então pra mim, nada é preto ou branco. E eu não teria coragem de julgar o que outra pessoa fez, muito menos colocar o label de "pilantra" em alguem... Mas, only IMHO.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/11/17 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi,

2009/11/18 Alexandre Valente <alexandre...@gmail.com>:

> Então, eu acho engraçado como o termo "pilantra" é usado... Vcs realmente
> encontraram gente na vida de vcs que falaram "ah, eu sei fazer melhor mas
> como eu quero enganar este cliente, vou entregar um lixao".... Eu nunca....

Sim. Muitas vezes, desde que o lixão fosse benéfico para o fornecedor.

> Como já foi citado um exemplo aqui, imagine um cliente pedindo um prototipo
> pro dia seguinte para fechar um negocio que se não for dia seguinte nao
> serve. Que trocas seriam feitas para atender o prazo? Eu faria quase todas.
> E eu não chamaria de alguem que fez nesta situação de pilantra.....

Pois é, mas você falou a palavra de ouro: protótipo. Se você quiser um
protótipo eu abro meu emacs e te entrego algo em duas horas usando
Sinatra. Mas é um protótipo que pode servir para validar/vender sua
idéia, mas é um protótipo.

É como uma maquete: serve para ter uma idéia do prédio mas não serve
para morar lá.

> O pessoal fala direto que o "custo de manutenção" é alto. Com base em que?
> Será que alguem realmente consegue saber o quanto baixou de custo por uma ou
> outra tecnologia no decorrer dos anos? Tenho muitas dúvidas. E eu tenho
> muitos exemplos do contrário, algo feito rápido pra um objetivo, que mesmo
> considerando o custo de refatoração (ou reconstrucao completa depois) com
> certeza foi mais lucrativo do que algo que tivsse perdido um prazo ou
> objetivo inicial.

Existem estudos sobre isso se você quer saber um número
pseudo-científico. Um deles:

http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

> E mesmo para as grandes empresas que o pessoal fala que são "pilantras", eu
> não seria tão rápido em chamar assim. Muitas vezes colocar estagiários é a
> única maneira de fazer a conta de um projeto fechar. Ai nao seria muito mais
> pilantra qem contrata sabendo que isto vai acontecer assim?

Desculpe mas isso não é aceitável na minha opinião, seja em software
ou em qualquer coisa. Não é ético porque provavelmente o cliente não
tem conhecimento do que é necessário -e nem deve ter, o especialista é
você e não ele.

É como, voltando para o exemplo do avião, eu insistir com a aeromoça
que não quero por o cinto de segurança e que arco com as
consequências. Sabe o que ela vai fazer? Eu vou ser convidado a sair
da aeronave, se preciso com ajuda da polícia.

> Por visao academica eu quis dizer pessoas que estao olhando pro software e
> não para o negócio. Eu acho que software nunca é o objetivo de nada, e só no
> meio academico ou em áreas de pesquisa de grandes empresas vc tem o luxo de
> fazer isto.

Ok mas eu não vi isso no email dele, muito pelo contrário.

> Claro que concordo que software deve ser feito com o maximo de
> qualidade possível. Mas o que é isto? O meu eu sei bem qual é o padrão nível
> e que eu acho que é muito bom.... Mas para cada cenário, cada pessoa o
> conceito de qualidade varia, então, do que estamos falando?

A qualidade ideal para um projeto varia, como falei antes. Existem
coisas, entretanto, que são sempre erradas e uma delas é aceitar um
projeto com prazo impossível ou que será feito apenas por estagiários
quando o preço cobrado é por desenvolvedores sênior. Isso não é
qualidade, é má fé.

> E eu não teria coragem de julgar o
> que outra pessoa fez, muito menos colocar o label de "pilantra" em alguem...

Eu vivi uma situação interessante. Eu já trabalhei para pilantras e
pedi demissão exatamente por entender que o que eles queriam não eram
uma relação de negócios com o cliente mas sim extrair tudo o que
conseguissem deles, custe o que custar. Quando sai da última empresa
pilantra eu entrei em uma empresa que não era consultoria e meu
primeiro trabalho foi lidar com um outro fornecedor pilantra que
estava há três anos desenvolvendo um sistema prometido para 3 meses.

Tendo visto de fora e de dentro eu me acho capacitado para dizer: é
pilantragem. E por pilantragem eu quero dizer falta de ética e de
comprometimento com o cliente. Lucrar é uma coisa, se aproveitar dos
outros é outra bem diferente.

Note, por favor, que eu não estou te chamando ou a qualquer um nesta
discussão de pilantra. Estou apenas comentando práticas e
anti-patterns de indústria.

[Denis Ferrari]

Rafael,

Para mim qualidade deve ser medida através de aspectos técnicos, sim.
Mas este tipo de qualidade por si só jamais determinará o sucesso de
um projeto.

Não me lembro de ninguém ter dito que só a técnica definia o sucesso do projeto, nem  na outra thread.

De que adianta entregar um software seguindo as melhores técnicas e
ignorar uma determinada limitação de projeto (prazo, custo...)

Se você não possui um prazo descente para garantir a qualidade necessária para o projeto, não é sábio embarcar nessa "aventura".

Alguém aí me responde essa?
Seu cliente vai te agradecer por um software que o Fowler assina
embaixo, mas que estourou prazo e custo?

Ninguem está interessado em ganhar uma estrelinha na testa do Fowler, estamos interessados em entregar um projeto que atenda a todos os requisitos impostos pelo cliente, funcionais, não-funcionais, prazo e custo.
Seu cliente está interessado em um trabalho profissional, fazer de qualquer jeito o sobrinho dele já fazia.

Talvez vocês só coloquem o pescoço em projetos perfeitos, onde o custo
trazido pela "garantia de qualidade" não representa qualquer tipo de
problema para o cliente.

Quem dera se a vida fosse assim.

Não estou defendendo fazer as coisas de qualquer jeito, mas vejo uma
enorme limitação em profissionais que só conseguem enxergar o lado
técnico da coisa.

Concordamos em não fazer de qualquer jeito, porém, mesmo entendendo o lado comercial não tenho a intenção de prostituir o lado técnico dos projetos.

Abraços!

Denis Ferrari
"Deixo meu suor no campo de treinamento, para não deixar meu sangue no campo de batalha" Sun Tzu

Microsoft MCP, MCTS, MCPD e MCT
http://desenvolvimento.denisferrari.com
http://twitter.com/denisferrari

2009/11/16 Rafael Noronha <rafan...@gmail.com>

[Eduardo Miranda]

Então, eu acho engraçado como o termo "pilantra" é usado... Vcs realmente encontraram gente na vida de vcs que falaram "ah, eu sei fazer melhor mas como eu quero enganar este cliente, vou entregar um lixao".... Eu nunca....

 

Assim como o Phillip eu também já pedi demissão de uma empresa onde todo o trabalho técnico era feito por estagiários, enquanto o cliente era cobrado por hora de consultor senior. A prova do "dolo" era que o gerente sempre nos lembrava que os clientes não podiam saber "que os meninos são estagiários" (com direito a sorriso maquiavélico no final). E nem o cliente, nem a consultoria eram pequenas empresas, nem médias.

 

Se isto não é pilantragem eu não sei o que é.

 

 

2009/11/18 Alexandre Valente <alexandre...@gmail.com>

[Rafael Noronha]

Denis,

Ninguém falou em prostituir o lado técnico.
O que eu não engulo é a conversinha de que apenas com o uso de X, Y e
Z, meu software vai ter qualidade, e este uso deve ser praticado
independente de determinada limitação comercial.

Phillip,

Sim, obviamente existe problema no mercado em relação ao prazo de
projetos de software.

[Eduardo Miranda]

Talvez vocês só coloquem o pescoço em projetos perfeitos, onde o custo

trazido pela "garantia de qualidade" não representa qualquer tipo de

problema para o cliente.

Isto está ficando repetitivo, vc insiste em afirmar que se alguém não pensa como vc é porque "não está fazendo software de verdade", "é do mundo acadêmico" ou "vive em um mundo perfeito".

 

 

2009/11/18 Denis Ferrari <denis....@gmail.com>

[Denis Ferrari]

Rafael,

Ninguém falou em prostituir o lado técnico.

Se o projeto não atende aos requisitos de qualidade necessários (especificados e não especificados pelo cliente) e o custo/prazo é usado como justificativa algo está errado.

O que eu não engulo é a conversinha de que apenas com o uso de X, Y e
Z, meu software vai ter qualidade, e este uso deve ser praticado
independente de determinada limitação comercial.

Bom, acredito que não estamos discutindo isso.
Se o comentário foi com base na defesa sobre TDD da outra Thread, continuo dizendo que EU sempre utilizo, porém, não espero que todos o façam. TDD é uma técnica, mas existem várias, use a que achar melhor.

Abraços!

Denis Ferrari
"Deixo meu suor no campo de treinamento, para não deixar meu sangue no campo de batalha" Sun Tzu

Microsoft MCP, MCTS, MCPD e MCT
http://desenvolvimento.denisferrari.com
http://twitter.com/denisferrari

2009/11/18 Rafael Noronha <rafan...@gmail.com>

[Daniel Moreira Yokoyama]

Se o seu processo muda você está com problemas.

 

Como eu disse, no máximo ele amadurece. Você aplica o processo hoje, amanhã você apanha por que deixou de observar etapas ou ações necessárias para o sucesso do projeto, depois de amanhã vc inicia outro projeto aplicando as lições aprendidas. Você evoluiu seu processo. Você não pega todas as coisas que aprendeu e joga fora a cada início de um novo projeto.

 

Se faz isso, você definitivamente precisa rever seus conceitos.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/11/15 Pedro Reys <pedr...@gmail.com>

[Daniel Moreira Yokoyama]

2009/11/16 Rafael Noronha <rafan...@gmail.com>

Alexandre,
Para mim qualidade deve ser medida através de aspectos técnicos, sim.
Mas este tipo de qualidade por si só jamais determinará o sucesso de
um projeto.

Ninguém disse isso. Aplicar a qualidade não se trata apenas de adotar boas práticas. Trata de passar por um ciclo de QA bem definido e maduro a ponto de fazer uma boa entrega.

 

A qualidade técnica (qualidade de código) é a qualidade que você aplica pra você mesmo, não pro cliente. Coesão e Acoplamento é algo que nós aprendemos pra fazer código que nós possamos dar manutenção sem precisar ter dores de cabeça.

 

De que adianta entregar um software seguindo as melhores técnicas e
ignorar uma determinada limitação de projeto (prazo, custo...)

Quem disse que ignoramos?

 

Alguém aí me responde essa?
Seu cliente vai te agradecer por um software que o Fowler assina
embaixo, mas que estourou prazo e custo?

Não. Até por que ninguém aqui faz questão que o Fowler assine embaixo de nada. O Fowler não tem nada de especial além de simplesmente publicar artigos dos quais a comunidade pode tirar boas lições. A boa notícia é que a maior parte do que ele escreve SÃO boas lições. Assim, se você, por exemplo, tentasse escrever de algo útil invés de criticar o uso de boas práticas, a comunidade iria te dar a mesma atenção, e nem por isso iria também querer  que você assinasse embaixo de qualquer coisa.

 

Talvez vocês só coloquem o pescoço em projetos perfeitos, onde o custo
trazido pela "garantia de qualidade" não representa qualquer tipo de
problema para o cliente.

Já trabalhei pra uma empresa que parecia ter medo do cliente. Ela tinha um contrato para prestação de um determinado serviço (que não era desenvolvimento de software) mas se achava na obrigação de fazer tudo o que o cliente pedia (inclusive desenvolvimento de software) pra não perder o contrato. Vou explicar melhor, o cliente contratou para  ter acesso a um portal da empresa que dispunha determinadas informações. Conforme o tempo foi passando o cliente passou a pedir por integrações com seus sistemas internos e a empresa simplesmente se dispunha a desenvolvê-los.

 

Tente advinhar quanta coisa mudou quando a empresa passou a dialogar com o cliente. Tente advinhar quantos clientes ela perdeu quando passou a tratar cada requisição dessa como um projeto orçado, com custo e prazo.

 

Se você abre as pernas para tudo  o que o cliente pede você nunca vai descobrir quanto stress vc teria poupado se simplesmente disser para o cliente que "Determinado requisisto não pode ser atendido no prazo que você está pedindo."

 

Simples assim. Como funciona onde eu trabalho agora? O cliente não estabelece prazo, nós passamos o nosso, e o nosso já contempla análise, implementação e QA. Quando o cliente pede por um prazo reduzido é muito simples, perguntamos a ele que requisito ele quer retirar do escopo. Simples assim. Desta forma o cliente aprende que não existe "quero por que quero". Quer saber quantos cliente perdemos por causa disso? Nenhum. Quer saber quantos deles estão insatisfeitos? Nenhum. Pra falar a verdade eles até gostam mais quando você coloca os pingos nos i's.

 

 

[Daniel Moreira Yokoyama]

2009/11/18 Alexandre Valente <alexandre...@gmail.com>

Então, eu acho engraçado como o termo "pilantra" é usado... Vcs realmente encontraram gente na vida de vcs que falaram "ah, eu sei fazer melhor mas como eu quero enganar este cliente, vou entregar um lixao".... Eu nunca....

 

Se for necessário que a pessoa use todas estas palavras pra classificar como pilantra então eu nunca vi um. Mas entenda, fica fácil classificar quando você usa outros critérios.

 

E por incrivel que pareça, o pior sistema que eu já vi, em termos de bagunça interna e facilidade de manutenção, foi um que foi criado por um arquiteto bem conhecido no mercado (sem nomes! :-)). E tenho certeza que ele não fez por mal, começo com uma boa itenção e foi pessimamente executado.

 

Mas isso só significa que não importa o quão especialista/Senior/Deus você seja, se você não tiver um processo de QA maduro, você pode estar comprometendo o projeto e, no caso deste, a própria imagem. Não é engraçado, quando me vi na condição que vc prega, de atentar a prazo e custo acima da qualidade (prazo e custo estipulado pelo próprio cliente) era muito comum eu ouvir da diretoria "Mas não é você o especialista?". Desnecessário dizer que o fato de ser especialista ou não não vem ao caso quando você aceita trabalhar sobre pressão. Você comete erros devido a falta de atenção em requisitos que funcionavam na hora que vc implementou mas deixaram de funcionar quando você implementou outros, além de muitos outros problemas desse modelo de trabalho. Desnecessário tamém é dizer que eu nunca mais precisei ouvir esse tipo de pergunta quando comecei a trabalhar em empresas que zelam pela qualidade do próprio serviço. Elas cobram de mim a qualidade. Para que o cliente não cobre delas.

  

E todos os casos de sistemas complexos de manter pra mim sempre foram um dos dois casos: ou quem fez não sabia o que estava fazendo direito (e aí eu não chamaria de pilantra),

 

Não chamaria de pilantra, chamaria de incompetente. O mínimo que se espera ao pegar um projeto é entender o que se quer fazer. Se até agora estávamos falando de um ciclo maduro de QA, este caso carecia de um ciclo maduro de análise.

 

ou a decisão foi tomada para se seguir daquela forma por algum motivo.

 

Ou por falta de ética ou por falta de cobrar do cliente uma definição consistente. Existem coisas que é responsabilidade do cliente em fornecer. Se o gerente de projeto não souber cobrar isso dele, a equipe vai ter que fazer do jeito que der na hora que o pepina aparecer.

 

Como já foi citado um exemplo aqui, imagine um cliente pedindo um prototipo pro dia seguinte para fechar um negocio que se não for dia seguinte nao serve. Que trocas seriam feitas para atender o prazo? Eu faria quase todas. E eu não chamaria de alguem que fez nesta situação de pilantra..... 

 

O Phillip já comentou a respeito do protótipo.

 

O pessoal fala direto que o "custo de manutenção" é alto. Com base em que?

 

Por manutenção você entende Requisição de mudanças ou Correção de Bugs? Entende a diferença das duas coisas? Uma é uma mudança de escopo, a outra é fazer com que o sofware obedeça o escopo num caso onde ele não estava obedecendo. RM reflete em caixa entrando para a sua empresa (caixa de onde sai o seu salário), Correção de Bugs reflete em prejuízo, por que o cliente não paga pra que você faça o que já devia ter feito, e o seu diretor vai cobrar de você a justificativa de por que ainda não conseguiu fechar o projeto que foi entregue 3 meses atrás.

 

Será que alguem realmente consegue saber o quanto baixou de custo por uma ou outra tecnologia no decorrer dos anos? Tenho muitas dúvidas. E eu tenho muitos exemplos do contrário, algo feito rápido pra um objetivo, que mesmo considerando o custo de refatoração (ou reconstrucao completa depois) com certeza foi mais lucrativo do que algo que tivsse perdido um prazo ou objetivo inicial.

 

Imagina então a lucratividade de ter feito algo que atendesse todos os requisitos e passado por um processo maduro de QA? Você negociaria um prazo aceitável (independente da qualidade ninguém deveria aceitar prazos que não conseguem cumprir) e não teria em uma única entrega obtido o mesmo lucro ou, no mínimo, ao longo prazo, menos prejuízo justamente com esse custo de refatoração ou reconstrução completa. O problema é que você relaciona "fazer algo bem feito" com "atrasar a entrega". Quando você entender que não existe esta ligação intrínseca, talvez você entenda os benefícios de se fazer algo bem feito.

 

E não se esqueça também que no longo prazo o barato sempre sai caro. É fácil olhar pro lucro no fim do mês, por isso que existem empresas que investem em QA, pq sabem que não adianta nada lucrar uma fortuna em janeiro, mas chegar em dezembro e descobrir que desde a entrega de janeiro o produto não fica 1 mês inteiro sem ser mexido. Aquele dinheiro que ela recebeu em janeiro já foi e ela continua pagando as horas dos desenvolvedores pra resolver os problemas que foram consequência dessa entrega às pressas pra atender o cliente.

 

E mesmo para as grandes empresas que o pessoal fala que são "pilantras", eu não seria tão rápido em chamar assim. Muitas vezes colocar estagiários é a única maneira de fazer a conta de um projeto fechar. Ai nao seria muito mais pilantra qem contrata sabendo que isto vai acontecer assim?

 

Nós sabemos que não é bem assim. Ninguém pede pra colocar estagiários cuidarem do software. O cliente pode ser esperto, mas não é bobo. Ele pode tentar barganhar preço, mas não vai tentar barganhar o profissional que vai cuidar do que ele está pagando.

 

Por visao academica eu quis dizer pessoas que estao olhando pro software e não para o negócio. Eu acho que software nunca é o objetivo de nada, e só no meio academico ou em áreas de pesquisa de grandes empresas vc tem o luxo de fazer isto.

 

Não é o meu caso e mesmo assim sou estimulado a dar estimativas considerando todo o tempo necessário pra fazer algo que atenda o cliente da melhor forma possível. O cliente recebe esta estimativa em horas e pode ou não aprovar. Mas não aprovar impacta em escolher requisitos a serem tirados do escopo. Na maioria dos casos os clientes só se dão conta da importância que dão pra isso quando você pede pra ele tomar esse tipo de decisão. E é aí que ele passa a te respeitar.

 

Claro que concordo que software deve ser feito com o maximo de qualidade possível.

 

Então essa discussão não faz sentido.

 

Mas o que é isto? O meu eu sei bem qual é o padrão nível e que eu acho que é muito bom.... Mas para cada cenário, cada pessoa o conceito de qualidade varia, então, do que estamos falando? 

 

Será que varia mesmo? Ou será que o que varia é a desculpa que as pessoas dão pra justificar a aplicação ou falta dela? A aplicação varia, mas isso são outros quinhentos. Você pode ter seu próprio ciclo de QA e ele pode ser uma mistura de conceitos úteis ou um processo totalmente criado por você e só estas duas hipóteses pode resultar numa variedade enorme de escolhas.

 

Então pra mim, nada é preto ou branco. E eu não teria coragem de julgar o que outra pessoa fez, muito menos colocar o label de "pilantra" em alguem... Mas, only IMHO.

 

Existem situações onde isso se torna evidente. Mas como eu disse antes, não sou muito politizado. 

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

[Daniel Moreira Yokoyama]

2009/11/18 Rafael Noronha <rafan...@gmail.com>

Ninguém falou em prostituir o lado técnico.
O que eu não engulo é a conversinha de que apenas com o uso de X, Y e
Z, meu software vai ter qualidade, e este uso deve ser praticado
independente de determinada limitação comercial.

E a conversinha de que o cliente quer mais é receber algo rápido feito às pressas?

 

Mas não é uso de X Y e Z a questão. É seu software ter qualidade, independente de como você garanta isso.

[Rafael Noronha]

Daniel,

Eu não critico o uso de boas práticas, pelo contrário.
Acabei trazendo da thread sobre TDD o meu descontentamento com o
discurso de algumas pessoas.

A impressão que tenho é de que há quem dê mais importância ao ego do
que às reais necessidades do cliente.

O meu posicionamento é o de que mesmo as melhores práticas precisam
ter o seu custo analisado,

Não sou contra entregar um software com 90% de cobertura de testes,
por exemplo.
Mas sou contra fazer isso sem fazer uma devida análise do que se ganha
e do que se perde.

[Juan Pedro A. Lopes]

Mais ou menos na onda do assunto, o post do Akita:

http://akitaonrails.com/2009/11/18/off-topic-restaurantes-e-tecnologia

(...) Decisões que normalmente se encaixam bem em enterpriseys são tomadas em empresas de tecnologia e vice-versa. É um dos motivos de muitas discussões inúteis. Eu consigo entender porque um banco se sentiria incomodado de implementar hoje uma nova tecnologia, vamos chutar, trocar alguns de seus DB2 por um CouchDB por exemplo. Também consigo entender porque uma empresa médica ficaria relutante em trocar seus atuais programas embarcados de C, por exemplo, por .NET micro framework. Não quer dizer que nenhuma delas tenta, mas sim que não é o caso da maioria e nem que as tecnologias não funcionariam.

O mesmo não pode ser dito de “empresas de tecnologia”. Nesse contexto, tentar usar o que há de mais novo e mais avançado deveria ser o normal. Mais do que isso: criar as próprias tecnologias deveria ser o normal. Agora, a preocupação é que isso fique aleatório, desordenado e leve ao caos. Não se trata disso. É justamente por isso que empresas de tecnologia como Google, Microsoft, Novell, RedHat e diversos outros menores tem algo que se assemelha a um departamento de “Research & Development” (pesquisa e desenvolvimento), ou no mínimo a noção de “pesquisar e experimentar”. É por isso que eles se esforçam em contratar os profissionais do mercado que estão na ponta das novas tecnologias, coisa que não faz sentido por exemplo em um banco, ou uma seguradora, ou uma empresa de transportes.

2009/11/18 Rafael Noronha <rafan...@gmail.com>