Fábrica de Sofware

This message was edited 1 time. Last update was at 29/12/2008 06:14:16

"

marcosalex wrote:o que muita gente faz é fechar contrato por pequenas partes a medida que for esclarecendo o serviço

Que tal desenvolvimento iterativo (e incremental)?

marcosalex wrote:Ter uma visão global e for atualizando com baselines a medida que as atividades forem se abrindo

Que tal um Product Backlog que vai tendo seus itens flutuando pra baixo e pra cima conforme a prioridade/necessidade DO CLIENTE?

marcosalex wrote:As ferramentas de gerenciamento de projeto hoje em dia fazem isso, já que não é só na nossa área que acontece isso. Os relatórios de baseline ajudam pra caramba a trabalhar esses projetos e tentar diminuir ao máximo o desvio, que na nossa área sempre vai ter.

Ter alguém com conhecimento do negócio do cliente e que seja comprometido com o projeto para fazer isso funcionar corretamente, que diga o que realmente importa para o cliente, já diminui drasticamente o desvio ocorrido nos projetos.

This message was edited 1 time. Last update was at 07/07/2008 11:15:27

marcosalex wrote:
Tem que é mais fácil identificar em muitos casos pontos onde pode haver paralelismo e onde não podem! Concordo que existe um limite, mas não se iluda de que não existe nenhuma forma de paralelismo e generalize. Se fosse assim, todo software por maior que seja teria um único profissional trabalhando.

Bom, eu trabalho com metodologias ágeis há alguns anos e não lembro de ter visto em nenhum lugar com cre'dito alguém defendendo este tipo de coisa. Na verdade, dado que em metodologias ágeis se trabalha em times pequenos e multi-funcionais, seria o extremo oposto. Eu não entendo como práticas como propriedade coletiva de código, user stories entregando valor de ponta-a-ponta, integração contínua e outras poderiam funcionar num ambiente onde exista qualquer paralelismo no desenvolvimento de um sistema.

Pode explicar melhor ou dar referências?

marcosalex wrote:
Pensa em um exemplo simples: pra alguém fazer um cadastro de clientes, nada impede de outro analista fazer o relatório desse cadastro mesmo que eles tenham de gastar um tempo se comunicando. Em muitas situações não é difícil identificar quando um novo profissional pode ajudar e quando não pode.

Se o desenvolvedor já está no time provavelmente o relatório é uma user story separada e sim, ele pode ser paralelizado dentro do time se fizer sentido. Se o desenvolvedor vem de fora então seu exemplo está explicado no livro do Fred Brooks, já citado:

The Mythical Man-Month, Chapter 2 wrote:
More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.

Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

Recomendo fortemente a leitura deste livro.

Quanto ao MVC, eu ainda não entendi como ele se encaixa nisso tudo. MVC é apenas uma forma de dizer como 3 componentes de uma aplicação se comunicam, não vejo o impacto na metodologia em usar ou não.

marcosalex wrote:
Entendi. Esse é um problema não só da nossa área, tem muitos projetos com essas características e tem tratamento próprio, mas como você disse, não existe uma fórmula exata, mas tem maneiras de minimizar. Escopo e prazos rígidos é certo que não funcionam, mas dá pra conseguir uma aproximação.
Não é novidade pra ninguém da área que quanto maior o projeto de software, mais difícil é fechar o escopo, custo e prazo, ao contrário da engenharia onde dá pra se ter uma base de tudo e até fazer uma maquete. Mesmo projetos pequenos, dependendo do tipo, pode ser difícil definir os requisitos, isso também todo mundo sabe.
Pra fechar com uma fábrica de software nesses casos o que muita gente faz é fechar contrato por pequenas partes a medida que for esclarecendo o serviço. Ter uma visão global e for atualizando com baselines a medida que as atividades forem se abrindo. As ferramentas de gerenciamento de projeto hoje em dia fazem isso, já que não é só na nossa área que acontece isso. Os relatórios de baseline ajudam pra caramba a trabalhar esses projetos e tentar diminuir ao máximo o desvio, que na nossa área sempre vai ter.

As ferramentas (e, principalmente, as metodologias) de gerenciamento de projeto fazem isso há anos e não resolveram os problemas. A questão é simples, creio: não adianta tentar controlar o incrontrolável. Há mais de duas décadas que se tenta isso com falhas miseráveis todos os anos (vide CHAOS reports).

Mas acredito que você está convergindo para o iterativo incremental, talvez eventualmente ágil. O grande problema é que iterativo e incremental não combina com linha de montagem, onde um time alimenta o outro. Neste modelo não há o tempo e a cerimônia do waterfall, os ciclos e iterações devem ser curtos e você não precisa se preocupar em entregar uma especificação 100% ok para o próximo da fila (analista -> proramador -> testes, etc) porque o que você vai desenvolver é só o necessário para aquela iteração.

This message was edited 1 time. Last update was at 29/12/2008 06:15:02

"

marcosalex wrote:
Sim, adaptado à realidade do desenvolvimento de software.

Mas modelo iterativo e incremental (com todas as suas variações) é para desenvolvimento de software.

marcosalex wrote:

Se o desenvolvedor já está no time provavelmente o relatório é uma user story separada e sim, ele pode ser paralelizado dentro do time se fizer sentido.

Exato, não consegui entender onde você discorda. No caso da fábrica, o time seria da fábrica. Lembre-se, claro , que sempre tem alguém de dentro do cliente acompanhando o projeto.

O que eu discordo é que (1)numa fábrica isso funciona e que (2)por serem atividades diferentes você pode adicionar pessoas num time para paralelizar tarefas livremente.

marcosalex wrote:

Quanto ao MVC, eu ainda não entendi como ele se encaixa nisso tudo.

Você não acha produtivo separar alguém cuidando da camada de apresentação enquanto outros cuidam das regras de negócios. E que as métricas pra avaliar cada uma das áreas costumam ser mais semelhantes entre si do que de camadas diferentes? Foi isso que eu quis dizer quando citei o MVC.

Bom, MVC não é sobre Camadas, mas ainda que fosse não é porque você tem Camadas diferentes que elas podem ser desenvolvidas por pessoas diferentes. O nível de acoplamento entre Camadas é grande demais, talvez você esteja se referindo à Componentes, que possuem contratos e interfaces bem-definidas.

marcosalex wrote:

As ferramentas (e, principalmente, as metodologias) de gerenciamento de projeto fazem isso há anos e não resolveram os problemas.

Podem não ter resolvido, mas conseguiram mensurá-lo e minimizaram. Um projeto complexo sem gerenciamento costuma atrasar muito, muito mais e sair muito mais fora do escopo. E pior de tudo, esse desvio não é dimensionado, deixando a empresa as cegas do quanto perdeu. A única coisa pior do que o projeto falhar, é não conseguir estimar o tamanho da falha.

Eu entendo seu ponto mas para mim isso é equivalente a dizer que alguém vai do Rio à São Paulo andando, mas vai de Nike. Por que não pegar um avião (cuja passagem custa menos que o tênis) em primeiro lugar?

marcosalex wrote:
Em algumas soluções pode até funcionar, ou mesmo em algumas partes do projeto, mas como você mesmo citou, ele não resolve tudo. Mais um motivo para ter um gerenciamento constante e trabalhar com baselines pra acompanhar. Várias metologias prevêem isso, como o tão citado Scrum, por exemplo.

Nada funciona em tudo mas a coisa não é como você falou. De qualquer forma, metdologias iterativas e incrementais, especialmente metodologias ágeis, possuem "gerenciamento constante" e baselines. Na verdade elas costumam ser bem rígidas com relação à como o processo é gerido.

O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido -ela, na verdade, foi criada para ser ineficiente e barata.

This message was edited 1 time. Last update was at 07/07/2008 23:26:55

marcosalex wrote:
Você não acha produtivo separar alguém cuidando da camada de apresentação enquanto outros cuidam das regras de negócios. E que as métricas pra avaliar cada uma das áreas costumam ser mais semelhantes entre si do que de camadas diferentes? Foi isso que eu quis dizer quando citei o MVC.

Marcos, desculpa a sinceridade, mas esse foi o maior absurdo que ouvi nesse fórum até hoje.

http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/

Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido. Kent Beck

This message was edited 1 time. Last update was at 29/12/2008 06:17:00

"

This message was edited 1 time. Last update was at 29/12/2008 06:17:24

"

marcosalex wrote:
Eu nunca disse livremente, mas onde for possível.
[...]
Entre Componentes é uma forma de identificar pontos que pode ter mais de um analista. Mas mesmo nas camadas você pode aproveitar mais de uma pessoa, dependendo do caso. Como eu disse antes, senão todo projeto teria um só analista do começo ao fim. Novamente, eu nunca disse que você pode aumentar o número de pessoas indefinidamente, mas em muitas situações, é sim possivel.

Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações. Existe um impacto muito grande em tirar ou colocar uma pessoa de um projeto, mesmo metodologias ágeis que pregam pair programming como XP tratam isso com extrema cautela e eu nunca vi ninguém recomendando -nem eu recomendo- colocar pessoas em projetos atrasados. Dificilmente o projeto está atrasado por falta de pessoal, geralmente o problema é mais embaixo, e se for por falta de essoal até estes se tornarem produtivos vai demandar muito tempo/custo.

E não confunda com "o mesmo analista do início ao fim", estamos conversando sobre a sua discórdia com Fred Brooks sobre acrescentar pessoas em projetos atrasados:

marcosalex wrote:

Jorge Diz wrote:
Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.

Depende do projeto e da alocação. Em algumas vezes sim, mas se existe capacidade de paralelismo ela pode ser explorada. Com projetos baseados em MVC e utilizando metodologias ágeis, muitos desses pontos são fáceis de identificar, mas a pessoa tem de saber gerenciar. Mais um motivo pra ter alguém de dentro pra acompanhar os terceiros (fábrica ou não).

Novamente eu recomendo a leitura do livro.

marcosalex wrote:
Achei engraçado seu exemplo mas não entendi. Você acha que acompanhar um projeto nunca vai ajudar a melhorar? É melhor deixar ele caminhando às cegas? Eu acredito que gerenciado você consegue identificar os gargalos mais rapidamente e tomar as ações necessárias antes que a coisa saia do controle. Na pior das hipóteses você vai poder avisar a diretoria com antecedência que o cronograma terá de ser revisto.

Eu não me lembro de ter falado em nenhum lugar ensta thread sobre não haver acompanhamento ou erenciamento. A analogia foi apenas para tentar mostrar que comprar uma ferramenta bonita e cara (o tênis ou uma ferramenta de gestão de projeto) não adianta.

Como eu já repeti aqui nesta thread algumas vezes isso de "avisar a diretoria" nunca acontece.

Primeiro porque o gerente confunde progresso com execução de tarefas e tenta medir o que não é mensurável. Se 90% das tarefas estão 90% concluídas então o projeto está quase que 90% concluído? Não. Gerenciamento de projeto de software não é matemática de primeiro grau, não adianta somar, dividir e multiplicar. Os 10% restantes podem ocupar 99% do tempo total do projeto e ninguém previu isso. No final o projeto chega no deadline em sei-lá-quantos-% pronto. 90% pronto não é pronto.

O outro problema é que ao primeiro sinal -sempre tarde demais- de que o projeto vai atrasar os gerentes de uma fábrica vão apertar seus funcionários para que trabalhem mais. Horas extras, sábados, feriados, baixar a qualidade do software... tudo o que for preciso para entregar. Entregar qualquer coisa, mas entregar algo.

Uma abordagem baseada em iterações possibilita prever o risco e traçar uma estratégia eficiente, porque se baseia em dados reais. Nossa velocidade é 5, temos duas iterações para acabar o projeto e 25 pontos. (1) Marque uma reunião com o cliente para priorizar quais dos 25 pontos restantes devem entrar nas duas últimas iterações (2) procure coisas simples que podem aumentar a velocidade e (3)em vez de um software 90% funcionando você entrega um software 100% funcionado com 90% do escopo implementado. Precisamos terminar? Bom, se a velocidade se mantiver precisamos de mais 3 iterações.

A coisa não é não gerenciar ou não acompanhar mas sim parar de seguir um anti-pattern chamado waterfall. Cronogramas completos, acompanhamento tarefa-a-tarefa... nada disso tem funcionado desde a época de Fred Brooks.

marcosalex wrote:

pcalcado wrote:
O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido - ela, na verdade, foi criada para ser ineficiente e barata.

Opinião não discuto

Engraçado, eu citei aqui alguns trabalhos -Mythical Man-month, CHAOS Report- estatísticos e acadêmicos. Será que é somente minha opinião?

E como adendo sobre componentes:
Comonentes podem tecnicamente ser implementados por times diferentes. Muitas vezes funciona. o problema é que para Componentes de Negócio isso é um mito. Novamente: é tecnicamente viável (assim como é viável fazer o mesmo sem componentes ou mesmo Camadas) mas qualquer caso de uso vai envolver mais de um componente e separar o mesmo caso de uso por pessoas distintas não é uma boa idéia.

marcosalex wrote:
Bom, se você acha que um trabalho de interfaces é mais comparável com quem trabalha na regra de negócios, ótimo. Sobre o artigo, ele vai muito em direção ao que falei: gerenciar o processo não é só caso de uso e uml, tem de ser gerenciado de perto analisando caso a caso as atividades. O que sai caro na grande maioria das vezes é deixar tudo andar com a maré.

Marcos,

Especializar papéis entre análise e programação já é sofrível. Fazer isso ao nível de camadas e tentar gerenciar essa dinâmica é uma aberração.

Pelas conversas que tivemos nesse fórum dá pra ver que você é bem fã da visão do PMBOK com relação ao gerenciamento de projetos (WBS, escopo detalhado, controle de tarefas e etc...). Atualmente tenho desenvolvido softwares para a área de engenharia (mecânica, elétrica e civil) e vejo que essa visão casa bem com esses tipos de projetos. São projetos que envolvem mais de 10 equipes e centenas de pessoas que muitas vezes não são profissionais do conhecimento (aka peão de obra). Outro ponto: esses projetos tem uma segurança com relação à sua previsibilidade. É um tipo de projeto que a soma das tarefas dá o resultado esperado.

Para projetos de software as tarefas não são importantes para o gerenciamento. O que é importante são os objetivos. São histórias implementadas e não tarefas cumpridas (como o pcalcado explicou). Nosso earned value cresce só com casos de uso funcionando. Escrever casos de uso, fazer modelos, fazer planos, codificar, testes não agregam valor. Como sempre digo, o escopo de um projeto de software é resolver problemas de negócios e não implementar requisitos. É um processo empírico.

This message was edited 1 time. Last update was at 29/12/2008 06:18:21

"

This message was edited 1 time. Last update was at 29/12/2008 06:18:52

"

marcosalex wrote:

pcalcado wrote:
Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações.

Nunca disse em muitas, mas "quando possível".

Sim, você disse que em muitas situações:

marcosalex wrote:
Eu nunca disse livremente, mas onde for possível.
[...]
Entre Componentes é uma forma de identificar pontos que pode ter mais de um analista. Mas mesmo nas camadas você pode aproveitar mais de uma pessoa, dependendo do caso. Como eu disse antes, senão todo projeto teria um só analista do começo ao fim. Novamente, eu nunca disse que você pode aumentar o número de pessoas indefinidamente, mas em muitas situações, é sim possivel.

marcosalex wrote:
Isso é fato em projetos de software e qualquer gerenciamento sabe disso. Eu tomaria cuidado com a palavra "sempre" porque se foi verdade na maioria das vezes, já deixou de ter faz um bom tempo. As métricas atuais tratam esse tipo de caso, basta saber usar. Isso vale tanto para fábricas de software quanto para outras empresas (de softwares ou similar).

O CHAOS Report discorda de você. Pode ser sua opinião mas dadas as estatísticas tanto do relatório quanto das pessoas que postaram nesta thread eu creio que voc6e está enganado.

marcosalex wrote:Você está analisando o pior caso. Será que a maioria dos gerentes de software ainda pensam assim? A grande maioria não, a realidade tem mudado bastante. Novamente eu tomaria cuidado com a palavra "sempre" e generalizações.

Novamente: confira as estatísticas antes de falar em maioria.

marcosalex wrote:
Todos os trabalhos citados falam de uma abordagem comum para todos os projetos, a famosa "receita de bolo para o sucesso". Gerenciamento nunca foi isso. E nesses trabalhos eles mesmo citam que não estão falando para não usar as metolodias, mas para não adotá-las como regra geral, eu concordo com isso. Gerenciamento é saber quando, onde e em que ponto usar. NESSE PONTO, fábricas de software podem ter um sucesso maior.

Nenhum dos trabalhos citados ala sobre receita de bolo ou sequer descreve metodologias. Antes de criticar algo é sempre bom saber do que se trata.

marcosalex wrote:Gerenciamento é saber quando, onde e em que ponto usar. NESSE PONTO, fábricas de software podem ter um sucesso maior.

Cite apenas um exemplo real de uma empresa conceituada que conseguiu isso dessa maneira que vc descreve tanto nessa thread!

Agora se quiser exemplos de empresas que não conseguem, podemos fazer uma lista aqui de pelo menos 10 páginas.

Parece que vc esta se esforçando para "vender" um brinquedo quebrado, que todos estão carecas de saber que não da certo, que não funciona, o Phillip cansa de citar autores e mais autores mostrando isso, relatos e mais relatos comprovando a grande porcaria que é trabalhar dessa maneira, mas como sempre, continuam tentando meter isso goela abaixo, vendendo idéias falidas há vários anos, tentando achar meios de justificar os erros para fazer acreditar que se tivesse sido feito corretamente, funcionaria.
Desculpe, mas estamos em 2008, acho pouco provável alguém (que seja do meio, geralmente o cliente não é) ver os fatos, analisar o cenário (como toda hora alguém faz mostrando dados, autores e etc) ainda dar crédito a toda essa maneira fálida de se pensar em software.

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