¿Cómo es realmente el desarrollo de software en su empresa (metodologías, herramientas, tools)? [cerrado]

Creo que el famoso Gran Bola de Barro patrón describe una gran cantidad de entornos de trabajo y le 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 la Gran Bola de Barro prevalece en un porcentaje deprimentemente grande de situaciones de desarrollo. Puede preguntar sobre el desarrollo impulsado por pruebas y el seguimiento de defectos y otro tipo de cosas de ese tipo, pero si la verdad se dice por lo que he visto, Yo diría que la Gran Bola de Barro es más o menos la forma de facto en que la gente trabaja should ya sea que deban o no.

• Test-Driven-Development-Almost there.
• Domain-Driven-Design-No
• Model-Driven-Design / Architecture - No
• ¿Haces pruebas? - Sí
• Pruebas unitarias-Sí
• Pruebas de integración-Sí
• Prueba de aceptación-No
• Revisiones de código-No
• Tecnologías innovadoras / Nuevas (Spring, Hibernate, Wicket, JSF, WS, REST,...) - ASP.NET ¿MVC? ¿NHibernate? Sí
• Ágil-Acaba de empezar
• Programación de pares-No
• UML - Nada formal
• Lenguajes específicos de dominio-No
• Especificación del requisito (¿Cómo?)- Sí. Capturar los requisitos de la historia.
• Integración continua-Sí. TeamCity
• Código-Herramientas de cobertura-Sí. NCover
• Modelo de Dominio Aenémico-No
• Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - Mensajería instantánea, Correo electrónico
• Estimaciones del esfuerzo-1,2,4,8
• Tamaño del equipo-4
• Reuniones - Daily stand up
• Métricas de código-No
• código Estático análisis-No
• Seguimiento de errores - Trabajo personalizado existente

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

• Desarrollo basado en pruebas: sí
• Diseño basado en el dominio: sí
• Diseño/Arquitectura basados en modelos: sí
• ¿Haces pruebas? sí
• Pruebas unitarias-sí
• Pruebas de integración-sí
• Pruebas de aceptación-sí
• Revisiones de código-sí
• Tecnologías innovadoras-sí
• Ágil-únicamente ágil
• Programación de pares-sí
• UML-a veces para peleas de pizarra ddd
• Idiomas específicos del dominio - sí
• Especificación del requisito (¿Cómo?) en forma de ejemplos y pruebas de aceptación
• Integración continua-sí-TeamCity
• Código-Herramientas de cobertura-sí-NCover
• Modelo de Dominio Aenémico-no está seguro
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) - wiki, mail, msn
• Tamaño del equipo - 6 + depende del proyecto
• Reuniones-todas las mañanas a las 9: 30-SCRUM
• Métricas de código-no sé
• Análisis de código estático - no sé
• Seguimiento de errores-Mantis

Y lo más importante...

• Todos se van a casa a las 5: 30: SÍ

Sin embargo, el salario es mucho más bajo porque mucha gente quiere trabajar para esta empresa. ¡No puedo tenerlo todo!

• Desarrollo basado en pruebas: 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ás desarrollando un marco técnico. No tiene mucha experiencia en DDD para saber cómo hacerlo.
• Model-Driven-Design/Architecture: Nope.
• ¿Haces pruebas?: Sí, pero no lo suficiente. Con cada lanzamiento (estamos tratando de lanzar lanzamientos menores cada 8 semanas) siempre hay más de 2 versiones de servicio. Estamos en el primer año de desarrollo de productos, así que creo que esto está bastante bien.
• Pruebas unitarias: Sí. A aprox. 30% de cobertura. La mayoría de los desarrolladores saben ahora que deben escribir pruebas unitarias por sí 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 pruebas de rendimiento dedicado para eso.
• Pruebas de aceptación: En realidad no, pero nuestro producto también se usa internamente y estamos recibiendo comentarios bastante rápido antes de que se lance. Lo cuento como prueba de aceptación.
• Revisiones de código: No. A veces, alguien más 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". Ahora son de la vieja escuela. Excepto JSF, que murió hace un par de años. Hizo Primavera + Hibernar durante el último par de años. Ahora haciendo Wicket + WS durante 2 años. Reemplazado Hibernate con iBATIS SqlMaps.
• Ágil: No.
• Par Programación: 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 utilizando la tecnología de reglas de negocio casera. Es un DSL visual que es adecuado para usuarios finales. Es como usar Visio para modelar decisiones.
• Especificación del requisito (¿Cómo?): No.
• Integración Continua: Sí. Basado en Hudson y Maven. Las pruebas unitarias se ejecutan en cada compilación. Compilaciones nocturnas adicionales con informes más detallados habilitados. Todo el equipo es notificado sobre compilaciones fallidas (sí, se quejan de recibir demasiados correos a veces si algo rompe la cadena y los 30 submódulos obtienen fallas de compilación, por ejemplo, cuando el repositorio Maven es inalcanzable)
• Herramientas de cobertura de código: Sí. Maven / Cobertura y Sonar.
• Modelo de Dominio Aenémico: No hay idea de lo que se supone que es esto.
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos): Wiki, Mail, IM, Reuniones diarias de standup, Manuales de usuario Final y desarrollador escritos por un profesional/no desarrollador.
• Estimaciones de esfuerzo: Esforzándose por hacer buenas estimaciones. Pero sin reqs, son solo estimaciones aproximadas. Lo suficientemente bueno para la planificación de recursos sin embargo.
• Tamaño del equipo: 12
• Reuniones: Standup diario, retro cada 8 semanas después de cada lanzamiento 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-Development-No
• Domain-Driven-Design-No
• Model-Driven-Design / Architecture - No
• ¿Haces pruebas? - Casi nunca
• Pruebas unitarias-Casi nunca
• Pruebas de integración-No
• Prueba de aceptación-No
• Revisiones de código-No
• Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST,...)- Primavera, Hibernación, Wicket
• Ágil-No
• Programación de pares-No
• UML-just bocetos
• Lenguajes específicos de dominio-No
• Especificación del requisito (¿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
• Código-Herramientas de cobertura-No
• Modelo de Dominio Aenémico-Sí
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) - Mapas mentales, Mail
• Estimaciones de esfuerzo - FITA (Dedo en el aire, ver aquí)
• Tamaño del equipo-2-6
• Reuniones-2-3 veces por semana
• Métricas de código-No
• Análisis de código estático-No (Probado FindBugs y Checkstyle)
• Seguimiento de errores-Sí, Bugzilla

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

Conozco varias compañías (incluidas las mías) que podrían marcar todas las casillas ' bueno' en su lista.

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

• Test-Driven-Development-si con esto te refieres a escribir pruebas antes del código, no siempre
• Diseño basado en el dominio-no DDD puro
• Model-Driven-Design / Architecture-never, but really NEVER, again
• ¿Haces pruebas? - sí, 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 el 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í a Spring, Hibernate, WS
• Ágil-sí, esto está en mi ADN
• Emparejar la programación-no siempre, pero sí (sobre temas nuevos, con nuevos miembros del equipo, si se les pregunta 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
• Lenguajes específicos de dominio-no reales uso hasta ahora
• Especificación del requisito (¿Cómo?)- especificaciones ligeras (por ejemplo, historias de usuario)
• Integración continua-por supuesto (y de acuerdo con nuestra definición de done, el código debe haber sido "integrado")
• Código-Herramientas de cobertura-sí (cobertura), esto está en la definición de hecho
• Modelo de Dominio Aenémico-no, tratamos de evitar que
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) - cara a cara, wiki, IM, mail, lista de correo (pero nosotros trate de evitar documentos de Word)
• Estimaciones de esfuerzo-sí, en puntos de historia en el nivel de backlog, en horas en el nivel de iteración
• Tamaño del equipo - 7+/-2
• Reuniones - sí, pero solo una útil y siempre en caja (planificación de iteración, 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 recogidos 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 - Aunque debería ser como se intentó introducir esto, pero no creo que haya despegado, por lo que sigue siendo un no, pero con más detalles ahora.
• Domain-Driven-Design-No
• Model-Driven-Design / Architecture - No
• ¿Haces pruebas? - Sí, pero no exhaustivamente. 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 lo hagas.
• Pruebas de integración - Generalmente, cuando es aplicable. Mi equipo siendo el equipo web no parece tener esto demasiado a menudo todavía.
• Pruebas de aceptación - Tenemos algunos niveles de esto. La primera es cuando se está desarrollando una nueva característica y tiene que obtener una aprobación inicial de alguien de otro equipo que ingresará el contenido que viene antes de que se integre con el código. La segunda 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 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", algo así.
• Revisiones de código - Estas ya no se hacen, pero probablemente sería una buena cosa.
• Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST,...)- Hay algunas ideas RESTful que se aplican en nuestro proyecto y estamos utilizando algunas características de la. Net framework como lambda expresiones.
• Ágil - Utilizamos Scrum y tenemos stand ups, story board, Reunión de Planificación de Iteración (Que es realmente para el sprint y no una iteración que es 2 sprints como después de cada par de sprints el trabajo se muestra a los ejecutivos y otros departamentos, mientras que la otra demostración es para un arquitecto y el jefe del equipo de entrada de contenido.)
• Programación de pares - Tenemos emparejamiento en la mayoría de los nuevos desarrollos que no se ven como trabajo pesado. Así que para quien quiera trabajar en la parte de formación del sitio, un par lo hará en lugar de solo un desarrollador.
• UML-No, y la herramienta para UML se eliminó en nuestras nuevas máquinas
• Lenguajes específicos del dominio: No, pero hay cierta terminología que es la propia interpretación de las cosas de la compañía, ya que algunos nombres de productos internos chocan con términos que otros pueden usar para varias cosas.
• Especificación del requisito (¿Cómo?)- Esto puede variar desde un gran documento de Word que detalla lo que se debe hacer hasta conversaciones sobre qué hacer y luego intenta esto y lo otro después.
• Integración continua - Tenemos Crucero Control.Net ejecutar para nuestro CI que se utiliza cuando confirmamos cambios de código.
• Herramientas de cobertura de código-No.
• Aenemic Domain Model - Algo en que 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, luego visitar cubículo. Hay una reunión semanal del equipo con el gerente de aplicaciones y standups diarios en el gran proyecto.
• Estimaciones de esfuerzo - Esto ahora es común en cada sprint, aunque a veces esto se hace enviando una hoja de cálculo para que todos pongan en sus estimaciones que el Scrum Master combina todos los resultados para que podamos ver al final.
• Tamaño del equipo: 5 desarrolladores con un líder de equipo, un analista de negocios que es el Maestro de Scrum, un probador para supervisar lo que tenemos y otros fuera del equipo que aparecen según sea necesario, incluidos los autores de contenido para usa el sistema.
• Reuniones: de negocios, cortas, efectivas y generalmente buenas para comunicarse donde están las cosas actualmente.
• Métricas de código - Ninguna que yo sepa.
• Análisis de código estático - No.
• Bug tracking - Quality Center se utiliza para el seguimiento de defectos. * Control de código fuente - Estamos usando Subversion ahora. Para cualquier característica o bug creamos una nueva rama para que podamos trabajar de forma independiente y que nuestros commits no rompan la compilación mientras estamos trabajando algo. Sin embargo, todos compartimos la misma base de datos para el desarrollo que puede ser interesante a veces.
• IDE-Visual Studio 2008 en XP usando. Net 3.5 y Sitecore 6.1
• ...

El equipo está en nuestro 3er equipo líder 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 vienen y que otros manejan.

Ha habido muchos cambios en el año que hemos tenía un vicepresidente de EI. La producción está más bloqueada y hay más trabajo para hacer una liberación, 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 de una pequeña empresa de software con propietarios muy no técnicos ("¿qué es un 'navegador'"-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 equivocada y juraría que está actuando por trastorno de estrés postraumático.

Domain-Driven-Design - Yep.

Model-Driven-Design/Architecture - Yep.

¿Haces 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 podría ser despedido. Y en serio es lo único que podría hacer que me despidan.

Pruebas de integración-Ver " ¿Pruebas?"

Pruebas de aceptación - Bueno, tenemos que implementarlo en algún momento, ¿verdad?

Revisiones de código - Nadie más lo entendería. He visto a todos elses. Ojalá no lo había hecho.

Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST,...- Sí. Pero recibo críticas por ello. 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 caigo en cascada. Pero tampoco soy muy ágil.

Programación de pares - No quieres tratar de hablar con el otro "programador" que trabaja en nuestra empresa.

UML - No. Pero yo dibuje cajas con identificadores en ellas a veces en mi pizarra. A los jefes les gusta eso. Menos mal que no están más inclinados técnicamente, o probablemente vería más cajas.

Lenguajes específicos de dominio-No.

Especificación del requisito (¿Cómo?)- Nope.

Integración continua - No.

Código-Herramientas de cobertura - No.

Modelo de Dominio Aenémico - Yep. Pruébelo. La mayoría de mis situaciones no me gusta y no lo uso.

Comunicación (Wiki, Correo, IM, Listas de correo, otros documentos) - Intentado, no pudo conseguir el buy-in del compañero de trabajo. Nuestra instalación de MediaWiki todavía tiene el gráfico del logotipo predeterminado.

Estimaciones de esfuerzo - Tenemos que estimar cuánto tiempo tomará cada trabajo en horas. Eso es lo que se factura al cliente. Y eso es lo que se espera gastar en el proyecto. Incluso hacemos esto cuando estamos buscando nuevos clientes y desarrollando nuevas aplicaciones desde cero, así como cuando hacemos correcciones de errores( sí, cobramos a los clientes por eso), adiciones de características, sucesivamente.

Tamaño del equipo - 1. Y permítanme decir que esta no es una buena manera de trabajar. Es mucho mejor poder rebotar ideas de otros programadores capaces en tiempo real.

Reuniones - pocas horas por semana, a veces el doble y rara vez menos que eso. La mitad de las reuniones que hago son con clientes, 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 consultora Ruby on Rails en Brisbane, Australia.

• Test-Driven-Development: Esto se presiona muy, muy duro en nuestra oficina. No probar es visto 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? Prueba.

• ¿Haces pruebas?: Véase el punto uno.

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

• Pruebas de integración : De nuevo, todo el tiempo, Pepino.

• Pruebas de Aceptación: Con nuestros boletos los "entregamos" con un Criterio de Aceptación. A continuación, el cliente tiene que "Aceptar" o "Rechazar" siguiendo la pelota que rebota. El Criterio de Aceptación tiene la ventaja de ser también en lo que están escritas nuestras características de pepino.

• Code Reviews & & Pair Progamming: Nos emparejamos. Es la versión instantánea de code review. Es increíble porque puedes sentarte y ver a alguien trabajar, escriben la prueba y luego escribes el código para que pase la prueba. Si estás enfermo, entonces la otra persona sabe lo que estabas haciendo y puede emparejarse con otra persona.

• Tecnologías innovadoras : Porque usamos Rails, nos gusta mucho el DESCANSO.

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

• Especificación del Requisito (¿Cómo?) : Usando 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, en características del Mundo real.

• Integración continua : Utilizamos un servidor CI que desarrollé llamado construct. Esto fue construido con la idea de ser como Integridad, pero con trabajos de fondo y un mejor soporte para las ramas. Ahora que la Integridad tiene un fondo de construcción, hay todavía el soporte de ramificación nos mantiene "por delante".

• Herramientas de cobertura de código : RCov a veces. No estamos realmente preocupados con la cobertura de 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 utilizando el correo electrónico principalmente, pero también tenemos "standups" con ellos usando Skype. También hemos utilizado Basecamp para esto. Estoy queriendo para usar Google Wave para nuestro próximo proyecto, como un pequeño experimento. Creo que sería de mucha ayuda.

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

• Reuniones : Tenemos un "scrum"/"standup" por las mañanas que dura unos 15 minutos. La idea de esto es que repases lo que hiciste el día anterior, cualquier problema que hayas encontrado, lo que vas a hacer hoy y algo "nuevo y brillante" que hayas encontrado. Esto debería no convertirse en una reunión de proyecto. Esos son para después del standup si es necesario.
• Bug tracking: De nuevo usamos Pivotal Tracker. El cliente puede archivar un error aquí y luego (idealmente) escribir cómo duplicarlo. Luego escribimos una prueba para asegurarnos de que esto nunca vuelva a suceder (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 estado usando prácticas de Desarrollo basadas en Pruebas desde el primer Libro de Kent Beck que se aplica en todo momento. Utilizamos NUnit y R # como el corredor de prueba.

¿Haces pruebas?: Además de TDD hacemos pruebas manuales (Visuales) y esto se automatiza cuando es necesario. Las tecnologías utilizadas para la automatización dependen de las tecnologías de interfaz de usuario.

Pruebas unitarias: Véase TDD.

Integration Testing: Sí, pero aún no lo usamos de forma 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: Programadas bimensualmente para cada proyecto. Incluso aquellos que han sido programados par/par.

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

Tecnologías innovadoras : Hemos hecho una gran cantidad de trabajo sobre Habanero y utilice este marco junto con un contenedor DI Unity y RhinoMocks.

Agile: Hemos estado usando filosofías ágiles durante 8 años y seguimos experimentando con herramientas y Filosofías a medida que continuamos por este camino.

Especificación del Requisito (¿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 estimaciones de esfuerzo, etc. que maneja dibujar gráficos, etc.

Continuo Integración: 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 Hudson para que podamos rastrearlos diariamente para cada proyecto.

Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) :Obviamente nos comunicamos de muchas maneras diferentes tenemos un Wiki interno, etc.

Equipo tamaño: Tenemos 15 desarrolladores de software.

Reuniones : Tenemos un "scrum" todas las mañanas que dura unos 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 las pruebas internas y dev) utilizamos redmine. Seguimiento externo (es decir, para nuestros clientes) utilizamos Mantis.

* Test-Driven-Development-Just starting to take over, very happy with it so far

* ¿Haces pruebas? - Por supuesto, todo el mundo lo hace, ¿quién quiere QA riéndose de ellos?

* Pruebas unitarias - Durante aproximadamente 2 años, ha ayudado con la estabilidad y las pruebas se ejecutan cada compilación

* Revisiones de código-Aquí y allá, especialmente con cualquier cambio tardío

* Ágil-El amor Ágil y su repsonsividad

* Programación de pares - Solo probándola en algunos puntos, retornos tempranos promising

* Integración continua - CruiseControl.NET ¡por la Victoria!!! Una gran ayuda

* Code-Herramientas de cobertura-Siempre durante cada ejecución de prueba unitaria, CC.NET publica esta información al mundo

* Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) - WIKI, IM, Campfire

* Tamaño del equipo: pequeño, cuando un equipo de producto llega a ser grande, nos dividimos en equipos de características

* Reuniones: cortas y no a menudo, es más probable que lleguen al pasillo reuniones

* Métricas de código-Solo complejidad ciclomática

* Análisis de código estático - Realmente probando esto Más use FxCop y VSTS de cosecha propia

* Seguimiento de errores-TFS para windows y Traq para Mac

Pruebas: Hago muchas pruebas del sistema, y una cantidad mucho menor de pruebas unitarias. Trato de usar el desarrollo impulsado por pruebas cuando tiene sentido, pero parece que 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 de si hago correctamente "lenguajes específicos de dominio" o no, pero uso mucho código generado automáticamente para capturar las cosas repetitivas en mi trabajo count Cuento 9 scripts de Perl que generan casi 100,000 líneas de codificar.

En cuanto al resto, el tamaño del equipo es siempre uno. Utilizo PC-Lint para análisis de código estático aproximadamente una vez al año. Uso gprof y valgrind bastante (parece que no has mencionado esta clase de herramientas). He estado suspirando por un sistema de seguimiento de errores adecuado durante años, pero todavía estoy usando software de lista de tareas pendientes y correo electrónico para manejarlo en este momento.

• Test-Driven-Development: muy ocasionalmente alguien podría hacerlo para un componente. Además, implementar una especificación pública que viene con pruebas de conformidad ofrece algunas de las ventajas de TDD, y mucho de eso continúa.
• Diseño basado en el dominio: no
• Model-Driven-Design/Architecture: no
• ¿Haces pruebas?: sí
• Pruebas unitarias: algunas, aunque no completas. Muchos componentes son bibliotecas para uso del cliente. Hay una línea fina entre la unidad y funcional testing of a "strlen" implementation.
• Pruebas de integración: no realmente, hay poco entre las pruebas de unidad y sistema
• Pruebas de aceptación: sí, y subconjuntos de las pruebas de aceptación utilizados como pruebas del sistema
• Revisiones de código: no hay proceso formal, pero se revisa algún código
• Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST,...): no
• Ágil: no
• Programación de pares: no
• UML: no
• Idiomas específicos del dominio: muy ocasionalmente
• Especificación del requisito (¿Cómo?): tipo de
• Integración continua: no, pero compilaciones diarias y reversión de los cambios que causan fallas a discreción del equipo de prueba
• Herramientas de cobertura de código: no hay requisito formal, se sabe que el equipo de prueba las usa
• Modelo de Dominio Aenémico: Ni siquiera sé qué es esto
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) : todos ellos, elegidos ad hoc excepto que los documentos de requerimiento y diseño deben ser HTML bajo control de código fuente, y la documentación de la interfaz interna se genera a partir de comentarios Doxygen en encabezados.
• Estimaciones de esfuerzo: un poco
• Tamaño del equipo: alrededor de 20 programadores, agrupados en equipos componentes de 1-4 personas. Prácticamente nadie trabaja exclusivamente en el componente a cuyo equipo pertenece.
• Reuniones: reunión completa semanal para intercambiar informes de progreso y compartir lo que está pasando. No hay otras reuniones programadas regularmente para desarrolladores: discusiones organizadas según sea necesario.
• Métricas de código: no
• Análisis de código estático: no a menos que cuente-pedántico; -)
• Seguimiento de errores: Bugzilla, algo integrado con source-control

• Desarrollo basado en pruebas: no.
• Diseño basado en el dominio: no
• Model-Driven-Design / Architecture: comenzamos con modelos para nuestras aplicaciones
• ¿Haces pruebas? Sí. A veces soy la única persona que prueba mis cosas. Odio esto.
• Pruebas unitarias-no. Este es un área deficiente en mi conjunto de habilidades que considero de alta prioridad para Rememdy.
• Pruebas de integración-no
• Pruebas de aceptación - a veces. Difícil conseguir que los usuarios lo hagan, incluso con amenazas desde Lo Alto.
• Revisiones de código-no. Hemos hablado de hacerlo, pero nunca lo hacemos al final. Estoy frustrado por esto.
• Tecnologías innovadoras-no
• Ágil-somos ligeramente ágiles, aunque no precisamente a través de un esfuerzo pre-meditado
• Programación de pares-no
• UML - tan poco como necesitamos, pero modelamos (somos más deliberadamente ágiles aquí).
• Lenguajes específicos de dominio-no
• Especificación del requisito (¿Cómo?- lo hacemos. Mi grupo es a veces principalmente responsable de la recopilación de requisitos. Normalmente somos asistidos por un analista de Negocios ahora, pero eso no siempre fue así. El Veep a veces nos da requisitos que vienen de no se de donde. A veces son cosas viejas que nunca se hicieron pero que se habían planeado hace siglos. por lo general, los requisitos recopilados se colocan en un documento de Word revisado por los usuarios principales, así como mi equipo, el Analista de Negocios y el Veep.
• Integración continua - no
• Código-Herramientas de cobertura-no
• Modelo de Dominio Enémico-No estoy familiarizado con el suyo, pero no.
• Comunicación (Wiki, Correo, Mensajería instantánea, Listas de correo, otros documentos) - solo correo electrónico y cara a cara. Abordé este tema recientemente porque necesitamos hacer algo más, un wiki preferentemente. Fue puesto en un segundo plano.
• Estimaciones de esfuerzo - sí, pero no hacemos ningún intento de rastrearlas realmente. Esta es otra área en la que me falta.
• Team size-3, myself incluido (Director
• Reuniones - nos reunimos una vez a la semana, aunque no siempre. Boss por lo general se registra al menos un par de veces a la semana individualmente. Las reuniones de grupos más grandes tienen lugar esporádicamente. Y, por supuesto, programamos reuniones para discutir los requisitos del proyecto según sea necesario.
• Métricas de código-no
• Análisis de código estático-nope
• Bug tracking - registramos errores. eso es más o menos nuestro seguimiento de errores.

Eso es todo. Tenemos áreas que siento como si pudiéramos mejorar.

Actualización:

Perdimos a nuestro analista de negocios a un gran despido un par de semanas después de que publiqué esto (principios de noviembre 08). Desde entonces he implementado ELMAH en una aplicación existente y una más recientemente desarrollada para ayudar en el seguimiento de errores (también nos registramos en una base de datos) y me encanta por la facilidad de uso, las características y la capacidad de capturar excepciones que no estamos capturando (que es en gran parte no utilizado, pero todavía una buena cobertura para tener). Todavía estoy husmeando con las Pruebas Unitarias por mi cuenta - realmente necesito tomar el ritmo allí (también quiero aprender MVC, pero sobre todo husmeo con eso también).

Estamos diseñando una nueva aplicación en este momento, y estoy haciendo un esquema BD simulado (que obtendrá algunos diagramas básicos) para 3 de los 6 módulos (el líder del equipo está trabajando en los otros 3). No estoy deseando que llegue, ya que esto será desarrollado en tándem por los 3 de nosotros (2 módulos cada uno) utilizando IronSpeed Designer (6.1). Hay cosas IronSpeed hará por mí lo que me gusta, pero no es la única manera de hacer estas cosas rápidamente, y hace algunas cosas que no me gustan.

Nada más ha cambiado.

Mi empresa ha saltado en la mayoría de las metodologías de "palabra de moda". Unit Testing, Test Driven Development, Scrum, Agile, Integración Continua, Análisis de Cobertura de Código, etc. Encuentro que estamos saltando de producto en producto a medida que los tamaños de los equipos cambian con la economía. Pasamos de Dev/Scrum de Rally a Jira/Agile después de muchos despidos. Estamos usando Selenium para pruebas automatizadas, pero ahora estamos mirando Tellenium y el WebDriver de Google.

¿Qué estamos encontrando? Sitios que han pasado todas las pruebas creado para ello (incluidas las pruebas de carga), puede ser increíblemente ineficiente cuando se analiza realmente. Después de un análisis de rendimiento del código, pudimos reducir los recursos del servidor en 2/3 para uno de nuestros sitios, y aún así tuvimos un mejor rendimiento. Todavía pasó las mismas pruebas también.

Las pruebas automatizadas Front-end no detectan problemas de posicionamiento que un humano notaría en segundos. Claro, podríamos pasar unas horas escribiendo pruebas para comprobar el posicionamiento. Pero las pruebas son frágiles y tienen que ser reescritas cuando los diseños de página cambian, aunque sea un poco. Las pruebas generalmente solo indican que el código funciona, no lo bueno que es.

He trabajado en grandes y pequeñas empresas utilizando muchas tecnologías diferentes. Incluyendo simple "cowboy coding". Hubo muchos más errores cuando no empleamos metodologías de planificación y pruebas, pero nos movimos mucho más rápido. Hicimos cambios y correcciones en horas, no en días y semanas.

Facebook hace un "push" cada semana (martes). A menudo hay errores en el última inserción de código (¿no hay pruebas suficientes?), pero a menudo hacen otro empujón para ese jueves o viernes para solucionar cualquier problema. Mi conjetura es que Facebook está más cerca de la metodología" cowboy coding " y ha estado trabajando para ellos.

Aquí están mis observaciones:

• Desarrollo basado en pruebas: No

• Diseño basado en el dominio: Sí

• Diseño/Arquitectura basados en modelos: Sí

• ¿Haces pruebas? : Sí

• Pruebas unitarias: Sí

• Pruebas De Integración : Sí

• Pruebas De Aceptación : Sí

• Revisiones de código: No

• Tecnologías Innovadoras (Primavera, Hibernar, Wicket, JSF, WS, RESTO, ...) : Sí

• Programación Par ágil: No

• UML: Sí

• Idiomas específicos del dominio: Sí

• Especificación del Requisito (¿Cómo? Sí

• Integración continua: Sí

• Herramientas de cobertura de código: No

• Modelo de Dominio Aenémico: No (¿Qué queremos decir con esto ?)

• Comunicación (Wiki, Correo, IM, Listas de correo, otros documentos): Wiki, Mail, IM, Listas de correo

• Estimaciones del esfuerzo: Sí

• Tamaño del Equipo : 2-4 miembros

• Reuniones: Cada lunes reuniones fijas y cada dos días reuniones flotantes

• Métricas de código: Sí

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

• Seguimiento de errores: Sí

• Test-Driven-Development-Yes
• Domain-Driven-Design-No
• Model-Driven-Design / Architecture - No
• ¿Haces pruebas? - Sí
• Pruebas unitarias-Sí
• Pruebas de integración-Sí
• Prueba de aceptación-Iniciado
• Revisiones de código-No
• Tecnologías innovadoras (Spring, Hibernate, Wicket, JSF, WS, REST,...- ¿No?
• Ágil-Sí
• Programación de pares-Sí casi todo el tiempo
• UML-Nada más formal que líneas y cajas en pizarras blancas.
• Lenguajes específicos de dominio-Un poco
• Especificación del requisito (¿Cómo?)- No, tratamos de obtener historias de usuarios si es posible
• Integración continua-Sí
• Código-Herramientas de cobertura-No
• Modelo de Dominio Aenémico -
• Comunicación (Wiki, Mail, IM, Listas de correo, otros documentos) - Wiki, IM, Email, Word Docs
• Estimaciones de esfuerzo: Utilizamos una combinación de tamaño de camiseta (S, M, L, XL, etc.) y un sistema de puntos para sprint by velocidad de sprint.
• Tamaño del equipo-6 - >8
• Reuniones - Daily stand up
• Métricas de código-No
• Análisis de código estático-No
• Seguimiento de errores-Bugzilla / Version One

• Test-Driven-Development-No
• Domain-Driven-Design-No
• Model-Driven-Design / Architecture - No
• ¿Haces pruebas? - A veces
• Pruebas unitarias-Casi nunca
• Pruebas de integración-Sí
• Pruebas de aceptación - A 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í.
• Lenguajes específicos de dominio-C++ es específico de dominio, ¿verdad?
• Especificación del requisito (¿Cómo?- Creo que los conocemos.
• Integración continua-Sí
• Código-Herramientas de cobertura-No
• Modelo de Dominio Aenémico-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 un wiki?
• Estimaciones de esfuerzo-1-2 días para cualquier tarea dada
• Tamaño del equipo: 2 ingenieros de software, 10 hardware ingenieros
• Reuniones-2 veces por semana
• Métricas de código-No
• Análisis de código estático-No
• Seguimiento de errores - No

• Desarrollo basado en pruebas-No, a propósito.
• Domain-Driven-Design - No, todavía estamos averiguando el dominio.
• Model-Driven-Design / Architecture-Nope
• ¿Haces pruebas? - Probamos las construcciones, y hacemos que los usuarios avanzados las prueben.
• Pruebas unitarias-Nada formal (no NUnit, etc.)
• Pruebas de integración-No
• Pruebas de aceptación-Sí
• Revisiones de código - Ocasionalmente.
• Tecnologías innovadoras-random SharePoint tools
• Ágil - Sí
• Programación de pares-No
• UML-Nunca
• Lenguajes específicos de dominio-No
• Especificación del requisito (¿Cómo?)- Nos mantenemos ligeros en esto e iterar. Tenemos un BA que hace algunos análisis de requisitos, pero por lo general solo invitamos al cliente a nuestra planificación y reuniones diarias a medida que avanzamos. No hay 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 - Perspectivas
• Estimaciones de esfuerzo: aproximadamente, duplíquelo y luego duplíquelo de nuevo.
• Tamaño del equipo-2-4
• Reuniones-todos los días a las 9am (scrum!) más una reunión semanal de planificación/revisión
• Métricas de código-No
• Seguimiento de errores-Bugzilla
• Source Control-SVN

¿Echaste un vistazo a NDepend? La herramienta analizar código C # y. NET y viene con un montón de características interesantes para navegar por los resultados del análisis. Con NDepend puede escribir reglas sobre el código, puede comparar 2 versiones del código base y puede aprovechar más de 80 métricas de código.

Además, la herramienta viene con varias funciones de visualización excelentes como:

Gráfico de dependencias:

Matriz de dependencias:

Visualización de métricas de código a través de flores de jardín:

Es bueno escuchar que la programación MDA, DDD y Pair no se usa en ninguna parte :D Martin Fowler no es dios, solo chicos con algunas ideas extrañas.

• Test-Driven-Development-if you want to
• 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