Design em uma equipe, codificando em outra


28

Estarei envolvido em um projeto em que todo o design de software é feito por uma equipe local e esses designs são enviados a uma equipe offshore para codificação.

É a primeira vez que enfrento um projeto com essas características e, para mim, é meio estranho: os gerentes esperam que façamos documentos de projeto muito detalhados, para que não haja espaço para erros na equipe offshore; da minha perspectiva, eles estão nos fazendo codificar em papel, enquanto podemos fazê-lo em um IDE.

Então, minha pergunta é: essa abordagem é boa ou está correta? Quais são as principais considerações que nosso processo de software precisa ter para ter sucesso em nosso projeto?



5
@ Mike: O software da nave espacial é um pouco diferente da maioria dos softwares. Ele tem que funcionar perfeitamente o tempo todo, ou perda de vidas e ativos extremamente caros podem ocorrer. Veja fastcompany.com/28121/they-write-right-stuff
Robert Harvey

9
Eu acho que a equipe offshore é mais barata, também tem o dobro do tamanho da equipe de design? Tem algumas vantagens reais sobre a equipe interna? por exemplo, eles falam o idioma natural dos usuários finais enquanto você não fala? Eles têm algum tipo de talento que você não tem internamente? Caso contrário, vejo que sua empresa tem um caso grave de envenenamento por PHB .
ZJR

11
@mike: Eu acho que seria mais preciso dizer que na maioria dos softwares um pequeno número de bugs é considerado aceitável, porque o software sem bugs é uma assíntota e obter esses bugs restantes é muito caro.
Robert Harvey

9
Eu sugiro que você comece a procurar outro emprego imediatamente. Programadores não são engrenagens intercambiáveis, que é a suposição subjacente a esse tipo de arranjo. Separar o design do desenvolvimento dessa maneira - onshore ou offshore - garante uma desconexão entre o cliente e os desenvolvedores, o que torna altamente provável a falha.
9788 Steven A. Lowe

Respostas:


36

Minha opinião:

Se tudo o que você fornecer ao pessoal no exterior for documentos e diagramas, você terá muitas falhas de comunicação e decepção .

Minha recomendação

  • Não lhes dê tantos documentos, mas interfaces e classes abstratas , a fim de colocá-las em camisa de força em seus objetivos de design .

  • Exija que eles usem um padrão de nomenclatura conhecido.

  • Exija que eles usem testes de unidade.

  • Envie um de seus designers / arquitetos para o exterior para supervisionar o processo, ainda será mais barato do que codificar internamente, mas você obterá melhores resultados.


2
As equipes offshore não funcionam da mesma maneira que as equipes onshore. Você precisa ser muito, muito específico sobre exatamente o que deseja, caso contrário não conseguirá o que deseja.
Robert Harvey

32
... Isso é parte do motivo pelo qual muito desenvolvimento está voltando para os EUA; Essa abordagem de projetar em terra, desenvolver em alto mar e depois depurar novamente em terra exige que você tenha os mesmos recursos em terra que você usaria para desenvolver a coisa toda como sopa de nozes em primeiro lugar. Em qualquer outro processo de produção, onde materiais diretos e mão-de-obra de fabricar as coisas são altos, a abordagem offshore faz sentido. Quando o design do que você está fazendo não é apenas a maior parte do seu custo, mas também pode ser o produto final, o desenvolvimento offshore se torna obviamente mais redundante.
Keiths

@KeithS Ótimo comentário. Eu concordo% 110 com você.
Tulains Córdova

2
Forçá-los a usar classes e interfaces que você criou sem ter escrito nenhum código é uma receita para o desastre.
quer

2
@Euphoric Há um longo período entre escrever abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()e realmente implementá-lo.
Tulains Córdova

26

Chama-se Big Design Up Front, também conhecido como Waterfall. Não é amplamente considerado como uma metodologia altamente bem-sucedida. Mas já vi isso funcionar e, quando funciona, funciona muito bem. É muito caro fazer o certo.

Também é o que seus empregadores pediram para você fazer.

As equipes offshore não funcionam da mesma maneira que as equipes onshore. Você precisa ser muito, muito específico sobre exatamente o que deseja, caso contrário não conseguirá o que deseja.


Você pode detalhar um pouco mais sobre "muito específico"? Eu tive que chegar ao nível de incluir o pseudocódigo?
Carlos Gavidia-Calderon

8
O pseudocódigo aumentará suas chances de obter o código da equipe offshore exatamente da maneira que você deseja. Como outros já apontaram, o processo de fazer a terceirização funcionar com êxito pode ser mais caro do que apenas manter todo o trabalho internamente. Mas essa não é sua decisão a tomar.
Robert Harvey

2
Isso não deveria ser It's very expensive when it goes wrong. :-)
LarsTech

@LarsTech: É por isso que a despesa adicional de fazer o certo é justificável.
Robert Harvey

Pseudocódigo como tomar o mesmo esforço como escrever código real, + sobrecarga de comunicação no mar
Web Devie

16

O último projeto foi o designer de software. Todo o desenvolvimento foi no exterior. Fomos bem sucedidos. Então esse processo pode funcionar.

Produzi muita documentação, mas não foi de forma alguma abrangente e nem passo a passo, nem detalhei nomes de classes, nomes de funções etc. Por exemplo, produzi diagramas de sequência, casos de uso, fluxos de trabalho, sistema e integração diragramas, bem como uma documentação de projeto mais detalhada, conforme necessário.

Realmente depende de quanto você confia no desenvolvimento offshore. Confio que minha equipe offshore seja desenvolvedora competente. Dito isso, eu forneci orientação geral, mas dei a eles margem de manobra que a equipe offshore achou agradavelmente satisfatória. No passado, eles eram mais microgerenciados. Em certas situações, eu os orientaria usando os padrões de design conforme necessário. Também realizei revisões e análises de código regularmente sobre o código que eles escreveram e recomendaria esforços de refatoração ou limpeza. Além disso, como parte da equipe sofreu acidentes com veículos de recreio, acabei codificando algumas das histórias durante a implementação, pois acabamos tendo poucos recursos.

Além disso, acho que esse processo realmente é bem-sucedido apenas com a força de seus líderes técnicos no projeto e com a comunicação entre negócios, designer, leads e desenvolvedores. Passamos muito tempo analisando cada recurso e história e garantimos que os recursos / leads offshore fossem bem versados ​​sobre quais eram os requisitos. Se eles não estiverem fazendo perguntas durante a revisão do artigo / matéria, espere alguns problemas. Além disso, o trabalho não foi considerado completo até haver aprovação comercial. Isso tornou todos responsáveis, pois tudo foi rastreado em uma ferramenta que gerenciava o desenvolvimento ágil.

Como uma das outras respostas já mencionou, o processo de desenvolvimento incluiu padrões de nomenclatura (regras de re-compartilhamento incorporadas), cobertura de caso de teste (usou TDD, zombando etc.), portanto, se houver um bom processo e procedimento de codificação, aumentará suas chances de um projeto bem-sucedido.


Você usa algum processo ágil específico? Um personalizado, talvez?
Carlos Gavidia-Calderon

2
Não era totalmente ágil, mais como iterações planejadas. Tudo foi planejado com antecedência e dividido em iterações de 2 semanas. Usamos processos ágeis em cada interação. Gráficos de velocidade e queima utilizados, stand up padrão diário seguido de uma ou duas horas de telefonema no exterior. Definitivamente, dedico muito tempo ao telefone para o exterior, mas nosso dia ideal de desenvolvimento foi de 6 horas para contabilizar o tempo de comunicação.
22613 Jon Jonnor

2
Nota para si próprio: elimine veículos recreativos de futuras iterações de software.
Robert Harvey

Você acredita que seu sucesso teve mais a ver com escolher a equipe offshore certa ou simplesmente confiar neles para fazer a coisa certa sem microgerenciamento? Você acha que sua técnica de "iterações planejadas" foi fundamental para o seu sucesso?
Robert Harvey

11
@ Jess - Não, a equipe é responsável apenas por fornecer histórias e recursos aprovados (funcionalidade). A funcionalidade futura não é entregue, embora o design do software geralmente permita flexibilidade de algum tipo, mas apenas entregamos o que foi solicitado.
precisa

2

O principal custo do desenvolvimento offshore é a comunicação. A documentação é uma forma de comunicação, no entanto, os documentos não são capazes de cobrir todos os detalhes e possíveis alterações normalmente.

Não tenho certeza do tamanho do seu projeto. Suponho que seja grande, caso contrário, não é valioso usar a equipe de desenvolvimento offshore. Assim, minha experiência é

  1. Defina o código do esqueleto, a interface pública, a interface de serviço etc. e revise juntos
  2. Defina os testes de aceitação com o outro lado
  3. Divida o documento grande em pequenas histórias, trabalhe com base nas pequenas histórias. O grande documento é apenas uma imagem grande de todo o sistema
  4. Configure os pontos de verificação das histórias, uma semana ou duas semanas

1 e 2 é realmente sobre o desenvolvimento, para garantir que o outro lado entenda bem o requisito e que ambos os lados estejam usando o mesmo padrão. 3 e 4 faz parte da metodologia de desenvolvimento ágil, mas para o desenvolvimento offshore é difícil usar o processo ágil completo.


1

Eu acho que até certo ponto todos nós trabalhamos assim. Alguém em algum lugar projeta algo e codificamos algo que faz parte ou trabalha com o sistema. Exemplos são a criação de aplicativos com base em uma estrutura, como aplicativos que não são de jogos em dispositivos móveis. Muitas decisões de interface do usuário foram tomadas pela equipe de design das pessoas que criaram a estrutura. Eles controlavam tudo, desde aprender a escrever um aplicativo até vendê-lo. Se você quiser saber por que esse modelo foi bem-sucedido, veja a quantidade de documentação e ferramentas fornecidas por alguns fornecedores.

Outro exemplo são os aplicativos da Web com muitos deles tentando implementar o estilo REST. Este não diz realmente como implementar algo, embora quando haja especificações sobre como usar o HTTP. De qualquer forma, existem especificações e princípios orientadores a seguir. Se você vir a quantidade de discussões sobre a implementação do REST na stackexchange ou no local de trabalho, é como se houvesse um arquiteto dizendo às pessoas para implementar algo de determinadas maneiras. Ainda é um modelo bem-sucedido, eu acho, com tantas pessoas seguindo o estilo.

A partir desses dois exemplos, você pode ver como os projetos são propagados, alguns como especificações de papel, outros vêm com livros, ferramentas e exemplos. Você pode ver como as pessoas perguntam (em volume), tentando entender corretamente em diferentes graus, dependendo de quais padrões / projetos estão tentando seguir. Basta ir ao stackoverflow e assistir;)

Se você me der suas especificações, eu perguntarei. Se você me der um teste de unidade, eu codificarei e testarei.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.