"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.

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

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.

pcalcado wrote:é waterfall, e está algumas décadas no passado

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

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

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

É 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!

JavaBaby Membro desde: 14/04/2006 19:28:16 Mensagens: 79 Offline

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

Vou rezar para o Vinícius Teles não ler isso.

Mais detalhes aqui.

Não existe RUP sem processo iterativo (e não existe processo iterativo de uma iteração só

) 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.

TheMask wrote:Vou rezar para o Vinícius Teles não ler isso.
Mais detalhes aqui.

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:

Vinicius wrote:
Na minha opinião, o fato de XP ter várias práticas técnicas não é uma indicação de que ele foque mais nesse aspecto. Ele tem várias práticas técnicas porque, ao contrário do Scrum, não está focado apenas na parte de planejamento e gestão de projetos. XP é direcionado para desenvolvimento de software. Por essa razão, há também as práticas técnicas. Para ser honesto, na parte de planejamento e gestão, XP me parece ainda mais disciplinado que o Scrum, porque direciona explicitamente para o uso de cartões e iterações mais curtas, provendo feedback mais rápido. Portanto, acho correto afirmar que Scrum tenha um foco maior (ou melhor, exclusivo) em gerenciamento e planejamento. Porém, não acho correto afirmar que XP seja mais direcionado para o lado técnico.

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.

agodinhost wrote: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 ...

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"?

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

pcalcado wrote:
- Iterações curtas (o quanto depende do ambiente, 15 a 30 dias é ótimo para a maioria dos casos)

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":
http://www.infoq.com/minibooks/scrum-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

mueller wrote:Acredito que iterações de 1 semana também são uma ótima opção, vai depender do seu ambiente de desenvolvimento...

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.

Notícias, artigos e o maior fórum brasileiro sobre Java