Y tu, ¿eres de diseño técnico o funcional?

Ayer, hablando con una amiga sobre una situación que se había dado en su equipo, me hizo pensar en escribir algo sobre esto, y es el eterno tema de hacer los diseños técnicos, los funcionales, como mejorarlos, como usarlos para comunicar el trabajo, etc.

La situación, para ponernos en antecedentes, es una tarea que había hecho otra persona y que ella tenía que validar, la tarea, descrita en el funcional, era bien sencilla, hacer una validación de un campo y en caso de error mostrarle un mensaje al usuario, bien sencillo, sin embargo, la persona que lo hizo, en vez de mostrar un error, hacia otra cosa distinta.

¿Por qué había ocurrido esto?, el desarrollador, se había basado en lo que muchos desarrolladores se basan para hacer sus tareas, y que usamos habitualmente entre nosotros como nuestro modo de comunicación, el diseño técnico, pero ah, amigo, realmente donde está detallado ese funcionamiento es en el diseño funcional, que es el que solemos tomar para hacer las pruebas, la pregunta que surgía era, ¿cómo puedo hacer mejores diseños técnicos para que especifiquen este tipo de cosas?.

Mi opinión en esto, es ¿realmente debe un diseño técnico detallar este tipo de cosas funcionales?, vale, ya sabemos que muchas veces a nivel de desarrollo usamos el diseño técnico, pero este documento, gráfico, o cualquiera que sea nuestro diseño técnico, nos vale para detallar la arquitectura del sistema, los componentes,  como se van a comunicar, que tecnologías vamos a usar, y todos los detalles técnicos, pero, a pesar de que este documento es nuestra base de todo, lo que tenemos que tener realmente siempre presente a la hora de trabajar, es la funcionalidad (recordemos, aportar valor al cliente), y es este documento el que tenemos que usar para nuestro trabajo diario, para saber como tiene que funcionar la tarea que estamos haciendo.

¿Y cómo hacemos entonces correctamente un diseño funcional? porque lo cierto es que muchas veces son documentos que no es factible utilizarlos en el día a día del proyecto para el desarrollo, yo, por ejemplo, como muchos ya sabéis, me gusta especialmente SCRUM que lo que hace es que gestionamos ese trabajo del día a día en lo que se llama Sprint Backlog, que sin meterme mucho en detalles de como se genera, no es más que la lista de tareas, descritas a nivel funcional (o técnico cuando así se requiere), de lo que vamos a hacer en una iteración, así cuando un desarrollador coge una tarea a realizar, lo que ve es «En este campo se ha de mostrar un mensaje de error al usuario cuando el valor es incorrecto» y eso es lo que tiene que hacer, y no «página ASP.NET de introducción de datos mediante TextBox, y validación de los campos».

Por supuesto, SCRUM no es los únicos que tienen algo así, existen muchas más opciones, como las tarjetas de eXtremeProgramming, o los paneles de descomposición de tareas (Work Breakdown Structure) que tanto le gusta a mi amigo Enrique Blanco.

Y por supuesto esto es mi opinión, yo personalmente me siento más cómo trabajando sobre la descripción funcional, que sobre los diseños técnicos, que normalmente nos aportan más información sobre la arquitectura, o tienen más posibilidad de interpretación que las descripciones funcionales de las tareas, pero ya digo, es mi opinión.

Ya están publicadas las TFS Power tools de Julio 2008

Ya están disponibles en el web de Microsoft para descargarlas, y aunque algunos privilegiados ya habíamos podido probarlas, ya están públicamente disponibles, y la verdad, traen mejoras muy interesantes, así que os recomiendo que os las bajéis: TFS July 2008 Power Tools.

¿Y qué traen estas nuevas power tools? Algunas de las nuevas mejoras son:

 

  • Mejoras en la línea de comandos TFPT.exe
  • TFS Best Practices Analyzer con soporte para SQL Server 2008
  • Arreglo de algunos fallos del Process Template Editor y en las plantillas de los Work Items
  • TFS SCOM Management Pack, esto seguro que le gusta a mi amigo Dani Matey, un paquete para poder monitorizar TFS usando SCOM
  • Custom check-in policies (También la teníamos ya)
  • TFS Server Manager (esta ya la teniamos de antes también jeje)
  • Soporte para cambiar los nombres de los usuarios, que los que ya lo hubieses hecho sabéis los problemillas que da (herramienta TFSUsers)
  • Alert Editor: un nuevo interfaz de usuario para suscribirnos a alertas y no tener que usar el antiguo «bissubscribe»

    En fin que merece la pena descargarlas y empezar a probarlas …

  • El valor empieza al valorar a las personas

    Los que hayáis estado en alguna de mis charlas, leído mi blog de vez en cuando, me habréis oído decir que una de nuestras máximas prioridades, a la hora del desarrollo, es aportar valor al cliente, y bueno, siempre hablamos de las herramientas, las prácticas y los valores que tenemos que tener en mente para esto, pero sin embargo, hay algo de lo que no he hablado, y que realmente es el primer sitio dónde podemos empezar a dar valor, y es valorando a las personas del equipo.

    Es extremadamente importante que la gente que tenemos en la empresa, equipo, con nosotros, esté valorada tal y como se merecen, lógicamente hay tantos tipos de personas como personas existen, siempre habrá gente que hace mejor o peor su trabajo, que se implica más o menos en proyectos, empresa, etc. Y a todos hay que valorarlos en su justa medida.

    Si no hacemos esto, queramos o no, va a repercutir en la calidad de los proyectos que hacemos, es como cuando se comenta que para las metodologías ágiles necesitamos equipos de gente responsable, y yo digo, ¿si no tienes gente responsable qué clase de proyectos haces?, pero más importante aún que el proyecto es cuidar a la gente.

    Inicialmente aunque alguien, a pesar de que su sueldo (si vamos a hablar de dinero), o sus responsabilidades, no estén de acuerdo a su implicación, ya que esta sea una persona que participa activamente de los equipos, los compañeros, la empresa, repito, aunque inicialmente esa persona no esté valorada, puede que siga adelante con su implicación y dando el 100%, pero al medio plazo (ni siquiera a largo), eso va a pasar factura, va a sentir que no está valorada, y aunque quiera seguir dando el 100% va a ser imposible, ya que este tipo de cosas invariablemente nos afectan en nuestro día a día, y además a nivel personal, lo cual debemos evitar siempre, pensad que trabajos con y para personas, no con máquinas, y como tal debemos tratarnos.

    Otra consecuencia de esto es la temida rotación, que aunque no siempre es mala (de esto si queréis hablamos otro día), en este caso si que se convierte en un «bad factor», porque si alguien se va de nuestros equipos o empresas, que no sea porque no se le valora, ya que esa persona ya nunca volverá y eso es malo, muy malo.

    ¿y cómo se puede hacer para valorar a la gente? bueno una de las cosas más directas y que seguro que todos estamos pensando es el sueldo, es importante que los sueldos vayan acorde a la implicación de las personas, valor que generan al cliente, oportunidades que generan a la empresa, más aún que referente a puestos, categorías, etc. las personas han de recibir lo que se merecen por su implicación y por el valor que aportan en su trabajo, de este modo podemos tener desarrolladores mucho más implicados en su trabajo que jefes de proyecto, o jefes de proyecto mucho más implicados que gerentes o directores de proyecto, y esto es importante reflejarlo también en los sueldos.

    Por supuesto, no todas las empresas, por desgracia, se pueden permitir dar los sueldos que quisieran a sus empleados, y desde luego, sólo con sueldo no se valora a las personas tenemos que ver todo lo que tenemos a nuestra disposición, y aquí no hay recetas fijas, desde promover determinadas actividades para la gente, mayores capacidad e independencia en su toma de decisiones (algo que la gente que se implica suele valorar mucho), o cosas tan simples como una llamada de apoyo (si una llamada aquí un correo no vale), en fin que hay muchas cosas, cada cual debe ver y decidir en su caso cuales son las más adecuadas.

    Y bueno, por suerte, yo, por suerte en casi todos los sitios que he estado he sido bien valorado en los sitios dónde he estado, tanto a nivel de sueldo, siempre que las condiciones lo han permitido, y con otros muchos factores, pero bueno, se que esto no siempre es así, y por eso quería escribir esto, para que todos lo tengamos siempre en cuenta.

    Nueva herramienta de los VSTS Rangers: SQL Load Test

    No se si muchos de vosotros conocéis que son los VSTS Rangers, pero bueno, en definitiva es un grupo dentro de Microsoft con gente de Microsoft Consulting Services, que crean ciertas herramientas para Visual Studio Team Syste, como puede ser por ejemplo el WCF Load Test que coge trazas de WCF y genera pruebas unitarias para reproducirlas después en una prueba de carga de VSTS.

    Pues acaban de sacar una nueva herramienta en este sentido que es el SQL Load Test y que coge los resultados de una sesión del SQL Profiler y nos permite generar esas pruebas unitarias.

    En fin tiene buena pinta,, a ver si la pruebo (otra cosa más).

    Y bueno, también comentaros que no me he olvidado del blog, pero últimamente tengo mucho trabajo ya demás estoy entrenando para mis próximas vacaciones, si entrenando, y es que, si todo va bien, me voy aquí ;).

    Prometo fotos a la vuelta y por supuesto comentarios por aquí ….

    Próximo evento MAD.NUG

    Bueno amigos, después del excelente resumen que ha hecho Jorge en su blog, y como creo que aún no lo habíamos anunciado públicamente, lanzo la convocatoria del siguiente evento :).

    En este no coincidimos con el fútbol, así que espero veros por allí a todos.

    Esta vez nos acompañará Roberto González, MVP de Biztalk, un auténtico titán del Biztalk, WF, y WCF, no os lo perdáis

    Y el nombre del evento es:

    Integración entre Workflow Foundation y Windows Comunication Foundation

    Tenéis más detalles y el link de inscripción aquí.