Re: [androidbrasil-dev] Comunicação Cliente - Servidor

Bacana pessoal!

Também acredito que, há casos e casos, e, é claro, estou tentando
simplificar ao extremo aqui o tipo de
produto desenvolvido, também levo em consideração um produto maduro
que o cliente está disposto a pagar
e o produto está em constante desenvolvimento, e, independentemente de
bugs, ele funciona sem causar
detrimento ao cliente.

O foco na minha frase não foi o sistema conter ou nào bugs, todos eles tem,
quem nunca criou bugs que atire a primeira pedra...kkk

Há casos e casos de produtos que podem ou não ter bugs, aplicativos de
missão crítica,
exigem um desenvolvimento mais estruturado, e também, com processos de
correção ou
identificação de bugs, seguindo aquela linha de Functional
Verification Testing, Internet
Verification Testing, Performance Testing, Security Standards check,
Architecture Review Board, etc.
Mas estes projetos ficam na mão de empresas gigantescas, e, portanto
não era o escopo do meu reply naquele e-mail.

Conto com o bom senso de todos, e, espero que tenham entendido o ponto
que quero chegar, e,
nada do que disse é uma cartilha a ser seguida à risca.

Valorizo muito a fase de levantamento de requisitos e, acredito que há
produtos a serem
criados dos quais nem mesmo os clientes sabem.

Dêem uma olhada neste vídeo, é uma Lean Startup dentro de uma empresa
gigantesca, a Nordström,
eles criaram um lab de inovações, para, poder realizar novos produtos
em tempos recorde, este processo facilita a criatividade e a
interatividade com o cliente, ou o processo lean chamado de Genchi
Gembutsu, ou seja, vá e veja você mesmo o que o seu cliente precisa,
ou do que o seu produto precisa para atrair mais clientes...

Eles criam um aplicativo de iPad em 1 semana, indo direto ao cliente e
levantando os requisitos
e seguindo um passo de ciclos de implementação bastante interessante...

http://www.youtube.com/watch?v=szr0ezLyQHY

Como o foco da lista é desenvolvimento de aplicativos para
dispositivos móveis, acredito que com um time enxuto e
com muita criatividade consigam também ir pesquisar melhor seu cliente
e tentar ao máximo entender do que ele
precisa pois muitas vezes nem o cliente sabe mesmo o que ele quer!

[]'s

Ernani

2013/2/5 Renato Lima <renattolima@gmail.com>:

> Opa, a discussão tá boa, então só pra botar mais lenha na fogueira:
>
> Concordo com suas colocações Fernando, mas como bem colocado pela citação do
> meu chará logo acima: as coisas devem ser equilibradas.
>
> Quando você disse ao Ernani para "pensar fora da caixa", imagino que você
> deva fazê-lo antes, pois ao meu ver você está pautado num modelo tradicional
> que, de fato, faz todo o sentido no contexto por você colocado. Contudo não
> podemos tirar o mérito daqueles que fazem uma ideia acontecer independente
> de seguir padrões ou boas práticas de programação e nesse mundo altamente
> concorrente de startups isso faz uma diferença enorme. Falo com a
> experiência de quem já esteve dos dois lados da moeda (startups e uma
> empresa tradicional com um sistema consolidado e uma grande carteira de
> clientes).
>
> Já cansei de ver de perto os benefícios de boas práticas, assim como também
> aprendi a aceitar que elas podem (e às vezes até devem) ser colocadas de
> lado afim de tirar uma ideia do papel quando você sente que o tempo dela
> pode passar se você não agir rápido. Quando você já tem uma equipe concisa
> acostumada com padrões tudo flui, mas tente fazer isso com pessoas que não
> estão acostumadas a eles, pode ser desastroso.
>
> Eu tinha o pensamento como o seu Fernando, mas foi trabalhando com uma
> startup que eu aprendi a "pensar fora da caixa". Por isso acredito
> totalmente na proposta do Ernani que um sistema pode sim ser rentável mesmo
> apresentando bugs, aí entra seu poder de administração dos mesmos e saber o
> que realmente é prioritário para o seu cliente.
>
> Just my 2 cents.
>
> Abraço,
>
>
> Em 5 de fevereiro de 2013 03:46, Renato Toi <renato.toi@gmail.com> escreveu:
>
>> Excelente discussão. Há poucos dias li uma citação mais ou menos assim;
>> "quando os americanos colocaram uma estatua em homenagem à liberdade na
>> costa leste, deveriam ter colocado uma estatua à responsabilidade na costa
>> oeste".
>>
>> Longe de mim querer discutir política, ideologia ou estatuas. Uso a
>> citação apenas para ilustrar os seguintes pontos:
>> 1- se há apenas uma dimensão sendo avaliada, cuidado, você pode estar
>> esquecendo de coisas importantes. O mundo não é uni-dimensional, e muitas
>> vezes ha diversas dimensões a avaliar. Considerar apenas a métrica
>> "quantidade de bugs" pode não ser o melhor.
>> 2- "responsabilidade" é um critério essencial para as decisões gerenciais.
>> A decisão bugs x prazo aparece constantemente em nossa vida. Agir
>> responsavelmente é um julgamento para o qual não há formula, que se altera
>> conforme o cliente, o tipo de produto, a nossa experiência etc.
>>
>> Abraços a todos
>> Renato
>>
>> Em 05/02/2013, às 03:28, Fernando Costa <fcosta@inmov.net> escreveu:
>>
>> Ernani
>>
>>
>> Ainda discordo que seja purismo e na sua colocação sobre sistemas sem
>> bugs.
>>
>> Não acredito que a entrega incremental deixe espaço para "liberar mesmo
>> com vários bugs"; pelo contrário. Como você sabe,  a entrega incremental  é
>> para medir o valor agregado do entregável agora e não no fim do projeto como
>> promove processos cascateados. Isso muda significamente a projeção do ROI e
>> Payback, além de diminuir os riscos do processo de desenvolvimento.
>>
>> Também venho acompanhado nestes 8 últimos anos equipes de 6, 600 e 2000
>> desenvolvedores diariamente respondendo requisitos de empresas como Shell,
>> Petrobrás, NET, McDonalds, Banco do Brasil, entre outros... Assim como
>> acompanhado desenvolvimento de softwares que faturam mais de 200 milhões de
>> reais ano e discordo categoricamente.. Os bugs não são notados pois os
>> cenários (user stories) não são testado como se devem ou porque a cobertura
>> do código não é suficiente! nem a cobertura de testes unitários nem as de
>> integração. Isso é fato!
>>
>> Em estratégias fremium, adotadas por diversas startups, alguns erros
>> matariam o produto no primeiro ano. No primeiro ano.  (Lembre-se que neste
>> período somente 1% transforma-se em clientes que pagam)
>>
>> Para saber se um sistema é viável ou não há inúmeras abordagens já
>> estudadas e praticadas por empresas de diversos portes. Sobre as
>> funcionalidades adequedas a serem promovidas a release concordo com você e
>> com a literatura. Há uma outra excelente literatura para isso: "Where good
>> ideas come from?".
>>
>> Obrigado pela conversa. Excelente tópico!
>>
>> []s FC
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Em 5 de fevereiro de 2013 01:36, Ernani Joppert Pontes Martins
>> <joppert@gmail.com> escreveu:
>>>
>>> Fernando, já imaginava que esta parte do texto fosse ser meio polêmica
>>> e, não foi à toa, só não quero causar atritos na lista, com um e-mail
>>> gigantesco, e sim trazer
>>> ao bom senso o que aprendi vendo exemplos por aí e lendo livros e
>>> aplicando na prática...
>>>
>>> Mas, também para não deixar a coisa de uma maneira tão vaga, e, dando
>>> margem à interpretações mil, quando quis dizer isto, levei como pré
>>> requisito um sistema funcional e que gera lucros...
>>>
>>> Depois claro que foquei também na quantidade de bugs...
>>>
>>> Quando saímos da faculdade, queremos por mais que tudo colocar todos
>>> os conceitos aprendidos na universidade e nos livros puristas as
>>> práticas ensinadas na teoria, mas, a prática é bem diferente...
>>>
>>> O foco aqui está no sistema funcional, e lucrativo, se o cliente
>>> paga,é porque está satisfeito...
>>>
>>> Se há bugs ou não, o cliente está pagando, e, se está pagando mesmo
>>> com bugs, por pior que seja este aspecto, significa que eles não
>>> causam detrimento do seu produto em questão...
>>>
>>> Agora, também abordando a qualidade de software, tenho acompanhado
>>> exaustivamente a maturidade da turma, e, sei que em toda sua maioria o
>>> pessoal aqui é bem fluente no que faz...tenho visto trabalhos
>>> exemplares...
>>>
>>> Gostaria que alguns até se manifestassem, mas, acho que é um uníssono,
>>> quando falamos que não existe sistema sem bugs...
>>>
>>> Os bugs as vezes existem e nem sequer notamos, a não ser quando o
>>> cliente reporta o quando damos a sorte de captá-lo antes de um
>>> release.
>>>
>>> Muitas abordagens, tais como TDD e afins, evitam esta situação, SCRUM
>>> também foca em bugs identificados para serem trabalhados no backlog do
>>> próximo release.
>>>
>>> O problema é que num ambiente enxuto, onde temos o desenvolvedor e
>>> mais ninguém ou, num caso de sorte, 2 amigos desenvolvedores, na sua
>>> garagem de casa (trazendo um pouco da era .com), isto é praticamente
>>> uma utopia.
>>>
>>> Claro que o sistema livre de bugs é o ideal, mas, se você não soltar
>>> seu produto o mínimo funcional possível, com várias coisas para
>>> colocar em prática, e, consequentemente vários bugs para corrigir ou
>>> várias melhorias para implementar, você nunca vai saber realmente se
>>> seu produto é viável e quando mencionei este texto, foi de uma maneira
>>> sucinta e um tanto quanto chocante (de propósito) de expor este
>>> processo prático de pensar em realmente lançar algo funcional,
>>> imperfeito mas, aceitável a fim de que seu cliente pague por ele e
>>> mantenha seu time ou você à todo vapor motivado a melhorar o sistema
>>> até que se torne algo tão viável que possibilite pensar em estratégias
>>> ainda mais ricas para a melhoria do produto em si...
>>>
>>> É o lance do livro lean startup, onde o cara do livro trabalhava numa
>>> empresa que fundaram, chamada de IMVU, e, tinha vários bugs o sistema
>>> de chat deles, era um chat tipo second life, com personagens em 3d, e,
>>> colocaram uma funcionalidade do personagem de teleportar, em vez de
>>> animar o personagem de um ponto A a um ponto B, e, depois de uma
>>> pesquisa de comportamento dos clientes, a fim de conseguirem mais
>>> usuários pagos, descobriram que este trade off era na verdade uma das
>>> funcionalidades mais interessantes para os clientes pagos, e, pararam
>>> de focar no que achavam legal e economizaram um tempo absurdo que
>>> teriam gasto se tivessem segurado o release do produto a fim de
>>> implementar esta tal funcionalidade que julgavam ser primordial.
>>>
>>> []'s
>>>
>>> Ernani
>>>
>>> 2013/2/5 Fernando Costa <fcosta@inmov.net>:
>>> > Prezado Ernani
>>> >
>>> > Quase enriquecedor seu email,  mas vi que você fudeo quando escreveu a
>>> > pérola "Eu sou partidário de que o melhor sistema ou tecnologia é
>>> > aquele que
>>> > funciona e dá lucro, independentemente da quantidade de bugs, problemas
>>> > ou
>>> > sequer arquitetura, ..".
>>> >
>>> > Prezado, como uma pessoa com sua experiência me solta essa pérola? Como
>>> > um
>>> > sistema pode funcionar independente da quantidade de bugs? Como podemos
>>> > defender um arquitetura middle-out assim?
>>> >
>>> > Nós como fornecedores de solução podemos manter uma mentalidade assim?
>>> >
>>> > Vamos pensar fora da caixa.
>>> >
>>> > Abs,
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Em 4 de fevereiro de 2013 19:12, Ernani Joppert Pontes Martins
>>> > <joppert@gmail.com> escreveu:
>>> >
>>> >> Acredito que tanto upgrades verticais quanto horizontais fariam
>>> >> diferenças significativas num ambiente apache + php dependendo do tipo
>>> >> de setup feito no apache.
>>> >>
>>> >> O apache 2 é multithreaded e, o php, se instalado com a libphp, que é
>>> >> um módulo do apache, suportaria threading também, o que, se, no caso
>>> >> de um upgrade de processador com mais cores, beneficiaria o setup.
>>> >>
>>> >> Memória, tudo depende do tipo de aplicação em questão, como os scripts
>>> >> em PHP são short lived, ou seja, executam e morrem, raramente precisam
>>> >> de muita RAM, o que pode ser feito é uma otimização no apache a fim de
>>> >> limitar ou aumentar a quantidade de threads e requests por thread e a
>>> >> quantidade de processos filhos que ele sobe inicialmente e qual o
>>> >> máximo de quantidade de threads ele aguentaria, o que, sinceramente
>>> >> consegue-se uma performance absurda.
>>> >>
>>> >> Tudo isto poderia beneficiar-se de um upgrade de RAM, dependendo da
>>> >> quantidade de memória definida por processo do PHP.
>>> >>
>>> >> Confesso que após vários projetos em Java. onde para a aplicação
>>> >> funcionar, precisava-se de um app server, e, consigo uma série de
>>> >> setups, tunning e ajustes de segurança, o Java e a JVM em si comem
>>> >> muita RAM, já o PHP é mais flexível nesta parte, e, por isto, o custo
>>> >> de hospedagem é mais em conta.
>>> >>
>>> >> Acredito que não exista bom ou ruim, nem melhor ou pior, o que define
>>> >> muito o ecossistema de uma empresa, e sua infra de TI é a vontade de
>>> >> adotar-se um padrão de desenvolvimento e por isto optam homogenização
>>> >> da tecnologia e com isso o Java sai em vantagem por estar presente em
>>> >> várias plataformas, inclusive embarcados.
>>> >>
>>> >> O PHP também está, mas, como é mais voltado para a Web, e, não tanto
>>> >> para comunicações remotas, tais como CORBA, RMI, IIOP e afins, ele
>>> >> acaba perdendo interesse das grandes empresas.
>>> >>
>>> >> Temos muitos casos de uso, mas, falando mais do PHP, o Facebook, por
>>> >> seguir uma linha mais voltada à Web, e também para webservices, deu um
>>> >> jeito interessante de inovar o PHP criando o compilador HIP HOP, que
>>> >> transforma os scripts em C puro, e também está adotando um mecanismo
>>> >> de JIT (Just in Time Compiler) justamente para poder tirar o máximo do
>>> >> proveito da velocidade de execução dos scripts.
>>> >>
>>> >> Bacana divagar sobre isto por horas, mas, o foco da lista é Android,
>>> >> peço desculpas pelo OT, mas acho legal que os desenvolvedores da
>>> >> lista tenham um entendimento mais macro de um ambiente distribuído e
>>> >> também não mitifique uma tecnologia X ou Y.
>>> >>
>>> >> Eu sou partidário de que o melhor sistema ou tecnologia é aquele que
>>> >> funciona e dá lucro, independentemente da quantidade de bugs,
>>> >> problemas ou sequer arquitetura, e, muitas vezes algumas linguagens da
>>> >> qual o desenvolvedor é mais familiarizado dá à ele a possibilidade de
>>> >> transofrmar a idéia em algo real e concreto, a fim de depois se
>>> >> preocupar com problemas dos quais todos nós gostaríamos de enfrentar,
>>> >> se, é claro, o negócio realmente for algo viável!
>>> >>
>>> >> Abraço,
>>> >>
>>> >> Ernani
>>> >>
>>> >> 2013/2/4 Ricardo Othuki <othuki@gmail.com>:
>>> >> > Escalabilidade vertical seria um Upgrade no servidor, como por
>>> >> > exemplo,
>>> >> > um
>>> >> > processador mais rápido, mais memória, maior numero de "cores", etc.
>>> >> > Sem entretanto aumentar o numero de servidores. Com Apache + PHP,
>>> >> > este
>>> >> > tipo
>>> >> > de upgrade fara pouca diferença em casos de alta concorrência.
>>> >> >
>>> >> > Normalmente tenta-se um upgrade vertical (de menor custo) e ao
>>> >> > atingir o
>>> >> > limite, parti-se a horizontal, incluindo mais servidores para
>>> >> > atender a
>>> >> > demanda, com mais servidores tem-se a necessidade de um load-balance
>>> >> > ou
>>> >> > outras soluções que impactam diretamente nos custos.
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed to the Google
>>> >> > Groups
>>> >> > "Android Brasil - Dev" group.
>>> >> > To unsubscribe from this group and stop receiving emails from it,
>>> >> > send
>>> >> > an
>>> >> > email to androidbrasil-dev+unsubscribe@googlegroups.com.
>>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups
>>> >> "Android Brasil - Dev" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, send
>>> >> an
>>> >> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>>> >> For more options, visit https://groups.google.com/groups/opt_out.
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > FERNANDO DA COSTA
>>> > Inmov - Inteligência em Movimento
>>> > fcosta@inmov.net
>>> > +55(11)2175-1174
>>> > +55(11)9319-8385
>>> > FaceBook Page
>>> > Siga-nos no twitter: @inmov
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "Android Brasil - Dev" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to androidbrasil-dev+unsubscribe@googlegroups.com.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Android Brasil - Dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>>
>> --
>> FERNANDO DA COSTA
>> Inmov - Inteligência em Movimento
>> fcosta@inmov.net
>> +55(11)2175-1174
>> +55(11)9319-8385
>> FaceBook Page
>> Siga-nos no twitter: @inmov
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Android Brasil - Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Android Brasil - Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to androidbrasil-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
>
>
> --
> Renato Lima
> @renattolima
> +55.31.8829.3777
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Brasil - Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to androidbrasil-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.