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

Arquitectura de Software para Dummies

View more presentations from Sorey Garcia.

IDEAS 2009

Me alegra mucho que mi entrada número 101 sea tan especial. Me inscribí a este evento sin saber mucho de el, solo con amplias espectativas acerca de uno de mis temas favoritos, la ingeniería de software, pues bien, me he llevado gratas sorpresas que han generado en mi de nuevo, muchas espectativas que quizá veia un tanto desvanecidas.

El evento del que hablo la Conferencia Iberoamericana de Ingenieria de Requisitos y Ambientes de Software este año en su XII versión a cargo de la Universidad EAFIT.

La Conferencia de Ingeniería de Requisitos y Ambientes de Software (IDEAS) fue concebido como un espacio dedicado a la difusión de actividades y resultados de investigación de profesores, estudiantes y profesionales del ámbito académico y empresarial iberoamericano. IDEAS es pionero en el estudio de temas propios de la Ingeniería de Requisitos y la Ingeniería de Software. Actualmente, IDEAS es considerado como uno de los eventos académico-científicos de mayor calidad y trayectoria en Iberoamérica. Este evento trata de proporcionar el foro adecuado para el intercambio de ideas y experiencias entre las personas y organizaciones Latinoamericanas que trabajan en temas relacionados con la Ingeniería de Requisitos y la Ingeniería de Software.

Pues bien, que puedo decirles, han habido muchos temas interesantes, pero en especial y a modo personal, situaciones bien inspiradoras, como por ejemplo el ver tanta gente joven autores de papers, estudiantes de maestrías y doctorados.

También me ha resultado de enorme valía conocer el pensamiento de tantos profesionales tan reconocidos en la academia a nivel de iberoamérica, y eso en especial por un conversatorio en el que participé ayer y la mesa redonda de hoy, en la cual se trató el tema "Iniciativas y retos de la academia para atender las demandas sociales y laborales del área de informática", nada habría descrito mejor mi tema de interés sobre la ingeniería de software.

Desde que me enamoré de la docencía, mis mayores preocupaciones se han centrado en este tema. Al tener casi que los 3 roles simultaneamente (Estudiante, Docente y Empleado) considero que mi visión del asunto tiene varios puntos por los cuales abogaba y discutía continuamente con algunos colégas. Hoy, escuchar a los acádemicos hablar de la necesidad de conciencia acerca de los problemas de la academía, la ciencia, la investigación, las empresas; encuentro como lo que pensaba en realidad es tan obvio para tantos, y a la vez me cuestiono como hasta este momento no habia conocido nadie, con una visión tan global y preocupada del asunto, esto definitivamente me ha gustado muchisimo.

Sobre las notas que tomé, los pensamientos de estas personas a quienes a partir de este evento admiro y de mis propios pensamientos que confluyen con los suyos, pues escribiré un post. Se que algunos podrán decirme que si, en efecto tambien pensaban esas cosas, pues el problema no es que no exista conciencia de ello, el problema es: que tantas acciones se toman para mitigarlo, que papel ejercemos como profesionales para que esto no ocurra o incluso nos ocurra a nosotros mismos, o que tanto enfrentamos el tema, en vez de evadirlo y dejarlo continuar su mal rumbo. En fín, serán cosas de las que ya hablaré espero que en mi proximo post.

Por el momento les recomiendo visitar y consultar la bibliografía y papers del evento, ya que son de enorme valía. Tambien visitar las universidades y profesionales vinculados al evento ya que tienen cantidad de buenos trabajos que podrían interesales.

http://ideas09.eafit.edu.co

Sabes trabajar en equipo?

Una compañerita de la oficina me envió esto,
espero les resulte de utilidad

http://test.es.msn.com/noticias/trabajarenequipo/Test.aspx