| Autor |
Mensagem |
|
|
mario.fts wrote:
Provocação Digital: desta vez concordei mais com o Glauco, acho que foi um bom texto. os comentários na verdade são algumas perguntas: Esta será uma coluna fixa a partir de agora? Será sempre o Glauco o autor? se for, a gente poderia escolher os temas a partir de enquetes no site?
Bom, sobre sugerir temas, convido todos a me contatar (o email está na revista) mesmo sem uma enquete oficial, ou ao Guerra.
Mas lembre-se de que existem alguns temas que são consenso, e aí não têm muito o que discutir. Se durante estes emails surgirem idéias interessantes, ou mesmo a proposta de um artigo inteiro de algum de vocês, não tem nenhum problema em "ceder o espaço", ou escrever a duas ou mais mãos um artigo. Estou ocupando um espaço de discussão que afinal é de todos.
Eu também compartilhava a idéia de produzir textos deste tipo com o Guerra, e acho que a revista Mundo Java deve ir além de apresentar as APIs e mostrar como utilizá-las. Precisamos discutir conceitos, tecnologias emergentes e sua perspectiva.
Temos procurado manter um tom ameno nos textos, porque em dose excessiva o veneno pode ser maléfico. Por isto as vezes aparecem em um tom de questionamento. Mas tenho minhas opiniões e procuro na medida do possível mostrá-las nas discussões
[]s
Glauco
|
 |
|
|
Bom, não desejo aqui fazer o papel de psicólogo, ou no caso psiquiatra, mas façamos um histórico das respostas :
"Século XXI falando sobre pontos de função.Todo mundo tá cansado de saber, não funciona"
Entretanto, logo depois (terceira resposta) comentou que têm dúvidas de como se calcula e também afirmou que eu não sei calcular, que todo o artigo é baseado em mentiras
"Se vc usa 12 artefactos UML para cada classe, andar, nodo e decisão do projeto a escolha é sua."
Bom, aparentemente desconhece e despreza a UML também
"Não é culpa do scrum ser bom e as pessas serem atrazados mentais."
"Confundir software e projeto é o erro da metodologias tradicionais. qualquer pessoa com mais de 5 anos no mercado sabe que as metodologias tradicionais não funcionam, são stressantes e fazem as SH perder dinheiro."
"O problema atualmente é que ninguem tem poder de remover o gerente excepto os diretores. Mas como é uma hirarquia não ha ninguem que audite o gerente e reporte ao diretor. O desenvolvedor não pode chamar a atenção do diretor para a incompetencia do gerente. Em scrum não só ele pode chamar a atenção do SM, como o SM pode chamar a atenção dos diretores."
"O cliente nunca sabe o que quer e nunca tem razão."
"Primeiro erro :o cliente tem sempre razão.
O cliente não tem sempre razão. Ele tem razão se pede coisas no ambito do contrato. Se está fora do contrato, está fora."
"??? Se eu quero mudar a forma embecil de se fazer projeto de software do modo tradiconal para Scrum ? claro que quero.
Se estou inventando o scrum agora, claro que não.
Então você é como todos os gerentes tradicionais : você esconde a realidade,mente e tem medo."
Bom, acho que o resumo de toda a discussão é que qualquer pessoa que sequer tenha dúvidas sobre SCRUM é um imbecil e atrasado. Tudo o que foi feito até hoje em termos de engenharia de software foi uma grande babaquice, as metodologias anteriores nunca fizeram nada de bom para o mundo, e SCRUM é a única coisa verdadeira. Todos os gerentes e diretores são estúpidos, e o cliente não sabe nada nem o que quer, e deve aceitar tudo o que Ken Schwaber (do qual foram apresentadas absolutamente todas as referências) ou seus representantes legais disserem que é verdade.
Bem, esquecí algo, antes de ir para um canto chorar o final de semana todo ?
PS : Continuo mesmo torcendo para que as pessoas que trabalham com SCRUM não tenham este grau de "radicalidade", caso contrário não tenho dúvidas sobre o fracasso da tecnologia.
[]s
Glauco Reis
|
|
|
|
Se o que negociamos na primeira reunião (Sergio, na primeira reunião) é o projeto, e o escopo vai sendo amadurecido durante as reuniões de levantamento (o Alexandre e o Guerra destacaram bem), então o cliente está comprando um projeto que poderá variar grandemente no quesito funcionalidades (assumindo como regra que o prazo final não muda).
Pior, porque irá variar em função da expertize da equipe. Times mais experientes conseguem entregar mais "coisas" implementadas em SPRINTs, Ou seja, depois de contratada a empresa que irá fazer o serviço, só deus sabe o que será entregue no prazo. Pode atender plenamente, mas pode se extender por mais tempo, ao longo dos SPRINTs. Se o cliente decidir pagar mais para continuar o projeto, porque percebe a evolução, o projeto continua.
Bem, neste momento, acho que devo destacar que já presenciei muitas negociações iniciais de projetos, para várias empresas de vários segmentos, e ao menos na minha vivência, digo que o comportamento apresentado pelos negociadores do projeto diz que :
"NÂO È ASSIM QUE FUNCIONA!!!!!"
O Cliente deseja saber antes de começar quanto vai custar (ele nem sabe o que é Sprint), e deseja tudo o que têm em mente.
Em uma licitação a coisa é pior ainda.
As consultorias costumam preparar documentos de pré-projeto ou documentos de Visão, com várias cláusulas que indicam o que "não é escopo do projeto", de forma a eliminar possíveis problemas futuros.
Com frequência acontecem realocações de pessoas dentro da empresa, e o sponsor do cliente pode mudar. Se não há documentos muito formais que indicam o que foi combinado e como seria implementado, problemas acontecem.São raros os projetos onde um mesmo time de pessoas (cliente e consultoria) trabalham desde o início até o final.
Ainda, todas as fases de maturação que foram propostas pelas metodologias durante vinte anos, e artefatos que representam os vários aspectos do desenvolvimento (análise estática - diagramas de classes, análises dinâmicas - sequências, estados). São doze artefatos definidos pela UML. Isto tudo deve ter sido um grande devaneio destes loucos, entre eles Jacobon, Booch e Rumbaugh, já que tudo foi reduzido a um conjunto de discussões e anotações em um papel de pão. Acho esta visão até um desrespeito ao que foi criado.
Quem já gerenciou equipes sabe que existem profissionais de mais alto nível, que têm a capacidade de desenhar o projeto em um nível mais alto, utilizando UML por exemplo, e programadores muito bons, mas que não conseguem ter uma visão de mais alto nível do projeto. São raros, mas muito raros mesmo, os que conseguem conversar com o usuário, entender a demanda, rabiscar em um papel o desenho de como vai ficar, de uma forma que o usuário entenda, ter força de persuasão, montar mentalmente quais são os patterns que serão utilizados e ainda sentar e codificar. Este processo demanda tempo de maturação, é a forma como o cérebro humano funciona. Aposto que todos nós já tivemos situações onde mais de 80% do código estava pronto, quando dá um estalo no chuveiro pela manhã, com uma idéia que revoluciona o projeto, mas o que foi feito precisa ser reescrito. Como se lida com isto ?
Vou lembrar uma historinha para vocÊs :
Quando o ASP foi criado (verdade que o PHP surgiu primeiro, mas o usado extensamente foi o ASP), as tecnolgias que dominavam eram programáticas. Perl, CGI, todas elas você tinha que codificar o HTML dentro do código. Era muito difícil. Quando o ASP popularizou, gerou um sucesso monumental. Era fácil criar páginas, tinha uma produtividade dezenas de vezes maior do que as tecnologias anteriores. A prototipação era visual. O que aconteceu depois de alguns anos ?
Se verificou que fazia o programador tender a criar vários códigos, dava pouca manutenção e os projetos travavam. Eu mesmo participei de projetos (graças a deus não programei em ASP) onde se chegou em uma situação que não era mais possível evoluir. Somente depois do fracasso se amadureceu para o modelo MVC para WEb, com Servlets e JSPs, dividindo visual e códigos. Até a própria Microsft modificou seu modelo de construção. Isto levou mais de 5 anos para fracassar.
Resumindo, o SCRUM como conhecemos hoje ainda é muito novo, e portanto existe pouca jurisprudência para sabermos se o modelo se sustenta no futuro. Tenho medo de daqui a alguns anos (e agora ninguém ainda pode afirmar nada nem a favor nem contra) as pessoas sentirem saudades daqueles montes de documentação, com milhares de códigos na mão e meia dúzia de papeis de pão. Torço para que isto não aconteça, e é por isto que disse no meu primeiro email : as pessoas estão ignorando completamente o passado e criando novos modelos. Quem das pessoas da velha guarda (que têm experiência) se rendeu a estas novas metodologias ?
[]s
Glauco Reis
|
|
|
|
"2. Estimar é opinar a respeito de algo de que não se tem certeza. Por exemplo, estimar a quantidade de pessoas que há numa fila, estimar o preço de uma roupa, estimar o resultado de uma conta, antes de executá-la. "
"Backlog de produto e backlog de sprint
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto."
Percebe a diferença na linha de tempo (um já começou e outro ainda não) ?
A linguagem java se profissionalizou e evoluiu mais no momento em que os radicais sairam do cenário e empresas e pessoas mais ponderadas começaram a apresentar visões mais realistas e sem os ranços radicalistas, o que fez com que o negócio gradualmente comprasse a idéia. O negócio não compra idéias de pessoas com bombas amarradas à cintura.
Torço para que as pessoas desta lista, que trabalham com Scrum, não sejam tão radicais a ponto de simplesmente ignorar o passado, sem saber porque (todo mundo sabe que não funciona não é resposta).
Mas como disse o Guerra, fico feliz que as pessoas estejam discutindo o tema, que quase sempre é jogado para debaixo do tapete após o início do projeto.
Sobre minha opinião, acho que não conseguiria deixar mais clara minha opinião de que os mecanismos citados (e que são utilizados ainda hoje) não conseguem gerar números verdadeiros, e apenas servem como números mágicos utilizados na negociação de novos projetos. Apresentar a técnica foi uma forma de mostrar matematicametne o porque do não funcionamento.
Glauco Reis
|
|
|
|
|
|