ágiles targetprocess taiga tablero software proyectos metodologias herramientas gestión desarrollo agiles survey

survey - targetprocess - taiga scrum



¿Qué le gusta realmente al desarrollo de software en su empresa(metodologías, herramientas,...)? (23)

Desde que comencé mi primer trabajo como desarrollador de software profesional hace unos dos años, he leído muchos artículos sobre metodologías comúnmente aceptadas (por ejemplo, Scrum, XP), tecnologías (por ejemplo, EJB, Spring), técnicas (por ejemplo, TDD, revisiones de código) ), herramientas (seguimiento de errores, wikis) y así sucesivamente en las compañías de software.

Para muchos de estos he encontrado que nosotros en nuestra compañía no los usamos y me pregunto por qué. ¿Lo estamos haciendo mal o es simplemente que estos artículos que he leído realmente no dicen cómo es en el mundo real? ¿Son estos artículos más académicos?

Por lo tanto, cuénteme cómo es en su empresa. Cuéntenos todo sobre el desarrollo de software. Aquí hay algunas sugerencias (en el orden en que vienen de mi mente). Dígale al menos si lo hace o no, o haga un breve comentario:

  • Desarrollo basado en pruebas
  • Dominio de diseño
  • Diseño guiado por modelo / arquitectura
  • ¿Pruebas?
  • Examen de la unidad
  • Pruebas de integración
  • Test de aceptación
  • Revisiones de código
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...)
  • Ágil
  • Programación de par
  • UML
  • Idiomas específicos del dominio
  • Especificación de requisitos (¿Cómo?)
  • Integración continua
  • Herramientas de cobertura de código
  • Modelo de dominio aenemico
  • Comunicación (Wiki, Correo, MI, listas de correo, otros documentos)
  • Estimaciones de esfuerzo
  • Tamaño del equipo
  • Reuniones
  • Métricas de código
  • Análisis de código estático
  • Seguimiento de errores
  • ...

Y recuerde: quiero saber lo que realmente hace, no lo que le gustaría hacer o pensar que debería hacer.

Creo que el famoso patrón Big Ball of Mud describe muchos entornos de trabajo y te da algunas buenas ideas sobre cómo combatir este tipo de cosas.

Por cierto, me doy cuenta de que no estoy respondiendo directamente a su pregunta, pero Big Ball of Mud prevalece en un porcentaje deprimentemente grande de situaciones de desarrollo. Puedes preguntar sobre el desarrollo impulsado por pruebas y el seguimiento de defectos y otras clases de cosas, pero si la verdad es contada por lo que he visto, diría que la Gran Bola de Barro es más o menos la forma en que la gente trabaja - si deberían o no deberían.

Lo siento por ti :) No es un buen ambiente para trabajar, ya que necesitas ejercer constantemente buenas prácticas de práctica para comprenderlas y usarlas realmente.

Conozco varias empresas (incluidas las mías) que podrían marcar todas las casillas " buenas " en su lista.

Sin embargo, el diablo está en los detalles e incluso en algunas compañías con buenas políticas de SDP no todos los proyectos las siguen.

es bueno saber que MDA, DDD y Pair Programming no se usan en ninguna parte: D Martin Fowler no es un dios, solo chicos con algunas ideas raras.

  • Test-Driven-Development - si quieres
  • Pruebas unitarias: sí
  • Revisiones de código - kindda
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - sí, Seam
  • UML - kindda
  • Integración continua: sí y no
  • Herramientas de cobertura de código: sí y no

• Test-Driven-Desarrollo - Apenas comenzando a asumir el control, muy contento con él hasta el momento

• ¿Prueba? - Por supuesto, todo el mundo lo hace, ¿quién quiere QA reírse de ellos?

• Unidad de Pruebas - por cerca de 2 años, ha ayudado a la estabilidad y pruebas se ejecute cada proyecto de construcción

• Código Comentarios - aquí y allá, sobre todo con los cambios de última hora

• Ágil - Amor ágil y su repsonsiveness

• Programación en Parejas - Simplemente tratar a cabo en algunos puntos, los primeros resultados prometedores

• integración continua - CruiseControl.NET para el triunfo !!! una gran ayuda, tales

• Herramientas de código de cobertura - Siempre durante cada prueba unidad, CC.NET publica esta información al mundo

• Comunicación (Wiki, correo, mensajería instantánea, Listas de correo, otros documentos) - WIKI, IM, Campfire

• Tamaño del equipo - pequeña, cuando un equipo de producto llega a grande que se dividen en equipos de características

• Reuniones - cortos y no muy a menudo, es más probable que obtener reuniones pasillo Get

• métricas de código - Sólo complejidad ciclomática

• análisis de código estático - Realmente probar este uso Más FxCop y de VSTS de cosecha propia

• El seguimiento de errores - TFS para ventanas y Traq para Mac

Pruebas: hago un montón de pruebas del sistema, y ​​una cantidad mucho más pequeña de las pruebas unitarias. Trato de usar el desarrollo impulsado por la prueba cuando tiene sentido, pero se siente como la mayoría de las veces no tiene sentido para el núcleo de lo que estoy haciendo.

En cuanto al resto, no estoy seguro si lo hago correctamente "lenguajes específicos de dominio" o no, pero hago uso de una gran cantidad de código generado automáticamente para capturar el material repetitivo en mi trabajo - Cuento 9 scripts de Perl generando casi 100.000 líneas de código.

En cuanto al resto, el tamaño del equipo es siempre uno. Yo uso de PC-Lint para el análisis de código estático aproximadamente una vez al año. Yo uso gprof y valgrind muy fuertemente (que parece que no se han mencionado esta clase de herramientas). He estado suspirando por un sistema de seguimiento de errores adecuada desde hace años, pero todavía estoy usando software de la lista de tareas y el correo electrónico para manejar la situación en el momento.

  • Desarrollo basado en pruebas - No
  • Diseño controlado por el dominio - No
  • Modelo-Driven-Diseño / Arquitectura - No
  • ¿Pruebas? - Casi nunca
  • Pruebas unitarias: casi nunca
  • Pruebas de integración: no
  • Pruebas de aceptación: no
  • Revisiones de código - No
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Spring, Hibernate, Wicket
  • Ágil - No
  • Programación de pares: no
  • UML: solo bocetos
  • Idiomas específicos del dominio: no
  • Especificación de requisitos (¿cómo?): Obtenemos una gran especificación de requisitos del cliente y utilizamos mapas mentales para extraer las características reales que luego se estiman
  • Integración continua: no
  • Herramientas de cobertura de código: no
  • Modelo de dominio de Aenemic - Sí
  • Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - Mapas mentales, Correo
  • Estimaciones de esfuerzo: FITA (dedo en el aire, ver aquí )
  • Tamaño del equipo: 2-6
  • Reuniones: 2-3 veces a la semana
  • Métricas de código: no
  • Análisis de código estático - No (Intentó FindBugs y Checkstyle)
  • Seguimiento de errores - Sí, Bugzilla
  • Test-Driven-Development - Casi allí.
  • Diseño controlado por el dominio - No
  • Modelo-Driven-Diseño / Arquitectura - No
  • ¿Pruebas? - Sí
  • Pruebas unitarias - Sí
  • Pruebas de integración: sí
  • Pruebas de aceptación: no
  • Revisiones de código - No
  • Innovadoras / Nuevas Tecnologías (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - ASP.NET MVC? NHibernate? Sí
  • Ágil: recién comenzado
  • Programación de pares: no
  • UML: nada formal
  • Idiomas específicos del dominio: no
  • Especificación de requisitos (¿Cómo?) - Sí. Capturar los requisitos de la historia.
  • Integración continua - Sí. TeamCity
  • Herramientas de cobertura de código: sí. NCover
  • Modelo de dominio de Aenemic - No
  • Comunicación (Wiki, Correo, MI, listas de correo, otros documentos) - MI, correo electrónico
  • Estimaciones de esfuerzo - 1,2,4,8
  • Tamaño del equipo - 4
  • Reuniones - Ponte de pie todos los días
  • Métricas de código: no
  • Análisis de código estático - No
  • Seguimiento de errores: trabajo personalizado existente

Mi departamento es un trabajo en progreso. En los últimos meses, me he esforzado por aplicar la mejora continua. Algunas cosas han sido difíciles de hablar. Sin embargo, al mirar hacia atrás, han mejorado.

  • Test-Driven-Development - De ninguna manera.
  • Domain-Driven-Design - ¿Qué es diseño ?
  • Modelo-Driven-Design / Architecture - ¿Qué es el diseño ? Tenemos un equipo de arquitectura. Con una excepción (el arquitecto más joven), no podían codificar la salida de una bolsa de papel. Sin embargo, ¡están seguros de dibujar cajas con líneas! Y establecer estándares de mierda, inútiles, sobre genéricos y completamente inútiles . (El viejo material de OPC está bien, pero el estándar de UA se ha "hecho el próximo mes" durante los últimos 4 años más o menos).
  • ¿Pruebas? - Sí, tenemos un equipo de prueba dedicado. Hay aproximadamente 1 probador por cada 10-12 desarrolladores. Están completamente inundados. Pregúntame si probamos bien .
  • Prueba unitaria : completamente informal / hasta el desarrollador. Lo hago cuando el horario que tengo me lo permite.
  • Pruebas de integración : sí. Esto es necesario dado el conjunto de productos que desarrollamos y apoyamos.
  • Prueba de aceptación : Sí, solo para trabajos con contrato.
  • Revisiones de código : siempre paga el servicio verbal, nunca lo hagas.
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Tomar nuevas dependencias está muy mal visto. Boost nunca será adoptado, por ejemplo, en general, hemos tenido la suerte de obtener versiones más nuevas de .Net, por lo general, dos años atrás de la curva.
  • Ágil : No. La gerencia afirma querer "ágil", aunque no muestran una comprensión mínima de lo que es. Recientemente modificamos nuestro proceso para que las tareas de mayor prioridad se especifiquen e implementen con ... (¡aguarde!) ¡Prioridad! La administración me dice que este es nuestro nuevo proceso "ágil". Todavía huele, camina y grazna como una cascada.
  • Programación de par : ¡De ninguna manera! Pagar a dos personas para hacer el trabajo de uno? A continuación, sugerirá que los desarrolladores deban perder el tiempo en diseños sin sentido y revisiones de código . Perros, gatos, viviendo juntos!
  • UML : No. Obtuvimos una herramienta UML una vez para ayudarnos a comprender una base de código heredada que había evolucionado. A la persona a cargo de evaluar la herramienta le encantó, ¡diseñó de forma inversa la base de código de millones de líneas + C ++ en menos de 30 segundos! Después de que los convencieron de comprarlo y los desarrolladores reales intentaron usarlo, descubrimos que realmente solo demoraron esos 30 segundos para no analizar más del 95% de la base de código. El informe de errores fue tan malo que el evaluador ni siquiera se dio cuenta de que falló. (¡ Te estoy mirando, niño! ) Solo nos tomó un año y medio para cancelar nuestras licencias por eso. ¿Ver? ¡Ágil!
  • Idiomas específicos del dominio . Probablemente se utilicen en alguna parte, aunque yo no.
  • Especificación de requisitos (¿Cómo?) - Un gerente de producto realiza vudú y los inventa. ¡A veces incluso pueden hablar con los clientes sobre ellos! Si tienes mucha suerte, incluso comprenderán la diferencia entre un caso de uso y un requisito. No cuentes con eso, sin embargo. Realmente no usamos casos.
  • Integración continua : de ninguna manera. Es mucho más emocionante cuando todo se rompe a la vez.
  • Herramientas de cobertura de código : una vez alguien puso una blankey en el servidor de repositorio de origen en la sala fría y fría del servidor. ¿Eso cuenta?
  • Modelo de dominio de Aenemic - con toda seriedad, nunca he oído hablar de esto antes.
  • Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - Memos. Lotus Notes no hace "correo electrónico". Un montón de basura recién creada.
  • Estimaciones de esfuerzo : en realidad no. En mi organización, las estimaciones son código para los objetivos. . La fecha de vencimiento de un proyecto está bloqueada durante la primera de las 5 fases "ágiles" del desarrollo de la cascada. Esas fechas de vencimiento se llaman "estimaciones de estadio", pero realmente significan "fechas de envío".
  • Tamaño del equipo : ejecuta la gama según el producto. Tenemos equipos tan pequeños como cuatro y tan grandes como quince si incluye gerentes.
  • Reuniones : no está mal si es relativamente joven y no está trabajando en más de uno o dos productos. Solo estoy obligado a asistir a 2-3 reuniones de una hora por semana.
  • Métricas de código - No.
  • Análisis de código estático - Teóricamente para .Net b / c FxCop está integrado y su uso es obligatorio según nuestro estándar, pero en realidad, no. Nadie lo revisa b / c nunca hay revisiones de código. Solo la auditoría de calidad ocasional (también conocida como auditoría de seguimiento / auditoría de papel) para garantizar que no perdamos lo que sea la certificación de este año.
  • Seguimiento de errores : sí, pero solo para problemas informados por los clientes. Los desarrolladores no pueden enviar errores descubiertos contra un producto en el que están trabajando, b / c que no es un "jugador de equipo". (El jefe de mi jefe me explicó esto con gran detalle cuando cometí ese error. Ahora soy amigable con un cliente en particular que está dispuesto a "descubrir" errores que podría mencionar "accidentalmente" en el transcurso de otra comunicación relacionada con el soporte .)

En cuanto a la gran cantidad de devotos corporativos, hay mucho peor por ahí. Dado el lugar donde vivo y la falta de trabajos de alta tecnología en el área, en realidad soy muy afortunado de tener un concierto. Sin embargo, eso no significa que me gusten las cosas tal como están las cosas. Solo lleva mucho tiempo y una presión constante intentar incluso influir en una cultura corporativa establecida.

Pero si se cansan de mis intentos de cambiar la cultura y despedirme, bueno, no creo que lloraría para dormir esa noche.

  • Test-Driven-Desarrollo: muy de vez en cuando alguien puede hacerlo por un componente. Además, la implementación de una especificación pública que viene con las pruebas de conformidad ofrece algunas de las ventajas de TDD, y un montón de lo que pasa.
  • Dominio-Driven Design: no
  • Modelo-Driven-Diseño / Arquitectura: no
  • Cómo se prueba ?: si
  • Unidad de Pruebas: algunos, aunque no completa. Una gran cantidad de componentes son bibliotecas para uso del cliente. Hay una línea muy fina entre la unidad y la prueba funcional de una aplicación "strlen".
  • Pruebas de integración: en realidad no, hay poco entre la unidad y el sistema de pruebas
  • La prueba de aceptación: Sí, y subconjuntos de las pruebas de aceptación utilizados como pruebas del sistema
  • Código Comentarios: hay un proceso formal, pero algo de código se revisa
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, descanso, ...): No
  • Ágil: no
  • La programación en parejas: no
  • UML: no
  • lenguajes específicos de dominio: muy de vez en cuando
  • Especificación de requisitos (¿cómo?): Tipo de
  • Integración continua: no, pero las construcciones diarias y la reversión de los cambios de fallo que causan a discreción del equipo de pruebas
  • Herramientas de código Cobertura: ningún requisito formal, equipo de pruebas ha sido conocido por usar ''em
  • Aenemic modelo de dominio: Yo ni siquiera sé lo que es esto
  • Comunicación (Wiki, correo, mensajería instantánea, Listas de correo, otros documentos): todos ellos, elegido ad hoc, salvo que los requisitos de diseño y documentos HTML debe estar bajo control de origen, y la documentación de la interfaz interna se genera a partir de los comentarios Doxygen en las cabeceras.
  • estimaciones de esfuerzo: un poco
  • Tamaño del equipo: unos 20 programadores, agrupados en equipos de diversas componentes de 1-4 personas. Casi nadie trabaja exclusivamente en el componente cuyo equipo al que pertenecen.
  • Reuniones: reunión semanal completa para el intercambio de informes de progreso y de otra manera comparten lo que está pasando. No hay otras reuniones programadas para los desarrolladores: Discusiones dispuestas según sea necesario.
  • métricas de código: no
  • análisis de código estático: no menos que cuentes -pedantic ;-)
  • El seguimiento de errores: Bugzilla, algo integrado con control de código
  • Test-Driven-Development: sí
  • Dominio-Impulsado-Diseño: sí
  • Modelo-Driven-Design / Architecture: sí
  • ¿Pruebas? sí
  • Pruebas unitarias: sí
  • Pruebas de integración: sí
  • Prueba de aceptación - sí
  • Revisiones de código - sí
  • Tecnologías innovadoras - sí
  • Ágil: únicamente ágil
  • Programación de par - sí
  • UML: a veces para ddd whiteboard fight
  • Idiomas específicos del dominio - sí
  • Especificación de requisitos (¿Cómo?) - en forma de ejemplos y pruebas de aceptación
  • Integración continua - sí - TeamCity
  • Herramientas de cobertura de código - sí - NCover
  • Modelo de dominio Aenemic - no estoy seguro
  • Comunicación (Wiki, Correo, MI, listas de correo, otros documentos) - wiki, correo, msn
  • Tamaño del equipo: 6+ dependiendo del proyecto
  • Reuniones - todas las mañanas a las 9:30 - SCRUM
  • Métricas de código - dunno
  • Análisis de código estático - dunno
  • Seguimiento de errores - Mantis

Y más importante...

  • Todos se van a casa a las 5:30: sí

Sin embargo, el salario es mucho más bajo porque muchas personas quieren trabajar para esta empresa. No puedo tener todo!

Mi empresa ha saltado en la mayoría de las metodologías "de boga". Unidad de Pruebas, Test Driven Development, Scrum,, integración continua, el análisis ágil Código-cobertura, etc. Me parece que estamos saltando de un producto a otro como tamaño de los equipos cambian con la economía. Hemos pasado de Rally Dev / Scrum a Jira / ágil después de un montón de despidos. Estamos utilizando selenio para pruebas automatizadas, pero ahora mirando Tellenium y de Google WebDriver.

¿Qué estamos encontrando? Los sitios que han pasado todas las pruebas creado para ella (incluyendo pruebas de carga), pueden ser increíble ineficaz cuando se analiza realmente. Después de un análisis de rendimiento del código hemos sido capaces de reducir los recursos del servidor 2/3 para uno de nuestros sitios, y todavía tenía un mejor rendimiento. Todavía pasar las mismas pruebas también.

pruebas automatizadas de aplicaciones para usuario no coge cuestiones de posicionamiento que un ser humano notaría en cuestión de segundos. Claro, podríamos pasar unas horas escribir pruebas para comprobar el posicionamiento. Pero las pruebas son quebradizos y tienen que ser reescritos cuando cambian los diseños de página, aunque sólo sea un poco. Las pruebas por lo general sólo indica el código funciona, no lo bueno que es.

He trabajado en empresas grandes y pequeñas que usan muchas tecnologías diferentes. Incluyendo simple "codificación de vaquero". Había muchos más errores cuando no empleamos planificación y ensayo de metodologías, pero se movían mucho más rápido. Empujamos a cabo cambios y correcciones en horas, no en días y semanas.

Facebook hace una cada semana (los martes) "empuje". Con bastante frecuencia hay errores en el último impulso de código (no hay suficiente prueba?), Pero a menudo lo hacen por otro impulso que el jueves o el viernes para solucionar cualquier problema. Mi conjetura es Facebook está más cerca de la metodología de "cowboy codificación" y ha estado trabajando para ellos.

  • Test-Driven-Desarrollo: no.
  • Dominio-Driven Design: no
  • Modelo-Driven-Diseño / Arquitectura: nosotros empezamos con modelos para nuestras aplicaciones
  • Cómo se prueba? sí. A veces soy la única persona que pone a prueba mis cosas. Odio esto.
  • Unidad de Pruebas - no. Esta es un área que falta en mi conjunto de habilidades que considero una alta prioridad a rememdy.
  • Pruebas de Integración - sin
  • Pruebas de Aceptación - a veces. Difícil de conseguir a los usuarios a llegar hasta el final, incluso con amenazas de lo alto.
  • Código de los clientes - no. Hemos hablado de hacerlo, pero nunca lo hacen al final. Estoy frustrado por esto.
  • Tecnologías innovadoras - no hay
  • Ágil - estamos medianamente ágil, aunque no precisamente a través de un esfuerzo premeditado
  • Par de programación - sin
  • UML - tan poco como necesitamos, pero lo hacemos modelo (estamos más ágil deliberadamente aquí).
  • lenguajes específicos de dominio - no hay
  • Especificación de requisitos (¿Cómo?) - que hacemos. Mi grupo a veces es principalmente responsable de reunir los requisitos. normalmente Estamos asistidos por un analista Biz ahora, pero que no siempre fue así. El Veep a veces nos da requisitos que vienen de no sé dónde. A veces son las cosas viejas que nunca fueron hechas, pero se habían planeado hace mucho tiempo. requisitos recogidos normalmente se colocan en un documento de Word revisado por los usuarios primarios, así como mi equipo, el analista Biz, y el Veep.
  • Integración continua - pues
  • Herramientas de código de cobertura - sin
  • Aenemic modelo de dominio - No estoy familiarizado con la suya, pero no.
  • Comunicación (Wiki, correo, mensajería instantánea, Listas de correo, otros documentos) - acaba de correo electrónico y cara a cara. Abordé este tema recientemente, porque tenemos que hacer algo más, preferiblemente un wiki. Fue colocado en un segundo plano.
  • estimaciones de esfuerzo - sí, pero no hacen ningún intento de realizar un seguimiento realmente ellos. Esta es otra área en la que me falta.
  • Tamaño del equipo - 3, yo incluido (Director <- Líder del equipo <- Me).
  • Reuniones - que se reúnen una vez a la semana, aunque no siempre. Jefe generalmente comprueba en por lo menos un par de veces a la semana de forma individual. reuniones de grupos más grandes se llevan a cabo de forma esporádica. Y por supuesto que programar las reuniones para discutir a fondo los requisitos del proyecto, según sea necesario.
  • métricas de código - nop
  • análisis de código estático - pues
  • El seguimiento de errores - registramos errores. eso es prácticamente nuestro seguimiento de errores.

Eso es. Tenemos áreas que siento que podríamos mejorar.

Actualizar:

Hemos perdido nuestro analista de negocio a un gran descanso de un par de semanas después de que envió este (principios de noviembre 08). Ya he implementado ELMAH en una aplicación existente y un desarrollo más reciente uno para ayudar en el seguimiento de errores (también conecto a una base de datos) y lo amo para la facilidad de uso, las características y la capacidad de capturar las excepciones que Aren ''t captura (que es en gran parte no utilizada, pero aún así la cobertura de fácil uso). Todavía estoy hurgando con pruebas unitarias en mi propia - Realmente necesito coger el ritmo allí (también quiero aprender MVC pero sobre todo hurgar con eso también).

Estamos desinging una nueva aplicación en este momento, y estoy haciendo un esquema DB maqueta (que conseguir algunos esquemas básicos) para 3 de los 6 módulos (Líder equipo está trabajando en los otros 3). No estoy deseando que llegue, ya que esta se desarrolla en conjunto por el 3 de nosotros (2 módulos cada uno) utilizando IronSpeed ​​Designer (6.1). Hay cosas IronSpeed ​​va a hacer por mí que me gusta, pero no es la única manera de hacer estas cosas rápidamente, y lo hace algunas cosas que no me importa para.

Nada más ha cambiado.

Aquí están mis observaciones:

  • Test-Driven-Desarrollo: No se

  • Dominio-Driven Design: Sí

  • Modelo-Driven-Diseño / Arquitectura: Sí

  • Cómo se prueba? : Sí

  • Unidad de Pruebas: Sí

  • Pruebas de integración: Sí

  • Pruebas de Aceptación: Sí

  • Código de Comentarios: No se

  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, descanso, ...): Sí

  • Ágil programación Par: No

  • UML: Sí

  • lenguajes específicos de dominio: Sí

  • Especificación de requisitos (¿cómo?) Sí

  • Integración continua: Sí

  • Herramientas de código de cobertura: No se

  • Aenemic modelo de dominio: (? ¿Qué entendemos por esto) n

  • Comunicación (Wiki, electrónico, mensajería instantánea, Listas de correo, otros documentos): Wiki, correo, mensajería instantánea, Listas de correo

  • estimaciones de esfuerzo: Sí

  • Tamaño del equipo: 2-4 miembros

  • Reuniones: Cada reuniones fix lunes y otras reuniones cada día flotando

  • métricas de código: Sí

  • análisis de código estático: No

  • El seguimiento de errores: Sí

  • Desarrollo basado en pruebas - No
  • Diseño controlado por el dominio - No
  • Modelo-Driven-Diseño / Arquitectura - No
  • ¿Pruebas? - A veces
  • Pruebas unitarias: casi nunca
  • Pruebas de integración: sí
  • Pruebas de aceptación: algunas veces
  • Revisiones de código: solo ocasionalmente
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - No
  • Ágil - No
  • Programación de pares: no
  • UML - en mi marcador, sí.
  • Idiomas específicos del dominio: C ++ es específico del dominio, ¿verdad?
  • Especificación de requisitos (¿Cómo?) - Creo que los conocemos.
  • Integración continua - Sí
  • Herramientas de cobertura de código: no
  • Modelo de dominio Aenemic: ¿Qué es un modelo de dominio?
  • Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - Correo electrónico y Skype. ¿Qué es una wiki?
  • Estimaciones de esfuerzo: 1-2 días para cualquier tarea dada
  • Tamaño del equipo: 2 ingenieros de software, 10 ingenieros de hardware
  • Reuniones: 2 veces por semana
  • Métricas de código: no
  • Análisis de código estático - No
  • Seguimiento de errores: no
  • Test-Driven-Development - No, a propósito.
  • Domain-Driven-Design - No, aún estamos averiguando el dominio.
  • Modelo-Driven-Design / Architecture - Nope
  • ¿Pruebas? - Probamos las compilaciones y hacemos pruebas a los usuarios avanzados.
  • Pruebas unitarias: nada formal (no nUnit, etc.)
  • Pruebas de integración: no
  • Prueba de aceptación - Sí
  • Revisiones de código - Occassionally.
  • Tecnologías innovadoras: herramientas aleatorias de SharePoint
  • Ágil - Sí
  • Programación de par: no
  • UML - Nunca
  • Lenguajes específicos del dominio - Nope
  • Especificación de requisitos (¿Cómo?) - Nos mantenemos al tanto de esto e iteramos. Tenemos un BA que hace algunos análisis de requisitos, pero generalmente solo invitamos al cliente a nuestra planificación y reuniones diarias a medida que avanzamos. Sin documentos formales.
  • Integración continua - Sí (cruisecontrol.net)
  • Herramientas de cobertura de código: no (pero usamos el análisis de código de Visual Studio)
  • Comunicación - Perspectiva
  • Estimaciones de esfuerzo: estadio, doblarlo y luego duplicarlo nuevamente.
  • Tamaño del equipo: 2-4
  • Reuniones: todos los días a las 9 a. M. (¡Melé!) Más una reunión semanal de planificación / revisión
  • Métricas de código - Nope
  • Seguimiento de errores - Bugzilla
  • Control de fuente - SVN
  • Test-Driven-Development - si con esto quieres decir escribir pruebas antes del código, no siempre
  • Domain-Driven-Design - DDD no puro
  • Modelo-Driven-Diseño / Arquitectura - nunca, pero realmente NUNCA, de nuevo
  • ¿Pruebas? - si, siempre
  • Pruebas unitarias: sí, siempre
  • Pruebas de integración: depende, pero tratamos de evitarlas, ya que normalmente son lentas
  • Pruebas de aceptación: sí, idealmente automatizadas
  • Revisiones de código: sí, esto está incluido en la definición de hecho
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...): no estoy seguro de que las tecnologías mencionadas sean innovadoras, pero sí de Spring, Hibernate, WS
  • Ágil - sí, esto está en mi ADN
  • Programación de pares: no siempre, pero sí (en temas nuevos, con nuevos miembros del equipo, si se solicita explícitamente)
  • UML: un poco (es decir, una clase o un diagrama de secuencia en una pizarra de vez en cuando), solo si es útil
  • Idiomas específicos del dominio: no hay uso real hasta ahora
  • Especificación de requisitos (¿cómo?): Especificaciones ligeras (por ejemplo, historias de usuarios)
  • Integración continua, por supuesto (y de acuerdo con nuestra definición de hecho, el código debe haber sido "integrado")
  • Herramientas de cobertura de código: sí (cobertura), esto está en la definición de hecho
  • Modelo de dominio Aenemic - no, tratamos de evitar eso
  • Comunicación (Wiki, Correo, mensajería instantánea, listas de correo, otros documentos): cara a cara, wiki, mensajería instantánea, correo, lista de correo (pero tratamos de evitar los documentos Word)
  • Estimaciones de esfuerzo: sí, en puntos de historia en el nivel de acumulación, en horas en el nivel de iteración
  • Tamaño del equipo: 7 +/- 2
  • Reuniones: sí, pero solo útil y siempre en el recuadro (planificación de iteraciones, reunión diaria, demostración y retrospectiva)
  • Métricas de código: sí (complejidad ciclomática, cobertura de código, estándares de codificación recopilados en sonar)
  • Análisis de código estático - sí (findbugs, checkstyle)
  • Seguimiento de errores - sí, por supuesto (pero tratamos de corregir errores tan pronto como los descubrimos)
  • Test-Driven-Development: No. En el mejor de los casos, en porciones muy pequeñas. Todos estamos hablando, pero no lo hagas.
  • Domain-Driven-Design: No. Es difícil saber qué es un "dominio" si está desarrollando un marco técnico. No tengo mucha experiencia en DDD para saber cómo hacerlo.
  • Modelo-Driven-Diseño / Arquitectura: No.
  • ¿Pruebas ?: Sí, pero no lo suficiente. Con cada lanzamiento (estamos tratando de lanzar lanzamientos menores cada 8 semanas) siempre hay más de 2 lanzamientos de servicio. Estamos en el primer año de desarrollo del producto, así que creo que esto está bastante bien.
  • Pruebas unitarias: sí. A aprox. 30% de cobertura. La mayoría de los desarrolladores ahora saben que deberían escribir pruebas de unidad para ellos mismos. Cada vez que tienen que corregir un error crítico en su propio código, pueden ver el beneficio si hubieran escrito una prueba simple por adelantado para evitar el error en primer lugar.
  • Pruebas de integración: Sí, usando Selenium y WebDriver.
  • Pruebas de rendimiento: sí, comenzando con ahora. El objetivo es archivar las mediciones de rendimiento a largo plazo y compararlas con las versiones. Usando JMeter y un servidor de prueba de rendimiento dedicado para eso.
  • Pruebas de aceptación: No realmente, pero nuestro producto también se usa internamente y recibimos comentarios muy rápido antes de que se publique. Lo considero como una prueba de aceptación.
  • Revisiones de código: No. Algunas veces, otra persona lo mira durante 30 minutos, pero eso es todo.
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...): desde mi punto de vista, esas tecnologías ya no son "innovadoras". Son más o menos de la vieja escuela ahora. Excepto JSF, que murió hace un par de años. Hizo Spring + Hibernate durante los últimos años. Ahora estoy haciendo Wicket + WS por 2 años. Se reemplazó Hibernate con iBatis SqlMaps.
  • Ágil: No.
  • Programación de pares: No.
  • UML: un poco, principalmente para diagramas de implementación. Los diagramas de clases son demasiado finos, granulares y, a menudo, no están sincronizados con la realidad. Los desarrolladores hacen lo que creen que es mejor, no lo que un diagrama UML les dice que hagan.
  • Lenguajes específicos del dominio: Sí, estamos usando la tecnología de reglas comerciales de fabricación casera. Es un DSL visual que es adecuado para los usuarios finales. Algo así como usar Visio para modelar decisiones.
  • Especificación de requisitos (¿Cómo?): No.
  • Integración continua: sí. Basado en Hudson y Maven. Las pruebas unitarias se ejecutan en cada compilación. Generaciones nocturnas adicionales con informes más detallados habilitados. A todo el equipo se le notifica sobre compilaciones fallidas (sí, se quejan de recibir demasiados correos electrónicos a veces si algo rompe la cadena y los 30 submódulos obtienen errores de compilación, por ejemplo, cuando no se puede acceder al Repositorio Maven)
  • Herramientas de cobertura de código: sí. Maven / Cobertura y Sonar.
  • Modelo de dominio aenemico: No tengo idea de lo que se supone que es esto.
  • Comunicación (Wiki, correo, mensajería instantánea, listas de correo, otros documentos): Wiki, correo electrónico, mensajería instantánea, reuniones diarias, manuales de usuarios finales y desarrolladores escritos por un profesional / no desarrollador.
  • Estimaciones de esfuerzo: esforzarse por hacer buenas estimaciones. Pero sin reqs, son solo estimaciones aproximadas. Lo suficiente como para planear recursos.
  • Tamaño del equipo: 12
  • Reuniones: presentación diaria, retro cada 8 semanas después de cada publicación menor.
  • Métricas de código: Sonar. Buscando cumplir con la mayoría de las reglas. Sin embargo, no tuvimos tiempo de reconfigurar las reglas para satisfacer nuestras necesidades.
  • Análisis de código estático: Sonar.
  • Seguimiento de errores : JIRA

Notas:

  • Sonar es un servidor de calidad de código. Combina herramientas como PMD, Findbugs, Checkstyle, etc.
  • Test-Driven-Desarrollo - Sí
  • Dominio-Driven Design - No se
  • Modelo-Driven-Diseño / Arquitectura - n
  • Cómo se prueba? - Sí
  • Unidad de Pruebas - Sí
  • Pruebas de Integración - Sí
  • Pruebas de Aceptación - Comienza
  • Revisiones de Código - No se
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, descanso, ...) - ¿No?
  • Ágil - Sí
  • Par de programación - Sí, casi todo el tiempo
  • UML - Nada más formal que las líneas y las cajas en las pizarras.
  • -Dominio específico idiomas - Un poco
  • Especificación de requisitos (¿Cómo?) - No, nosotros tratamos de conseguir historias de usuario, si es posible
  • Integración continua - Sí
  • Herramientas de código de cobertura - n
  • Aenemic modelo de dominio -
  • Comunicación (Wiki, electrónico, mensajería instantánea, listas de correo, otros documentos) - Wiki, mensajería instantánea, correo electrónico, documentos de Word
  • estimaciones de esfuerzo - se utiliza una combinación de tamaño de la camiseta (S, M, L, XL, etc) y un sistema de puntos para la carrera por la velocidad de sprint.
  • Tamaño del equipo - 6-> 8
  • Reuniones - Ponte de pie todos los días
  • Métricas de código: no
  • Análisis de código estático - No
  • Seguimiento de errores - Bugzilla / Version One
  • Test-Driven-Development - Aunque debería ser como se intentó traer esto, pero no creo que haya despegado, así que esto sigue siendo un no pero con más detalles ahora.
  • Diseño controlado por el dominio - No
  • Modelo-Driven-Diseño / Arquitectura - No
  • ¿Pruebas? - Sí, pero no de manera exhaustiva. Tenemos algunas pruebas unitarias, algunas pruebas de integración y algunas pruebas WatiN.
  • Pruebas unitarias: tenemos algunas para nuestro nuevo desarrollo, pero las heredadas no.
  • Pruebas de integración: generalmente, cuando es aplicable. Mi equipo siendo el equipo web no parece tener esto demasiado a menudo todavía.
  • Prueba de aceptación: tenemos algunos niveles de esto. La primera es cuando se desarrolla una nueva característica y tiene que obtener una aprobación inicial de alguien de otro equipo que ingresará el contenido antes incluso de que esté integrado con el código. El segundo es cuando las características se demuestran al final de un Sprint para obtener más comentarios sobre lo que no se ve bien o no funciona bien. Luego hay un tercer nivel justo antes de que entre en producción como final, "Sí, esto no arruina lo que ya tenemos", más o menos.
  • Revisiones de código: ya no se hacen, pero probablemente sería una buena acción.
  • Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...): se están aplicando algunas ideas RESTful en nuestro proyecto y estamos utilizando algunas características del framework .Net como expresiones lambda.
  • Agile - Usamos Scrum y tenemos stand ups, storyboard, Iteration Planning Meeting (Eso es realmente para el sprint y no una iteración que es de 2 sprints ya que después de cada par de sprints el trabajo se muestra a los ejecutivos y otros departamentos mientras que el otro demo es para un arquitecto y el jefe del equipo de ingreso de contenido).
  • Programación de pares: tenemos emparejamiento en la mayoría de los nuevos desarrollos que no se ven como trabajo pesado. Entonces, para quien quiera trabajar en la parte de Entrenamiento del sitio, un par lo hará en lugar de un solo desarrollador.
  • UML: no, y la herramienta para UML fue eliminada en nuestras máquinas nuevas
  • Idiomas específicos del dominio: no, pero hay una terminología que es la propia interpretación de la empresa de las cosas, ya que algunos nombres de productos internos chocan con términos que otros pueden usar para varias cosas.
  • Especificación de requisitos (¿Cómo?) - Esto puede ir desde un documento de gran tamaño explicando lo que se debe hacer a las conversaciones sobre qué hacer y luego probarlo e intentarlo luego.
  • Integración continua: contamos con Cruise Control.Net para nuestra IC que se usa cuando realizamos cambios de código.
  • Herramientas de cobertura de código - No.
  • Modelo de dominio de Aenemic - Algo en eso no hay realmente un gran modelo de dominio aquí.
  • Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - En orden de importancia: correo electrónico, mensajería instantánea, teléfono y luego visitando el cubículo. Hay una reunión semanal del equipo con el gerente de aplicaciones y actualizaciones diarias del gran proyecto.
  • Estimaciones de esfuerzo: esto es ahora común en cada sprint, aunque a veces esto se hace enviando una hoja de cálculo para que todos puedan incluir sus estimaciones de que el Scrum Master combina todos los resultados para que podamos verlos al final.
  • Tamaño del equipo: 5 desarrolladores con un líder de equipo, un analista de negocios que es el Scrum Master, un probador para supervisar lo que tenemos y otros fuera del equipo que aparecen según sea necesario, incluidos los autores del contenido para usar realmente el sistema.
  • Reuniones: para el negocio, cortas, efectivas y generalmente buenas para comunicarnos donde están las cosas actualmente.
  • Métricas de código: ninguna que yo sepa.
  • Análisis de código estático - No.
  • Seguimiento de errores: Quality Center se utiliza para el seguimiento de defectos. * Control de fuente: ahora estamos usando Subversion. Para cualquier función o error creamos una nueva rama para que podamos trabajar de forma independiente y no tener nuestros compromisos romper la construcción, ya que estamos trabajando en algo. Sin embargo, todos compartimos la misma base de datos para el desarrollo que a veces puede ser interesante.
  • IDE - Visual Studio 2008 en XP usando .Net 3.5 y Sitecore 6.1
  • ...

El equipo está en nuestro tercer equipo en los casi 2 años que he estado aquí.

El proyecto CMS es el gran proyecto en el que todos estamos trabajando aunque hay varias solicitudes de soporte que los demás manejan.

Hubo muchos cambios en el año en que tuvimos un VP de IS. La producción está más bloqueada y hay más trabajo para realizar un lanzamiento ya que ahora hay un procedimiento de lista de verificación y más aros que pueden ser útiles.

Soy uno de los dos programadores en una pequeña empresa de software con propietarios MUY no técnicos ("qué es un ''navegador''", se lo pregunté seriamente la semana pasada).

La ventaja es que puedo elegir por mí mismo en la mayoría de estos puntos.

Test-Driven-Development - Nuestro propietario tuvo una mala experiencia o algo así. Mencione las pruebas de la manera incorrecta y juraría que está actuando a partir del PTSD.

Dominio-Driven-Design - Sí.

Modelo-Driven-Design / Architecture - Sí.

¿Pruebas? - No. Las pruebas recaen en el personal de ventas y soporte y los propietarios. Así que nada se prueba mucho una vez que sale de mi máquina de desarrollo.

Pruebas unitarias: si me pillan haciéndolo, es posible que me despidan. Y es en serio lo único que podría hacer que me despidan.

Pruebas de integración: consulte "¿Prueba?"

Prueba de aceptación: bueno, tenemos que implementarla en algún momento, ¿verdad?

Revisiones de código: nadie más lo entendería. He visto a todos los demás. Ojalá no lo hubiera hecho

Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Sí. Pero me da mal gusto por eso. Soy el "niño" que no sabe nada que no se haya inventado en los últimos diez años (a pesar de tener 30 años y tener "Lecturas en sistemas de bases de datos" en mi escritorio).

Ágil - No hago cascada. Pero tampoco realmente soy ágil.

Programación de pares: no desea intentar hablar con el otro "programador" que trabaja en nuestra empresa.

UML - No. Pero a veces dibujo cuadros con identificadores en mi pizarra. Los patrones así. Lo bueno es que no tienen una inclinación más técnica, o probablemente vería más cajas.

Lenguajes específicos del dominio - No.

Especificación de requisitos (¿Cómo?) - No.

Integración continua - No.

Herramientas de cobertura de código - No.

Modelo de dominio aenemico - Sip. Lo intenté. La mayoría de mis situaciones no me gustan y no las uso.

Comunicación (Wiki, Correo, mensajería instantánea, listas de correo, otros documentos) - Intenté, no pude obtener la aceptación de un compañero de trabajo. Nuestra instalación de MediaWiki todavía tiene el gráfico predeterminado del logotipo.

Estimaciones de esfuerzo: debemos estimar cuánto demorará cada trabajo en horas. Eso es lo que se le factura al cliente. Y eso es lo que se espera que gastemos en el proyecto. Incluso hacemos esto cuando buscamos nuevos clientes y desarrollamos nuevas aplicaciones desde cero, así como cuando corregimos errores (sí, cobramos a los clientes por eso), incorporamos funciones, etc.

Tamaño del equipo: 1. Y déjenme decir que esta no es una buena manera de trabajar. Es mucho mejor poder intercambiar ideas de otros programadores capaces en tiempo real.

Reuniones: pocas horas que valen una semana, a veces el doble y raramente menos que eso. La mitad de las reuniones que hago son con clientes, tienen son totalmente internas.

Métricas de código - No.

Análisis de código estático - No.

Seguimiento de errores: no tanto como debería.

Trabajo para una consultoría de Ruby on Rails en Brisbane, Australia.

  • Desarrollo impulsado por prueba : Esto se empuja muy, muy duro en nuestra oficina. No probar se ve como "increíblemente estúpido". Usted escribe el código, ¿cómo se asegura por medio de un proceso automatizado como CI, que todavía funciona? Pruebas.

  • ¿Pruebas? : Ver el punto uno.

  • Pruebas unitarias : todo el tiempo, usando RSpec. Soy "fluido" en Test :: Unit y Shoulda también.

  • Pruebas de integración : una vez más, todo el tiempo, pepino.

  • Prueba de aceptación : con nuestros tickets los "entregamos" con un Criterio de Aceptación. Luego, el cliente debe "Aceptar" o "Rechazar" siguiendo la bola que rebota. Los Criterios de aceptación tienen la ventaja de ser también en lo que están escritas nuestras características de Pepino.

  • Revisiones de Código && Programación de Par : Emparejamos . Es la versión instantánea de la revisión del código. Es increíble porque puedes relajarte y ver trabajar a alguien más, escriben la prueba y luego escribes el código para que pase la prueba. Si estás enfermo, la otra persona sabe lo que estabas haciendo y puede emparejarse con otra persona.

  • Tecnologías innovadoras : como usamos Rails, nos gusta mucho el REST.

  • Ágil : trabajamos en iteraciones de 2 semanas usando Pivotal Tracker .

  • Especificación de requisitos (¿Cómo?) : Al usar las características en Pivotal Tracker, el cliente puede especificar qué requisitos tienen y luego los desarrollamos (generalmente hablando con ellos) en criterios de aceptación y, finalmente, características de Real World.

  • Integración continua : utilizamos un servidor de CI que desarrollé llamado constructivo . Esto fue construido con la idea de ser como Integridad, pero con trabajos en segundo plano y mejor soporte para sucursales. Ahora que Integrity tiene formación en segundo plano, aún existe el soporte de ramificación que nos mantiene "adelante".

  • Herramientas de cobertura de código : RCov a veces. No estamos realmente preocupados con la cobertura del código, ya que probamos TODO antes de escribirlo. Si existe, hay algo que lo probará.

  • Comunicación (Wiki, correo, mensajería instantánea, listas de correo, otros documentos) : nos comunicamos con nuestros clientes principalmente a través del correo electrónico, pero también tenemos "standups" con ellos usando Skype. También hemos usado Basecamp para esto. Quiero usar Google Wave para nuestro próximo proyecto, solo como un pequeño experimento. Creo que sería realmente útil.

  • Tamaño del equipo : Tenemos 4 personas en nuestro equipo, generalmente 2 parejas a menos que alguien esté enfermo.

  • Reuniones : Tenemos un "scrum" / "standup" por las mañanas que dura aproximadamente 15 minutos. La idea de esto es que repases lo que hiciste el día anterior, cualquier problema que encuentres, lo que vas a hacer hoy y algo "nuevo y brillante" que hayas encontrado. Esto no debería convertirse en una reunión de proyecto. Esos son para después del standup si es necesario.
  • Seguimiento de errores : Nuevamente usamos Pivotal Tracker. El cliente puede presentar un error aquí y luego (idealmente) escribir cómo duplicarlo. Luego, escribimos una prueba para asegurarnos de que esto nunca vuelva a ocurrir (también conocido como: Pruebas de regresión) y pasa por el mismo proceso de trabajo que nuestras características, entregamos y el cliente acepta.

Trabajo para Chillisoft.co.za en Sudáfrica

Desarrollo basado en pruebas: hemos utilizado las prácticas de Desarrollo basado en pruebas desde el primer libro de Kent Beck en el que se aplica. Usamos NUnit y R # como el corredor de prueba.

¿Pruebas? : Además de TDD hacemos pruebas manuales (Visual) y esto se automatiza cuando es necesario. Las tecnologías utilizadas para la automatización dependen de UI Technologies.

Prueba unitaria : ver TDD.

Pruebas de integración : Sí, pero aún no las utilizamos de manera ubicua.

Pruebas de aceptación : Hacemos desarrollo de software personalizado para clientes externos a los que no se les paga hasta que acepten, por lo tanto, sí.

Revisiones de código : Programado bimestralmente para cada proyecto. Incluso aquellos que han sido programados por pares / pares.

Programación de pares : hacemos la mayor parte de nuestra codificación por parejas, pero ciertamente hay algunas tareas y algunas etapas del proyecto donde esto es menos eficiente. Lo que hacemos es durante el inicio del proyecto (primeras semanas de cada fase) emparejamos el programa. En las etapas finales no lo hacemos. También tenemos momentos específicos (8 horas por semana por desarrollador) cuando trabajamos en proyectos de código abierto, todos están programados por pares. Todas nuestras máquinas están configuradas con múltiples teclados y mouse para facilitar la interacción fluida entre desarrolladores.

Tecnologías innovadoras : Hemos realizado una gran cantidad de trabajo en Habanero y utilizamos este marco junto con un contenedor DI Unity y RhinoMocks.

Ágil : hemos utilizado filosofías ágiles durante 8 años y seguimos experimentando con herramientas y filosofías a medida que avanzamos por este camino.

Especificación de requisitos (¿Cómo?) : Capturamos historias de usuarios (Casos de uso) para las próximas iteraciones en MSWord. Luego capturamos el resumen de estos en Jeera con estimados de esfuerzo, etc. que manejan gráficos de extracción, etc.

Integración continua : actualmente estamos usando Hudson que funciona sobre SVN.

Herramientas de cobertura de código: ejecutamos la cobertura de código para cada proyecto como parte de nuestra compilación nocturna. Hemos integrado el informe resultante en los informes de Hudson para que podamos rastrear estos diarios para cada proyecto.

Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) : Obviamente nos comunicamos de muchas maneras diferentes, tenemos un Wiki interno, etc.

Tamaño del equipo : tenemos 15 desarrolladores de software.

Reuniones : tenemos un "scrum" cada mañana que dura aproximadamente 10 minutos.

Seguimiento de errores: utilizamos diferentes sistemas para el seguimiento de errores internos (es decir, durante el desarrollo y las pruebas internas) y para el seguimiento de errores externos, es decir, errores de los clientes. Seguimiento interno (es decir, durante pruebas internas y desarrollo) usamos redmine. Seguimiento externo (es decir, para nuestros clientes) usamos Mantis.

¿Has echado un vistazo a NDepend? La herramienta analiza el código C # y .NET y viene con muchas características geniales para examinar los resultados del análisis. Con NDepend puede escribir reglas sobre el código, puede comparar 2 versiones de la base de código y puede aprovechar más de 80 métricas de código .

Además, la herramienta viene con varias características de gran visualización como:

Gráfico de dependencia:

Matriz de dependencia:

Code metric visualization through treemaping: