"Metodologias" para desenvolvimento de software OO

Recentemente fui incubido com a santa tarefa de ajudar meu gerente a re-estruturar nossa fábrica de software. Irei ajudá-lo especificamente com o que ele chamou de fase de “projeto” dentro do processo que ele está finalizando (estou com o chapéu de arquiteto mas, como a grande maioria na área, esse é apenas um dos chapéus). Estamos em andamento com o processo do PMS-BR fase G (a primeira) e esse é o primeiro degrau para a certificação.

Bem, venho utilizando a “metodologia” do “UML Components” do Chesman e Daniels e, à pouco, vi alguma coisa do ICONIX (material que vi aqui mesmo no fórum).

Achei o ICONIX muito mais simples e objetivo que o “UML Components”. Ainda não me aprofundei, lí apenas o básico necessário para ter uma idéia e poder compará-lo com o UML Components. Fiquei meio desconfiado da simplicidade e, antes de adentrar no material mais pesado, gostaria de trocar idéias com alguém que já tenha usado essa metodologia.

Se alguém tiver alguma outra sugestão de metodologia, por favor, basta citá-la. Sou todo ouvidos (e muitas interrogações).

Só pra listar as metodologias (ditas simples)

  • “UML Components”
  • ICONIX

Alguma outra?

Woody

Qualquer projeto que tenha fase de analise, fase de projeto, fase de etc. é waterfall, e está algumas décadas no passado. Procure uma metodologia iterativa e ágil de desenvolvimento, recomendo Scrum.

aproveite essa reestruturação e “de uma chance” para a dupla SCRUM + XP

Eu ainda não vi bons cases de XP na prática, vi algumas aberrações na embratel aqui no Rio que me deixaram um pouco traumatizado, a galera sempre simplifica muito na hora de implementar …

Já o Scrum ouvi falar dele há umas duas ou três semanas: ouve uma palestra no RioJUG apresentado na Santa Luzia e a gelera que conheço que foi gostou muito, voltou dizendo que ficaram andando em círculos pra demonstrar um conceito lá. Muito bem lembrado. Mas pela descrição que me deram eu havia entendido que esse “processo” ou “metodologia” estava mais preocupado com a gerência e coordenação (me disseram por alto que isso é conseqüencia do excesso de chefes e a burocracia que os processos estão gerando).

Não sei do Scrum, mas o XP não estaria mais para processo não? Tipo o RUP. Na minha cabeça tenho que metodologia é algo menor.

Uso waterfall sem problemas, gosto de pensar que posso voltar pra revisar e melhorar o quê estou escrevendo.

Na prática, vôcê está usando Scrum?

  1. A palestrs em questão foi sobre Scrum mas o case da ImproveIT é de XP

  2. Até onde eu sei isso de XP na Embratel foi um engodo

  3. Pode ser que você se de bem com Waterfall, especialmente para projetos muito pequenos e sem um cliente final, mas a in eficácia do processo no âmbito geral é provada estatisticamente há mais de vinte anos. claro que se dá certo para você pdoe ser o caso de uma exceção (baseado na minha experiência eu sicneramente duvido, mas pode acontecer)

  4. Na Globo.com existem departamentos que já trabalham com princípios como iterações curtas, planning game e TDD há mais de seis meses e estão na fase da implantação do Scrum

  5. Se você gosta de revisar o que escreve vai gostar ainda mais de abordagens iterativas como RUP, XP e Scrum que fazem isso com disciplina e qualidade :wink:

  6. XP é mais uma prática de engenharia, Scrum de gerência de projeto. pdoem ser utilizadas em conjunto

É verdade, IMHO, SCRUM é um framework mais dedicado a parte gerencial, enquanto XP tem práticas e valores com um foco maior no desenvolvimento.

Eu acho que se vc procurar, vc vai encontrar ótimos cases de XP na prática. Eu já participei de um projeto usando XP e o resultado foi ótimo.

Mas se a procupação é somente com a gerência, eu acho que SCRUM ou Lean são boas opções.

Na verdade é bem o contrário. Estou procurando por “metodologias” mesmo, “receitas de bolo” para a fase de projeto. Logo no início do processo do MPS BR fui “convidado” para os cursos e comentei com o Zé (meu gerente) que eu conhecia uma metodologia para projeto que eu achava que poderia ser encaixada no nosso processo (a UML Components).

Estava compilando a documentação dessa “metodologia” quando entrei aqui no fórum e vi o artigo sobre o ICONIX, que me chamou bastante a atenção. Daí caiu a ficha: “Woody - é melhor trocar idéias antes de decidir pelo UML Components …”

Nosso processo é (ou será, pois não está 100%) baseado em RUP, com alguns trecos de outros processos (CMMI). O processo como um todo já está bem adiantado, meu gerente têm bastante experiência com tailoring do RUP. Fiquei responsável pela parte da especificação da fase de projeto em si.

Pelo pouco que vi do ICONIX cheguei à conclusão que esse também poderia ser aplicado.

Lean? Nunca ouvi falar, vou pesquisar!

[quote=pcalcado]
6) XP é mais uma prática de engenharia, Scrum de gerência de projeto. pdoem ser utilizadas em conjunto[/quote]
Vou rezar para o Vinícius Teles não ler isso. :roll:
Mais detalhes aqui.

Não existe RUP sem processo iterativo (e não existe processo iterativo de uma iteração só :wink: ) então ou você trabalha com ‘fase de análise’ e etc. ou usa RUP (o RUP possui fases mas é um conceito beeeeem diferente).

UML components é uma metodologia de engenharia que pode ser comparada em alguns aspectos com XP, e possui o fim bem específico de produzir arquiteturas CBD, hoje em dia este conceito não anda muito em voga.

CMMI e MPS.BR não são processos, são certificações dadas à processos que obedeçam características específicas. Teoricamente a maioria dos processos, incluindo os baseados em XP, RUP e Scrum, podem obtêr estas certificações.

Minha sugestão:

  • Iterações curtas (o quanto depende do ambiente, 15 a 30 dias é ótimo para a maioria dos casos)
  • Test-Driven Development
  • Planning Game com um backlog único priorizado
  • Agile Modeling (veja livro do Scott Ambler)

Só com estas ferramentas simples você já tem um modelo muito eficiente.

[quote=TheMask]Vou rezar para o Vinícius Teles não ler isso. :roll:
Mais detalhes aqui.[/quote]

Eu discordo do Vinicius neste aspecto. Scrume XP são muito parecidos e altamente compatíveis, mas não são a mesma coisa. Discordo principalmente deste ponto:

Para mim XP e Scrum são baseados nos mesmos princípios e por isso são compatíveis, mas possuem foco completamente diferente. Scrum simplesmente não fala sobre software ou programar, fala sobre resolver problemas (que podem ser de qualquer tipo).

O papel do facilitador (Scrumaster no caso) para mim é fundamentalmente diferente. Minha maior dificuldade como ScrumMaster é ficar fora das decisões técncias, geralmente eu visto o chapéu de coach e Master, o que não é o ideal. Idealmente o ScrumMaster fica fora de qualquer decisão neste sentido. Se eu usasse XP não teria sequer esta questão filosófica.

É como se por fazer um programa OO possuíssemos uma arqutietura de componentes. Ambos se baseiam no mesmo princípio mas possuem focos completamente diferentes.

2 perguntas: nunca viu pessoalmente, ou vc so nao le noticias sobre TI, mesmo?

Outra: o que vc quer dizer com “a galera sempre simplifica muito na hora de implementar”?

[quote=pcalcado]

  • Iterações curtas (o quanto depende do ambiente, 15 a 30 dias é ótimo para a maioria dos casos)[/quote]

Apenas para deixar claro, acredito que quando o Phillip fala de 15 à 30 dias, ele quer dizer para você escolher um duração entre 15 à 30 dias. Não é para começar uma iteração que pode terminar dentre 15 ou 30 dias. “timebox” é o conceito.
Acredito que iterações de 1 semana também são uma ótima opção, vai depender do seu ambiente de desenvolvimento…

Saiu um eBook gratuito na InfoQ sobre como uma empresa Sueca estão usando Scrum e XP juntos “Scrum and XP from the Trenches”:

O livro inclui:

  • Dicas praticas para a maioria das praticas de Scrum e XP
  • Dificuldade tipicas e como foram resolvidas
  • Diagramas e fotos ilustrando o dia a a dia do trabalho
  • Testando e desenvolvendo guiado por testes
  • Escalando e coordenando múltiplas equipes
  • Lidando com a resistência de dentro e fora das equipes
  • Técnicas de planejamento e estimativa de prazos

Eu adoraria ter iterações de uma semana. Pena que apra botar algo em produção hoje eu preciso de 4 dias de ritual burocrático, daí acabo fazendo de 15, que na verdade de dias úteis ficam uns 5.

Eu gosto de iteracoes de 2 semanas pra times grandes (15+), mas se fazer um deploy requer um bode em cima dum pentagrama rodeado por velas pretas, va la: 15 dias eh bem aceitavel.

Delicado como sempre né? Como você sugerio e pra ser sincero tá difícil. Acho que é essa a idéa do fórum não é? Trocar idéia com gente mais experiente (em algum assunto expecífico).
Nunca vi pessoalmente, pra projetos grandes (projetos com mais de um ano). Citei até um exemplo.

[quote=cv]
Outra: o que vc quer dizer com “a galera sempre simplifica muito na hora de implementar”?[/quote]
A frase é quase que auto-explicativa (ao meu ver) mas vamos lá: No XP, a galera (que eu vi na Ebt) sempre saia pro código depois de levantar os requisitos, sem um planejamento inicial - e isso sempre dava m. Vi isso ocorrendo, também, em mais 2 outros projetos (médios, aviação).

Falei m quando disse que usava waterfall. Ultimamente (na empresa em que estou) estou usando “civiranego”, mas usei muito GSMS (EDS) e RUP (Ebt e outra). Usei iterativo. Sry.

[quote=pcalcado]2) Até onde eu sei isso de XP na Embratel foi um engodo[/quote]Nem me fale …

TDD é test driven developemnt certo? agora esse outro, planning game, nunca ouvi falar. Vou pesquisar …

Quanto a abordagem iterativa: realmente gostei - pena que é muito difícil vender sistemas nesse formato. O cliente sempre quer um começo, meio e fim muito bem definido pra justificar pelo que estão pagando, eles contam com apenas uma iteração e o gerente acaba quase sempre repassando isso pro projeto e desenvolvimento em uma única iteração …

Verdade. Ambas certificações já sugerem um formato inicial de trabalho, muito por alto. Quiz dizer que nosso processo irá utilizar um pouco de cada (90% RUP, pelo que conheço do meu gerente).