Evaluando el estado de tu proyecto de desarrollo

Nuevamente en uno de mis blog favoritos Variable not found encuentro algo super divertido, en la oficina pusimos estos rangos de evaluación:

Si tu proyecto cumple con:

Más de 2: Estás en problemas :-P .
Entre 5 y 10: Tu vida será un desastre mientras el proyecto dure :) .
Más de 10: Lo que estás, esllevado, tu y todo tu equipo, y te deseamos suerte. XD

Jeje, disfrutenlo!

101 formas de saber que tu proyecto está condenado al fracaso

1. La dirección ha cambiado el nombre del "procedimiento en cascada" por "cascada ágil".
2. Se han empezado a contratar consultores para poder echarles las culpas de todo.
3. El servidor de integración continua retorna el error "Que te jodan. Me largo".
4. Habéis implementado vuestro propio framework en Ruby que usa archivos de configuración XML.
5. El miembro del equipo más mayor se refiere a Martin Fowler como "ese gamberro engreído".
6. Vuestro sistema de control de código fuente consiste en una serie de carpetas en un disco compartido en red.
7. El tiempo asignado para QA es destinado a preguntarse el por qué de ese desastre.
8. Todos los requisitos están escritos en una servilleta de papel.
9. Empiezas a considerar un cambio de empleo para no tener que mantener la aplicación que estás desarrollando.
10. El responsable de desarrollo web piensa que la X de XHTML viene de "eXtremo".
11. Las reuniones de todas las iteraciones comienzan por un "¿prefieres las buenas o las malas noticias?".
12. El equipo todavía considera que su nivel de CMM es una mierda.
13. El progreso se mide por el número de errores corregidos, y no por funcionalidades o características finalizadas.
14. La integración continua está haciendo que los empleados nuevos lean el manual del empleado.
15. Eres amigo del portero.
16. Al SCRUM master no le importa lo que hicisteis ayer, ni lo que haréis hoy.
17. Cada hito acaba en un sprint mortal.
18. Vuestro mejor desarrollador lo único que tiene es su expediente académico brillante.
19. No entendéis los acrónimos DRY, YAGNI o KISS, pero sí WTF, PHB o FUBAR.
20. El jefe podría ser sustituido por un script de redirección de emails.
21. La única certificación de vuestros procesos de construcción de software es la ISO 9001/2000.
22. El jefe piensa que "métrica" es un tipo de bebida proteínica.
23. Todos los errores son priorizados como críticos.
24. Todas las funcionalidades son priorizadas como triviales.
25. Las estimaciones económicas del proyecto mágicamente coinciden con el presupuesto disponible para el mismo.
26. Los desarrolladores usan la excusa del código autodocumentado para justificar la ausencia de comentarios.
27. Vuestro patrón favorito es el god object.
28. Todavía pensáis que compilar es una forma de testear.
29. Los desarrolladores todavía utilizan Notepad como entorno de desarrollo.
30. El gestor del proyecto pasa 7 horas a la semana pidiendo informes de progreso (basado en hechos reales).
31. No tenéis máquina propia, y no estáis programando por parejas.
32. Norma del equipo: no hay reuniones hasta las 10:00am, puesto que ayer estuvimos aquí hasta las 2:00am.
33. En el equipo se piensa que los ORM son una moda.
34. El equipo piensa que la transición desde VB6 a VB.NET será sencilla.
35. El gestor piensa que MS Project es la mejor herramienta de gestión de proyectos del mercado.
36. Tu esposa sólo consigue verte en una webcam.
37. Ninguno de test unitarios tienen aserciones (asserts).
38. Vuestro editor de páginas favorito es FrontPage.
39. Se discute encendidamente sobre si la llave "{" debe escribirse en una nueva línea, pero se es impacial ante el uso de patrones como MVC.
40. El lema de la compañía es "haz más con menos".
41. La frase "funciona en mi máquina" se escucha más de una vez al día.
42. La última conferencia a la que asistió el equipo de desarrollo .NET fue la Apple Worldwide Developers Conference 2000.
43. Los gestores insiten en registrar toda la actividad, pero nunca usan esa información para tomar decisiones.
44. Toda la depuración se hace en el servidor en producción.
45. El jefe no sabe cómo comprobar el email.
46. El jefe piensa que ser compatible SOX significa no trabajar las noches en las que hay béisbol.
47. La empresa contrata al senador Ted Stevens para la charla de inicio del proyecto.
48. El último libro que leíste fue la Biblia de Visual Interdev 6.
49. El presupuesto general se confunde con tu gasto semanal en Mountain Dew.
50. El jefe se pasa la hora de la comida llorando en el coche (otro hecho real).
51. El responsable de desarrollo web define Ajax como un producto de limpieza.
52. Tu jefe espera que pases los dos próximos días creando una solicitud de compra por un componente de 50$.
53. El equipo de ventas reduce tus estimaciones porque creen que podéis trabajar más rápidamente.
54. Requisito - Rank #1 en Google.
55. Todos los días trabajas hasta medianoche, y tu jefe se va a las 16:30.
56. A los jefes les encanta decir: "¿por qué se preocupan los desarrolladores? Cobran por horas".
57. El personal del turno de noche de StarBucks te conoce por tu nombre.
58. El jefe no pueden entender por qué alguien puede necesitar más de un monitor.
59. El equipo de desarrollo sólo usa el control de código fuente como sistema de backup por si falla el suministro eléctrico.
60. Los desarrolladores no son responsables de realizar ninguna prueba.
61. El equipo no usa SVN porque piensan que los algoritmos de fusión (merge) son pura magia negra.
62. Tus pizarras no tienen nada escrito (Version One).
63. El cliente confunde siempre tu gráfico burn-down con un burn-up (lo que queda por hacer con lo que está hecho).
64. El nombre clave del proyecto pasa a ser "Marcha de la muerte".
65. Te duele físicamente decir la palabra "sí".
66. Tus compañeros no refactorizan, sino refuctorizan.
67. Como recompensa por el tiempo extra, tu jefe compra una nueva cafetera.
68. El presupuesto de tu proyecto se contabiliza en la empresa como gastos estructurales.
69. Puedes bloguear desde el trabajo, gracias a que subcontratas porciones del proyecto.
70. Se crea un comité de control de cambios del proyecto, incluso antes de disponer de la primera versión alfa.
71. Diariamente consideras romperte los dedos para estar impedido un tiempo.
72. El hito final de entrega ha sido renombrado simplemente como "hito", igual que el anterior.
73. La política de puertas abiertas de la dirección sólo se aplica desde las 17:00 hasta las 8:00 horas.
74. La dirección opina que "por qué comprarlo cuando podemos construirlo".
75. Traes cerveza a la oficina durante el segundo turno.
76. Descubrís al director del proyecto consultando una tabla Ouija.
77. Das información errónea sobre tus compañeros de trabajo para parecer mejor en tu revisión personal.
78. Las revisiones de código se planifican para una semana antes del lanzamiento del producto.
79. Sólo existe presupuesto para realizar pruebas "si tenemos tiempo".
80. El cliente sólo habla sobre los requisitos cuando ya tiene una estimación fija.
81. Tu jefe no le encuentra la gracia a Dilbert.
82. Comienzas a notar los faroles del jefe durante un planning poker.
83. Empiezas a pensar si trabajar dos turnos en Pizza Hut sería una mejor alternativa para tu carrera profesional.
84. Todos los problemas de rendimiento se solucionan poniendo máquinas más potentes.
85. El proyecto va a ser lanzado como una versión beta permanente.
86. Se llevan tu coche del parking por pensar que estaba abandonado.
87. El jefe de proyecto suele garabatear durante las reuniones de toma de requisitos.
88. Estás utilizando MOSS 2007.
89. Tu equipo SCRUM consiste en una única persona.
90. Tu hoja de control de horas parece un ticket de Powerball.
91. El desarrollador web piensa que 508 tiene que ver con sus pantalones Levi's.
92. Piensas que necesitas medicación para la personalidad múltiple porque eres Mort, Elvis, and Einstein al mismo tiempo.
93. Tu jefe sustituye el asesoramiento profesional de un consultor por una bola mágica.
94. Sabes exactamente cuántos warnings en compilación provocan que tu IDE genere una excepción de "fuera de memoria".
95. A estas alturas, todavía no sabes a qué me refiero con el término "IDE".
96. Has copiado y pegado código desde The Daily WTF.
97. Los tests unitarios que fallan son eliminados porque, obviamente, están obsoletos.
98. Eres enviado a una conferencia a aprender, pero te saltas las sesiones para ir a ver si pillas algo.
99. El personal de QA te apoda "Jefe Off-by-one".
100. Tenéis el 90% del software completo el 90% del tiempo.
101. "Oh, oh, casi se me olvida. Ah, voy a necesitar que vengáis también este domingo... gracias".

Post original: 101 Ways To Know Your Software Project Is Doomed
Publicado en: Variable not found