¿Cómo puede un gran número de desarrolladores escribir software juntos sin un proceso engorroso o software de mala calidad?

Question

Trabajo en una empresa con cientos de personas escribiendo software para esencialmente el mismo producto. La calidad del software debe ser alta, ya que muchas personas dependen de él (no menos de los propios desarrolladores). Debido a esto, cada problema importante ha resultado en un nuevo cheque, ya sea automático o manual.

Como resultado, el proceso de entrega de software se vuelve cada vez más oneroso. Entonces eso requiere más desarrolladores que ... bueno, pueden ver que es un círculo vicioso.

Ahora tenemos un problema para liberar software rápidamente: el tiempo de espera incluso para cambiar una línea de código por un problema muy grave es al menos de un día.

¿Qué técnicas utiliza para acelerar la entrega de software en una organización grande, mientras se mantiene la calidad del software?

Answer 1

También trabajo en una organización grande y engorrosa. He tenido éxito implementando varias metodologías agile software development, pero hay dos en particular que he encontrado especialmente valiosas.

Desarrollo iterativo e incremental - Mantenga su ciclo de liberación corto y apretado. En un equipo grande, si se realizan numerosos cambios entre lanzamientos, puede encontrarse en una pesadilla de integración.

Las grandes organizaciones se inclinan por los grandes planes de proyectos con largas líneas de tiempo de desarrollo. Lucha esto. Planificar un proyecto durante todo un año no tiene sentido cuando toda su percepción puede cambiar después de las primeras dos semanas de desarrollo. Acondicione a sus partes interesadas para que se acostumbren a la idea de realizar pequeñas versiones incrementales y adaptarse a los requisitos siempre cambiantes.

Pruebas unitarias automatizadas - Esta es una gran manera de asegurarse de que está lanzando un software de calidad. Los peores errores son causados ​​por cambios de código aparentemente inocentes que tienen consecuencias involuntarias en otros lugares. Las pruebas integrales de unidades son quizás la mejor forma de detectar este tipo de error. Si puede graduarse a test driven development o behavior driven development, aún mejor.

Cualquier gran organización va a tener algunos desarrolladores mediocres. Es un hecho de la vida. Las pruebas unitarias automatizadas son una excelente manera de vigilarlos. Haga que uno de sus mejores desarrolladores escriba sus pruebas unitarias para ellos. Tendrás la seguridad de que al menos su código funciona (incluso si es feo).

Answer 2

Ver Continuous-Integration

Y por favor leer The Joel Test: 12 Steps to Better Code.

Answer 3

Hay muchas maneras de mejorar el proceso, pero el componente clave es modularity. Al separar claramente las responsabilidades (tanto en el código como en la organización) y definir interfaces claras y coherentes, un equipo grande puede trabajar como tantos equipos pequeños todos vinculados.

Answer 4

Wise pero sombrías dichos:

• Fred Brooks: Adding programmers to a late project makes it later.

• Gerry Sussman: Los programadores combinan las resistencias en paralelo.

• Alguien más: El costo de un proyecto es el número de programadores multiplicado por la duración del programa.

Algo que podría funcionar:

organizar el proyecto, de manera que hay un uso de la base construida por una o dos personas, preferentemente funcionando a través de una lengua. Luego, permita que todos los programadores sean efectivamente usuarios del núcleo, mediante la codificación en ese idioma.

Estoy pensando en productos basados ​​en el lenguaje: SAS, S/R, MATLAB, etc.