Programar em equipa - como é isso?

Kayvlim

Kayvlim

Moderating from /home
Staff
Boas!

Tenho já esta dúvida há bastante tempo (mais ou menos desde que comecei a aprender a programar). Até agora, para mim, a programação não tem passado de um acto "individual", em que sou eu que penso no que quero fazer, depois penso em como fazer, e, finalmente, faço.
Mas grandes projectos são normalmente feitos por várias pessoas, especialmente em empresas.

O que me tenho perguntado é... como é que se organizam várias pessoas de modo a que todos consigam fazer um programa em "harmonia"? O que é que é geralmente atribuído a cada pessoa? É que no meu caso, acho difícil conseguir juntar-me a outra pessoa, e fazermos os dois alguma coisa funcional. E como é que duas pessoas diferentes escrevem no mesmo código? Cada pessoa mexe apenas num módulo, por exemplo?
(vale a pena dizer que eu costumo testar o programa muito frequentemente... normalmente testo-o a cada modificação que faço, porque ajuda logo a pôr de lado quaisquer side effects inesperados).

Não me consigo explicar melhor, mas acho que a ideia está cá. Como é que se organiza uma equipa para trabalhar num mesmo projecto, e o que é que geralmente cada programador faz?

Cumprimentos,
angelofwisdom
 
Depende.

A divisão de trabalho pode ser feita como quiseres. Há diversas técnicas de desenvolvimento em equipa, sendo uma delas bastante falada actualmente, que é o extreme programing, ou Xp, que possui diversas características próprias: http://en.wikipedia.org/wiki/Extreme_programing.

Para controlar o trabalho, considerando as inúmeras ferramentas que são postas ao nosso dispôr acaba por se tornar fácil. Para controlar mesmo o código, podes sempre recorrer ao CVS (http://en.wikipedia.org/wiki/Concurrent_Versions_System) ou ao SVN (http://en.wikipedia.org/wiki/Subversion_(software)).

Para troca de ideias ou feedback podes usar algo mais requintado que o email e teres um fórum ou um wiki, para gestão da documentação e desenvolvimento do projecto (sempre com acessos privados para não andar quem está de fora a cheirar, e com controlo de inscrições).

No mundo actual em que há várias coisas feitas em cooperação, o trabalho em equipa torna-se essencial para um rápido desenvolvimento dos produtos que os clientes pedem. E tem a noção que trabalhar em grupo não implica, como se faz muitas vezes, estar a trabalhar no mesmo espaço que o colega. Isso pode acontecer, mas também pode não acontecer e não é desculpa para um mau desenvolvimento (olha o caso do Linux, por exemplo).

Mesmo para os projectos da faculdade, tentei sempre controlar isto e tentar manter o máximo de independência entre os elementos dos diversos grupos com os quais trabalhei. Sem manter o controlo do desenvolvimento (troca de feedback por email, feedback constante sobre o desenvolvimento em fóruns ou wikis criados para o efeito e inclusão de changelogs sempre no CVS/SVN). Até porque a vida pessoal de cada um acaba por nem sempre ser compatível por causa de diversos factores. E não é por isso que se vai deixar de fazer o projecto.

De qualquer maneira, há por exemplo no caso do extreme programming um ponto em que se refere a vantagem de ter duas ou três (e não mais para não atrasar o desenvolvimento) pessoas a trabalhar no mesmo código. Isto é, uma a programar, outra a ver e depois com rotação de funções ao fim de um tempo. Isto porquê? Porque porque quando se está a "bater código" há sempre pormenores que falham, coisas que podem ir desde um ponto e vírgula, passando por uma variável mal declarada, podendo acabar num algoritmo completamente desajustado. As duas pessoas servem para minimizar o número de erros a este nível e até porque, quem programa sabe, às vezes quando se tem um erro e se está a tentar explicá-lo ao colega, acabamos por perceber a falha na implementação :D

Bem espero que o texto não tenha sido muito longo e que tenham pachorra para o ler ;)
 
A resposta à tua pergunta é simples. A execução nem sempre é fácil e muitas pessoas, por diversas razões, não são capazes.

Não há nenhum segredo, mas o "segredo" está no imenso trabalho que é feito antes de se passar à implementação de um projecto. Há muito para fazer, desde análise de requisitos até à definição das especificações. É importante definir o que é que faz o quê e quem é que faz o quê e quando. Espero que esta frase se perceba.

Por exemplo imagina que te era atribuído um bocado de um projecto que consistia na implementação de uma função. Parece simples. Agora imagina que essa função vai ser utilizada por diversas equipas espalhadas pelo mundo. Tu não podes começar a fazer a coisa à tua maneira, mesmo que esteja correcta. É preciso que haja uma espécie de contrato. Nesse contrato é definido que a função faz pipocas, recebe batatas e devolve alhos. A implementação pode não ser importante, mas o contrato tem de ser respeitado.

Todo este trabalho leva uma vida para aperfeiçoar e não se aprende de um dia para o outro.
 
E também importante está a divisão de tarefas. Usar o modelo MVC é meio caminho andando para poder separar as tarefas. É por exemplo o modelo aplicado na empresa onde estou.
Existe uma equipa para os objectos (que tratam da base de dados e de criar as apis para acesso aos dados) e uma equipa para o modelo e controlo. Depois dentro de cada equipa existe um trabalho colaborativo, onde cada um é responsavél por algo mais pequeno que o todo, seguindo guidelines especificadas anteriormente. Desta forma podes separar facilmente o trabalho entre várias pessoas.
 
oscarolim disse:
E também importante está a divisão de tarefas. Usar o modelo MVC é meio caminho andando para poder separar as tarefas. É por exemplo o modelo aplicado na empresa onde estou.
Existe uma equipa para os objectos (que tratam da base de dados e de criar as apis para acesso aos dados) e uma equipa para o modelo e controlo. Depois dentro de cada equipa existe um trabalho colaborativo, onde cada um é responsavél por algo mais pequeno que o todo, seguindo guidelines especificadas anteriormente. Desta forma podes separar facilmente o trabalho entre várias pessoas.
Clicar para expandir...

O MVC já é uma arquitectura de desenvolvimento. Não tem bem a ver com programar em equipa, porque nem todos os projectos precisam de obedecer ao MVC. De qualquer maneira fizeste bem em referir porque em projectos que suportem essas três camadas, para além de modularizar o desenvolvimento e a aplicação, também facilita a divisão de responsabilidades.

Claro que também podíamos começar para aqui a falar de modelos de desenvolvimento, mas não está directamente relacionado com o tópico. Enquadra-se, mas ...
 
Boas!

Antes de mais, muito boa thread! As respostas a esta questão fazem falta a muita gente!

@tópico, quando comecei a trabalhar em grupo (a sério) foi durante um estágio na Somague TI, até lá os meus trabalhos em grupo (secundário) resumiam-se a programar ao lado de outra pessoa que ia mandando uns bitaites úteis. Durante esse estágio tive de desenvolver alguns sites em ASP em equipa, lá o pessoal usava o FrontPage e isso nunca se adequou às minhas necessidades, como tal comecei a usar uma ferramenta da M$, o InterDev, não sei como funciona a ferramenta, mas estava sempre a actualizar num servidor central as páginas, não tinhamos de submeter nada, não tinhamos de nos preocupar com nada. E acho que tinha historial. O nosso rendimento (2 estagiários) aumentou de uma forma brutal, e posso afirmar que foi a única vez que trabalhei realmente em grupo, divisão de tarefas controlada e adequada.

Sobre algo numa perspectiva mais actual, sem qualquer sombra de dúvidas ferramentas tipo SVN, e claro, uma boa organização nas tarefas, tanto pode ser em módulos, como apenas em pequenas funções, mas usar uma ferramenta sem nos sabermos organizar é como conduzir um ferrari quando só se andou de burro...

Sem a possibilidade de usar estas ferramentas, a sugestão da boa organização altera-se..., terá de ser uma excelente organização :P

HecKel
 
Se tiveres a trabalhar numa empresa como programador de certeza que existe alguem que "desenhou" a aplicação que distribui algumas tarefas, normalmente cada programador faz uma série de módulos associados a uma funcionalidade.

Essencial é usar o CVS ou o Sourcesafe.

Numa empresa tens várias equipas... equipa de design que faz jpgs com o aspecto da aplicação, equipa de integração que normalmente faz o HTML, CSS e Flash numa aplicação web e a equipa de desenvolvimento que pega nisso, pensa na solução e passa aquilo tudo para conteúdo dinâmico, lógicas de negócio e por ai até chegares à base de dados.

Uma equipa de desenvolvimento ainda está dividida por programadores, arquitectos de software, gestores de projecto e por ai.

Os nomes dos cargos e isso tudo depende das empresas, mas a organização tem de ser assim pra funcionar bem.

É sempre trabalho em equipa. Um bom ambiente é essencial, existem projectos com duração de 2, 3 meses até 1 ano ou mais.
 
Última edição:
Boas.

Como já foi dito existem vários tipos de desenvolvimento de aplicações em equipa mas a parte importante é a de existir sempre documentação de tudo. Esta é uma aprte fundamental dado que os outros elementos quando pegam no código basta dar uma vista de olhos nos esquemas e apontamentos que se têm para se perceber.
Eu já programei aos pares e digo-te que foi um método que apreciei muito e deu-me bastante gozo pois tudo o que o meu amigo fazia eu estava atento e percebia e quando chegava a uma parte que ele não sabia como fazer e eu tinha as ideias de como fazer agarrava no código e desenvolvia eu e vice-versa. Atenção que éramos os dois programadores quase ao mesmo nível. Isto de um ser bom e o outro não perceber nada não dá resultado. Têm que se equilibrar +/- o nível dos dois.
Esta é uma parte divertida o único problema é que têm que andar sempre os dois juntos no trabalho. Por vezes pode-se tornar um incómodo e daí existir a Extreme Programming em que basicamente um programador desenvolve durante 8 horas seguidas. Acabadas ele descansa e o outro agarra no código e mais 8 horas de trabalho e claro tudo sempre bem documentado senão ninguém sabia em que ponto estava.

Espero ter ajudado a terem uma visão elhor da programação em equipa.

Cumps
 
Obrigado a todos! Sinceramente, gostei mesmo de todas as respostas! (que, para além do conteúdo, tinham algo que tem sido cada vez mais raro de se ver por cá - poucos smileys, nenhum pitês e (quase?) nenhuma abreviatura. Tudo em bom português. Vantagens de falarmos em programação...)

HecKel disse:
(...) os meus trabalhos em grupo (secundário) resumiam-se a programar ao lado de outra pessoa que ia mandando uns bitaites úteis. (...)
Clicar para expandir...
Exactamente! A diferença é que os trabalhos de grupo eram apenas projectos pseudo-revolucionários que eu e o meu irmão fazíamos. No entanto, já nessa altura (tinha eu 12 e ele 16 anos) não nos compreendíamos, e advém daí a minha questão. Nunca soube bem como é que se organizavam equipas inteiras para trabalhar num mesmo projecto - como uma distribuição do Linux.

Já tinha consciência de que organizar uma equipa era complicado, mas não era de forma alguma disto que estava à espera. Não imaginava que existiam modelos para isto.

Quando me referia a programar em equipa, refiro-me a mexer no código propriamente dito. É natural que o design esteja a cargo de outras pessoas mais qualificadas, uma vez que é difícil ser-se um programador profissional e um designer profissional ao mesmo tempo, e é profissionalismo em tudo que se quer, em grandes projectos :)

Tentando resumir um pouco, para se organizar uma equipa é necessário recorrer a ferramentas (como o CVS ou o SVN ou o SourceSafe), e tácticas como o Extreme Programming?
Penso que a documentação é essencial em qualquer tipo de projecto. Não numa de "programar em equipa" mas mais numa de manter organizadas as funcionalidades/modificações/to do's/etc.

Já vi o Microsoft InterDev, mas não simpatizei lá muito com aquilo. Talvez porque não sabia para que é que servia, mas apenas o usei para editar páginas HTML, em tempos idos :x

Dentro do tópico, uma pergunta na mesma "onda": no caso de projectos Open Source, como é que se organizam as modificações aos códigos? Não é uma pessoa qualquer que chega ao código e altera-o, com certeza. Para além da possibilidade de vandalismo, não havia nenhum tipo de "centralização" de modificações ou organização.
Diz-se que projectos como o Linux derivam do trabalho de programadores de todo o mundo, e pelos vistos "qualquer um pode contribuir", mas como? Também é algo que ainda não compreendi, e integra-se no trabalho de equipa.
*
Voltando atrás, continuo com uma dúvida... podem existir duas ou três pessoas a editar o mesmo código ao mesmo tempo? Ou cada um pega no código e continua-o a partir do ponto onde alguém o deixou?


Mais uma vez, um grande Obrigado pelas respostas!
 
ha alguem que gere, que aceita ou não a alteração, isso a um nivel basico

alem disso quando fazem um update por cvs ou similar, não apagam as versões antigas, deve ficar tudo num servidor, pc proprio apenas ao alcance de poucos, os que gerem o projecto.
 
angelofwisdom:

nenhum dos conceitos que se falou aqui é obrigatório para se trabalhar em equipa. Há pessoal que consegue trabalhar bem sem recorrer a nada disto.
Isto são apenas best-practices que simplificam bastante o trabalho em equipa. Sinceramente, acho que a utilização de algumas destas ajuda bastante não só no próprio desenvolvimento, como também a manter o tracking da organização que foi feita e do processo de desenvolvimento.

Em relação ao open-sourcing, é óbvio que qualquer pessoa pode fazer uma alteração ao código, mas esse código é sempre submetido a apreciação por parte dos gestores dos projectos e talvez mesmo acima disso.

Por exemplo o caso do elemento mais crítico do linux, o Kernel, o código é visto pelo responsável pela parte do kernel que foi alterado, depois pelo maintainer da tree e caso seja necessário muitas vezes pelo próprio Linus. E antes disso, quem deseja fazer alterações acho que aínda tem de indicar o porquê de querer fazer alterações em determinado código.

Esta hierarquização permite que tudo funcione sem sobressaltos de maior, uma vez que num projecto em que qualquer pessoa pode ter uma contribuíção, é necessário um controlo apertado do que é incluído.
 
xtr3me disse:
angelofwisdom:

nenhum dos conceitos que se falou aqui é obrigatório para se trabalhar em equipa. Há pessoal que consegue trabalhar bem sem recorrer a nada disto.
Clicar para expandir...
Pois, o uso do termo "necessário" da minha parte foi um pouco exagerado, já que as coisas já se faziam antes desses sistemas existirem. Mas acabaste por responder ao que eu queria perguntar:

xtr3me disse:
Isto são apenas best-practices que simplificam bastante o trabalho em equipa. Sinceramente, acho que a utilização de algumas destas ajuda bastante não só no próprio desenvolvimento, como também a manter o tracking da organização que foi feita e do processo de desenvolvimento.
Clicar para expandir...
Mas pondo de parte as ferramentas em si e pegando no que elas fazem... o essencial neste caso é manter uma "cópia" de cada alteração dos ficheiros e registar o seu motivo? (ainda não vi bem como trabalha aquilo tudo. É muito :x )

xtr3me disse:
Em relação ao open-sourcing, é óbvio que qualquer pessoa pode fazer uma alteração ao código, mas esse código é sempre submetido a apreciação por parte dos gestores dos projectos e talvez mesmo acima disso.

Por exemplo o caso do elemento mais crítico do linux, o Kernel, o código é visto pelo responsável pela parte do kernel que foi alterado, depois pelo maintainer da tree e caso seja necessário muitas vezes pelo próprio Linus. E antes disso, quem deseja fazer alterações acho que aínda tem de indicar o porquê de querer fazer alterações em determinado código.

Esta hierarquização permite que tudo funcione sem sobressaltos de maior, uma vez que num projecto em que qualquer pessoa pode ter uma contribuíção, é necessário um controlo apertado do que é incluído.
Clicar para expandir...

Era isso que tinha em mente. Portanto, todos podem mexer no código, mas ninguém pode tocar no principal - as alterações são "moderadas" e justificadas. Suponho que sejam os tais "core developers" que alteram o source principal após uma modificação ser aceite.
 
angelofwisdom disse:
Pois, o uso do termo "necessário" da minha parte foi um pouco exagerado, já que as coisas já se faziam antes desses sistemas existirem. Mas acabaste por responder ao que eu queria perguntar:


Mas pondo de parte as ferramentas em si e pegando no que elas fazem... o essencial neste caso é manter uma "cópia" de cada alteração dos ficheiros e registar o seu motivo? (ainda não vi bem como trabalha aquilo tudo. É muito :x )
Clicar para expandir...

O essencial de programar em equipa é conseguir coordenar o desenvolvimento concorrente. Por isso é que ferramentas como o CVS/SVN ou outro sistema de controlo de versões dão muito jeito. Há quem faça isso pelo mail e com cópias locais, mas é o caos total.

Depois outra coisa essencial é a comunicação. É necessário que toda a equipa saiba em que ponto está o desenvolvimento e como está cada um dos developers. Isto facilita também o esclarecimento de dúvidas, a definição de standards (caso se trabalhe com entidades comuns, o que é perfeitamente normal) e também uma pseudo-documentação do desenvolvimento.

O que nos leva ao terceiro ponto, a gestão da documetação, que muitas vezes é essencial, não só para explicar o que está feito a pessoas que não são developers (elementos do negócio, se estivermos a falar de uma empresa, ou clientes se estivermos a falar de um projecto "pessoal").
É que é importante que os informáticos não se esqueçam que nem toda a gente fala a linguagem técnica.

Isto aínda é um dos problemas em portugal. As empresas não se preocupam em uniformizar a linguagem que usam, em termos do negócio e depois acabam por surgir conceitos reduntantes (por exemplo, o departamento de TI, o departamento de Gestão, o departamento de RH todos conhecem a entidade cliente, mas se perguntares a cada um, todos te dizem definições e características diferentes para a mesma entidade). É por causa disto que acontece por exemplo que muitas empresas têm problemas com a consistência dos dados, tendo muitas vezes a mesma pessoa moradas diferentes, etc. Isto porque a entidade não é única, mas sim está replicada em vários sistemas.

Mas isto já é mais um problema de integração de aplicações e de consistência da informação. Sorry pelo ligeiro desvio :P


angelofwisdom disse:
Era isso que tinha em mente. Portanto, todos podem mexer no código, mas ninguém pode tocar no principal - as alterações são "moderadas" e justificadas. Suponho que sejam os tais "core developers" que alteram o source principal após uma modificação ser aceite.
Clicar para expandir...

Sim, claro. No código "oficial" released, só algumas pessoas é que mexem. Senão era o caos total :D
 
Trabalhar sem um CVS ou Sourcesafe é o caos total, é impressionante como atrasa tudo e todos!! Em projectos de maior envergadura é impossivel trabalhar sem um repositório de ficheiros/versões centralizado onde todos podem aceder, quando editas num ficheiro é feito um lock ao mesmo e só tu podes mexer.

Trabalhar sem documentação técnica é igualmente o caos total, um gajo fica perdido.
 
john disse:
Trabalhar sem um CVS ou Sourcesafe é o caos total, é impressionante como atrasa tudo e todos!! Em projectos de maior envergadura é impossivel trabalhar sem um repositório de ficheiros/versões centralizado onde todos podem aceder, quando editas num ficheiro é feito um lock ao mesmo e só tu podes mexer.

Trabalhar sem documentação técnica é igualmente o caos total, um gajo fica perdido.
Clicar para expandir...

Mas quem é que edita ficheiros directamente do CVS?

Trabalhas sempre na sandbox local e só quando queres fazer release da versão é que fazes commit para o cvs.

Não?
 
xtr3me disse:
Mas quem é que edita ficheiros directamente do CVS?

Trabalhas sempre na sandbox local e só quando queres fazer release da versão é que fazes commit para o cvs.

Não?
Clicar para expandir...

Não te estou a perceber, mas eu disse que não era assim ???? Onde é que disse que editavas directamente do CVS ???

Eu disse que quando fazes edit, só tu podes mexer e só quando fazes check in claro que só ai é que ele vai para lá, obviamente que tens uma cópia local... todos a trabalhar directamente no servidor havia de ser bonito....
 
john disse:
Não te estou a perceber, mas eu disse que não era assim ???? Onde é que disse que editavas directamente do CVS ???

Eu disse que quando fazes edit, só tu podes mexer e só quando fazes check in claro que só ai é que ele vai para lá, obviamente que tens uma cópia local... todos a trabalhar directamente no servidor havia de ser bonito....
Clicar para expandir...

Não, não. Eu sei que não disseste que era assim, só que pelo problema que puseste pensei que estavas a sobre isso.

É que estás enganado. Qualquer um pode mexer no ficheiro. Nunca tive problemas de permissões por editar seja que ficheiro fosse do CVS.

Já tiveste problemas com isso?
 
Imagina que estamos a trabalhar no mesmo projecto, fazemos get do projecto do servidor e se eu na minha máquina fizer check out ao ficheiro xpto.cs, se tu na tua tentares fazer o mesmo vai dizer que o utilizador "john" está a mexer lá. Só quando faço check in da nova versão é que tu podes ir fazer check out.
 
john disse:
Imagina que estamos a trabalhar no mesmo projecto, fazemos get do projecto do servidor e se eu na minha máquina fizer check out ao ficheiro xpto.cs, se tu na tua tentares fazer o mesmo vai dizer que o utilizador "john" está a mexer lá. Só quando faço check in da nova versão é que tu podes ir fazer check out.
Clicar para expandir...

Nunca me aconteceu tal coisa. Já por diversas vezes fiz check-out a seguir a colegas meus terem feito (e vice versa) e que me lembre, nunca tive problemas.

De qualquer maneira também podes contornar isso fazendo update.
 
Inicie sessão ou registe-se para poder participar.
Back
Topo