Autor: NicoPaez

Update 08

En miércoles pasado se llevó a cabo en Buenos Aires, el evento para desarrolladores "Update08". El mismo se realizó en el paseo La Plaza y contó con interesantes oradores. Lamentablemente no puede escuchar todas las charlas, pero sí escuché las de Diego Golombek y Emmanuel Bernard, la cuales me resultaron excelentes. También participé como orador en una charla junto a gente de mi equipo, el material que utilizamos está disponible aquí. El balance del evento fue muy bueno (asistieron más de 1200 personas :-)).

Sobre el inicio de los proyectos

Si analizamos como surge un proyecto de desarrollo de software, nos encontraremos que la motivación principal es una necesidad de una organización. Puede que el resultado del proyecto represente una mejora directa al negocio o bien que permita soportar al negocio de una forma más «óptima».

Yendo un paso más allá nos encontraremos que previo al inicio del proyecto y antes que el mismo sea concebido como tal, debería hacerse un análisis para determinar si vale la pena o no hacer el proyecto.  Como desarrolladores muchas veces pasamos por alto este hecho ya que generalmente somos convocados cuando la decisión de hacer el proyecto ha sido tomada. El análisis de si debe o hacerse el proyecto suele conocerse como «caso de negocio» (Business case) y debería contemplar minimamente las siguientes cuestiones: descripción del proyecto, objetivos, alineamiento con la estrategia del negocio, impacto en la operaciones, costos, beneficios y riesgos.

Una vez presentado el caso de negocio y decidido que se avanzará con la ejecución del proyecto se procede a iniciar el mismo. Independientemente del tipo de proyecto y el proceso de desarrollo a utilizar, absolutamente todo proyecto debe comenzar con un documento de visión y alcance que deje en claro para todos los involucrados el porque del proyecto y a grandes rasgos cual es la funcionalidad que se espera del mismo. En algunos casos dependiendo de las características del proyecto es conveniente tener documentado en forma separada la visión y el alcance, pero independientemente de ello es necesario para poder comenzar con el proyecto que todos los involucrados tengan en claro los siguientes puntos:

  • Objetivos del proyecto
  • Beneficios para el negocio que traerá el proyecto
  • Quienes son los involucrados en el proyecto detallando al menos: sponsor, usuarios clave, experto de negocio y líder del proyecto
  • Relación del proyecto con otros proyectos
  • Alcance esperado de la solución a implementar
  • Plan de alto nivel con principales hitos y entregables

Toda esta información es lo que suele volcarse en el documento de visión y alcance. Adicionalmente dicho documento también contiene la lista de riesgos del proyecto.

continuará….

VSTS Inner Circle Airlift

Del 17 al 19 de marzo estuve en Seattle invitado por Microsoft participando del lanzamiento del programa Visual Studio Inner Circle.
Del evento participaron alrededor más de 100 empresas de desarrollo de todo el mundo. Personalmente tuve la oportunidad de dialogar con gente de: Suiza, Brasil, Portugal, Mexico, Colombia, Inglaterra, Ecuador, USA, Canada, India, Salvador, Santo Domingo y Venezuela.
Por lo visto en el evento hay un futuro muy prometedor para los productos de la familia Team System, pero solo el tiempo nos dirá si la promesa se convierte en realidad.

Sobre los roles en proyectos ágiles

Durante el último tiempo he estado analizando los roles que resultan imprescindibles a la hora de encarar un proyecto de desarrollo utilizando un proceso ágil. Resulta necesario hacer una aclaración preliminar para poner en contexto mi visión. Yo trabajo actualmente en una organización dedicada al desarrollo de software y por lo general nuestros clientes son organizaciones que se dedican a alguna actividad X que NO es el desarrollo de software. Continuando con el tema de interés, todos los métodos ágiles hacen hincapié en la participación de los usuarios, pero más allá de eso, dentro del paraguas de métodos ágiles la cantidad de roles propuesta por los distintos métodos es variable. De acuerdo a mi experiencia personal y a la cultura/procesos de la organización donde trabajo actualmente creo que en todo proyecto más allá de ser ágil o no, es necesario identificar claramente los siguientes roles:

  • Sponsor: quien está pagando por el proyecto, generalmente es algún gerente de la empresa cliente.
  • Dueño del producto: quien conoce las funcionalidades que debe tener el producto final. Tiene un amplio conocimiento del negocio y por ello puede priorizar las funcionalidades del producto. Es quien lidia con los usuarios y luego de filtrar sus opiniones las transmite al equipo de desarrollo.
  • Líder del proyecto: quien se encarga de la gestión del proyecto y de que el mismo llegue a buen puerto en tiempo y forma.

Los roles de sponsor y dueño de producto deben ocupados por personas de la organización cliente, mientras que el rol de líder de proyecto es ocupado por alguien de la empresa de desarrollo. Obviamente siempre hay presente en el proyecto un equipo de desarrollo conformado por técnicos y que es el que lleva a cabo la actividades de construcción. Los roles que conforman dicho equipo suelen variar dependiendo del proceso que se utilice para llevar a cabo el proyecto. Este equipo suele estar conformado por personal de la empresa de desarrollo, aunque es recomendable que también cuente con técnicos de la empresa cliente. Ahora enfocándonos en proyectos ágiles, me es posible decir que ocasiones resulta necesario/recomendable contar adicionalmente con los siguientes roles:

  • Líder de proyecto cliente: es el facilitador que se encarga de destrabar todas cuestiones surgidas en el ambiente cliente para las cuales el líder de proyecto no tiene la autoridad suficiente por ser una persona externa. Su presencia resulta mucho más relevante cuando el proyecto se lleva a cabo en las oficinas del cliente. A diferencia del sponsor debe estar en el día a día del proyecto. Dependiendo de la organización puede que el rol sea ocupado por el propio sponsor.  Es necesario aclarar que si bien es deseable que el sponsor esté en el día a día del proyecto es común que por su responsabilidades dentro del negocio no tenga disponibilidad para estarlo, lo cual da cabida al surgimiento de este rol.
  • Administrador de infraestructura: en quien se encargará de la administración de todo el ambiente de desarrollo y prueba. Esto implica la instalación configuración y mantenimiento del software de base (sistema operativo, service packs, base de datos) y aplicativos como entornos de desarrollo, herramientas de integración continua y herramientas colaborativas (wiki, mail, blog, CMS, etc)
  • Gerente de cuenta: este rol es parte del la organización de desarrollo y tiene a su cargo las cuestiones de índole comercial entre las organizaciones. Si bien en ocasiones dichas cuestiones suelen recaer en el líder de proyecto, resulta mucho más saludable que no sea así. El líder de proyecto está enfocado en su proyecto y estas cuestiones contractuales suelen establecerse entre organizaciones (al menos es como NOSOTROS acostumbramos trabajar), es por ello que resulta necesario que sean manejadas por alguien que tenga la visión de todos los proyectos realizados junto a la organización cliente. Para despejar cualquier duda, el tipo de cuestiones al que me refiero tiene que ver con: cambios de tarifas, relaciones entre las organizaciones a mediano y largo plazo, alianzas, etc.

En cuanto al equipo de desarrollo de desarrollo, como ya se mencionó está conformado por técnicos, entre los cuales podemos distinguir en el caso de desarrollos ágiles distinguimos:

  • power developers: que hemos dado en llamarlos de esta forma dado que cuentan con ciertas responsabilidades y capacidades adicionales a las entender especificaciones técnicas y escribir código. Entre estas capacidades se encuentran: la capacidad de análisis e interacción directa con los usuarios y el criterio/conocimiento para diseñar el software e implementarlo entre otros.
  • solution architect: quien es el encargado de definir las bases de la solución y es el referente técnico del proyecto. Si bien su principal participación es al comienzo del proyecto, tiene una dedicación parcial constante para asistir a los developers en cuestiones que estos se sientan superados o simplemente requieran de una opinión más experimentada.

Si digo que esto es todo, alguien podría preguntar:

  1. ¿quien trabaja junto al cliente/usuario para especificar los requerimientos?
  2. ¿quien realiza el diseño?
  3. ¿quien realiza las pruebas?

Y dado que estamos hablando de un proceso ágil, particularmente basado en principalmente en XP con algunos condimento de FDD, las respuestas serian:

  1. Los power developer que dada sus habilidades pueden perfectamente lidiar con este tipo de actividades. Pero ojo no perdamos de vista el contexto del proceso que estamos utilizando. No existen extensas y detalladas especificaciones de casos de uso, generalmente serán historias de usuarios o similares.
  2. Los power developers. Aunque hay que destacar que inicialmente los mismos realizan un modelo de dominio en conjunto con los usuarios y el arquitecto. Con lo cual la base del diseño queda establecida desde un comienzo.
  3. Los power developers realizan las pruebas de unidad y demás pruebas técnicas (de ser necesarias) mientras que es el usuario quien se encarga de escribir y ejecutar las pruebas de aceptación. Obviamente para que el usuario pueda lleva a cabo esta tarea es previamente capacitado por los power developers.

Bien, esto es todo. Creo que los roles han quedado claramente descriptos. Obviamente no es necesario que cada persona ocupe un solo rol, pero si bien hay roles compatibles (que pueden ser ocupados por una misma persona) hay otros que no lo son.

Espero que les resulte útil y me hagan llegar sus comentarios.

Embedded Resources

Sometimes your assembly on runtime depends on a file, like a image or a simple text file. To manage this file, you could store its location in the application configuration file, and then load your file by reading its location from configuration. Another option is to embedded the file as a resource in your assembly and then use the following code snippet to load it.

System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream(«NameOfTheFile»);

Lets see an example. Suppose an assembly called Model.dll that requires a file called TextFile.txt that is part of the same visual studio project. First of all you should define that file as an embedded resource (properties->build action = embedded resource). Then in your code, when you need to access this file you can load it this way:

System.IO.Stream fileStream = this.GetType().Assembly.GetManifestResourceStream(«Model.TextFile.txt»);
System.IO.StreamReader sr = new System.IO.StreamReader(s);
string fileContent = sr.ReadToEnd();
fileStream.Close();

Note that the name of the assembly has been appended to the of the file. One you have read the contents of the file, remember to close the stream

Desarrollo con .NET 1.1: Herramientas de soporte

A pesar de que la versión actual de .NET es la 3.5, algunos clientes aún continúan trabajando con la versión 1.1. Precisamente en este momento me encuentro trabajando en uno proyecto así. Adicionalmente al uso de dicha tecnología, nos hemos visto impedidos de utilizar nuestro ambiente de desarrollo típico, montado sobre TFS, lo cual nos obligó a montar un ambiente alternativo. Después de un breve repaso de las necesidades del proyecto terminamos armando nuestro ambiente con los siguientes componentes.

El hecho de trabajar con .NET 1.1, ya de movida nos lleva a utilizar Visual Studio 2003.

Como framework de pruebas unitarias, elegimos NUnit y logramos integrarlo con VS2003 para poder depurar mientras ejecutamos las pruebas.

Como controlador de versiones decidimos utilizar Subversion, por considerarlo la mejor alternativa descontando TFS y suma a su amplia difusión.

Como cliente del subversión estamos utilizando TortoiseSVN, ya que las experiencias que hemos tenido con el plug-in the ANK no han satisfactorias.

Para la automatización de los builds, estamos utilizando NAnt.

Como es herramienta colaborativa estamos utilizando Trac. De esta herramienta utilizamos principalmente la funcionalidad de wiki y la planificación de milestones. Si bien esta herramienta cuenta con un sistema de tickets que puede utilizarse para tracker el progreso del proyecto, hemos preferido utilizar un SUPER excel ajustado para trabajar a lo SCRUM.

La programación como disciplina central del desarrollo del software (introducción)

Parte 1: La programación, la academia y la industria

Claramente si trazáramos un paralelismo entre el desarrollo de software y las construcción de edificios, bien podríamos decir que en cierto modo, el programador es al desarrollo de software lo que el albañil es a la construcción de edificios. Al mismo tiempo, resulta que el trabajo llevado a cabo por los programadores insume aproximadamente la mitad del esfuerzo total del desarrollo del software.

Si uno analiza la situación actual del mercado IT en Argentina rápida se encuentra con la escasez programadores, como uno de los principales problemas para el crecimiento de la industria.

Curiosamente, si uno mira la oferta académica actual de las universidad nacionales (no estoy al tanto de las universidad privadas, pero supongo que la situación debe ser similar), se encuentra con abundantes opciones de licenciaturas / ingenierías en sistemas, pero ninguna carrera enfocada en la formación de programadores. Si bien es cierto que todo licenciado / ingeniero en sistemas debería ser capaz de programar, para ser programador no basta con ser capaz de programar. Las universidades enseñan programación en la primera mitad de la carrera, tratándola más como una base necesaria para las materias del ciclo superior que como una disciplina en si misma.La falta de una carrera de programador hace que aquellos jóvenes con aspiraciones de ser programadores se vean obligados a estudiar una licenciatura/ingeniería que no los formará como programadores, provocando una deserción temprana en la carrera. Como consecuencia de todo esto, la academia no forma programadores, sino ingenieros/licenciados capaces de programar.

Por su parte la industria asume que la formación general de los programadores es responsabilidad de la academia y por ello en el mejor de los casos solo invierte en la especialización del programador en una tecnología particular.

Estas posiciones adoptadas por la industria y la academia posiblemente sean consecuencia de la subestimación de la tarea del programador y por una falta de conciencia de la importancia de la actividad.

Personalmente creo que resulta necesaria una revalorización (en la academia y la industria) de la programación como disciplina fundamental del desarrollo de software y es por ello que he decidido escribir una serie de artículos centrada en programación como actividad fundamental del desarrollo de software dejando en claro la diferencias entre ser capaz de programar y ser programador.