Por que adotar um processo de desenvolvimento de software? [fechadas]

Question

Agile (SCRUM, XP, FDD, ...), Cascata, RUP, ... Por que uma pequena empresa incomoda adotar um em primeiro lugar. Porque não basta cortar-away cada projeto até a conclusão (com um tamanho da equipe usual de 1 ~ 2).

Estou preparando uma breve apresentação contra o argumento, mas gostaria de ouvir o que todo mundo pensa.

Answer 1

Ooh, meu tipo favorito de questão. Sempre que SDLC surge, a resposta apropriada é sempre: "Depende!" :) Eu odeio essa resposta, tanto quanto todo mundo, então vamos cavar mais fundo.

Se seus projetos são administráveis ??por uma única pessoa e muito curto (isto é, <3 meses) então o processo não formal, provavelmente faz sentido. Princípios de alguns dos processos são importantes, mas a maior parte da cerimônia pode seguramente ser descartado. Por exemplo, em uma espécie Agile-y de forma, eu ainda rastrear cartões que tinham histórias técnicas (uma frase ou assim), histórias de usuários (uma ou duas frases), tarefas, etc, então eu não iria deixar a bola cair em qualquer coisa . Eu não faria iterações necessariamente, apenas rolando-wave. Se você sabe que tem alguma data difícil para um beta / preview / whatever, então você pode planejar sua onda em conformidade escolhendo a prioridade dos cartões que você está trabalhando semana-a-semana.

Uma das vantagens de ter algum processo é que você provavelmente vai deixar alguns artefatos de planejamento / gestão (cartões desfeitas, a carteira, etc.) por isso, se você ou necessidades alguma outra pessoa para continuar o desenvolvimento do projeto, você pode pegá-lo novamente mais facilmente .

A 6mo projeto e mais com 2 ou mais pessoas deve definitivamente ter algum tipo de processo para manter as coisas de ficar muito caótico e fora de sincronia entre os membros da equipe. Stand-ups são importantes aqui, como são os cartões de tarefa e responsabilidade.

Todo este material, por sinal, é o projeto de gestão / processos. Mesmo em uma equipe de 1-homem, eu ainda iria usar controle de origem, integração contínua, TDD, etc. Esta é uma necessidade para software de qualidade, independentemente do que processar que você está usando para a atribuição de tarefas.

Answer 2

"mexer" é um processo de desenvolvimento, não é apenas aquele que é facilmente controladas ou previsto!

o ponto do processo é a consistência e previsibilidade

Answer 3

Se um projeto "mexer" falhar isso acontece:

• gerentes pensam: "lazy programmers, they should work harder"
• programadores pensam: "next time I will really do unit testing" ou "we should have taken *this* tools or *that* language..."
• bons programadores pensam: "Bye everybody, I'm leaving"

E se a corrida "mexer" atrasos no projeto, os gestores tendem a adicionar mais pessoas para o projeto. De há é o dizendo: "I need this baby in a month send me nine women!"

A coisa complicada é adaptar um processo existente para sua empresa e equipe:

1. Entenda o processo
2. analisar os componentes do processo
3. plano de como você deseja apresentar e medir a integração de processos
4. começar beijo para integrar um ou dois componentes do núcleo (como reunião diária, ou um- hour par-programação de um dia, ou código de comentários, ou obter um cliente em seu escritório)
5. medida e reconfigure seu plano

Answer 4

A consistência é a chave. Se você vai de um projeto para apenas "cortando", então vai demorar um colega de trabalho (ou especialmente um novo funcionário) mais tempo para chegar até a velocidade em um projeto, que se existem normas e convenções em vigor. Realmente não importa qual normas / metodologia que você escolher, apenas contanto que você escolher um que irá trabalhar para a sua equipe, e usá-lo de forma consistente.

Answer 5

Se vai ou não realizá-lo, você já tem um processo de desenvolvimento. O ponto mais saliente de olhar para o vasto mundo dos processos é saber que outros têm encontrado maneiras de tornar seu trabalho mais produtivo. Talvez você também pode!

A melhoria do processo é o fundamento de processo. O ponto de adotar um processo é aprender a melhorar sistemicamente de modo que as melhorias não agite o trabalho em pedaços.

O fato de que você só tem duas pessoas na equipe não é a barreira de entrada. Eu uso os princípios Lean e Kanban, mesmo em projetos que eu faço como uma equipe de um homem só. I podem beneficiar dessas porque eu aprendi com eles, e de que a aprendizagem de minha mente se abriu para maneiras de ser mais produtivo que eu não tinha concebido no passado.

Se você já acha que não tenho nada para melhorar, então você provavelmente não precisa de olhar para processos fora do que você já está fazendo. Se você realmente se sente assim, tentar observar o seu estado emocional em detalhes quando você mantenha pensamentos em sua mente de explorar processos de desenvolvimento. Se você tem mesmo o momento mais ínfimo de estresse, quando você fizer isso, você pode estar recuando da percepção do trabalho envolvido em vez dos benefícios da aprendizagem a partir do trabalho e exploração de outros. Esse tipo de recolhimento psicológico inerente não é incomum, mas a sua raramente útil quando confrontado com uma questão significativa.

Answer 6

Você usa um processo de software para gerenciar tempo e recursos no projeto. 'Hacking away' é bom para um projeto de uma única pessoa em que você não se importa se o que você produz é overbudget, passados ??entregues todos os prazos e na verdade não atender aos requisitos dos clientes *. Para projetos que se importam com estes então um processo de software é apresentado como uma camada de gerenciamento. Os gestores podem então monitorar de forma mais eficaz o ciclo de desenvolvimento, esforço foco para as tarefas identificadas como crítica, importante, etc, fornecer feedback para o cliente como para o estágio em que estão, e todas as outras coisas que parece sem importância para os desenvolvedores, mas os gestores e clientes adoram, porque mostra que estamos realmente fazendo alguma coisa eles acham que é útil:)

* Eu não estou sugerindo que estes são sempre consequências para mexer ou que um processo mais estruturado irá removê-los. Eles são mais chamadas áreas 'de maior risco' do método de cortar afastado e, portanto, um projeto que apenas hacks e hacks e hacks praticamente não se importa se eles ocorrem ou não:)

Answer 7

Eu acho que o mesmo motivo por que há um processo para a construção de carros, e construção de casas?

A adoção de um processo de desenvolvimento pode reduzir quantas vezes você diz "Oh, deve ter pensado nisso".

Answer 8

Se a "mexer" processo permite que a pequena empresa para entregar o que seu cliente quer e por um custo que o cliente está feliz com, a empresa não deve se preocupar em adotar qualquer outro processo, obviamente.

Claro que o problema é que mexer, mesmo em uma pequena empresa, faz produzir esses resultados mais difícil. Além disso, se a empresa ou suas aplicações estão olhando para crescer, pirataria vai se tornar rapidamente insustentável.