Migración a Team Foundation Server 2010 – Donde están los Reportes? por Daniel Laco

20. agosto 2010

 

Dónde quedan los reportes de TFS2008 cuando se realiza la migración a TFS 2010?

A no preocuparse si acceden a los viejos reportes y ven que la fecha de actualización del cubo quedó congelada a la fecha de la migración, porque los reportes están ahora en una nueva locación

Por los cambios producidos en los modelos en la nueva version 2010, el proceso de actualización que realiza TFS hace que se instalen las nuevas bases de datos y cubos siguiendo el concepto de Project Collections (ver http://www.vemn.com.ar/Blog/post/Nuevos-conceptos-en-TFS-2010.aspx)

Las bases anteriores TFSWarehouse y al cubo también llamado de la misma manera siguen existiendo y los reportes en Reporting Services (SSRS) siguen apuntando a esta base .

Pero los reportes para los templates basados en MSF for Agile y MSF for CMMI en la versión 4.2 son migrados a un nuevo directorio en Reporting Services. Este directorio se llama TFSReports y dentro de él está el directorio DefaultCollections (esto dependiendo del nombre de la collection que fué creada en la migración). Dentro de este último directorio vamos a encontrar todos los reportes de los proyectos anteriores migrados a la nueva versión 2010 de TFS.

Por supuesto, que todos los proyectos abiertos desde Visual Studio, apuntan ahora a la nueva ubicación. Esta ubicación es sacada desde la consola de configuración de TFS.

En el gráfico siguiente, está un esquema de como quedan ahora las bases de datos y los Data Sources de Reporting Services

 

ServerUpgrade

 

Tambien tenemos nuevos Data Sources

2008

2010

TfsReportsDS

Tfs2010ReportsDS

TfsOlapReportsDS

Tfs2010OlapReportsDS

 

Aquí les dejo una serie de link sobre información puntual sobre el tema de reportes (algunos extraidos del blog de Buck Hodges:

Sunder Raman, Program Manager para TFS, ha escrito una serie de post (en inglés) sobre los cambios en el almacenamiento y en los cubos para 2010.

Reporting

 

Customizing Reports for Team Foundation Server 2010 (en MSDN)

Cube

 

 

John Socha-Leialoha, escribió una serie de post sobre la actualización de reportes en TFS

ALM, Gestión de Proyectos, TFS , ,

Migración de TFS 2010 - Como detener o iniciar todos los servicios? por Daniel Laco

19. agosto 2010

 

Si es necesario hacer backup o restore de las bases de datos, o mover una instalación o hacer cambios importantes, es útil contar un algo que nos permita con un solo comando parar o arrancar todos los servicios que usa Team Foundation Server.

Hay una herramienta de linea de comandos  que se llama TFSServiceControl que permite realizar esas operaciones con todos los servicios,  y los Application Pools que usa el Team Foundation Server.

El comando se usa:

TFSServiceControl [quiesce|unquiesce]

TFSServiceControl quiesce Detiene los servicios

TFSServiceControl unquiesce Inicia los servicios

 

Fuente (en inglés) : http://msdn.microsoft.com/en-us/library/ff470382.aspx

 

ALM, Gestión de Proyectos, TFS ,

Nuevos conceptos en TFS 2010 – Categorizando Work Items por Victor Passador

10. agosto 2010

Siguiendo con nuestra idea de mostrar novedades que exceden la calificación de “nueva característica”, y que nos ponen en situación de repensar algunas situaciones, quisiera comentar sobre las Categorías de Work Items.

Ahora, con TFS 2010, podemos categorizar Work Items, pero … ¿por qué querríamos o necesitaríamos hacer esto?.

Porque tendríamos la posibilidad de tratar de la misma manera a aquellos work items que son diferentes pero parecidos, teniendo en cuenta que cuando hablo de “tratar” estoy apuntando al seguimiento de esos work items. Con este nuevo agrupamiento podríamos por ejemplo:

  • Construir queries, con una sintaxis mucho más simple e intuitiva, que devuelvan work items de más de un tipo. ¿O acaso una “User Story” y un “Quality of Service Requirement” no son en definitiva requerimientos del usuario?
  • Construir reportes de manera más simple apuntando a obtener resultados más “macro” sin resignarnos a perder el detalle de lo que hay debajo (… o ver el bosque y también ver los árboles). Cada work item tendrá su propia estructura de datos, con el nivel de detalle que requiera cada uno, pero aquella información que tengan en común podría ser explotada en reportes utilizando estas nuevas categorías.
  • Construir Test Suites utilizando Microsoft Test Manager (el nuevo integrante de la familia TFS, del que estaremos posteando/presentando novedades muy pronto)

 

Para crear queries que respondan a este nuevo agrupamiento, tenemos disponible el comando “In Group”. Aquí tienen un ejemplo de una query utilizada por el Microsoft Test Manager que se vale de este nuevo operador.

image

Estas categorías están definidas en el template con el cual fue creado el proyecto. Es por este motivo que no encontraremos (al menos por ahora) ningún botón que diga “Add New Category”.

Pero no todo está perdido, si nos damos un poco de maña, nos prometen que podemos categorizar work items en proyectos que no tenían esa facilidad.

Hasta la próxima !

Gestión de Proyectos, TFS, ALM , , , ,

El Datawarehouse de TFS no se actualiza luego de un upgrade a SQL Server 2008 por Victor Passador

19. julio 2010

Días pasados, en el proceso de upgrade de un servidor a TFS 2010, comenzamos con la actualización del motor de base de datos a su versión 2008, uno de los prerrequisitos exigidos.

Si bien el servidor estaba virtualizado y ante algún imprevisto podríamos restaurar rápidamente un backup reciente de esa VM, decidimos tomar una precaución adicional que fue esperar un par de días luego de ese upgrade antes de encarar la instalación de la nueva versión de TFS, para ver si algún usuario informaba de inconvenientes.

Ya decididos a instalar TFS 2010, un PM nos informa que los reportes de los diferentes proyectos estaban mostrando datos viejos. La espera no había sido en vano.

Lo primero que hicimos fue forzar la actualización del Datawarehouse (aquí hemos descripto cómo hacerlo), pero sin éxito.

SQL Management Studio por su parte, informaba las bases de datos de Analysis Services estaban funcionando correctamente, pero los datos aún no se actualizaban.

Sin mensajes de error, la búsqueda de ayuda en Internet se complicaba. No aparecían casos similares en los buscadores, hasta que mirando en el Log de Eventos del SO dimos con algunas palabras claves que nos condujeron a un artículo de Bill Wang.

Básicamente el problema era que, luego del upgrade a SQL Server 2008, TFS seguía intentando conectarse a Analisys Services pero de la versión 2005, y allí se producía el fallo.

Para solucionar el inconveniente, hay que reemplazar una entrada del Web Config del WS de TFS como a continuación se detalla:

Reemplazar …

   1: <dependentAssembly>
   2:         <assemblyIdentity name="Microsoft.AnalysisServices"
   3:                           publicKeyToken="89845dcd8080cc91"
   4:                           culture="neutral" />
   5:         <bindingRedirect oldVersion="9.0.242.0" newVersion="9.0.242.0"/>
   6: </dependentAssembly>

… por …

   1: <dependentAssembly>
   2:         <assemblyIdentity name="Microsoft.AnalysisServices"
   3:                           publicKeyToken="89845dcd8080cc91"
   4:                           culture="neutral" />
   5:         <bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0"/>
   6: </dependentAssembly>

Tener en cuenta que además, la herramienta “SetupWarehouse.exe” también accede al cubo de la misma forma, con lo cual deberá modificarse el archivo “SetupWarehouse.exe.config”.

TFS, Gestión de Proyectos, SQL Server , ,

Nuevos conceptos en TFS 2010 por Victor Passador

8. julio 2010

Como es de esperarse a estas alturas, existe infinidad de blogs que enumeran las características que vienen con la nueva versión de Team Foundation Server.

Para no caer en la misma situación, la idea de este post es que nos enfoquemos solamente en algunas pocas de esas nuevas características a las que el nombre de “feature” le queda un poco chico, ya que implican un cambio más de fondo y que va un  poco más allá de una simple “nueva funcionalidad”.

Project Collections

Las colecciones de proyectos brindan una capa adicional de indirección que permite el agrupamiento de proyectos según el criterio que a nosotros más nos convenga. Esta agrupación podría ser por tipo de arquitectura, por equipo o área de la empresa, o por ejemplo, separando proyectos de desarrollo de aquellos otros de consultoría.

Lo interesante de este agrupamiento es que no es solamente a nivel lógico, sino que también lo es a nivel físico. Esto permite lograr un mejor nivel de aislamiento entre proyectos, y ese aislamiento impacta en el aspecto de seguridad, ya que cada colección equivale a una nueva instancia de TFS en términos de sus versiones 2005/2008.

Project collection compartmentalization

 

El lector atento dirá a esta altura “… pero ojo… acá la cosa se complica …”.

Y si, como en cualquier otro caso, nos encontraremos con ventajas y desventajas en la implementación de colecciones de proyectos. Vamos a enumerar las más importantes:

Ventajas:
  • Aunque parezca obvio, no deja de ser una ventaja el hecho de poder seguir trabajando como en las versiones anteriores de TFS si no tenemos ganas de complicarnos la vida con estas colecciones, con la única salvedad de que nuestros proyectos estarán ahora dentro de una “Default Collection”.
  • Como cada colección maneja su propia base de datos, tenemos muchas más opciones a la hora de escalar y manejar balanceo de carga.
  • En grandes organizaciones (y no tanto), este nivel de aislamiento permite una administración de seguridad mucho más granular.
  • Tenemos la posibilidad de hacer respaldo/restauración de grupos de proyectos de manera independiente.
 
Desventajas:
  • Lo que para algunos pueda ser una ventaja, es lo contrario para otros, ya que se podrá argumentar que ante una gran cantidad de colecciones se complicará seguramente la tarea del administrador al momento de configurar permisos de acceso a cada uno de los proyectos.
  • A raíz de que cada colección usa su propia base de datos, nos encontraremos con una tarea más ardua al momento de administrar copias de resguardo de toda esa información adicional.

 

En el blog de Steve Lange podrán encontrar un diagrama de flujo muy interesante que les ayudará a decidir si necesitan o no manejar Project Collections.

 

Nuevos templates de Proyectos

Al momento de crear un nuevo proyecto en TFS en la versión 2010, nos encontraremos con un par de nuevos templates, entre ellos la versión 5.0 de MSF for Agile (aquí podrán encontrar una comparativa con la versión anterior).

No quisiera centrarme en describir el proceso que intenta implementar, sino en la funcionalidad que aportan sus nuevos tipos de Work Item, Workflows y por sobre todo, las nuevas relaciones que se pueden establecer entre ellos.

Cabe recordar que TFS 2010 permite establecer jerarquías de work items y además crear relaciones mucho más ricas que una simple dependencia de ida y vuelta entre uno y otro. Valiéndose de esto último, el nuevo template permitirá documentar por ejemplo “Historias de Usuario” y “Casos de Test” vinculados por una relación de tipo “Testea a …” o “Testeado por …” entre otras.

Este es, indudablemente, un modelo mucho más rico que el anterior, ya que permite ser explotado por queries mucho más intuitivas, muchas de las cuales ya vienen incluidas en el propio template.

Podríamos consultar, por ejemplo, Historias de Usuario que no cuentan con casos de test asociados para tener rápidamente un acceso a partes de nuestra aplicación que no tienen las pruebas mínimas necesarias.

 

Dashboards

Gracias a su integración con las últimas versiones de Sharepoint, los portales de proyectos creados con TFS 2010 mejoran su capacidad de reporting incluyendo Dashboards.

La idea de un Dashboard (o tablero de control) es contar con una consola que incluya diferentes indicadores que muestren rápidamente la situación actual del proyecto en un único lugar pero a un nivel más “macro” y que, además, permita a las áreas gerenciales determinar que tan en línea está un determinado proyecto con las políticas de su negocio.

Los Sharepoint Dashboard son la materialización de lo que se conoce como Balance Scorecards, es decir, sistemas de gestión y planificación estratégica que intentan alinear las actividades diarias del desarrollo con la visión de la empresa.

Obviamente estos Dashboards son altamente personalizables, pero de manera inmediata podremos contar con la siguiente información:

  • Reporte de Task Burndown
  • Lista de cantidades de Work Items en sus diferentes posibles estados (Activos, Cerrados, Resolved, etc.)
  • Lista de fechas importantes
  • Lista de los últimos Builds
  • Lista de los últimos checkins realizados y sus comentarios
  • Vista rápida del Product backlog donde se ve el estados de sus items

 

Cada uno de estos indicadores no es más que un wepbart embebido en el portal Sharepoint, por lo que contando con MOSS podremos personalizarlos y/o extenderlos de una manera muy flexible.

Hasta la próxima.

Gestión de Proyectos, Sharepoint, TFS , ,

Desmitificando Branches por Victor Passador

8. junio 2010

En el tiempo que llevamos trabajando en consultoría relacionada con TFS, y en particular con lo concerniente al Source Control, nos hemos encontrado con dos tipos de casos:

  • Empresas que no aprovechan los beneficios aportados por el branching.
  • Empresas que hacen abuso del branching, que también pierden esos mismos beneficios y terminan siendo devorados por el monstruo.

 

Los primeros no quieren ni hacer mención al branching por simple temor a lo desconocido, pero en cuanto vencen ese primer miedo y obtienen los primeros buenos resultados, se convierten automáticamente en los de la segunda clase, casi sin término medio.

Los segundos vuelven a convertirse en los primeros por abandono.

Con este post me propongo  hacer una introducción a las políticas de branches, para que ambos grupos puedan lograr el equilibrio.

Branching Guidance

En gran parte de los casos con los que me he cruzado, el caos viene de la mano de la falta de políticas de branches. Casi como la planificación previa de la arquitectura de cualquier aplicación, los branches necesitan ser diagramados y consensuados de antemano.

Desde hace varios años ya, está publicada en Codeplex lo que se conoce como “Branching Guidance” sobre la cual estoy basando este post. Hoy la guía se encuentra en su versión 2.0 a raíz del feedback recibido desde la comunidad y recientemente fue publicado el Release 2010, obviamente apuntando al lanzamiento de la nueva versión de la plataforma.

En esa guía hay una frase a modo de advertencia que me gustaría transcribir:

Cada branch que se crea tiene un costo, por lo tanto asegúrese de obtener algún valor de él.

Creo que esta frase resume perfectamente el concepto de equilibrio al que hacía referencia  anteriormente, y al punto al que deberían llegar las empresas que decidan apostar por una política de branches.

Apostando a una política de branches

El uso de branching requiere ordenamiento, y por tal motivo voy a enumerar algunos principios que se deberán tener en cuenta antes de meter mano:

  • El encargado de ejecutar y mantener la política de branches que se defina, deberá tener un nivel medio-avanzado en el manejo de TFS. (“Cada branch tiene un costo …”).
  • La política que se defina dependerá fuertemente de los tipos de Release (release de nueva versión, de service pack, de hot fix, etc.) requeridos por el proyecto en cuestión, de lo que se desprende:
    • Se pueden definir diferentes tipos de políticas para diferentes tipos de proyecto.
    • A menor cantidad de tipos de release, un plan de branching más simple.

 

Los planes de branching sugeridos en la guía tienen una característica “aditiva” lo que permite elegir en primera instancia un plan simple, y en caso de que aparezcan nuevos tipos de release (conocidos como release vehicles, ver Glosario) ir “complicando” el plan agregando nuevos branches.

Un plan equilibrado – El “Standard Branch Plan”

Imaginemos un escenario con las siguientes características:

  • Se desarrolla un producto del cual el cliente siempre tiene la última versión.
  • Se desarrollan permanentemente nuevas versiones con nuevos features (un release vehicle por aquí).
  • Se entregan además actualizaciones (services packs, bug fixes, otro release vehicle por aca).
  • Cada actualización liberada sobre una determinada versión contiene todas las actualizaciones anteriores.
  • Los services packs se desarrollan paralelamente a los features de la nueva versión.

 

Dado este escenario, un plan de branches como el que muestro a continuación permitiría soportar las necesidades del proyecto a la vez que mantendría una cantidad de branches controlada, fuera de una situación de caos.

image

Qué propone este plan:

  • Branch Development:
    • Sobre él se desarrollan los features de la próxima versión.
    • Existe un flujo continuo desde y hacia el branch Main (merges).
    • Merge hacia Main (RI) ante cada objetivo cumplido, por ejemplo el fin de una iteración.
    • Merge desde Main (FI) cada vez que Main genera un build exitoso.
  • Branch Service Pack:
    • Se crea en el mismo instante que Release, determinando en ese momento la jerarquía Main –> Service Pack –> Release.
    • Los cambios “de servicio” se hacen sobre esta rama y luego se hace merge (RI) sólo hacia Main.
  • Branch Release:
    • Es hijo de Service Pack.
    • La entrega al cliente se hace desde este branch, y una vez que se libera, el branch se marca como read-only.
    • Bug fixes graves, que se hagan sobre el branch Release, deben hacer merge hacia Main pero pasando por el branch Service Pack (Release –> Service Pack –> Main)
    • Una vez que se creó este branch, los cambios que no fueron aprobados para el Release en curso sólo deberían hacerse en Main.

 

Herramientas de TFS

Con el lanzamiento de TFS 2010, se agregaron nuevas ventajas que facilitarán la vida del desarrollador que se encuentre con la difícil tarea de hacer los merges al momento de incorporar cambios a los diferentes branches, entre los que tenemos:

Visualización gráfica de la jerarquía de branches …

image

y visualización gráfica de los merges a los diferentes branches (incluye línea de tiempo …)

image

Con esta última mejora, podremos saber si un determinado cambio fue incorporado a un branch que lo requiera (si no se hubiera hecho el merge, el branch se vería en color rojo), y además, podemos saber en qué fecha y con qué changeset fue realizado.

Conclusión

Lograr equilibrios no es sencillo, pero los beneficios pueden ser muchos.

Invertir tiempo en la planificación y el mantenimiento de una política de branches que cubra nuestras necesidades pero que a la vez no se descontrole puede no ser fácil, pero seguramente permitirá reducir llamados de nuestros clientes enviando saludos a nuestras hermanas, madres y abuelas porque la entrega de la última versión, con aquellos fantásticos nuevos features, revivió bugs que habían sido ya solucionados.

Glosario

Development Branch con los cambios de la próxima versión
Main Es la conjunción de los branches Development y Release. Representa un “foto” estabilizada del producto que podría ser compartida, por ejemplo, con el equipo de QA
Service Pack Una colección de bug fixes que apuntan a la última versión liberada
Release Un branch sobre el que se hacen cambios de último momento o bug fixes de alta prioridad
Forward Integrate (FI) Merge desde branches padres a hijos
Reverse Integrate (RI) Merge desde branches hijos a padres
Release Vehicle Es la forma en que el producto llega al cliente

ALM, Gestión de Proyectos, TFS

Manage IT 2010 - Gestión de Proyectos y Arquitectura de Software por Daniel Laco

26. abril 2010

Se viene el evento nuevamente !!!

 

Este año estaremos repitiendo el evento sobre Gestión de Proyectos y Arquitectura de Software.

VEMN SA conjuntamente con el MUG, Lagash SA y el apoyo de la Universidad Argentina de la Empresa (UADE) realizaremos el evento el día 8 de Junio a las 9.00 hs. en la sala Magna de la UADE.

Temario

8:30 - 9:30 Acreditación
9:30 – 10:00 Presentación del Evento y KeyNote
10:00 – 11:15 Value Express. Optimizando los resultados de sus inversiones realizadas.
(Susana Silberberg)
11:15 - 11:45 Break
11:45 – 13:00 Desarrollo de aplicaciones de misión crítica.
(Diego Gonzalez y Rodolfo Finochietti)
13:00 – 14:15 Almuerzo Libre
14:15 – 15:30 Estimación de Proyectos de Software. La cara oculta de las diferencias.
(Daniel Laco y Patricia Scalzone)
15:30 – 16:00 Break
16:00 – 17:15 ¿Sueñan los Gerentes de IT con programadores eléctricos?
(Luis Ávalo)
17:15 – 17:30 Cierre y Sorteos
Es un evento de interés para profesionales de TI, Gerentes de Sistemas, Líderes de Proyectos, Arquitectos, Analistas y todo aquel interesado en el mundo TI.


El evento es gratuito. Vacantes limitadas, con inscripción previa.

Para mas información en www.manageit.com.ar.


ALM, Eventos, Gestión de Proyectos, Metodologías y Procesos, Tecnología , , , , ,

Especificaciones sin ambigüedades? por Patricia Scalzone

3. febrero 2010

Se imaginan? Nos cambiaría la vida a los analistas de sistemas, tal vez correríamos el riesgo que pase a ser la profesión más codiciada.

El Ing. Simón Pristupin está trabajando desde 1997 en una teroría denominada Gramática Distributiva (GD), que tiene por objetivo mejorar las capacidades de las personas para redactar discursos complejos.

En realidad, esto se aplica a cualquier disciplina o individuo que esté dispuesto a escribir correctamente. Un proyecto muy interesante sería que los niños aprendieran esta técnica desde pequeños, para mejorar en el futuro las malas interpretaciones provenientes de la escritura. Se están haciendo experiencias en este aspecto.

La comunicación es un proceso complejo, y más aún cuando es escrita.

En el desarrollo de Software, es habitual que en el momento del relevamiento, el usuario no cuente todo lo que sabe, o asuma que nosotros conocemos del tema, y es así como se omiten las aclaraciones de lo obvio. El analista lo recibe en su contexto conceptual, lo interpreta de cierta forma, lo escribe, y se lo entrega al desarrollador para que produzca lo que está plasmado en el documento de especificaciones. Entonces vuelve a cobrar vigencia la hamaca de Slabbovia, que la vi por primera vez pegada en el pasillo del 4to. piso de la Fiuba allá lejos cuando estudiaba, y no perdió vigencia en absoluto (se muestra más abajo).

Lo que propone Simón con la GD es no utilizar el lenguaje natural en la escritura de discursos que deben ser precisos, claros, sencillos y directos. Hay que depurar las ambigüedades e impurezas que nos ofrecen los textos escritos en dicho lenguaje. Para lograrlo, transfiere la complejidad de una cadena de muchas palabras a un conjunto de cadenas binarias (de dos palabras) mediante un proceso analítico, y luego se reconstruye la cadena de muchas palabras a partir de cadenas binarias, mediante un proceso de síntesis. Dicho de otra manera, la GD logra desglosar en forma sencilla discursos complejos, analizándolos desde la perspectiva de la cadena de palabras de menor complejidad (dos palabras o binaria). En su libro http://www.universia.com.ar/contenidos/LIBRO-GRAMATICA-DISTRIBUTIVA.pdf se explica claramente.

Parece complejo, pero es bastante sencillo. Creemos que vale la pena conocerlo y aplicarlo.

A medida que avancemos en nuestras pruebas, las iremos publicando.

 

 

Gestión de Proyectos, Metodologías y Procesos , , ,

Manage IT 2009 - Gestión de Proyectos y Arquitectura de Software por Daniel Laco

23. marzo 2009

Gestión de Proyectos y Arquitectura de Software

Nuevos desafíos de TI


Dentro del ciclo de vida de desarrollo de l Software, existen varias etapas que en mayor o menor medida ya se encuentran resueltas por la industria.
Actualmente, en la ejecución de proyectos, los aspectos tecnológicos dejaron de ser el factor problemático esencial, ya que contamos con diferentes herramientas como Guías y Frameworks que nos acompañan en los desarrollos.
Sin embargo existen dos áreas que hoy en día son las claves para el éxito o fracaso de un solución, siendo estas las que ofrecen mayor incidencia en el costo y tiempo de los proyectos.
Estas aéreas son la de Gestión de Proyectos y la Arquitectura de esas soluciones.
En este evento, oradores de primer nivel referentes de la comunidad tecnológica, nos mostrarán su visión desde diferentes ángulos, ya sea tanto desde la Gestión propiamente dicha como desde la administración de equipos de desarrollo. Además nos contarán desde su experiencia cuáles son las alternativas a tener en cuenta al diseñar la arquitectura de una aplicación.

Las buenas prácticas y el impacto en el costo de los proyectos de software. - Gestión de Proyectos
Oradores: Patricia Scalzone - Daniel Laco - VEMN Sistemas

Aún con los avances de estos tiempos, y las metodologías, herramientas y procesos con los que contamos, la gestión de proyectos sigue siendo un problema en las empresas.
La paradoja es pensar que la incorporación de buenas prácticas puede encarecer y enlentecer el proyecto, cuando la realidad es que podríamos ser mucho más eficientes, sobre todo en épocas de ajustes.
ALM (Application Lifecycle Management) son disciplinas que permiten alinear las estrategias del negocio, con el desarrollo del software y la operación.
En esta conferencia, se transmitirá el valor agregado que adquiere un equipo de desarrollo con la incorporación de estas prácticas.


Arquitectura y Desarrollo en Tiempo de Crisis
Orador: Rodolfo Finochietti - LAGASH System

En los últimos años se ha incorporado la práctica de arquitectura a los proyectos de software con diversos objetivos, la industria ha tomado este rol de diferentes formas y se ha acoplado a los equipos de desarrollo. En la actualidad y en el marco de una crisis global, las organizaciones se plantean un punto de inflexión en el cual se están revisitando decisiones anteriores, se están reestructurando equipos para acomodarse a los nuevos desafíos, en términos de velocidad, costos, y otros aspectos. A lo largo de esta presentación se darán cuenta de distintos desafíos y algunos lineamientos generales para encararlos.


Arquitecturas Web - Alternativas, Casos y Recomendaciones
Orador: Esteban Dannunzio  - VEMN Sistemas

En las aplicaciones Webs, hay desafíos a resolver en una arquitectura. Desde la elección del Framework principal, pasando por el desarrollo de la interfaz de usuario y las comunicaciones, hasta pensar las operaciones y mantenimiento de un sitio.
En esta presentación hablaremos sobre recomendaciones y alternativas para resolver cada una de las áreas, la incidencia en el proyecto, Contaremos algunos casos reales de implementaciones, con los pro y los contras de cada uno de ellos.


Gestión de equipos de Desarrollo
Orador: Diego González - LAGASH System

Los RRHH de TI (o sistemas) es uno de los perfiles más difíciles de gestionar, el nivel de compromiso con los proyectos debe ser alto, la especialización juega un rol azaroso, los desafíos pueden ser complicados de establecer, la rotación de los equipos, la sobrecarga de trabajo, entre muchos otros temas. En esta charla se identificarán esos problemas para dar lugar distintas técnicas de manejo de equipos que minimizan los desafíos mencionados y ayudan a una mejor integración de los equipos entre sí y hacia las organizaciones.

Gestión de Proyectos, Eventos ,

Nueva area de recursos sobre ALM y SharePoint por Daniel Laco

4. febrero 2009

Una nueva area en el sitio de MS sobre Sharepoint y ALM.

Se acaba de publicar el Application Lifecycle Management Resource Center for SharePoint Server

Aqui se pueden encontrar guias, articulos, links, herramientas sobre todo lo relacionado con ALM y Sharepoint.

Hay temas como:

  • Templates para Visual Studio
  • Control de código fuente.
  • Testing
  • Builds
  • TFS
  • Etc. etc. etc.

 

Sharepoint-ALM

 

ALM, Gestión de Proyectos, Metodologías y Procesos, Sharepoint ,