E você tem tido sucesso implementando assim? Pq eu aposto pelo menos nessa idéia!
Veja, sistemas corporativos são sistemas mais complexos que “sisteminhas” e os profissionais de TI se contentam com User Stories e Casos de Uso sem ir colocar a mão na massa pessoalmente. UML, User Stories, Casos de Uso entre outros, na prática, não passam de ferramentas de adivinhação.[/quote]
Sim, no meu caso sempre foi bom. Não posso dizer nada sobre os corporativos, mas eu tambem acredito que ficaria muito mais claro o que o cliente realmente precisa, porque todos sabemos que o cliente só sabe que quer alguma coisa, ficar tentando ouvir da boca dele o que realmente quer é complicado, é muito mais produtivo voce ir la pessoalmente e ver de fato o funcionamento da coisa.
Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.
[quote=fredferrao]
Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.[/quote]
Exatamente por isso os processos modernos , como scrum, incluem demonstrações ao cliente. Isto ajuda a que ele veja com os olhos da cara o software funcionando e que haja discussão com base em algo concreto. Além disso isto serve de treinamento para quando o cliente virar usuário. É sem duvida util ter poucos intermediários e é por isso que em Scrum se fala em Porcos e Galinhas.
[quote=sergiotaborda][quote=fredferrao]
Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.[/quote]
Exatamente por isso os processos modernos , como scrum, incluem demonstrações ao cliente. Isto ajuda a que ele veja com os olhos da cara o software funcionando e que haja discussão com base em algo concreto. Além disso isto serve de treinamento para quando o cliente virar usuário. É sem duvida util ter poucos intermediários e é por isso que em Scrum se fala em Porcos e Galinhas.[/quote]
Sim eu entendeo seu ponto, mas veja que continuam sendo historias contadas por alguem para alguem e sabemos que o entendimento é sempre complicado, voce citou o scrum, ótimo sempre ha as reuniões, e o cara vai la ver as releases, mas e o tempo que ja se gastou no sprint e no fim o cliente fala que nao era aquilo? Mas eu entendi, no scrum o produto vai se adaptando dinamicamente/iterativamente, mas concorca que houve perda de tempo e dinheiro que eu poderia ter impedido se tivesse algo mais concreto na mão?
Eu vejo os seguintes pontos:
1 - O cliente não sabe falar direito o que quer, nao sabe se expressar;
2 - Alem do cliente não se expressar direito, o analista entende ainda de outra forma;
Bom só aqui ja temos A, B e C, sendo o que o cliente queria, o que ele explicou e o que o analista entendeu.
Então como seria simples se fossem cliente e analista la olhar o processo como ele realmente é.
Ai que esta a diferença. em agil não apenas um conto. è um compromisso. Portanto todo o mundo tem que estar consciente e concorda com o é para fazer. Se o PO ( não o cliente) diz faz X e depois de arrepende o problema é dele. Ele que gastou Y SP para uma coisa errada. Se vc usa scrum direito e o PO faz isto muitas vezes o SM vai apertá-lo. Ele passa a ser um impedimento ao projeto e o SM tem poder de pedir a demissão do PO se ele não se indireitar. Entenda que o PO controla o software, o SM controla o processo. Se alguem impede o processo essa pessoa é avisada, é treinada, se mesmo assim não der, é removida. Simples assim.
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.
As reuniões servem o proposito exacto das pessoas se entenderem. Não ha margem para falhas desse tipo. Algum detalhe pode não ficar bom, mas a funcionalidade é aquela, porque foi discutida entre todos. Em Scrum não ha ordens, ha necessidade e consenso de como resolver.
Não. Não concordo. É impossivel vc ter um processo que impede erros. O que pode ter é contigência de minimizar os problemas criados por esses erros. O PO pode errar. Ele só não pode errar sempre. Ele é um profissional. Espera-se que aprenda com erros ou é demitido. O dinheiro jogado fora é sim um problema e por isso o PO é despedido se isso for muito problemático.
É essa a diferença para o gerente tradicional que erra constantemente mas nada lhe acontece, o que permite que continue errando.
Sim, as pessoas não se sabem expressar direito. Vemos isso todos os dias aqui no guj, mas isso não impede que se façam bons software. Existem boas práticas tb para levantar requisitos. Por exemplo , desconfie sempre que o cliente usar as palavras “sempre” e “nunca”. E existem Padrões de Requisito que permitem que quando o cliente pede uma coisa, vc desconfie que ele está pedindo mais um conjunto de N coisas.Se vc só coloca o que ele pediu vc vai se ferrar, mas se vc sabe das N coisas vc repassa uma a uma.
As que ele quiser, coloque. Por exemplo : “o sistema tem que ter login” -> “a senha tem que ser encriptada ?” ,“como muda a senha?” , “como faz se esquecer a senha?” De 1 estoria vc adiciona 4 no backlog.
Analisando a figurinha que o FredFerrao postou, talvez, o último quadro foi tão bem colocado que o texto foi “o que o cliente realmente precisava” e não “o que o cliente queria”. O que o cliente precisa não é exatamente o que ele quer. Uma vez que você apenas confia nas reuniões e relato de cliente você só tenta adivinhar o que ele quer.
Eu não vejo outra forma de você saber o que ele realmente precisa se você não for o próprio usuário com bons conhecimentos em “como automatizar” o trabalho.
[quote=Thiago Senna]
Eu não vejo outra forma de você saber o que ele realmente precisa se você não for o próprio usuário com bons conhecimentos em “como automatizar” o trabalho.[/quote]
Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.
Sempre é aconcelhando vc ouvir o usuário. Porque muitas vezes (aka sempre) o cliente acha que os usuários precisam de tal coisa,mas os usuários odeiam essa coisa. Pesquisa de mercado é exatamente isto. È por isso que o Google a Microsoft e outros incluem nos seus software mecanismo de estatistica de uso. Isto indica o que pegou e o que não pegou.
O cliente nunca sabe o que quer e nunca tem razão.
[quote=sergiotaborda]
Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.[/quote]
Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.
Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).
Que tipo de coisas você gostaria de ver na revista? Diga o que não gostou na edição! Por que assuntos você se interessaria?
Este tipo de feedback é importante para estarmos fazendo uma revista cada vez melhor!
Saudações![/quote]
Uma coisa que acho que poderia ser valida é ensinar o consultor java a saber pesquisar assuntos e como decidi-los a estudar, fica muito complexo pegar a revista e ver soluções sem ao menos a pessoa saber porque deve-se usar isso ou aquilo, a revista esta indo no caminho para esse entendimento quando colocou no"Artigo 38 -Boas Práticas Java EE", ao Tema Acerte na sua escolha, mas ainda percebo que falta melhor direcionar os assuntos sobre obras e escritores, claro que isso é um grande desafio, mas acredito que possa mesmo a ter uma real colaboração sobre esse ponto de vista, por onde se deve mapear resultados sobre desenvolvimento e implementações com soluções em tecnologias, levar ao leitor a auto critica e elevar seu grau intelectual de conhecimento.
[quote=mochuara][quote=sergiotaborda]
Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.[/quote]
Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.
Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).[/quote]
:shock: As coisas que temos que ler por aqui …
Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?
Estou muito curioso como vc faz sistema sem levantar requisito algum.
Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.
[quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.[/quote]
Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.
Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).[/quote]
:shock: As coisas que temos que ler por aqui …
Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?
Estou muito curioso como vc faz sistema sem levantar requisito algum.
Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.[/quote]
Como falei, vc pode desistir do cliente e ir desenvolver frameworks, bugtrackers e outras ferramentas para programadores ou então exigir do cliente um domain expert. Mas o projeto só começa depois que os requisitos forem conhecidos. E no caso de clientes corporativos tais requisitos não é competência da área técnica.
Volto a repetir, em um modelo de tempo fechado para entrega, o Scrum não é totalmente eficaz se o cliente e a empresa que for desenvolver não conhecer o negócio bem. Só é eficaz se o prazo for estabelecido e a empresa já tiver uma experiência no assunto (não no desenvolvimento, mas no que será desenvolvido), pois sem isso, não adianta cada um ir aprendendo o que o cliente quer em cada interação que tanto um, como o outro, vai descobrir que o buraco é mais embaixo e o prazo expira.
Você mesmo Sergio, tá falando que faz iterações que às vezes aumenta a estória, às vezes as funde e às vezes descarta. De um jeito ou de outro, isso é uma descoberta do que vai ser feito, tanto do cliente como da empresa que vai desenvolver. Se for assim, a desenvolvedora vai descobrir lá no sprint sei lá do que, que o tempo pré-estabelecido é impróprio. E o cliente vai aumentar o tamanho do software além do imaginado. Tá, pode ser que isso seja barrado com cláusulas contratuais, mas a satisfação do cliente vai pro ralo e, talvez, no meio da descoberta, o cliente estime que sem aquela funcionalidade XYZ que vai detonar no software, não poderá ser implementada por ter um tempo curto.
Claro que isso tudo muda se for um modelo de sistema que a empresa de software está acostumada a fazer. É possível estimar neste caso.
Por isso penso que, isso só rola com um contrato flexível. Preço e prazo fixo, não vai rolar totalmente.
PS: O povo tá falando de métodos administrativos, mas já vou mandar a bola: o Scrum não mostra eficazmente uma previsão de demanda como na administração. Gente, não caiam nessa de que Scrum é um faz tudo, porque previsões são fórmulas matemáticas aplicadas com uma precisão real. O Scrum é um pressuposto que vai interagindo sem matemática e métrica real de tempo previsto inicialmente. E pelo que estou vendo, ele só tem uma noção métrica de quanto tempo vai durar algo quando passar da metade do trabalho feito ou quando ele tiver forma o suficiente para que tanto o cliente como os desenvolvedores saibam que corpo vai ter aquele aplicativo.
[quote=mochuara][quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.[/quote]
Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.
Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).[/quote]
:shock: As coisas que temos que ler por aqui …
Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?
Estou muito curioso como vc faz sistema sem levantar requisito algum.
Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.[/quote]
Como falei, vc pode desistir do cliente e ir desenvolver frameworks, bugtrackers e outras ferramentas para programadores ou então exigir do cliente um domain expert. Mas o projeto só começa depois que os requisitos forem conhecidos. E no caso de clientes corporativos tais requisitos não é competência da área técnica.[/quote]
Piorou. O projeto só começa depois que os requisitos são conhecidos, mas não ha levantamento de requisitos. então como ele são conhecido ? Telepatia ?
[quote=Thiago Senna][momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?
Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”
Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem][/quote]
Se o cliente não sabe o que precisa não é por falta de programadores ou analistas que se formaram em curso de computação, eles precisam de um domain expert.
Das dua,três: ou vcs não sabem o que é scrum e ficam dando pitaco sobre o que vcs acham que scrum é, ou vcs estão com a consciencia alterada por algum produto quimico ou vcs estão de sacanagem comigo.
Até aqui perfeito.
Isto nunca vai acontecer porque o tempo nunca é estabelecido. Vc não estima em tempo. Estima tamanho.
O máximo que vai acontecer é sua estimativa estar errada e em vez de fazer em um sprint vc faz em dois.
Isso é aceite e esperado em scrum. Não muda nada no planejamento do projeto.
Vc contratou 3000 pontos. uma features que vc cotou como 8 pontos foi na realidade 21 pontos. Isso significa que vc perdeu 13 pontos. Isso significa que features equivalentes a 13 pontos não serão incluidas neste release. Se o projeto só tem um release (o que é estupido,mas é possivel) isso significa que vão existir features que somam 13 pontos que não serão incluidas.
Veja bem, o cliente não está pagando para incluir todas as features. ele está pagando para ter um software utilizável numa certa data. Esta é uma grande diferença do metodo tradicional. No método tradicional software utilizável, escopo, tempo e custo é tudo a mesma coisa. Em agil não é.
Tlv seja isto que vcs não estão entendendo. Em scrum o foco é ter software entregável. A cada sprint o software é integravel. O PO pode chegar no fim de uma reunião de fim de sprint e dizer :“tá blz. empacota assim” ( nice, ship that). Isso significa que o release foi antecipado e o cliente tem o sistema antes do prazo. Antes do prazo.Onde vc vê isso no método tradicional? nunca. é sempre depois do prazo.
Do software, não do projeto. São coisas diferentes em Scrum. Tem que entender este conceito , porque senão vai ficar chovendo no molhado.
Não. Isso nunca vai acontecer. Porque ele priorizou. Se ele chega nessa conclusão a culpa é dele. Portanto não tem como ficar insatisfeito com a equipa. mas a satisfação nunca vai para o ralo porque todos os meses ele tem um software novo. Acho que é isso que vc não enxergam. Todos os fins de sprint ele tem um brinquedo novo para mexer. Isso é satisfatório.
[quote]
O Scrum é um pressuposto que vai interagindo sem matemática e métrica real de tempo previsto inicialmente. E pelo que estou vendo, ele só tem uma noção métrica de quanto tempo vai durar algo quando passar da metade do trabalho feito ou quando ele tiver forma o suficiente para que tanto o cliente como os desenvolvedores saibam que corpo vai ter aquele aplicativo.[/quote]
Isto é totalmente equivocado. Um burdown chat tem muita matemática e permite fazer muitos ajustes e estimativas. Vc tem que entender um burdown chat antes de dizer que o scrum não tem matemática.
Vocês vão ficar nesse loop infinito pra sempre desse jeito.
Ágil é uma via de mão dupla: não é só a software house, mas o cliente também tem que adotar. Não adianta ter uma equipe ágil e o cliente ser tradicionalista, e essa é a situação que todos querem que o Scrum resolva, sendo o maior exemplo a questão das licitações, muitas vezes exigindo, mesmo que não de forma escrita, um processo tradicional.
Se você quer adotar ágil, você vai precisar convencer seus clientes de que isso vale a pena antes. Não adianta você querer artefatos tradicionais usando uma metodologia ágil, ponto final.
E podemos voltar a discutir a revista?
Aliás, ainda não pude ler, pois não achei em nenhuma banca aqui em Recife.
[quote=jcracker]
Uma coisa que acho que poderia ser valida é ensinar o consultor java a saber pesquisar assuntos e como decidi-los a estudar, fica muito complexo pegar a revista e ver soluções sem ao menos a pessoa saber por deve-se usar isso ou aquilo, a revista esta indo no caminho para esse entendimento quando colocou no"Artigo 38 -Boas Práticas Java EE", ao Tema Acerte na sua escolha, mas ainda percebo que falta melhor direcionar os assuntos sobre obras e escritores, claro que isso é um grande desafio, mas acredito que possa mesmo a ter uma real colaboração sobre esse ponto de vista, por onde se deve mapear resultados sobre desenvolvimento e implementações com soluções em tecnologias, levar ao leitor a auto critica e elevar seu grau intelectual de conhecimento.[/quote]
Tenha certeza que isso realmente é um desafio! Tentamos a cada edição trazer um conteúdo relevante para os nossos leitores. Como já disse outras vezes aqui no fórum, o nosso maior concorrente são os artigos da Internet, que são numerosos e abrangem muitos assuntos! Estar trazendo sempre algo novo, como esse formato de artigo com a estória interativa e a entrevista exclusiva com Alex Buckley na edição anterior, é algo que temos sempre perseguido!
Para a próxima edição aguardem uma nova surpresa e a volta do Rodrigo Yoshima que estava meio sumido da revista!!!
Isto é totalmente equivocado. Um burdown chat tem muita matemática e permite fazer muitos ajustes e estimativas. Vc tem que entender um burdown chat antes de dizer que o scrum não tem matemática.[/quote]
Quando vimos o burdown chat aqui na empresa, os caras da área de engenharia, que cuidam da parte matemática dos softwares que desenvolvemos, que são específicos para previsão de demanda, riram. Se você não pode estimar com uma certeza o fim de um projeto, não tem matemática. A métrica do burdown chat não é a matemática de previsão de demanda.
Tá, o cliente fica feliz com um brinquedo novo cada vez que vc termina uma parte, mas ele não fica satisfeito por não termos adicionado a feature matadora que ele tanto precisa/queria, porque os pontos se foram. Tempo é dinheiro e o Scrum não tem estimativa fixa, ele vai se adequando a demanda do cliente. Logo, o que parecia 2 semanas ficam 3, porque adicionamos isso e aquilo, já que o cliente pode dizer que tudo é prioritário. Se a gente faz um levantamento de requisitos, ele não nos dá calculos matemáticos de quanto tempo levará para se fazer um aplicativo que nem sequer temos experiência. Ele apenas diz o que o cliente quer, INICIALMENTE.
Depois, com Scrum, vamos chegando com o cliente na situação “real”, porém, nem tanto. Se o tempo estimado para desenvolver o projeto já foi lançado como fixo, temos um problema grande: faz o que o cliente vai olhando como prioritário e deixa as loucuras de lado pra dar tempo ou…, simplesmente implementa e cobra mais do cara, porque o tempo estoura.
To falando isso porque aqui eu vi cliente insatisfeito. Não completamente, mas insatisfeito porque os caras começaram a inventar. E não tem bola de cristal pra invenção. Foge do escopo e da previsibilidade. No final, ele diz que essa e aquela feature era muito importante (não tanto, porque antes nas iterações iniciais não era), mas…apareceram. Os pontos vão se acabando e o tempo se esgotando. O software é entregue, mas devido a interatividade intermitente do cliente, muita coisa foi adicionada e muito tempo justo pra colocar em prática. Se o método ágil prega a satisfação do cliente, não foi o que vi. Vi foi um tanto de frustração porque no meio do caminho, eles foram tendo ideias que, no modelo antigo, você entrega e, se eles tem novas ideias, eles pagam a mais pra adicionar. Os clientes aqui não ficaram muito satisfeito e nos avaliaram mal por não atendermos a todos os requisitos que eles desejavam. Esse foi o problema do tempo fixo com Scrum adotado. Por isso que pra mim, Scrum por si só não funciona como pregam. Precisaria de algo junto pra estimar melhor ou um contrato de escopo variável e precificação também. Terminou um módulo, pagou, parte pro próximo. Ficamos felizes e o cliente também, já que invenção soma tempo e dinheiro ao estimado inicialmente.
[quote=Guerr@][quote=juliofsn]
E podemos voltar a discutir a revista?
[/quote]
100% Apoiado!!!
Uma coisa que eu acho muito importante, e que não me lembro se todos os artigos tem, são referências. no artigo do Gazola, por exemplo, tinham ótimas refêrencias, e eu fui atras pra le-las (ta certo isso que eu escrevi? :? ). Isso é como a bibliografia de trabalhos cientificos, se vc gostou do assunto, va ler as referências, e as referências das referências e assim por diante. Isso já é um começo para a proposta do jcracker de ensinar o cara a estudar.
