Getting in Real

heatcold:

A ideia era termos 3 integrantes no time:

1. Webdesigner - HTML/CSS/Tableless (View)
2. Desenvolvedor Frontend - Java (Controler)
3. Desenvolvedor Backend - Java (Model)
   

[]s

"Os Três Mosqueteiros

Use uma equipe de três para a versão 1.0
Para a primeira versão da sua aplicação, comece com apenas três pessoas. Este é o número mágico que lhe dará força de trabalho suficiente sem lhe tirar o dinamismo e a agilidade. Comece com um desenvolvedor, um designer e um varredor (alguém que possa transitar entre ambos os mundos)."

Eu só adaptei a situação utilizando o MVC.
Acho que funciona legal.

Acho que todos aqui nesse forum faria bem ( ou melhor) o papel de desenvolvimento backend.

Nesse caso, deixa eu deixar claro os papeis dentro do que estou pensando:

1. webdesigner: responsavel pela criação da interface gráfica do sistema, utilizando html/css/js.
2. frontend: responsavel pela criação da camada de controle, validações de tela e integração entre a interface gráfica e a camada de serviços
   (estou projetando um sistema orientado a serviços).
3. backend: responsavel pela camada de serviços (incluindo suas validações) e a camada de persistencia.

Acredito que seja uma questão de conceito.

<blockquote><div class="quote-author">heatcold:</div>2. Desenvolvedor Frontend  - Java (Controler)

3. Desenvolvedor Backend - Java (Model)

</blockquote>

Essa divisão não faz sentido nenhum… pegue um cara bom de Java que ele fará as duas “tarefas” tranquilamente, e vc ainda terá uma boca a menos pra sustentar… a menos que sua startup esteja cheia da grana e isso não faça diferença.

[]s

Continuo com a opinião que todos fariam bem o backend (Alguns talvez se interessariam pela interface/layout).

Luiz, não da pra dizer que não faz sentido sem conhecer a extratégia que será utilizada no desenvolvimento.

Essa abordagem é parecida com a que aconteceu na revolução industrial.
Inicialmente, uma pessoa que construia alfinetes, por exemplo, fazia parte de todas as partes do processo, ou seja: desenrolar o arame, cortar as cabeças dos alfinetes e juntar a cabeça do alfinete com o seu corpo. Em media, uma pessoa conseguia produzir 90 alfinetes por dia. A sacada foi dividir o serviço em 3 pessoas e cada uma fazia a tarefa. Após essa divisao a média de alfinetes produzidor por dia, passou a ser 3000, por pessoa.

Outro exemplo que segue o mesmo raciocinio é produção de uma garrafa pet.
Uma garaffa pet é produzida em 3 paises diferentes. Onde cada país é responsavel por um parte do processo.

Eu sei o que estou falando e sei como ganhar produtividade com menos esforço seguindo esse modelo.

Quanto as bocas para alimentar?
“Preocupe-se com os problemas quando eles aparecerem.”

:!: :!: :!: FRASE POLÊMICA DETECTED ! :!: :!: :!:

heatcold:

Luiz, não da pra dizer que não faz sentido sem conhecer a extratégia que será utilizada no desenvolvimento.

Essa abordagem é parecida com a que aconteceu na revolução industrial.
Inicialmente, uma pessoa que construia alfinetes, por exemplo, fazia parte de todas as partes do processo, ou seja: desenrolar o arame, cortar as cabeças dos alfinetes e juntar a cabeça do alfinete com o seu corpo. Em media, uma pessoa conseguia produzir 90 alfinetes por dia. A sacada foi dividir o serviço em 3 pessoas e cada uma fazia a tarefa. Após essa divisao a média de alfinetes produzidor por dia, passou a ser 3000, por pessoa."

Essa idéia não é novidade em nossa área. Pode acreditar

Eu sei que não.
Só estou defendendo meu ponto de vista.

Dizer que não é novo, não quer dizer que não valido.
Bancos de dados NoSQL são projeto a mais de 15 anos.

De qualquer forma, discutir sobre isso, foge a essencia desse topico.

heatcold:

Essa abordagem é parecida com a que aconteceu na revolução industrial.
Inicialmente, uma pessoa que construia alfinetes, por exemplo, fazia parte de todas as partes do processo, ou seja: desenrolar o arame, cortar as cabeças dos alfinetes e juntar a cabeça do alfinete com o seu corpo. Em media, uma pessoa conseguia produzir 90 alfinetes por dia. A sacada foi dividir o serviço em 3 pessoas e cada uma fazia a tarefa. Após essa divisao a média de alfinetes produzidor por dia, passou a ser 3000, por pessoa.

Outro exemplo que segue o mesmo raciocinio é produção de uma garrafa pet.

Uma coisa já provada com décadas de estatísticas é que desenvolver software baseado em abordagens industriais como se fosse fazer um carro, uma garrafa pet ou um alfinete, é completamente errado e falho, a porcentagem de projetos que falham (em escopo, orçamento, prazo, nos 3 ou em alguns deles) é muito maior que os que conseguem sucesso, sem falar no aumento extremo de custos que essas abordagens podem causar a um projeto.

Acho que ninguém esta te recriminando ou tentando fazer vc desistir de algo, estamos apenas tentando lhe mostrar que pode fazer melhor e ter melhores resultados, eu não “perderia” 5 minutos escrevendo isso se não acreditasse de verdade que posso lhe ajudar com o que estou falando, assim como os demais.

Boa sorte.

Luiz, agradeço seus comentarios (e os do immortalSoul) e posso lhe adiantar que nenhum deles foi impertinente.

Só não quero entrar no merito desse tipo de discussao.

A metodologia (getting in real) nada tem a ver com a produção industrial e só citei aquele exemplo com o intuito de expandir a nossa percepção,
demonstrando que é possivel distruibuir o trabalho de forma a aumentar a produtividade, desde que seja feito de forma coerente
(falo em coerencia pois não sei se o exemplo das 9 mulheres é valido nesse caso).

O sucesso ou não dessa abordagem vai depender da experencia de quem estiver aplicando.
(nosso time é dividido dessa forma e lhe garanto que funciona, desde que seja bem entendido)

heatcold:

Luiz, agradeço seus comentarios (e os do immortalSoul) e posso lhe adiantar que nenhum deles foi impertinente.

Só não quero entrar no merito desse tipo de discussao.

A metodologia (getting in real) nada tem a ver com a produção industrial e só citei aquele exemplo com o intuito de expandir a nossa percepção,
demonstrando que é possivel distruibuir o trabalho de forma a aumentar a produtividade, desde que seja feito de forma coerente
(falo em coerencia pois não sei se o exemplo das 9 mulheres é valido nesse caso).

O sucesso ou não dessa abordagem vai depender da experencia de quem estiver aplicando.
(nosso time é dividido dessa forma e lhe garanto que funciona, desde que seja bem entendido)

Quando ele falou do caso das 9 mulheres:

Leitura mais que recomendada.

Legal! Comprei o livro. (por sinal não vai de encontro ao que eu havia proposto)

ixi, vai ser dificil arrumar um cara pra view, a maioria prefere backend…, assim como você…

você vai trabalhar somente nesse projeto ou tem algum emprego fixo?

Beleza Douglas?

Pois é, como java é uma tecnologia voltada para web achei que seria mais facil achar um programador frontend.
Por sorte encontrei um cara muito bom pra fazer esse papel.

Meu desafio agora é encontrar um webdesigner, mas caso não encontre, vamos dar um outro jeito.

Tenho trabalho fixo sim. Esse projeto estou fazendo nas horas vagas.

se eu fosse de curitiba eu até gostaria de ficar entre o back e o front…

mais como sou de campinas, e ja iria começar remoto, talves não seja sua idéia

abs

A ideia inicial era concentrar o pessoal em mesmo lugar, mas falo com você logo que precisarmos de um ‘varredor’ (back/front).
valeu!

douglaskd:

se eu fosse de curitiba eu até gostaria de ficar entre o back e o front…

mais como sou de campinas, e ja iria começar remoto, talves não seja sua idéia

abs

Bom, nop Getting in real, eles contam a experiência que um dos membros da equipe se encontra em um local com um fuso horário tbm bem diferente dos demais…

Seria uma excelente forma de treinar inclusive isso… Se quiserem, tenho uma idéia de Projeto… Podemos colocar em prática os conceitos do Getting In Real…

Só tenho que reler pra reforçar de vez os conceitos que acabo nunca aplicando em um trabalho tradicional do qual estou buscando me livrar…

Abs []

Adriano, acho que pode ser uma boa. O que voce propôe?

Realmente é dificil aplicar o ‘getting in real’ em qualquer empresa.
Nem todo mundo conhece a metodologia, o que gera resistencia, e essa filosofia não concorda em tudo com o agile (ex: scrum),
apesar de ter vários pontos em comum.

Quanto ao “Getting in Real” eu acho que está totalmente de acordo com a Filosofia ágil sim.

Como coloquei acima e o Luiz bem ressaltou de forma clara, é bom que realmente o Getting in Real seja bem entendido para poder ser perfeitamente aplicável…

Uma coisa que percebi da 37 Signals e foi o que mais gostei nas práticas da Doc. foi o fato de eles avisarem de forma clara que isso que está escrito lá é a forma que ELES trabalham e a filosofia adotada na empresa deles… Que fique claro que se precisarmos ir de encontro ao “Getting in Real” em algum quesito porque funcionamos assim, ou somos mais produtivos assim, que assim seja, façamos o que temos que fazer para sermos uma equipe forte…

Por isso disse que embora não se adeque às Metodologias Ágeis, cai como uma luva na Filosofia Ágil…

Abs []

Um ponto de divergencia entre o scrum e o getting in real por exemplo:

'Reuniões São Tóxicas

Não tenha reuniões:
Você precisa mesmo de reuniões? Reuniões geralmente acontecem quando um conceito não está claro o suficiente. Ao invés de recorrer a uma reunião, tente simplificar o conceito, para que você possa discutí-lo rapidamente por email ou IM ou Campfire. O objetivo é evitar reuniões. Cada minuto que você gasta em uma reunião é um minuto que você poderia estar trabalhando.’

É totalmente o contrário das ‘standup meetings’ sugeridas pelo scrum.

Não digo que uma coisa não tenha nada haver com a outra, mas existem divergencias.

Entendi o que você disse. Realmente faz sentido.

O Getting Real não é uma metodologia hein… precisam ter isso muito fixo em mente… o livro foi baseado num conjunto de atitudes, conceitos e pensamentos que deram muito certo para a 37Signals e inspiraram outras empresas que absorveram e adaptaram os conceitos do livro para o ambiente deles.

[]s

aff… fiz merda na pressa de responder… editei o meu Post e não dei o Quote no que havia dito…

PQP… heueheueueeu… enfim, acho que vocês leram o que escrevi anteriormente…

Abs []