| Autor |
Mensagem |
|
|
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.
|
|
|
|
sergiotaborda wrote:
A sua equipa pode desenvolver em XP sem a necessidade dos gerentes saberem disso ou interferirem com isso.
Desculpa Sérgio... isso é impossível. XP não é só sobre técnicas de engenharia. O que dizer de ritmo sustentável, cliente presente, humanismo, responsabilidade aceita, benefício mutuo? Isso envolve mais a gestão e o cliente do que qualquer outra coisa do Scrum.
XP muda muito mais os gerentes do que Scrum.
Carol, não recomendo começar este trabalho sem ter apoio da gerência. Agile não são práticas para simples otimização local. É algo bem mais amplo e envolve a empresa toda. Para se ter uma idéia, o mindset do processo de contratação do cliente que estou atuando agora é o impedimento que estou combatendo para defender a implantação Agile. Logicamente que você tem beneficios em melhorar a comunicacão da equipe e etc... Mas os benefícios serão maiores se todos participarem. Feudos são o pior inimigo para implantações Agile.o
Se você estiver em São Paulo nós da Aspercom podemos fazer uma palestra gratuita. Mas seus caciques tem que participar.
|
|
|
|
mochuara wrote:
Minha sensação é que não é possível reunir Java + OO + Agile em projetos reais e ganhar dinheiro, a não ser que seja vendendo cursos, livros ou escrevendo num blog famoso no circulo de nerds. Pra criar programas em Java usando boas práticas de OO vc precisa de tecnicas de engenharia de software, especificações detalhadas e processo waterfall!
Técnicas de Engenharia de Software? Quais delas? Que processo prega espeficificações detalhadas em baixa plataforma?
Já participei de um projeto bilhonário com Java, OO e Scrum/XP. Alto ROI e cliente MUITO satisfeito. Não só é possível como vários clientes meus usam. Um exemplo é a Synchro. Outro seria a Sumus. Tenha um pouco mais de experiência de mercado antes de fazer generalizações estúpidas.
fonte: blog.aspercom.com.br
|
|
|
|
Lucas Emanuel wrote:
Se as ferramentas da IBM fosse o mesmo preço da EA, voce ainda continuaria com EA ou partiria para IBM? Já ouvi dizer que as ferramentas da IBM não é lá essas coisas.
É uma questão de filosofia do produto. A IBM (ao menos no seu posicionamento com o Rhapsody, RSA, RSM) ainda vê a UML como BluePrints ou como Programming Language. UML as Sketch não é muito explorado pelos tool vendors de UML por razões óbvias, mas é uma miopia estúpida. Já o EA é uma ferramenta que depois que você se acostuma com ela fica fácil diagramar como rascunho, além da ferramenta ser bastante barata. UML não é o aspecto mais importante em nenhum projeto. Não há razão para gastar dinheiro com ferramentas caras de UML.
FYI:
http://martinfowler.com/bliki/UmlAsBlueprint.html
http://martinfowler.com/bliki/UmlAsProgrammingLanguage.html
http://martinfowler.com/bliki/UmlAsSketch.html
|
|
|
|
pcassiano wrote:
Duas ou três versões atrás o Rose era uma porcaria... usei por imposição da empresa em que estava alocado, pois se pudesse escolher, escolheria o EA... Não sei como estão as ferramentas da IBM hoje...
O Rose é uma ferramenta que deveria ser descontinuada em 2003... Ela não é UML 2.0, é ruim de lidar, é ruim para SCM, é pesada e etc... Dou um desconto pois o Rose é uma ferramenta de quase 20 anos...
|
|
|
|
Para modelar atores e seus objetivos: Diagrama de Casos de Uso e narrativas
Para modelar o fluxo de trabalho: Diagrama de Atividades
Para modelar objetos, seus atributos, relacionamentos e responsabilidades: Diagrama de Classes e Objetos
Veja meu artigo: "UML Não é Documentação" de 2006, mas ainda 100% atual...
http://blog.aspercom.com.br/2008/06/06/uml-nao-eh-documentacao/
|
|
|
|
Classes e objetos são diferentes de Tuplas e Tabelas...
Modele classes se seu sistema é orientado a objetos. Faça suas tabelas como simples repositórios de dados, consequencia do seu modelo de objetos, e não o contrário.
(BTW, com tecnologias como o Hibernate no Java e no .NET e Migrations no Rails, faz uns bons 5 anos que não modelo tabelas no green field)
|
|
|
|
Com relação a custo benefício nenhuma bate o EA.
Jude: ruim
Poseidon: pesado
Ferramentas da IBM: caras
Abraços...
|
|
|
|
Rafael, qualquer coisa que se torna Mainstream há declínio nas buscas... Pode fazer um teste com Java, Extreme Programming e qualquer outra coisa que você vai ver o mesmo padrão... Eu tenho visto bastante que o nível das buscas é o nível de curiosidade das pessoas e não ha qualquer relação com o uso da tecnologia e a sua inovação...
|
|
|
|
Como já disse aqui e em vários artigos de revista, JAVA não implementa MVC as is. Nem JSF, nem JSP, nem Swing implementa...
MVC não é sobre camadas (acho que essa que disse aqui já tem uns 3 anos e rendeu um post do Shoes).
(desculpe, sem tempo para postar links)
|
|
|
|
Arquiteto, assim como DBA, é um cargo que vai se extinguir...
Bons arquitetos fazem a arquitetura sumir.
|
|
|
|
|
|
|