process - una - sunco oil tiene tres procesos distintos que se pueden aplicar para elaborar varios tipos de gasolina

¿Cuál es su proceso de programación o el de su empresa? (4)

Utilizamos Trac como nuestro sistema de seguimiento de errores / características.
Los boletos de Trac se revisan, se cambian para ser unidades viables y luego se asignan a un hito
Los tickets de trac son nuestras especificaciones, que contienen en su mayoría información muy escasa que debe ser discutida durante el hito
No, pero nuestro equipo de desarrollo está formado únicamente por dos miembros.
Sí, probamos, y sí, TDD nos ha ayudado mucho. La cobertura es de alrededor del 70 por ciento (Cobertura)
No, nos refactorizamos cuando sea apropiado (durante los cambios de código)
Solo documentamos métodos y clases públicas, nuestro número máximo de líneas es de 40, por lo que los métodos suelen ser tan pequeños que se pueden describir por sí mismos (si existe tal cosa ;-)
svn con tronco, rc y ramas estables.
1. tronco - Desarrollo de nuevas características, corrección de errores de características anteriores
2. rc - Para las pruebas internas, las correcciones de errores se combinan desde el tronco
3. estable - solo correcciones de errores fusionadas desde el tronco o rc

Estoy buscando sugerencias de procesos y he visto algunas en el sitio. Lo que me encantaría escuchar es lo que usa específicamente en su empresa, o solo usted y sus proyectos de pasatiempo. ¡Cualquier enlace a otros sitios web que hablen sobre estos temas es bienvenido!

Algunas preguntas para basar una respuesta de:

¿Cómo te reportan los usuarios las solicitudes de errores / características? ¿Qué software utilizas para realizar un seguimiento de ellos?
¿Cómo se convierten las solicitudes de errores / características en "trabajo"? ¿Planeas el trabajo? ¿Tienes un horario?
¿Tienes especificaciones y las sigues? ¿Qué tan detallados son?
¿Tienes una ventaja técnica? ¿Cuál es su papel? ¿Hacen alguna programación ellos mismos, o solo arquitectura / tutoría?
¿Pruebas unitarias? ¿Cómo te ha ayudado? ¿Qué dirías que es tu cobertura?
¿Código de revisión? Cuando se trabaja en un plazo ajustado, ¿sufre la legibilidad del código? ¿Piensas volver más tarde y limpiarlo?
¿Usted documenta? ¿Con cuánto comentario se sienten cómodos usted o su compañía? (¿Descripción de la clase, cada método y métodos internos? ¿O simplemente partes del código difíciles?)
¿Cómo se ve tu flujo de SCM? ¿Usas ramas de características, etiquetas? ¿Cómo se ve tu "baúl" o "maestro"? ¿Es donde ocurre el nuevo desarrollo o la parte más estable de su base de código?

No estoy seguro de por qué esta pregunta fue rechazada. Creo que es una gran pregunta. Una cosa es buscar en Google y leer algunos sitios web aleatorios que muchas veces intentan venderte algo en lugar de ser objetivos. Y otra cosa es preguntar a la multitud, que son desarrolladores / gerentes de TI, que compartan sus experiencias y qué funciona o qué no funciona para sus equipos.

Ahora que este punto está fuera del camino. Estoy seguro de que muchos desarrolladores lo orientarán hacia "Agile" y / o Scrum, tenga en cuenta que estos términos a menudo se usan de manera muy general, especialmente Agile. Probablemente voy a sonar muy controvertido al decir esto, que no es mi intención, pero estas metodologías están sobrevaloradas, especialmente Scrum, que es más un producto comercializado por consultores de Scrum que una metodología "real". Habiendo dicho eso, al final de un día, debe usar lo que mejor funcione para usted y su equipo, si es Agile / Scrum / XP o lo que sea, hágalo. Al mismo tiempo, debe ser flexible al respecto, no volverse religioso con respecto a ninguna metodología, herramienta o tecnología. Si algo no funciona para usted, o puede ser más eficiente cambiando algo, hágalo.

Para ser más específicos con respecto a sus preguntas. Aquí está el resumen básico de las técnicas que me han funcionado (muchas de estas son de sentido común):

Organice todos los documentos y correos electrónicos relacionados con un proyecto específico, y hágalo accesible a otros a través de una ubicación central (uso MS OneNote 2007 y me encanta para toda mi documentación, progreso, características y seguimiento de errores, etc.)
Todas las reuniones (que debe intentar minimizar) deben ir seguidas de elementos de acción donde cada elemento se asigna a una persona específica. Cualquier acuerdo verbal debe ser puesto en un documento escrito. Todos los documentos agregados al sitio del proyecto / repositorio. (MS OneNote en mi caso)
Antes de comenzar cualquier nuevo desarrollo, tenga un documento escrito de lo que el sistema será capaz de hacer (y lo que no hará). Comprométete a ello, pero sé flexible a las necesidades del negocio. ¿Qué tan detallado debe ser el documento? Lo suficientemente detallado para que todos entiendan de qué será capaz el sistema final.
Los horarios son buenos, pero sé realista y honesto contigo mismo y con los usuarios de negocios. La guía básica que uso: software de calidad de lanzamiento y uso que carece de algunas funciones, en lugar de un software con errores con todas las características.
Tener líneas abiertas de comunicación entre tu dev. Equipo y entre sus desarrolladores y grupos de negocios, pero al final de un día, una persona (o algunas personas clave) debe ser responsable de tomar las decisiones clave.
Prueba unitaria donde tiene sentido. Pero NO te obsesiones con eso. 100% de cobertura de código! = Sin errores, y el software funciona correctamente de acuerdo con las especificaciones.
Tienen normas de código y revisiones de código. Comprometerse con los estándares, pero si no funciona para algunas situaciones, se requiere flexibilidad.
Comente su código especialmente difícil de leer / entender partes, pero no lo convierta en una novela.
Regrese y limpie su código si ya está trabajando en esa clase / método; implementando una nueva característica, trabajando en una corrección de errores, etc. Pero no lo reformule solo por refactorizar, a menos que no tenga nada más que hacer y esté aburrido.
Y el último y más importante elemento: no te conviertas en un religioso acerca de ninguna metodología o tecnología específica. Obtenga los mejores aspectos de cada uno y encuentre el equilibrio que funcione para usted y su equipo.

Para dar una mejor respuesta, la política de mi empresa es utilizar XP lo más posible y seguir los principios y prácticas que se describen en el manifiesto Agile.

http://agilemanifesto.org/

http://www.extremeprogramming.org/

Así que esto incluye cosas como tarjetas de cuentos, desarrollo basado en pruebas, programación de pares, pruebas automatizadas, integración continua, instalaciones con un solo clic, etc. No nos gusta la documentación, pero nos damos cuenta de que necesitamos producir solo la documentación suficiente para crear un software que funcione.

En una cáscara de nuez:

cree solo las historias de usuario suficientes para comenzar el desarrollo (las historias de usuario aquí deben ser el comienzo de una conversación con empresas y no con especificaciones completas o casos de uso completamente completos, pero pequeños fragmentos de valor empresarial que se pueden implementar en menos de 1 iteración)
Implementar iterativamente las tarjetas de historias basadas en lo que la empresa prioriza como la más importante
obtener retroalimentación del negocio sobre lo que se acaba de implementar (por ejemplo, bueno, malo, casi, etc.)
repita hasta que el negocio decida que el software es lo suficientemente bueno

Para mi (pequeña) empresa:

Primero diseñamos la interfaz de usuario. Esto es absolutamente crítico para nuestros diseños, ya que una IU compleja enajenará casi de inmediato a los compradores potenciales. Realizamos un prototipo de nuestros diseños en papel , luego, a medida que decidimos los detalles específicos del diseño, preparamos la Vista y cualquier código de Controlador apropiado para la creación continua de prototipos interactivos de nuestros diseños.
A medida que avanzamos hacia una IU aceptable, escribimos una especificación en papel para la lógica del flujo de trabajo de la aplicación. El papel es barato, y repasar los diseños garantiza que al menos haya pasado una pequeña cantidad de tiempo pensando en la implementación en lugar de codificar a ciegas.
Nuestras especificaciones se mantienen en control de revisión junto con nuestra fuente. Si decidimos un cambio, o queremos experimentar, ramificamos el código, e INMEDIATAMENTE actualizamos la especificación para detallar lo que estamos tratando de lograr con esta rama en particular. No se requieren pruebas unitarias para sucursales; sin embargo, se requieren para cualquier cosa que queramos incorporar de nuevo en el tronco. Hemos encontrado que esto alienta a los experimentos.
Las especificaciones no son sagradas, ni son propiedad de ningún individuo en particular. Al comprometer la especificación con el entorno democrático de control de fuente, fomentamos la experimentación y la revisión constantes, siempre que esté documentada, por lo que no estamos diciendo "¿WTF?" luego.
En un juego de iPhone reciente (aún no publicado), terminamos con casi 500 sucursales, que luego se tradujeron en casi 20 características diferentes, una gran cantidad de simplificaciones de conceptos ("Tocar para cancelar" en la barra de progreso en lugar de un botón separado) , una serie de ideas rechazadas, y 3 nuevos proyectos. Lo bueno es que todas y cada una de las ideas estaban documentadas, por lo que era fácil visualizar cómo la idea podía cambiar el producto.
Después de cada compilación principal (cualquier cosa en el troncal se actualiza, con las pruebas de unidad aprobadas), intentamos que al menos 2 personas prueben el proyecto. Principalmente, tratamos de encontrar personas que tengan poco conocimiento de computadoras, ya que hemos descubierto que es demasiado fácil diseñar complejidad en lugar de simplicidad.
Usamos DOxygen para generar nuestra documentación. Todavía no tenemos la generación automática incorporada en nuestro proceso de construcción, pero estamos trabajando en ello.
No codificamos revisión. Si la prueba de la unidad funciona y la fuente no causa problemas, es probable que esté bien, pero esto se debe a que podemos confiar en la calidad de nuestros programadores. Esto probablemente no funcionaría en todos los entornos.
Las pruebas unitarias han sido un regalo de Dios para nuestras prácticas de programación. Dado que no se puede pasar ningún código nuevo al troncal sin las pruebas de unidad apropiadas, tenemos una cobertura bastante buena con nuestro troncal y una cobertura moderada en nuestras sucursales. Sin embargo, no es un sustituto para las pruebas de usuario, solo una herramienta para ayudar a llegar a ese punto.
Para el seguimiento de errores, usamos bugzilla. No nos gusta, pero funciona por ahora. Probablemente pronto lanzaremos nuestra propia solución o migraremos a FogBugz. Nuestro objetivo es no lanzar software hasta que alcancemos un estado de 0 errores conocidos. Debido a esta postura, nuestras actualizaciones a nuestros paquetes de códigos existentes son generalmente mínimas.

Entonces, básicamente, nuestro flujo usualmente se parece a esto:

Papel UI Espec + Planificación » Pruebas Mentales » Paso 1
Ver código + Pruebas unitarias »Pruebas de usuario » Paso 1 o 2
Controlador de papel y especificaciones de modelo + Planificación » Pruebas mentales » Paso 2 o 3
Modelo y código de controlador + Pruebas unitarias »Pruebas de usuario » Paso 3 o 4
Idea ramificada »Especificaciones» Codificación (sin pruebas unitarias) » Pruebas mentales » Rechazo
Idea ramificada »Especificaciones» Codificación (sin pruebas unitarias) » Pruebas mentales » Aceptación »Pruebas unitarias» Tronco » Paso 2 o 4
Errores conocidos »Seguimiento de errores» Reparación de errores » Paso 2 o 4
Producto terminado »Informes de errores» Paso 2 o 4

Nuestro proceso no es perfecto de ninguna manera, pero un proceso perfecto también implicaría seres humanos y tecnología perfectos, y eso no sucederá en el corto plazo. La cantidad de papel que pasamos en la planificación es asombrosa: ¿quizás sea hora de que obtengamos un contrato con Dunder Mifflin?