Acho que ter um programador que não sabe se comunicar com pessoas da sua área ou não é uma das coisas mais nocivas que pode existir em uma equipe.
emerleite,
Só não estou de acordo porquê sei que cada um de nós tem limitações diferentes, então é natural que surjam “especializações” …
[quote=agodinhost]emerleite,
Só não estou de acordo porquê sei que cada um de nós tem limitações diferentes, então é natural que surjam “especializações” …[/quote]
Sim, cada um pode ser melhor que outros em determinados aspectos, mas, saiba que especialização pelo próprio termo é algo que não se aplica a atividades criativas. Dá uma olhada nisso:
O problema mais comum da especialização na nossa área é que se temos na equipe gente só preocupada com levantamento do negócio, gente só preocupada em programar e gente só preocupada em testar é capaz que não tenha ninguém preocupado em entregar o projeto. A soma das tarefas desempenhadas por cada especialista não produz necessariamente software funcionando.
Já ouviu um tester deixar escapar um erro e falar: “-Ahhh… não tava no caso de uso…” ou um codificador falar “-Isso é responsabilidade do analista de negócios…”. Pois é… se isso acontece na minha equipe da primeira vez eu explico… na segunda é uma advertência. Na terceira é rua.
Respeito aquilo em que cada um é melhor. Porém, vejo uma equipe de desenvolvimento de software como um coeso grupo de programadores. Todos eles devem ser bons em teste. Alguns podem ser muito bons em arquitetura e a maioria são bons em conversar com o cliente. Alguns podem ser capazes de analisar o negócio, porém, estes mesmos sentam a bunda na cadeira e programam. A equipe gerencia a distribuição das tarefas e não o papel.
O sonho de uma fábrica de software é fazer esse anti-pattern que citei no blog funcionar, infelizmente (ou felizmente) eles falham miseravelmente.
IMO o maior problema é fazer com quê cada um no grupo saia da sua zona de conforto pra se arriscar em outras atividades. Nosso gás vai acabando com o passar dos anos e até os mais velhos se acomodam.
Concordo, porém, algumas equipes que treinei eles tentaram praticar o multi-funcional e tiveram sucesso. Muitos testers começaram a programar como exemplo. Porém, quando os analistas de negócio viram que eles teriam que trabalhar de verdade muitos decidiram ir embora. :?
O problema são as pessoas entenderem que desenvolver software é um trabalho criativo.
[quote=rodrigoy]Porém, quando os analistas de negócio viram que eles teriam que trabalhar de verdade muitos decidiram ir embora. :? [/quote]Rodrigo, ví isso acontecendo em diversas posições: desenvolvedor que achou que seria mais fácil, analista que achou que não ia por a mão na massa, dentre os principais. Me considero sortudo quando essa galera vai embora de livre e espontânea vontade (na maior parte das vezes eles ficam mas fazem um trabalho tão medíocre que, deixa pra lá …). Acredito que boa parte disso seja acomodação natural do ser humano mas boa parte (diria 50%) é por incapacitação gerencial. Da mesma forma que os bancos (em um grau muito, muito menor) a área de TI sofre com os gerentes que tem, que ou são muito bons técnicamente e péssimos gerentes ou são “bons” gerencialmente e péssimos técnicamente.
emerleite, concordo, desenvolvimento de software é um processo criativo, contudo - no capitalismo, ele é apenas um meio de produção e, como tal, deve dar lucro. A cada dia que passa o espaço pra criatividade em desenvolvimento cede espaço para o processo. Não leve a mal - eu gosto de processo, mas o “processo” sempre bota um rótulo à frente de cada atividade que acaba “stressando” ou “podando” o processo criativo. IMO, contudo, nem toda atividade em desenvolvimento é realmente parte desse processo criativo, um cadastro de cliente por exemplo, 8 horas (16 com teste de unidade), um relatório de vendas? O máximo de espaço que nos sobra pra criatividade aqui é a escolha das ferramentas (Jasper/iReport? Crystal?)
Considerar cadastro como meta não é nada criativo mesmo. É o tipo de infraestrutura já pronta! :twisted:
Saber escolher a ferramenta sim é importante! Porque os problemas são sempre diferentes… até mesmo cadastros.
[quote=cmoscoso]Considerar cadastro como meta não é nada criativo mesmo. É o tipo de infraestrutura já pronta! :twisted: [/quote]Não estou me limitando a custodiais cara, foi só um exemplo.
[b]Analistas X Programadores
[color=darkred]Por Ulysses Monteiro Duarte[/color][/b]
Qualquer um que vive na área já deve ter visto o clássico ciclo de vida do desenvolvimento de sistemas. Salvo pequenas variações para cada modelo ou peculiaridades de cada projeto, o tal ciclo seria composto do estudo de viabilidade, análise, modelagem, implementação e implantação. Há quem considere a fase de testes uma fase independente, o que não faz grande diferença prática.
Se não há grandes divergências quanto ao ciclo em si, o caro leitor já deve estar curioso para saber do que trata este texto ou está tentado a abandonar a leitura por aqui. Antes que isto ocorra, esclareço: o objeto deste texto é a causa da briga entre analistas e programadores: o tamanho e importância das fases. São basicamente quatro perguntas :
Quando começar a implementação, ou seja a codificar ?
Pode a implementação concorrer no tempo com a análise ?
E com a modelagem ?
Quando termina a fase de modelagem ?
A mesma pessoa que fez a análise pode fazer a codificação ?
Os puristas
Para os engenheiros de software puristas clássicos, a alma do sistema está definida na fase de análise e o corpo na fase de modelagem. A implementação não envolve grande inteligência, é como se o sistema já estivesse pronto e a implementação fosse apenas o girar do interruptor para a posição ON. Por mais que esteja crescendo, este grupo ainda é bem pequeno, a grande maioria dos sistemas desenvolvidos já são iniciados pelo código, documentação são alguns comentários esparsos pelos fontes e análise é o conjunto de rabiscos em que resultou a reunião da equipe. O analista purista domina as ferramentas CASE, metodologias, mas normalmente não se aventura a escrever uma linha de código sequer.
Visual Drag and Drop
Há alguns anos desenvolvimento de sistemas era uma coisa absolutamente desconhecida, atividade restrita a um seleto grupo de gênios, nerds ou malucos, simplesmente. A maioria das ferramentas de desenvolvimento era interpretada ou levava horas para compilar um programa de tamanho médio. Ainda no início dos anos 90 era comum os desenvolvedores compilarem seus programas durante toda a noite, para fazer os testes no dia seguinte. Com toda esta limitação técnica, era fundamental um mínimo de análise e teste antes de ser digitada a primeira linha de código, pois um simples erro de sintaxe poderia custar um dia inteiro de trabalho.
Hoje os tempos são outros, ao mesmo tempo que as máquinas evoluíram a ponto de diminuir a importância de parte da atividade pré- codificação, como o famoso teste de mesa, as ferramentas de desenvolvimentos evoluíram para interfaces visuais e amigáveis. O resultado é que quase todo mundo hoje é capaz de desenvolver sistemas. Esses dois fatores combinados resulta numa desvalorização da fase de análise.
Uma pessoa é capaz de criar algo funcional usando algo como o Visual Basic, sem sequer imaginar o que seja objeto, classe, método ou mensagem. Mas não só os leigos são adeptos do Visual Drag and Drop, Just do it, muitos bons profissionais da área abandonaram grande parte do seu conhecimento teórico e também adotaram a metodologia Just in Time de desenvolvimento. Toda esta gente é tecnicamente um programador de sistemas, surge até o que tem-se chamado de Analista Programador, na verdade um programador com salário mais alto.
O Confronto
Tudo correria bem, cada grupo e suas convicções trabalhariam tranqüilamente, se não houvesse o encontro na mesma esquipe de membros dos dois grupos. Tudo transcorre bem no início, nas fases de estudo de viabilidade e de requisitos. As divergências aparecem quando a fase de projeto começa a se alongar e os programadores começam a ficar ansiosos para codificar. Normalmente o que se faz é buscar tarefas periféricas para ir distraindo o programador até que os analistas consigam adiantar o projeto até um ponto satisfatório.
Os argumentos
Tanto analistas clássicos, quanto os programadores têm argumentação forte para defender seu ponto de vista.
O analista:
No desenvolvimento sem análise, gasta-se cerca de 80% do tempo refazendo código e corrigindo bugs. A troca de um membro da equipe é muito mais traumática.
O programador:
O cliente paga pelo programa rodando, pelo código. ë muito mais complicado justificar o tempo gasta, sem código para ser mostrado. A análise não interessa para o cliente.
De fato ambos os argumentos são pertinentes, de modo que não há como definir de que lado está a razão. A grande questão é como administrar e tirar o máximo proveito de uma equipe mista.
Boa convivência
Deixando de lado o radicalismo, há sempre uma forma de ter analistas e programadores em harmonia, fazendo com que as diferenças contribuam para o engrandecimento do grupo como um todo. Como fazer isto? A resposta passa pelas quatro questões iniciais:
Quando começar a implementação, ou seja a codificar ?
Cada um tem de atuar onde é mais forte. Não adianta muito forçar um programador a fazer análise. Logo, até que haja código a ser escrito, os programadores estarão subaproveitados. Uma boa análise certamente decomporá o sistema em módulos com funcionalidade própria. Alguns módulos podem ser definidos quase que totalmente logo no início do projeto. Um exemplo usual é a comunicação como banco de dados, mas há diversas outras possibilidades. Numa equipe onde a utilização de recursos é otimizada, esses módulos serão projetados o quanto antes e ,enquanto são projetados os demais módulos, os programadores já estarão trabalhando na codificação dos módulos iniciais.
Pode a implementação concorrer no tempo com a análise ?
E com a modelagem ?
Não há nada que impeça que os programadores estejam codificando um módulo, enquanto os analistas sequer analisaram um outro módulo. Fazendo a analogia com as clássicas árvores de busca, basta que o desenvolvimento seja feito, pelo menos em parte, em profundidade e não em largura , como os analistas tendem a pensar de início.
Quando termina a fase de modelagem ?
Há uma máxima na computação que diz que um sistema jamais estará realmente finalizado, sempre há o que alterar, corrigir ou melhorar. Um erro que muitos de nós cometemos é não manter a sincronização entre a análise, o modelo e a implementação. Muitas vezes é tão prático corrigir um bug ou fazer uma alteração, que sequer passa-nos pela cabeça voltarmos ao modelo. Quando estamos utilizando ao máximo os recursos que dispomos, o modelo está ao lado da implementação e , ao contrário do que possa parecer, o trabalho dos analistas não terminará antes que o dos programadores.
Quando termina a fase de modelagem ?
Esta é a pergunta mais fácil de responder: NUNCA. Se um sistema jamais está pronto e se o projeto deve estar sincronizado com a implementação, o projeto, da mesma forma, jamais estará concluído.
A mesma pessoa que fez a análise pode fazer a codificação ?
Até pode, mas será que estaremos tirando o máximo dos recursos disponíveis? Evidentemente que não. Pelé era um bom goleiro, chegou até a atuar nesta posição algumas vezes, por quê então ele não jogava metade do tempo no gol e outra metade como ponta de lança ?
Equipe nota Dez
[color=red]Para montar uma equipe vencedora não basta ter somente elementos vencedores. É necessário que cada elemento esteja atuando no máximo de sua capacidade e maior tempo possível. Os defensores, defendem e os atacantes, atacam. Com idéias simples podemos garantir a máxima produtividade de nossa equipe e, de quebra, contar com elementos satisfeitos, fazendo aquilo que gostam.[/color]
[color=darkred]Mergulhe no assunto [/color]
Bowles, Joseph E. : Foundation Analysis and Design - Ed. Mcgraw Hill
Yourdon, Edward : Modern Structured Analysis ? Ed. Pearson
Booch, Grady : Object-Oriented Analysis and Design With Applications - Addison-Wesley Pub
Rumbaugh, James: Object-Oriented Modeling and Design - Prentice Hall
Jalote, Pankaj : CMM in Practice: Processes for Executing Software Projects at Infosys - Addison-Wesley Pub
[color=red] Para pensar[/color]
Afinal quando será desligado o último mainframe ?
Eu trabalhei em uma empresa pequena que tinha dois sócios, um deles era tecnicamente excelente, o outro era muito bom nos relacionamentos com os clientes e parceiros… só o último ia nas reuniões, e funcionava bem assim…
E não há?! Sérgio, eu não sei quando foi escrito esse texto, mas lhe garanto que em 1970 já havia grandes divergências sobre o ciclo em si. Diria para seguir a dica mais simples e abandonar a leitura por ali.
Senão, podes ler até o fim. Mas depois não deixe de ler aqui, isto e isto (no mínimo, no mínimo), o que certamente te fará pensar que, quem quer que seja que escreveu esse texto, nunca escreveu um software.