Deu pau no TI......

Apesar da alta necessidade nos próximo 5 aninhos ae, acredito que cada dia vai ficar mais difícil achar profissionais como hoje. Basta analizar o que as ferramentas de hoje disponibilizam no quesito "botão direito, next, next > finish, meu sistema está pronto".

Se os caras conseguirem socar 213.000 profissionais no mercado em 5 anos, nem quero ver o que vai sair. Vai sair várias caras que sabem clicar e pronto.

E o pior é que os caras reclamam que vai rolar um colapso sabendo que os principais culpados SÃO ELES. E ainda por cima dizem que a galera ganha d+

Virtual Machine Man Membro desde: 14/09/2006 10:58:22 Mensagens: 604 Offline

maquiavelbona wrote:
Por favor, defina "gestor covarde".

Um Bundão!

Já que virou flame mesmo esse tópico, vamos avacalhar...

Qual era o foco mesmo?

Virtual Machine Man Membro desde: 14/09/2006 10:58:22 Mensagens: 604 Offline

Leozin wrote:Apesar da alta necessidade nos próximo 5 aninhos ae, acredito que cada dia vai ficar mais difícil achar profissionais como hoje. Basta analizar o que as ferramentas de hoje disponibilizam no quesito "botão direito, next, next > finish, meu sistema está pronto".

Se os caras conseguirem socar 213.000 profissionais no mercado em 5 anos, nem quero ver o que vai sair. Vai sair várias caras que sabem clicar e pronto.

E o pior é que os caras reclamam que vai rolar um colapso sabendo que os principais culpados SÃO ELES. E ainda por cima dizem que a galera ganha d+

Leozin, criam-se oportunidades...

Quando criaram o VB e Delphi, permitiram que analfabetos funcionais programassem. Vou te falar que foi a época que eu ganhei mais dinheiro, porque entrava no projeto pedindo o que eu queria para corrigir projetos.

Alguns arrumei. Outros nem com macumba deu certo.

O único saco é que muitas vezes você era o bode espiatório e era mandado embora a cada três meses.

Uma vez fui mandado embora as 17:30h e contratado por outra empresa as 18:30h (já estava em negociação, claro).

Mas é engraçado.

O que disse uma vez Larry Ellison, presidente da oracle:

Você admite que às vezes comanda intimidando?
ELLISON Não. Você não consegue dirigir uma empresa de sucesso intimidando as pessoas. Nesses 25 anos que estou na Oracle, o único grupo que dirigi realmente é o da engenharia. Se eu tentar intimidá-los, eles darão risada, se levantarão, irão embora e conseguirão um emprego que pague 20% mais em meia hora.

E assim vamos vivendo...

[]'s

Definição do Gestor Covarde

Muitos dos projetos que participei ou tentei colocar uma cultura mais ágil sempre esbarrei num determinado gerente com características muito peculiares:

1. É PMP ou gostaria de ser;
2. Acredita que não existe outra maneira de se fazer software a não ser em cascata (você precisa de uma planta para construir uma casa)
3. Não conhece nenhuma tecnologia ou metodologia nova; Acha que sabe muito do RUP;
4. Cobra prazo, mas desconhece os problemas;
5. Não Possui nenhuma característica de liderança;
6. Adora se esconder atrás de um Gantt Chart (Ms Project não serve para gerenciar projeto de software);
7. Usa o Project como única ferramenta de gerenciamento;
8. Geralmente desmotiva a equipe;
(essa lista vai longe)

A última que ouvi nessa semana de um gestor covarde é "- Nunca me foi cobrado controlar os custos...". Na minha opinião controlar os custos é o MÍNIMO que um gestor deve fazer...

Os gestores são muito mal preparados. São deles que saem as idéias mirabolantes que corroem o nosso setor.

Vou falar um pouco mais sobre isso na minha coluna que sai em novembro na MundoJava. Acho que vcs vão gostar...

rodrigoy wrote:Definição do Gestor Covarde

Muitos dos projetos que participei ou tentei colocar uma cultura mais ágil sempre esbarrei num determinado gerente com características muito peculiares:

1. É PMP ou gostaria de ser;
2. Acredita que não existe outra maneira de se fazer software a não ser em cascata (você precisa de uma planta para construir uma casa)
3. Não conhece nenhuma tecnologia ou metodologia nova; Acha que sabe muito do RUP;
4. Cobra prazo, mas desconhece os problemas;
5. Não Possui nenhuma característica de liderança;
6. Adora se esconder atrás de um Gantt Chart (Ms Project não serve para gerenciar projeto de software);
7. Usa o Project como única ferramenta de gerenciamento;
8. Geralmente desmotiva a equipe;
(essa lista vai longe)

A última que ouvi nessa semana de um gestor covarde é "- Nunca me foi cobrado controlar os custos...". Na minha opinião controlar os custos é o MÍNIMO que um gestor deve fazer...

Perfeito!!!!

Virtual Machine Man Membro desde: 15/08/2006 16:15:11 Mensagens: 598 Offline

maul wrote:Pergunta. Pq em um fórum com tanto conteudo sempre tem q ter os que tentam fazer flame?
Axo q vo entra pra campanha "não alimente os trolls".
Em vez de corrigir erros propositais dos outros, pq não se preocupam com coisas mais interessantes, como fazer faculdade?
Ah, e antes q isso se transforme realmente em flame... me manda por MP qual é a sua empresa, quem sabe eu mande um cv pra ela.

vlw.

Desculpa cara, sinceramente, a ideia não era te agredir, nem perder o foco do tópico, e tenho certeza que não fiz isso.

Marck

Virtual Machine Man Membro desde: 15/08/2006 16:15:11 Mensagens: 598 Offline

Eu não acredito que haja possibilidades de a TI ser extinta.

Lembro de uma aula de Adm. em que o professor dizia que um dia, as empresas que tinha energia eletrica conseguiam se diferenciar, pois era uma novidade. Hoje, o que é uma empresa/casa sem energia eletrica??

Até 2000, acredito, as empresas eram capazes de usar ti como diferencial, melhores estrátegias. HOje, assim como a energia eletrica, o que seria uma empresa sem TI?

JavaChild Membro desde: 14/03/2007 13:26:46 Mensagens: 134 Offline

Marck wrote:

maul wrote:Pergunta. Pq em um fórum com tanto conteudo sempre tem q ter os que tentam fazer flame?
Axo q vo entra pra campanha "não alimente os trolls".
Em vez de corrigir erros propositais dos outros, pq não se preocupam com coisas mais interessantes, como fazer faculdade?
Ah, e antes q isso se transforme realmente em flame... me manda por MP qual é a sua empresa, quem sabe eu mande um cv pra ela.

vlw.

Desculpa cara, sinceramente, a ideia não era te agredir, nem perder o foco do tópico, e tenho certeza que não fiz isso.

Marck

Bah, acredito que o problema esteja resolvido.

Aos demais participantes do tópico, desculpem o inicio de flame.

JavaChild Membro desde: 14/03/2007 13:26:46 Mensagens: 134 Offline

rodrigoy wrote:Definição do Gestor Covarde

...

Bom não sei se seria exatamente "covarde" a melhor forma de defini-los.

rodrigoy wrote:
Os gestores são muito mal preparados.

Disse tudo.

flw.

Virtual Machine Man Membro desde: 14/09/2006 10:58:22 Mensagens: 604 Offline

rodrigoy wrote:Definição do Gestor Covarde

Muitos dos projetos que participei ou tentei colocar uma cultura mais ágil sempre esbarrei num determinado gerente com características muito peculiares:

1. É PMP ou gostaria de ser;
2. Acredita que não existe outra maneira de se fazer software a não ser em cascata (você precisa de uma planta para construir uma casa)
3. Não conhece nenhuma tecnologia ou metodologia nova; Acha que sabe muito do RUP;
4. Cobra prazo, mas desconhece os problemas;
5. Não Possui nenhuma característica de liderança;
6. Adora se esconder atrás de um Gantt Chart (Ms Project não serve para gerenciar projeto de software);
7. Usa o Project como única ferramenta de gerenciamento;
8. Geralmente desmotiva a equipe;
(essa lista vai longe)

A última que ouvi nessa semana de um gestor covarde é "- Nunca me foi cobrado controlar os custos...". Na minha opinião controlar os custos é o MÍNIMO que um gestor deve fazer...

Os gestores são muito mal preparados. São deles que saem as idéias mirabolantes que corroem o nosso setor.

Vou falar um pouco mais sobre isso na minha coluna que sai em novembro na MundoJava. Acho que vcs vão gostar...

Fale a verdade, quem é vc?

Você trabalha comigo e se esconde no fórum... Ninguém nunca descreveu meu gerente de forma tão perfeita!!!

Falando nisso cadê o Paulo Silveira?

Gostaria de ter informações sobre aquele curso da Caelum de Scrum...

[]'s

GUJ Ranger Membro desde: 20/01/2003 15:45:15 Mensagens: 782 Offline

rodrigoy wrote:Muitos dos projetos que participei ou tentei colocar uma cultura mais ágil sempre esbarrei num determinado gerente com características muito peculiares:

Se o seu cargo é Analista, arquiteto, programador ou qualquer coisa que não seja Gerente de Projeto, essa decisão não é sua... imagine a situação:
Você queimou um bocado de neurônio pensando numa solução bacana para qualquer tipo de problema e daí vem um cara de fora, bico *mesmo* falando que você está fazendo errado. Duvido que você ia gostar. E nesse caso a culpa não é sua, é do bico.
Se a empresa que você estava pretendia algum nível de CMMI ou MPS.BR você deveria saber que a divisão de papéis é um fato e para algumas empresas funciona melhor assim. O ambiente conta muito nesses casos. Claro que a famosa reunião em pé para contar de ontem, hoje e amanhã é interessante e pode ser usada em quase todos os projetos. Em contrapartida, o contato direto com o cliente que não sabe o que quer e fica pedindo coisas a cada dois dias é uma chatura se o contrato estabeleceu que será um 'software de caixinha'.

rodrigoy wrote:1. É PMP ou gostaria de ser;

O problema não é o PMP... acredito mais que sejam as pessoas ou o ambiente, como já falei. Conheco gerentes com PMP que são fantásticos.

rodrigoy wrote:2. Acredita que não existe outra maneira de se fazer software a não ser em cascata (você precisa de uma planta para construir uma casa)
3. Não conhece nenhuma tecnologia ou metodologia nova; Acha que sabe muito do RUP;

Para algumas empresas e projetos é a melhor maneira de fazer. Nem sempre XP, Scrum são as melhores soluções e essas metodologias não são mágicas que funcionam para tudo. Algumas vezes ter a planta da casa ajuda a planejar e coordenar melhor as ações e esforços da equipe.
Você pode gostar muito de RUP, mas com um pouco de bom senso vai saber que nem sempre é a melhor escolha. O mesmo para Scrum.

rodrigoy wrote:4. Cobra prazo, mas desconhece os problemas;

Quem define o prazo (de novo, dependendo da empresa) são os analistas que fazem estimativa de ponto de função e outras métricas... E dependendo do processo de desenvolvimento da empresa, a medição/estimativa do tamanho do projeto ocorre mais de uma vez. Se o esforço foi mal estimado, falha do analista. Se foi fechado *antes* de uma definição dos requisitos e necessidades mínimas do cliente, daí o erro é do gerente ou do departamento comercial... Nós temos que viver com isso.

rodrigoy wrote:5. Não Possui nenhuma característica de liderança;
6. Adora se esconder atrás de um Gantt Chart (Ms Project não serve para gerenciar projeto de software);
7. Usa o Project como única ferramenta de gerenciamento;
8. Geralmente desmotiva a equipe;
(essa lista vai longe)

A última que ouvi nessa semana de um gestor covarde é "- Nunca me foi cobrado controlar os custos...". Na minha opinião controlar os custos é o MÍNIMO que um gestor deve fazer...

Os gestores são muito mal preparados. São deles que saem as idéias mirabolantes que corroem o nosso setor.

Dessas não tem como escapar. Aqui eu concordo com você que o problema é mesmo da *pessoa*. Em todos os exemplos anteriores o ambiente/momento tem um impacto muito grande nas variáveis.
Um gerente sem essas últimas caracteristicas é fraco tecnicamente, e é pouco provável que ele vá se adaptar a qualquer processo de desenvolvimento. Pede para contratar um melhorzim ou manda ele estudar um bocado.

rodrigoy wrote:Vou falar um pouco mais sobre isso na minha coluna que sai em novembro na MundoJava. Acho que vcs vão gostar...

Estamos esperando. (;

E não, eu não sou gerente de projetos... mas tenho que admitir que é uma carreira interessante.

Virtual Machine Man Membro desde: 14/09/2006 10:58:22 Mensagens: 604 Offline

Marck wrote:Eu não acredito que haja possibilidades de a TI ser extinta.

Lembro de uma aula de Adm. em que o professor dizia que um dia, as empresas que tinha energia eletrica conseguiam se diferenciar, pois era uma novidade. Hoje, o que é uma empresa/casa sem energia eletrica??

Até 2000, acredito, as empresas eram capazes de usar ti como diferencial, melhores estrátegias. HOje, assim como a energia eletrica, o que seria uma empresa sem TI?

Inclusive o grande lance de distribuição de energia elétrica agora é telecomunicações....

http://www.eletropaulotelecom.com.br/website/artigo.asp?cod=279&idi=1&id=2376

Bandrade, não estamos discutindo metodologia, mas sim postura do gestor. Na sua opinião você acha que a gestão das empresas que desenvolvem software é boa?

Mas vamos discutir alguns pontos:

bandrade wrote:Se o seu cargo é Analista, arquiteto, programador ou qualquer coisa que não seja Gerente de Projeto, essa decisão não é sua...

Se a decisão não é da equipe, de quem é? Gerente de Projeto tem skill para saber quais práticas se aplicam nos projetos? Gerente de Projeto sabe definir estratégia de teste? Sabe sobre arquitetura? Sabe gerenciar as dependências dos projetos? Isolar os analistas, arquitetos e programadores dessa decisão é uma boa?

bandrade wrote:
Você queimou um bocado de neurônio pensando numa solução bacana para qualquer tipo de problema e daí vem um cara de fora, bico *mesmo* falando que você está fazendo errado. Duvido que você ia gostar. E nesse caso a culpa não é sua, é do bico.

Não entendí o contexto... Se ele fala que eu estou errado ele deve compartilhar o ponto de vista com argumentos... só isso.

bandrade wrote:
Se a empresa que você estava pretendia algum nível de CMMI ou MPS.BR você deveria saber que a divisão de papéis é um fato e para algumas empresas funciona melhor assim. O ambiente conta muito nesses casos.

Nenhuma certificação prega divisão de papéis. Divisão do trabalho e preocupação com papéis é um cancer que precisa ser tirado das empresas. É uma má intepretação do RUP. Essa cascata Requisitos, Analise, Codificação e Teste é uma aberração. Não existe esse tipo de dependência.

bandrade wrote:
O problema não é o PMP... acredito mais que sejam as pessoas ou o ambiente, como já falei. Conheco gerentes com PMP que são fantásticos.

PMBOK resolve coisas básicas num projeto de software. Eu valorizo 1.000 mais um CSM do que um PMP. Você sabia que nem mesmo o PMBOK prega o uso de um Gantt Chart? Eu conheço 2 PMPs que são fantásticos, o resto deveria gerenciar projeto de construir ponte e não construir software. PMBOK é só um conjunto de práticas, não dá pra tomar de maneira determinista.

bandrade wrote:
Para algumas empresas e projetos é a melhor maneira de fazer. Nem sempre XP, Scrum são as melhores soluções e essas metodologias não são mágicas que funcionam para tudo. Algumas vezes ter a planta da casa ajuda a planejar e coordenar melhor as ações e esforços da equipe.
Você pode gostar muito de RUP, mas com um pouco de bom senso vai saber que nem sempre é a melhor escolha. O mesmo para Scrum.

A planta da casa é sou um exemplo. O problema é o quanto se investe nessa "planta".

http://www.ddj.com/architect/201800550

Cascata não é bom pra projeto nenhum de software. Nem mesmo os projetos de 1 mês. Cascata é um anti-pattern na minha opinião e não alternativa. Num projeto de 1 mês creio que investiria menos de 4 horas em requisitos up-front, praticamente nem investiria nada em design (pegaria alguma arquitetura de caixinha), o esforço seria basicamente 50% codificação e 50% teste/homologação.

Hoje em dia não se aplica mais RUP, XP, SCRUM, XPTO e etc... um bom processo usa práticas de diversas metodologias que são boas para o projeto sob o ponto de vista da equipe. O processo pode inclusive mudar de uma iteração para a outra.

O mínimo que se espera de um stakeholder é saber a respeito do negócio. Se nem isso ele sabe então é melhor nem começar o projeto. Aqui no Brasil as empresas não investem nada na concepção do sistema.

bandrade wrote:
Quem define o prazo (de novo, dependendo da empresa) são os analistas que fazem estimativa de ponto de função e outras métricas... E dependendo do processo de desenvolvimento da empresa, a medição/estimativa do tamanho do projeto ocorre mais de uma vez. Se o esforço foi mal estimado, falha do analista. Se foi fechado *antes* de uma definição dos requisitos e necessidades mínimas do cliente, daí o erro é do gerente ou do departamento comercial... Nós temos que viver com isso.

Cara, realmente não quero que isso vire uma discussão ferrenha, mas vc precisa abrir a cabeça que essa divisão do trabalho e responsabilidade é algo muito ruim! Teoria Taylorista não se aplica a processos empíricos como o desenvolvimento de software. O sucesso no cumprimento das tarefas não garante o sucesso do projeto. Se cada um cuidar da sua responsabilidade ninguém é responsável pelo sucesso do projeto.

Vou até sugerir uma dinâmica pra você. Sabe quando vc vai jogar bola e ninguém quer ser goleiro? Proponha o seguinte: "-Eu vou começar como goleiro, mas quando tomar um gol o cara culpado vai ficar no gol e eu vou pra linha." Observe o comportamento do time. Já fiz isso e percebí que os jogadores da linha ficam tão preocupados em "não ser o culpado" que simplesmente não buscam o objetivo de fazer gols. Alguns deles até ficam gritando "A culpa é sua! A culpa é sua!"

A responsabilidade do projeto é compartilhada entre todos os envolvidos. Se o projeto tem sucesso é sucesso da equipe, se falha é falha da equipe, mas não adianta ter caça às bruxas, se o projeto falhou deve servir como lições aprendidas.

Qualquer métrica simplesmente dá tamanho funcional. Tamanho funcional não leva em consideração riscos importantes como arquitetura, motivação da equipe, ambiente de desenvolvimento, gestor covarde e etc... Métricas ágeis levam em consideração esses fatores para fornecer um prazo. Recomendo a leitura "Agile Estimating & Planning, Mike Cohn".

bandrade wrote:
Dessas não tem como escapar. Aqui eu concordo com você que o problema é mesmo da *pessoa*. Em todos os exemplos anteriores o ambiente/momento tem um impacto muito grande nas variáveis.
Um gerente sem essas últimas caracteristicas é fraco tecnicamente, e é pouco provável que ele vá se adaptar a qualquer processo de desenvolvimento. Pede para contratar um melhorzim ou manda ele estudar um bocado.

O problema é que tenho visto em várias empresas que o gestor covarde é a regra e não a excessão. Muita coisa está errada. Muita coisa precisa melhorar.

bandrade wrote:
E não, eu não sou gerente de projetos... mas tenho que admitir que é uma carreira interessante.

Se vc busca essa posição você é uma das pessoas que pode mudar esse cenário.

GUJ Ranger Membro desde: 20/01/2003 15:45:15 Mensagens: 782 Offline

rodrigoy wrote:Cara, realmente não quero que isso vire uma discussão ferrenha

Se vc fosse de BH te chamava pra tomar umas na feira no domingo pra gente discutir... rsrsrs... discussões são ótimas oportunidades de aprendizado. (;

rodrigoy wrote:Bandrade, não estamos discutindo metodologia, mas sim postura do gestor. Na sua opinião você acha que a gestão das empresas que desenvolvem software é boa?

Não tenho muita experiência não... mas credito muito na evolução, pois eu vi a evolução dos gestores pelas empresas que passei. Tudo pode ser melhorado.

rodrigoy wrote:Se a decisão não é da equipe, de quem é? Gerente de Projeto tem skill para saber quais práticas se aplicam nos projetos? Gerente de Projeto sabe definir estratégia de teste? Sabe sobre arquitetura? Sabe gerenciar as dependências dos projetos? Isolar os analistas, arquitetos e programadores dessa decisão é uma boa?

Depende da decisão... os exemplos são vários.
Decisão que deve ser tomada por um gerente: Cliente pede uma alteração nos requisitos do software. Gerente recebe o pedido, discute com o analista o impacto (prazo/custo/recurso) e responde ao cliente. Mesmo que o analista fale que não impacta tanto, o gerente pode negar o pedido do cliente por motivos não técnicos.
Decisão a não ser tomada pelo gerente: Arquiteto / Analista / Programador resolve desenvolver um sistema utilizando Strus

. Problema do analista... o gerente nao tem muito o que fazer.

rodrigoy wrote:Não entendí o contexto... Se ele fala que eu estou errado ele deve compartilhar o ponto de vista com argumentos... só isso.

Claro que deve ter argumentos... mas também deve ter sensibilidade e percepção, porque achar pessoas que aceitem criticas é difícil...

rodrigoy wrote:Nenhuma certificação prega divisão de papéis. Divisão do trabalho e preocupação com papéis é um cancer que precisa ser tirado das empresas. É uma má intepretação do RUP. Essa cascata Requisitos, Analise, Codificação e Teste é uma aberração. Não existe esse tipo de dependência.

Papéis existem de qualquer forma, é mais fácil de organizar. Pode haver mais de uma pessoa exercendo mais um papel para facilitar as coisas. O famoso faz tudo. A única divisão que acho válida é a homologação. Testes devem ser feitos por uma equipe externa, não viciada no aplicativo.

rodrigoy wrote:PMBOK resolve coisas básicas num projeto de software. Eu valorizo 1.000 mais um CSM do que um PMP. Você sabia que nem mesmo o PMBOK prega o uso de um Gantt Chart? Eu conheço 2 PMPs que são fantásticos, o resto deveria gerenciar projeto de construir ponte e não construir software. PMBOK é só um conjunto de práticas, não dá pra tomar de maneira determinista.

O Gantt Chart é apenas uma das ferramentas que um gerente de projetos pode utilizar. Tem softwares para acompanhamento de tarefas, geração de relatórios, apropriação de horas e tudo mais... isso são ferramentas. Estão ali só para auxiliar. As ferramentas não fazem um gerente de projetos, mas um bom gerente de projetos sabe fazer um excelente uso das ferramentas disponíveis para ele.

PMBOK é um guia, um conjunto de práticas (como vê disse), assim como o Scrum.

rodrigoy wrote:A planta da casa é sou um exemplo. O problema é o quanto se investe nessa "planta".

Acho que nesse ponto é onde temos uma opinião divergente. Acredito que a planta deve ser muito bem planejada, muito tempo deve ser investivo nela. Pois na hora de construir, a chance de ocorrerem alterações diminuem. Se a casa não é bem planejada, o cliente pode chegar e pedir uma janela aonde devia ser uma parede. Com um planejamento melhor, a chance desse tipo de situação diminui.

rodrigoy wrote:http://www.ddj.com/architect/201800550

Li. Concordo. Pratico.
Quando pode haver uma metodologia ágil, menos documentação, acompanhamento, builds constantes eu prefiro, mas nem sempre é assim. E isso tende a criar um projeto infinito.

Mas em alguns lugares simplesmente funciona melhor assim... imagine quando é preciso entregar o fonte, a documentação e um manual para o usuário. A descrição dos casos de uso deve ser mais extensa, os casos de teste devem estar explicados, mais alguns diagramas UML deve ser criados, fonte muito bem comentado, screen shot da interface pois o manual do usuário tem que estar bacana, um treinamento deve ser preparado (com material didático, apresentação e provinha... tá, a provinha foi exagero). Muita coisa não é? Mas o cliente *pediu*, tá no contrato, ele paga por isso! Quando a empresa é uma fábrica de software que faz as caixinhas, ela simplesmente deve fazer uma caixinha bonitinha para que o cliente continue a comprar dela.

rodrigoy wrote:Cascata não é bom pra projeto nenhum de software. Nem mesmo os projetos de 1 mês. Cascata é um anti-pattern na minha opinião e não alternativa. Num projeto de 1 mês creio que investiria menos de 4 horas em requisitos up-front, praticamente nem investiria nada em design (pegaria alguma arquitetura de caixinha), o esforço seria basicamente 50% codificação e 50% teste/homologação.

Projetos de 1 mês são simples... 1 semana requisitos up-front. Provavelmente 2 semanas codigo (inclua testes unitários, testes em desenvolvimento) e 1 semana para homologaçao e correção de bugs que passaram (testes no cliente, etc.) Mas só porque foi dividido, não quer dizer que seja cascata, é só uma organização para guiar e dar noção de tempo para os participantes.

rodrigoy wrote:Hoje em dia não se aplica mais RUP, XP, SCRUM, XPTO e etc... um bom processo usa práticas de diversas metodologias que são boas para o projeto sob o ponto de vista da equipe. O processo pode inclusive mudar de uma iteração para a outra.

Pegar o melhor de todas... igual Ruby. \o/
Sou totalmente a favor. (;

rodrigoy wrote:O mínimo que se espera de um stakeholder é saber a respeito do negócio. Se nem isso ele sabe então é melhor nem começar o projeto. Aqui no Brasil as empresas não investem nada na concepção do sistema.

Em poucos lugares as pessoas pensam em concepção do sistema... vamos ter que viver com isso. É um dos grandes males da área.

rodrigoy wrote:Cara, realmente não quero que isso vire uma discussão ferrenha, mas vc precisa abrir a cabeça que essa divisão do trabalho e responsabilidade é algo muito ruim! Teoria Taylorista não se aplica a processos empíricos como o desenvolvimento de software. O sucesso no cumprimento das tarefas não garante o sucesso do projeto. Se cada um cuidar da sua responsabilidade ninguém é responsável pelo sucesso do projeto.

Nem sempre o que dá certo é o certo.
Existem os pápeis, as siglas, rótulos que damos as pessoas. O cara que programa é o programador... quem analisa é o Analista... isso não quer dizer que a responsabilidade é apenas do analista ou que o trabalho foi dividido.

rodrigoy wrote:Vou até sugerir uma dinâmica pra você. Sabe quando vc vai jogar bola e ninguém quer ser goleiro? Proponha o seguinte: "-Eu vou começar como goleiro, mas quando tomar um gol o cara culpado vai ficar no gol e eu vou pra linha." Observe o comportamento do time. Já fiz isso e percebí que os jogadores da linha ficam tão preocupados em "não ser o culpado" que simplesmente não buscam o objetivo de fazer gols. Alguns deles até ficam gritando "A culpa é sua! A culpa é sua!"

Já dei essa dinâmica, meu trabalho por muito tempo foi dar treinamentos de trabalho de equipe e liderança... Bons tempos, ainda volto a fazer isso, mas preciso de um pouco mais de preparação e $$$.

rodrigoy wrote:A responsabilidade do projeto é compartilhada entre todos os envolvidos. Se o projeto tem sucesso é sucesso da equipe, se falha é falha da equipe, mas não adianta ter caça às bruxas, se o projeto falhou deve servir como lições aprendidas.

Sim, equipe é equipe. Não temos o que discutir aqui... mas vai explicar isso para um gerente / diretor? Ele vai querer chamar alguem pra conversar e o primeiro nome que vai aparecer na cabeca dele é o do gerente do projeto e nao o estagiário / programador... as vezes ele chama a equipe inteira, é mais dificil mas já vi acontecer.

rodrigoy wrote:Qualquer métrica simplesmente dá tamanho funcional. Tamanho funcional não leva em consideração riscos importantes como arquitetura, motivação da equipe, ambiente de desenvolvimento, gestor covarde e etc... Métricas ágeis levam em consideração esses fatores para fornecer um prazo. Recomendo a leitura "Agile Estimating & Planning, Mike Cohn".

Riscos existem e são incluidos em qualquer projeto que se preze... gerenciamento de risco inclusive é uma disciplina do PMBOK...

rodrigoy wrote:O problema é que tenho visto em várias empresas que o gestor covarde é a regra e não a excessão. Muita coisa está errada. Muita coisa precisa melhorar.

Sim, existem *muitos* gerentes ruins por aí.... mesmo em empresas que pregam Scrum. Da falta de formação das pessoas poucos podem reclamar...

Acho que concordamos na maior parte das coisas, basta um pouco mais de debate... a maior disparidade foi mesmo nos rótulos que dei as pessoas de acordo com a atividade que elas estão executando naquele momento... e também ao tempo gasto com requisitos up-front, eu gosto mais deles que você, mas isso nao faz nenhum de nos dois melhor, mais legais ou até mais certos (ou menos errados). É tudo uma questão de gosto.
Continuo achando que o problema são as pessoas e não o sistema.

Notícias, artigos e o maior fórum brasileiro sobre Java