| Autor |
Mensagem |
|
|
mochuara wrote:
Dica do mochuara: Desconfie quando alguém disser que X morreu, principalmente se X ainda é amplamente utilizado pela indústria.
Desconfie do quê? Diz aí... Trabalho com RUP a mais de 10 anos, sou consultor e só em 2010 devo ter visitado mais de 30 empresas para conversar sobre processos, times e problemas. Uma coisa te digo, ninguém mais está me procurando para implantar RUP. Isso é um fato. Qual a sua desconfiança?
É culpa do RUP? Não. RUP é um bom processo.
|
 |
|
|
marcosalex wrote:
Como te citei e mostrei, a forma que você colocou no artigo não é a maneira correta de se usar e no seu artigo dá a entender que é a única forma de se trabalhar. Mas se você prefere outra ferramenta ou se tem algo contra a Microsoft, você é livre pra usar a ferramenta que se adaptar melhor.
Legal, legal, sempre que alguém aparece defendendo Gantt Chart, a ferramenta de mercado mais utilizada para isso e acompanhamento de tarefas, eles dizem que meu artigo não é maneira correta de fazer. E já apareceram uns 10 falando isso. Você é apenas mais um. Você poderia escrever no seu blog ou em algum lugar como é a maneira correta?
O mais engraçado de tudo isso é que se realmente fosse tão boa a "sua alternativa" teria muita atenção para o assunto, mas quando você busca no Google por "gantt chart software" meu artigo é um dos primeiros hits que aparece.
http://www.google.com.br/search?q=gantt+chart+software&hl=pt-BR&safe=off&source=lnt&tbs=ctr:countryBR&cr=countryBR&sa=X&ei=reMbTMDXHoL6lwegiNzPCg&ved=0CAoQpwU
|
|
|
|
marcosalex wrote:
Justamente gerenciando as mudanças de escopo pra projetos empíricos
O que é uma mudança de escopo para você usando métodos empíricos em software? Alguma literatura de processos empíricos defende uso de baselines num Backlog, como exemplo?
marcosalex wrote:
Como eu disse, não é somente com percentual que o Project trabalha. E cada tarefas pode ser uma história, daí você vai ter as tarefas concluídas, em andamento e não iniciadas, da mesma forma que um dashboard.
Sim, mas neste caso, será que uma planilha do excel ou fichas pautadas não resolve? Qual é o benefício de usar o Project para isso? Há dependência entre histórias? Há %complete em histórias? Qual é o benefício de gerenciar histórias usando project?
marcosalex wrote:
O que eles são contra é com a forma de gerenciar e não com uma ferramenta (que nada mais é que uma ferramenta, assim como o backlog). Basta usar as histórias no project como uma fila e não como uma rede. Novamente: o Project permite trabalhar de diversas formas, o errado é trabalhar como um projeto de engenharia como as fábricas fazem.
Desculpe, mas creio que você está desinformado. Jeff Sutherland e Ken Schwaber são explicitamente contra Gantt Charts e gestão baseada em tarefas. Você sabia que nem a Microsoft usa o Project para gerenciar seus projetos de software? 
http://scrumjeffsutherland.blogspot.com/2006/02/why-gantt-charts-were-banned-in-first.html
marcosalex wrote:
Desde que deixe claro que é "sua" opinião e não uma verdade absoluta, tudo bem. hhehehe 
Minha opinião, do Ken Schwaber, do Jeff Sutherland, do Joel Spolsky, do Chris Peters e muitos outros. Creio que estou melhor fundamentado que você. Sorry. Mais uma vez, tenho fundamentos objetivos, você só sua opinião pessoal.
|
|
|
|
marcosalex wrote:
Com certeza quando você escreveu você não conhecia o recurso de baseline, usado pra acompanhar projetos empíricos onde o escopo varia durante o projeto como no caso de software.
Sim, e o que baseline me ajuda?
marcosalex wrote:
Também não devia saber que não é somente por percentual que o Project gerencia tarefas concluídas ou não.
E o que eu ganho em saber %complete ou qualquer outra coisa baseada em tarefas concluídas se a minha base de valor agregado são histórias concluídas e não tarefas?
marcosalex wrote:
Mas o mais importante é que na época você devia pensar que tarefas lançadas no project tenha de ter dependência analise-codificacao-teste, o que é incorreto. No meu caso, eu coloco as dependencias nos sprints e interações, proporcionando uma forma muito simétrica de visualizar o que trabalhamos em cada dia e acompanhando as mudanças.
Legal, Marcos, mas já que você citou sprints, sabe a opinião dos criadores do método Scrum sobre Gantt Charts? Eles são contra. O que escrevi é somente baseado na opinião deles e com algumas observações pessoais. Nenhum autor sobre métodos modernos de desenvolvimento de software defende o uso de Gantt Charts ou qualquer tipo de acompanhamento de tarefas. A base do gerenciamento de projetos ágil é um Backlog. Veja o processo como uma fila de itens observaveis pelo usuário e não como uma rede de tarefas que não agregam valor algum.
marcosalex wrote:
Todo mundo é livre pra usar a ferramenta que se adaptar melhor, não existe solução única que atenda todo tipo de projeto e todo tipo de pessoa. O que é muito diferente de dizer que "solução X não funciona" ou "Y não serve pra nada".
Sim, eu também sou livre para observar que certas ferramentas não funcionam na maioria dos cenários que tive contato em 16 anos de carreira, e sou livre para escrever minha opinião mostrando argumentos objetivos onde quiser.
|
|
|
|
|
Rubem, acho que a passagem de mensagens é um aspecto a ser considerado.
|
|
|
|
Nonaka e Takeuchi? Na Toyota? Tem certeza? Sempre achei que eles eram professores na Universidade Hitotsubashi.
|
|
|
|
Joel, tai um bom artigo pra você escrever...
(e realmente não acho que esse assunto terá audiência aqui, se fosse repositórios com REST daria mais Ibope)
|
|
|
|
Já faz 3 anos que escreví isso... É um dos artigos mais lidos do blog, graças a Deus isso influencia o Brasil...
http://blog.aspercom.com.br/2007/11/15/ganttchartnaofunciona/
|
|
|
|
sergiotaborda wrote:
Vc precisa aprender os fatos antes de poder fazer esses comentários. Scrum nasceu do Lean criado pela toyota e não do XP. O XP nasceu do lean aplicado a desenvolvimento ( o scrum é aplicado a gestão). Ou seja, agil não nasceu no meio universitário. Nasceu da filosofia oriental numa fábrica de carros.
Scrum não veio do Lean. Apesar disso ser uma crença popular em desenvolvimento de software, não há fundamento para acreditar em tal. XP também não nasceu do Lean. Agil não nasceu numa fábrica de carro. Nenhum dos proponentes do Agile eram operários. Não há razão para acreditar em tal....
|
|
|
|
mochuara wrote:
Sim, é engracado ouvir gente falando que RUP é iterativo. A agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis, mas por outro lado aumentou a pressao da equipe de desenvolvimento que vai ter que descobrir que raios deve fazer algum parte do sistema que nao é "chave"!
O RUP nunca foi waterfall. Não é waterfall. Se você acha engraçado gente falando que o RUP é iterativo, pode rir agora:
O RUP é iterativo. Sempre foi. E é um processo customizável, então, se a "agilizacao do RUP fez com que os analistas gerassem menos artefatos inuteis", então o RUP é Ágil desde 1998.
http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/
Prezado Mochuara, tem base bibliográfica para suportar as afirmações do paragrafo citado acima?
|
|
|
|
sergiotaborda wrote:
Por outro lado a sua limitação a achar que scrum é o que o Ken fala e diz mostra ainda mais a sua limitação no conhecimento de scrum. Aliás, o Ken acabou saindo da Scrum Alliance que ele mesmo fundou. Isso mostra várias coisas, mas mostra principalmente que não ha uma relação de identidade entre o ken e o scrum.
O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)? Que relação há entre a saída do Ken da SA e a sua autoridade no assunto Scrum? Não há uma relação de identidade entre Ken e Scrum? Conceitualmente incorreta sua colocação e me lembra os aloprados da OMG quando falaram para o Ivar Jacobson que ele não tinha entendido nada de casos de uso.
Se você toma a liberdade de dizer que o XP como ele é caiu em desuso, tomo a liberdade de dizer que coragem, algo citado no black book do Ken caiu em desuso. Isso nem consta no livro novo (que está mais direcionado para transparência, inspeção e adaptação) e sequer consta no Scrum Guide. Concorda comigo ou não?
Sua colocação define o que é gestão e o que é engenharia. Me explica: User Stories é engenharia ou gestão? O que ocorre num planning é só gestão?
Sergio, não preciso me justificar sobre meu conhecimento e principalmente minha atuação no mercado. Aliás, não achei seu curriculum em lugar nenhum. Outra sugestão: vamos acalmar os ânimos... desculpe se coloquei algo que te ofendeu. Não vamos partir para ofensas pessoais. Abraços!
|
|
|
|
Sim, sim Sérgio... Scrummeiros geralmente dizem que Scrum envolve tudo. Projetos de software e etc... É bastante engraçado pois a literatura base do Scrum que é o livro do Ken SÓ DÁ EXEMPLOS DE PROJETOS DE SOFTWARE. Scrummeiros também seguem o seguinte lema: Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.
Me dê mais detalhes. Aonde Coragem e Simplicidade estão no Scrum? No Foco? Que relação há entre Foco e Coragem? O que você entende por Coragem no XP?
(eu sei que vc vai colocar no Google "courage +xp" e me mandar o primeiro link)
Ter o sistema "deploy ready" é uma prática de gestão? Oras, então Pair Programming é para Foco e assim, seria mais uma prática de gestão do XP para complementar meu argumento. Taí!!! Pair Programming é uma prática de gestão do XP que não tem no Scrum... Se vale dizer que qualquer prática é de gestão fica ainda mais fácil ainda defender meu argumento. Ou será que é o Sérgio Taborda que decide quais práticas são de gestão e quais são de engenharia.
sergiotaborda wrote:
Não estou em liberdade para dizer os nomes. (procure o meu curriculo e tire sua conclusões dai)
Engraçado, a maioria das pessoas que falam que fazem agile, que implantam agile, que fazem isso e aquilo no mercado nunca estão em liberdade para dizer nomes. Eu acho isso muito estranho. Muito mesmo. Sem fundamentar seu argumento em fatos não dá para continuar a discussão.
Só para reafirmar, SIM, todo o meu trabalho que faço atualmente nesta seguradora partiu de uma palestra que ministrei no ano passado a pedido e um aluno que NÃO ERA GERENTE. Se você não consegue fazer isso eu te recomendo um curso de vendas.
|
|
|
|
Assumindo que não sabemos ao certo todos os requisitos, o prazo é móvel. De qualquer forma, para facilitar, os meus orçamentos sempre são em iterações:
"Este projeto planejamos 10 iterações de 2 semanas com 6 pessoas"
Essa é a maneira que trabalhamos com projetos aqui na Aspercom. O custo da iteração é uma métrica importante. Graças a Deus projetos de software são simples com relação a custo. Geralmente as despesas com pessoal e mais posição de trabalho já fecham a conta.
Trabalhamos com projetos de escopo negociável: Renegociamos a cada mês o escopo, o Backlog é a maior autoridade com relação ao andamento do projeto, damos uma previsibilidade sobre quantas iterações ainda temos para finalizar o projeto (baseada em story points e velocidade). O benefício para o cliente é que ele não paga qualquer gordura e recebe a solução ao fim de cada iteração com qualidade constante.
|
|
|
|
Sergio, você escreve muito. Seja mais direto. Coloque seu ponto de vista sem fazer estripulias. Fica difícil discutir com você como sempre. Só um desabafo.
sergiotaborda wrote:
Se vc pegar o XP e retirar dele as praticas comuns ao Scrum, sobra apenas tecnicas de engenharia.
Se eu tirar o Scrum do XP ainda sobra:
Valores:
1. Simplicidade (é um conceito de gestão)
2. Coragem (é um conceito de gestão)
Princípios (que envolvem Gestão):
1. Falha
2. Humanismo
3. Passos de Bebê
4,.Redundância
Práticas (mais uma vez, somente as que envolvem GESTÃO):
1. Ambiente Informativo (psc, esses quadrinhos da moda Scrum não é prática do Scrum)
2. Ciclo Trimestral (sim, se você leu o livro do Ken, note que ele não fala sobre planejamento de release, dá zero para ele)
3. Folga (equipes Scrum não precisam disso, são Chuck Norris por natureza)
4. Histórias (opa, mais uma prática de Gestão do XP, noooooosa, stories não é do Scrum?)
5. Sentar-se Junto (será que os POs ficam o tempo todo com a equipe?)
6. Trabalho Energizado (prática de Gestão).
sergiotaborda wrote:
Scrum não define práticas de engenharia porque em tese não serve apenas para projetos de TI. XP serve apenas para projetos de TI ("programming"), e por isso tem que ter essas caracteristicas de engenharia. XP precisa de valores, etc etc,... porque é uma disicplina agil, mas essa parte existe da mesma forma em Scrum.
É falácia. O Scrum define sim práticas de engenharia. Leia o livro do Ken. O papel do ScrumMaster é promover boas práticas de engenharia. O pedaço de funcionalidade potencialmente implantável é uma prática de engenharia, e uma das mais difíceis.
sergiotaborda wrote:
Discordo absolutamente. XP não pode mudar mais porque é menos focado em gerencia. Ele consegue equipas mais coesas e isso pode levar o gerente a aceitar a mudança,mas não muda o gerente. Tudo o que XP faz na parte de orgnaização , planejamento e retrospectiva é o mesmo que scrum faz.
Estude melhor o XP. XP menos Scrum não fica só práticas de engenharia como provado acima. Isso é falácia de Scrummeiro. Os tópicos que coloquei acima não estão no Scrum e pode ter certeza que ritmo sustentável, sentar-se junto, coragem e humanismo mudam mais a gestão do que as coisas do Scrum. Sim, o Scrum tem o mérito de ser mais simples, mas o humanismo do XP é algo que muda a gestão completamente. XP não fere o humanismo em detrimento a performance.
sergiotaborda wrote:A diferença é XP é extremo , num esquema de tudo ou nada. ou faz pair programing toda a hora ou não é XP. Este tipo de pensamento está em decaimento e XP , hoje em dia, resume-se a um conjunto de práticas de engenharia que junto com scrum.
Fontes por favor? Artigo, pesquisa? Quem disse que está em decaimento?
sergiotaborda wrote:Em uma empresa real, ou se faz isso, ou nunca se mudará nada.
Você não conseguirá convencer os gerentes de forma racional. Eles têm que sentir que XP/Scrum é melhor que o método atual.
Eles têm que sentir que não vão perder o emprego , que não vão perder o salário de "gerente" (eles pensam que num ambiente assim o gerente é dispensável e por isso eles têm medo de mudar). Vc não pode argumentar contra o medo. Não funciona.
Mais uma vez, cases por favor? Quais empresas você tentou isso e não deu certo? Qual a sua experiência? Engraçado, meus melhores argumentos são contra o medo....
sergiotaborda wrote:
Certo. Supondo que alguem os convence a participar e vc conseguir fazer essa lavagem cerebral a estes gerentes em uma palestra gratuita por favor nos avise dos resultados.
Seria interessante algum tipo de estatistica tipo quantos gerentes antes relutantes saem da sua, quer dizer da vossa, palestra convencidos.
Eu duvido que uma unica palestra consiga convencer alguem. Para isso funcionar a pessoa já tem que estar pré-disposta a aceitar Agil. E esse é que é realmente o problema aqui.
Sergio, Sergio. Isso aconteceu num cliente meu. A Synchro. Antes relutantes e depois confiantes, e isso com um treinamento de 8 horas. O mais engraçado de tudo isso é que este cliente que estou atuando agora é uma das maiores seguradoras do país com faturamento de 8 bilhões de reais, o Agile lá vai escalar para 300 devs e convencí eles em uma palestra de 2 horas. Na semana passada ministrei um treinamento de TDD e XP na Imagem (img.com.br). Esses caras se convenceram lendo o Débito Técnico. Não é lavagem cerebral, tenho bons argumentos e bons cases, principalmente em clientes ISV e empresas pequenas. Eu sei das dificuldades que esses gestores tem. É bem simples até, mas a decisão é do gestor. A palestra é simplesmente para tirar dúvidas. Concordo que empresas como a minha são involuntariamentes beneficiadas pelo efeito "santo de casa não faz milagre", por isso recomendei essa estratégia para a Carol.
|
|
|
|
Definição de Atores e Casos de Uso não tem relação com o controle de acessos da aplicação, então, essas afirmações do tipo: "O Ator x pode... e não pode" não faz sentido...
O modelo de casos de uso responde o que o seu sistema faz, manter o controle de acessos fora disso é bem saudável.
|
|
|
|
|
|