O que você adicionaria nesta lista de verificação do projeto de desenvolvimento de software? [fechadas]


14

Sou um grande fã de listas de verificação. Há uma lista de verificação de viagem , lista de verificação móvel e até uma lista de verificação do Scrum .

Contexto : você foi contratado por uma grande corporação e recebeu a missão de configurar todo o ambiente de desenvolvimento de software, processos, equipe etc. Você tem "carte blanche". Você será responsável pela criação dos incrementos de trabalho do software. Tamanho do projeto: 2000 homens / dias.

Quais itens você adicionaria à seguinte lista de verificação (intencionalmente pequena e incompleta):

  • Instale um servidor de integração contínua
  • Escreva um DoD
  • Escreva as diretrizes de codificação de uma página
  • Criar uma lista de pendências de produtos
  • Instale um sistema de rastreamento de erros
  • Programar Horário de Face Regular

Respostas:


10

* 1.) Converse com os desenvolvedores para ver o que eles realmente precisam! *

2.) Investigue uma solução para criar vários ambientes muito rapidamente (pense em instâncias de nuvem pública ou privada ou em máquinas virtuais à moda antiga, se você não estiver em conformidade com os chavões)

3.) Controle de fonte / versão

4.) Sistema de revisão de código (Crucbile / Fisheye como exemplo)

5.) Parede Kanban (ou algo semelhante)

6.) Protocolos de comunicação (o bate-papo em tempo real é uma grande vantagem), os wikis também incentivam a colaboração. Isso também abrange relações públicas internamente - como você vai se envolver com os empresários, a equipe de suporte técnico e outros grupos?

7.) Lousas eletrônicas

8.) Ambiente confortável para desenvolvedores (sofás, mesas, áreas de descanso, bom WiFi etc.)

9.) Ótimo café !!!


cofee faz a diferença:) + 1
RBA

quais são os quadros eletrônicos eletrônicos que você usa?

@Pierre 303 - Imprimindo os resultados de uma sessão do quadro branco a (foto de alta qualidade fará o mesmo truque, eu acho).
Martijn Verburg

8
  • Configuração da cadeia de ferramentas - IDEs, servidor de CI, servidor de qualidade de código, controle de origem, servidor da web, bancos de dados, rastreador de problemas etc.
  • Backups - Qual o papel de cada pessoa da equipe? Quais processos / módulos ele 'possui' e quem é seu backup?
  • (Aceitação do usuário) Configuração do ambiente de teste - Não apenas integração contínua w. testes de unidade, mas testes de integração para cobrir as coisas realmente ruins, várias plataformas, servidores de aplicativos, VMs etc.
  • Configuração dos testes de desempenho - Quanto mais cedo, melhor, pois você precisará de dados históricos para responder "Com qual recurso / marco o desempenho caiu tanto?"
  • Resumo da documentação (usuário final) - O que vai estar na documentação? Que tipo de documentação é necessária?
  • Canais de marketing - Como os marcos internos e os lançamentos externos estão sendo anunciados? Você tem um nome legal para o software, um logotipo, cores, texto etc.?
  • Comunicação interna - Como os colegas de outras equipes serão informados sobre as mudanças? Como está sendo feita a colaboração? Wiki? Direitos de acesso?
  • Pessoas e processos de garantia de qualidade - Quem testará o quê, com que frequência e com quais critérios?
  • Processo de lançamento - Quando, com que frequência, como, quem está fazendo isso, quem está recebendo o lançamento etc.
  • Gerenciamento de riscos - cenário de pior caso (de um projeto mgmt pov e de um tempo de execução pov, por exemplo, 'o cliente está perdendo dinheiro porque o software falhou no módulo X, qual é o plano de backup?)
  • Proteção do ambiente de desenvolvimento principal, por exemplo, virtualização para o compromisso
  • Locais para reuniões formais e informais
  • Treinamento ou introdução para todas as pessoas, para que eles saibam para que serve toda a instalação, para que servem cada parte e como a utilizam.
  • Identificando o zelador e dando a ele todas as coisas (por exemplo, permissões) que ele precisa para cuidar quando as coisas correm mal

+1 para backups e treinamento
Liviu T.

backups, embora eu ache que isso é extravagante.
BlackICE

5

Revisões post-mortem - Como você está trabalhando em blocos, eu agendaria uma revisão de uma a duas horas (dependendo do tamanho da equipe) para ter uma reunião cara a cara (se possível), onde todo mundo sai e diz o que foi feito corretamente, o que poderia ser feito melhor e o que não era necessário. Ser capaz de aprender com seus erros no processo de desenvolvimento antecipadamente significa que você pode evitar cometê-los mais tarde, quando não tiver muito tempo para trabalhar.


4

Vamos começar contratando uma boa equipe dos profissionais certos para o seu projeto. Em um aplicativo comercial típico, você precisa contratar um desenvolvedor de banco de dados e um dba, um responsável pelo controle de qualidade, um administrador de sistemas, analistas de negócios, desenvolvedores de aplicativos, um especialista em interface do usuário e líderes de equipe no mínimo. DBA, administrador do sistema, analistas de negócios e controle de qualidade devem estar em uma cadeia de relatórios separada da equipe de desenvolvimento. O especialista em banco de dados de desenvolvimento deve reportar-se ao mesmo líder técnico que os desenvolvedores de aplicativos e o especialista em UI.

Configure o espaço do escritório. Os escritórios particulares são ótimos se você puder obtê-los (desejo-lhe muita sorte com isso), mas no mínimo você precisa de mesas, telefones, computadores, quadros brancos e duas salas de conferência dedicadas. Verifique se há um local para almoços, uma geladeira, refrigerantes, lanches e café disponíveis. Refrigerantes e café gratuitos ainda melhores.

Configure os servidores dev / qa / staging e prod para o aplicativo e os bancos de dados. Os bancos de dados nunca devem estar no mesmo servidor que os aplicativos. Dependendo do tamanho e do escopo do projeto, você pode precisar de vários servidores ou SANs, etc, para cada ambiente.

Assim que os servidores forem configurados, agende backups do sistema de arquivos, do banco de dados e dos logs de transações do banco de dados. Faça isso no primeiro dia em que tudo estiver configurado. Contrate uma empresa como a Iron Mountain para fazer backups fora do local semanalmente.

Configure um sistema de controle de origem e crie um documento descrevendo como será usado. Não se esqueça de insistir para que TODAS as alterações estruturais do banco de dados e as inserções de dados para tabelas do tipo de pesquisa estejam em scripts no controle de origem. Isso facilitará a implantação.

Compre software comercial ou faça o download de software de código aberto para o conjunto de ferramentas que você decidiu usar com licenças para todos os usuários pertinentes.

Compre máquinas para desenvolvedores que estão gritando rápido e têm dois monitores. Compre pelo menos uma máquina de usuário de teste que geme lentamente e é típica do que os usuários terão em seus desktops.

Treine seus novos desenvolvedores em como você deseja que as coisas sejam feitas. Se você tem uma equipe grande o suficiente para ter alguns desenvolvedores juniores, programe treinamento extra para eles e inclua o tempo no planejamento do projeto. Monitore os juniores de muito perto por pelo menos três meses. Monitore de perto todos os novos funcionários durante o primeiro mês. Livre-se dos desenvolvedores de madeira morta e desonestos o mais rápido possível.

Determine o que precisa ser feito em que ordem (o caminho crítico). Não atribua tarefas no final do caminho crítico até que as tarefas das quais dependem estejam concluídas.

Crie planos e requisitos de teste.

Organize regularmente reuniões de progresso agendadas com os clientes. Eles merecem saber o que você está fazendo e quais são os obstáculos. Não deixe de dizer quando as coisas vão se atrasar. Se você estiver a três semanas de um prazo e já sabe que vai perdê-lo, esse déficit não desaparecerá magicamente antes que você precise informar o cliente. Certifique-se de que o cliente saiba que requisitos adicionais significam custos e tempo adicionais e que todos os requisitos adicionados terão que ter outras tarefas descartadas ou o prazo mudará de acordo com a quantidade de horas nas novas tarefas. Deixar isso claro desde o início economizará muita dor e horas extras e excederá os custos absorvidos pelo seu grupo e não pelo cliente.

Configure um ambiente para teste de desempenho, não apenas a velocidade de um usuário, mas onde você possa testar o número esperado de usuários simultâneos. Não espere para fazer esse teste até o dia anterior ao lançamento.

No planejamento do projeto, suponha que o controle de qualidade encontre bugs e que eles levem tempo para serem corrigidos. Não programe o controle de qualidade por apenas um dia no final.

Crie dados de teste aproximadamente do tamanho que você acha que o banco de dados terá. Faça com que todos os desenvolvedores testem seu código no banco de dados desse tamanho. Não permita que os desenvolvedores desenvolvam apenas um pequeno banco de dados em suas máquinas pessoais. Essa é uma causa frequente de código que funciona bem até atingir a produção.

Planeje recompensas no orçamento. Desmotiva as pessoas quando trabalham duro por meses e apenas os gerentes recebem bônus. Diga também obrigado com frequência e por escrito.

Pode ser necessário um sistema de gerenciamento de projetos ou, pelo menos, configurar planilhas para rastrear o que você precisa rastrear. Ao fazer o planejamento do projeto, assuma no máximo seis horas por dia em seu plano. Isso ajuda a contabilizar o tempo que não será gasto no projeto, como férias, ausência por doença, feriados, reuniões de RH, análises de desempenho etc. Se você souber que o projeto está em um período de alta indisponibilidade (por exemplo, um projeto que é executado de 1 de novembro a 1 de janeiro nos EUA), pode ser necessário conceder subsídios extras para mais férias e férias. Não é justo esperar que os desenvolvedores desistam de suas férias e ninguém pode prever quando coisas como tempo de doença, dever do júri, tempo de luto etc. acontecerão. Suponha que eles acontecerão com sua equipe neste projeto.


Eu acho que a máquina do usuário de teste deve estar "gemendo devagar", não "gritando devagar";) lista muito boa.
BlackICE

@ David, eu gosto da sua sugestão e mudei no texto.
HLGEM

Ótima resposta - pontos de bala ou nomes de seção podem ajudar um pouco.
JBRWilkinson

3

Algumas coisas que não vejo na pergunta e nas respostas subseqüentes:

  • Plano de recuperação de desastres. Como você está fazendo backup das caixas de desenvolvimento, teste, teste etc.? Todo desenvolvedor tem o que precisa para trabalhar em casa em um dia ocasional de neve? Etc.

  • Plano de treinamento. Quantas semanas do ano de treinamento seus desenvolvedores precisam manter a nitidez? Alguém está rastreando? (Uma planilha pode ser suficiente para a maioria das equipes.) Tenha um mecanismo para que eles relatem (enviando a alguém um e-mail dizendo que assistiram 2 horas de webcasts sobre "o que quer que seja" provavelmente seja o suficiente)) e que a gerência planeje - por exemplo, quem devemos enviar para o que conferência este ano.

  • a Posição da ferramenta. É este o tipo de local "oferecemos a todos uma assinatura do MSDN; não instale mais nada em suas máquinas de trabalho" ou um "queremos o seu código, mas não nos importamos com o que você usa para editar, compilar e testá-lo" "tipo de lugar. Tome e registre a decisão.

  • o ALM integrado que você puder suportar ou pagar. Geralmente, a razão para a "incompatibilidade de impedância", entrada dupla, sobreposição de ferramentas e integração de aplicativos de cadeira giratória é que o sistema cresceu em pedaços. Começando do zero, você quer mostrar que seu pessoal pode permanecer em uma única ferramenta durante todo o ciclo. Não digitando código em X, compilando com Y, testando com Z, alterando o status do item / tarefa de trabalho com A, relatando seu tempo gasto com B, informando à pessoa que estava esperando que agora pode prosseguir com C, tentando descobrir o que fazer em seguida com D, ajudando o progresso geral com E etc.


2

Negocie mais dias de trabalho.

É um evento raro quando as pessoas alocam o suficiente inicialmente.

[Mais tarde ... renegocie ainda mais ...]


Tendo em vista que mais dias de trabalho devem sempre ser negociados não é algo que eu recomendaria, eu preferiria fornecer estimativas precisas e confiáveis ​​da duração de um trabalho ou projeto.
NimChimpsky

@NimChimpsky Houve uma discussão aqui recentemente sobre se a capacidade de estimar com segurança era um mito em projetos de computador. A menos que o trabalho seja muito conhecido e não contenha pesquisas, é intrinsecamente difícil prever o tempo. Mesmo se você puder prever o cronograma de sua própria equipe - é quase impossível prever fatores externos e atrasos. Portanto, estimativas "precisas e confiáveis" não são algo que acredito que exista em geral.
Orbling

@Orbling eles existem onde eu trabalho. Um revendedor nacional listado na ftse 250 no Reino Unido. Alguns projetos estão atrasados, mas não tão tarde, e eles são a exceção.
NimChimpsky

@NimChimpsky É possível obter uma estimativa relativamente precisa se você tiver controle total de todas as entregas de um projeto, não estiver sendo bloqueado por fatores externos e a tarefa em questão não envolver pesquisas. Fornecer seu orçamento se estende a uma análise completa antes da estimativa do tempo. Na maioria das empresas, o orçamento simplesmente não existe para investigar completamente antes do início.
Orbling

@orbling É possível que sempre solicitar mais tempo seja puramente arbitrário e nem um pouco baseado em evidências, resultados, análises ou orçamento.
NimChimpsky

2

Vendo que eu tive o maior problema com bibliotecas de terceiros e seu uso:

  1. Determine as bibliotecas e versões que você usará.
  2. Crie o processo de integração de atualizações da biblioteca ao seu projeto.
  3. Verifique se os desenvolvedores estão todos de acordo com as opções da biblioteca.
  4. Crie um canal benéfico para a discussão aberta sobre as tecnologias que estão sendo usadas.

Por quê? Não sei dizer o número de vezes que as bibliotecas de terceiros (proprietárias) tiveram bugs heniosos que nos enviaram semanas de tempo de desenvolvimento, porque não tínhamos processo para subir ou descer. Ou lidando com desenvolvedores dizendo "qual versão você usou? Por que você usou funções marcadas como obsoletas?"


1

Um grande custo para as organizações não é atribuir orçamento à segurança durante todo o ciclo de vida do desenvolvimento, isso significa que a segurança geralmente acaba ocorrendo após o fato de um conjunto de atividades ou controles ineficazes e dispendiosos, implementado tarde demais para fazer muito bem.

Obtenha a segurança integrada no plano inicial do projeto, com os principais marcos, da mesma forma que faria com todos os outros aspectos do desenvolvimento, e use um processo iterativo para manter as orientações de segurança atualizadas. A aprovação final da segurança deve ser uma verificação sem surpresas, de que todos os controles de segurança foram implementados conforme o projeto.

Caso contrário, você acabará executando a segurança após a implementação - onde pode custar de 8 a 10 vezes mais (números do Gartner, IBM e outros), incomodará as pessoas, pois a funcionalidade provavelmente será afetada e pode ser tarde demais para impedir a exploração e danos.


Estou curioso, isso deve fazer parte da lista de verificação da configuração do projeto? Eu o colocaria como parte do desenvolvimento de software, mas não sei sobre a configuração do projeto. Eu colocaria isso com marcos de desenvolvimento, mas acho que não era sobre isso que o OP estava perguntando, eu poderia estar errado.
BlackICE

David - talvez você esteja certo de que esse nível de detalhe não deveria estar lá, mas acho que deveria haver pelo menos um item de linha para segurança. Melhor?
Rory Alsop

1

1. Leve para a equipe

Pergunte aos programadores! Realmente, isso é a coisa mais importante. Você encontrará muita resistência se os desenvolvedores não estiverem diretamente envolvidos nessa mudança. Afinal, é sobre como eles funcionam, não você. Escusado será dizer, mas tentar forçar métodos e ferramentas nas pessoas geralmente sai pela culatra horrível.

2. Inspecione e adapte

Faça com que a equipe descubra a melhor maneira de trabalhar, usando sua experiência para ajudá-los a entrar na trilha escolhida. Depois, regularmente e de forma colaborativa, analise como você está (eles) e adapte o processo para torná-lo melhor.

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.