ALM Day 2014

por Alejandra Federico  25. marzo 2014

En la 4ta edición del ALM Day, el temario estará orientado a conocer las estrategias adecuadas de la gestión de proyectos, contando con prestigiosos expertos quienes expondrán las mejores alternativas y estrategias en cada área.

En esta oportunidad contaremos con la participación de Alfredo Fuentes Espinosa, Developer Solution Lead de Microsoft Corp.

Horario: 9:00 a 13:15 hs. 

Agenda:

9:00 - 9:30: Acreditación

9:30 - 9:45: KeyNote (Patricia Scalzone – VEMN Sistemas)

El desafío está en la gestión y no en la tecnología, pero si está todo integrado... cuanto mejor. 

9:45 - 10:30: Gestión del Cambio en ALM  (Gregorio Correa – Incuba Consultores)

Una visión estratégica de cómo llevar adelante una implementación de ALM en una Empresa, y la implicancia de Gestión del Cambio que conlleva.

10:30 - 10:45: Break

10:45 - 11:30: Claves para la implementación de Metodologías Ágiles en Desarrollo (Viviana Chelini – VEMN Sistemas)

Ante problemas de proceso se buscan recetas mágicas como solución, considerando que la ejecución de cada paso de esa receta nos llevará al éxito. Las recetas existen…. pero la magia no!!

Además de una receta a seguir se deben considerar los ingredientes en el contexto a aplicar, con esto decimos no nos olvidemos del equipo tanto a nivel humano como técnico.

Durante esta charla abordaremos las claves a tener en cuenta para una adecuada implantación de metodología ágil en diferentes tipos de equipos.

11:30 - 12:15: Estrategias para Control de Versiones (Victor Passador - VEMN Sistemas)

Al comienzo de todo proyecto, durante la planificación tenemos en cuenta el diseño de arquitectura y definición de esqueleto de la solución, pero ¿dedicamos el suficiente esfuerzo en planificar la estrategia de branching o el tipo de repositorio donde alojaremos nuestro código? ¿Nos conviene un repositorio centralizado o uno distribuido? ¿Necesitamos branches by feature, branches by release o, como se empieza a escuchar ahora, “los branches son para cobardes”?

En esta charla plantearemos diferentes estrategias de versionado de código fuente y los escenarios a lo que mejor se adapta cada una.

12:15 - 13:00: Release Managent  (Alfredo Fuentes Espinosa, Developer Solution Lead Microsoft Corp.)

Cuanto más rápido se implemente el software, antes podrás obtener feedback. Con Release Management en Visual Studio, puedes configurar, aprobar e implementar tus aplicaciones para cualquier entorno. Crear orquestaciones de implementación automatizada para cada entorno sea cual sea la complejidad de la configuración. Al entregar el software con más frecuencia y facilidad a un entorno, los Testers y usuarios  pueden comprobar antes el sistema mientras se mantiene implicadas a las partes interesadas en la aportación de feedback y resultados.

13:00 - 13:15 Cierre y Sorteos


Datos del Evento:

Jueves, 27 de Marzo del 2014.

en el Auditorio del MUG, Rivadavia 1479, Piso 1°A, Capital Federal.

Para más información e inscripción AQUÍ

Tags:

ALM | Eventos | Gestión de Proyectos | Metodologías y Procesos | Metodologías y Procesos | Testing

Agregando Bugs al Board de Web Access - Template MSF for Agile 5.0

por Victor Passador  17. diciembre 2012

TFS 2012 propone gestionar las tareas del desarrollo a través de un Web Access totalmente renovado desde su versión 2010. Utilizando esta herramienta, el PM podrá entre otras cosas, administrar las capacidades del equipo, crear y asignar User Stories, Taks, Bugs, planificar sprints, verificar estado de avance del proyecto a través del Burndown chart, del reporte de salud de los Builds, y varios etcéteras más.

La planificación propiamente dicha, se realiza a través del “Board” (un tablero muy útil en daily meetings además de otros momentos) y facilita la administración de tareas ya que no hay que trasladar el cambio de estado de los papelitos en el “tablero de corcho” a la herramienta, sino que se puede hacer directamente desde ésta.

Considero que la herramienta aporta mucho a la agilidad, pero en ciertos escenarios, se queda corta en posibilidades de personalización.

El caso que quiero plantear se da con un Team Project ya creado y migrado desde la versión anterior, con el template MSF for Agile 5.0, donde quisiéramos que aparezcan en ese board los bugs, además de las tareas.

Aquí se explica cómo es que funciona el board y cuáles son los tipos de Work Item que allí aparecen.

Si bien el texto es claro y con ejemplos, no cubre el 100% de la necesidad de nuestro escenario. Describiré más abajo cuáles son los pasos a seguir (tomando los pasos detallados en el link y ampliando con lo que estaba faltando):


Aclaración 1: Cada uno de estos pasos consiste en exportar desde TFS a un directorio local una sección del Process Template con el que fue creado el Team Project, modificar las entradas que sean necesarias y volver a incorporar esa sección modificada en el servidor, todo esto utilizando el comando witadmin

Aclaración 2: Como estamos modificando definiciones en un servidor que probablemente esté en producción, es buena práctica conservar una copia de cada archivo que obtengamos luego de ejecutar un comando “witadmin exportxxx …”. Si las cosas no salen como esperamos, teniendo un backup, siempre será posible volver todo a su estado inicial ejecutando el comando “witadmin importxxx …”


Paso 1: “Bajar” la definición de categorías del template para poder incluir a los bugs dentro de la categoría Task Category (hace un tiempo escribí aquí sobre categorías de Work Items)

witadmin exportcategories
     /collection:CollectionURL
     /p:ProjectName
     /f:"DirectoryPath\categories.xml"

Paso 2: Modificar la sección correspondiente para que quede como se muestra a continuación

<CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
   <DEFAULTWORKITEMTYPE name="Task" />
   <WORKITEMTYPE name="Bug" />
</CATEGORY>

Paso 3: “Subir” la nueva definición

witadmin importcategories
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\categories.xml"

Paso 4: “Bajar” la definición de configuración para agregar los estados (metastates) y así unificar entre Task y Bugs

witadmin exportcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Paso 5: Modificar la sección correspondiente para que quede como se muestra a continuación

<TaskWorkItems category="Microsoft.TaskCategory">
    <States>
       <State value="Active" type="Proposed"/>
        <State value="Resolved" type="InProgress"/>
        <State value="Closed" type="Complete"/>
    </States>
</TaskWorkItems>

Paso 6: “Subir” la nueva definición

witadmin importcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"


Atención: En el ejemplo del artículo de MSDN hay una entrada para el estado “New”, pero debemos eliminarla porque no existe ese estado en el template MSF for Agile 5.0.  Si omitimos ese cambio, obtendremos un error al ejecutar el comando witadmin importcommonprocessconfig


Paso 7: “Bajar” la definición de Bug para poder modificar el template y agregar el campo Activity

witadmin exportwitd
    /collection:CollectionURL
    /p:ProjectName
    /n:Bug
    /f:"DirectoryPath\Bug.xml"

Paso 8: Modificar la sección correspondiente para que quede como se muestra a continuación

<FIELD name="Activity" reportable="dimension" type="String" refname="Microsoft.VSTS.Common.Activity">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development"/>
        <LISTITEM value="Requirements"/>
        <LISTITEM value="Design"/>
        <LISTITEM value="Testing"/>
        <LISTITEM value="Deployment"/>
        <LISTITEM value="Documentation"/>
    </SUGGESTEDVALUES>
</FIELD>

Paso 9: “Subir” la nueva definición

witadmin importwitd
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\Bug.xml"


Aclaración: Si bien estamos agregando este campo a la definición del bug porque el bug ahora pertenece a la categoría TaskCategory (paso 1) y requiere de esta definición, no es necesario modificar el Layout de edición a menos que queramos tener acceso a ese campo al momento de editar un bug.


Conclusión

Como ven en la captura, ahora tenemos visibilidad de los Bugs en el board Agile, y además, se ve una nueva columna (Resolved) que muestra los bugs en ese estado. Por favor no tomen en cuenta el Burndown Chart, es sólo un proyecto para pruebas Smile

image
 
Si después de realizar todo el proceso, los bugs siguen sin aparecer, por favor revisen que estén vinculados a la respectiva User Story.

Hasta la próxima!

Tags: , ,

ALM | Gestión de Proyectos | TFS

Manage IT 2011 Online

por Alejandra Federico  12. diciembre 2011

El martes 13 de diciembre se llevará a cabo, como todos los años, el evento sobre “Gestión de Proyectos y Arquitectura de Software”, que el mismo se realizará online.

Vemn conjuntamente con el MUG y Lagash presentarán diversos temas que en apariencia no son centrales en el negocio de IT, sin embargo muchas veces son clave para el éxito o el fracaso de los proyectos. Manage IT es el espacio para hablar de estas cuestiones.

Temario

16:00 – 16:10

 Presentación del Evento

16:10 – 16:30

 El desafío de diseñar aplicaciones para personas  (Ing. Andrés Stang)

16:30 – 17:00

 Caso de Éxito: Implementación de ISO 9001 con Scrum (Mg. Patricia   Scalzone)

17:00 – 17:30

 Tendencias actuales de desarrollo de Software basado en estándares: HTML 5 y  JavaScript (Rodolfo Finochietti)

17:30 – 18:00

 Manejo Documental en la Empresa. El impacto en los costos de una   solución de ECM (Enterprise Content Management)  (Daniel Laco)

 

Para más información e inscripción AQUÍ

Tags: ,

Eventos | Gestión de Proyectos | Metodologías y Procesos

ALM BootCamp–Video de las presentaciones

por Daniel Laco  23. mayo 2011

 

El pasado 28 de Abril participamos como oradores con Victor Passador en el ALM BootCamp en Microsoft Argentina.

También participaron Juan Pablo Díaz, Maxi Accotto y Eric Delahaye.

Aquí les dejo los videos de las presentaciones y que las disfruten !

 

Apertura - Juan Pablo Díaz:

 

 

Control de Versiones - Daniel Laco:

 

 

Versionado de Base de Datos - Maxi Accotto:

 

 

Arquitectura - Eric Delahaye:

 

 

Testing- Victor Passador:

 

 

Receta mágica de ALM para aplicar en TFS

por Victor Passador  26. marzo 2011

En la búsqueda diaria de la solución absoluta y definitiva a los problemas de gestión del código fuente, di con un post de El Bruno donde plantea algo muy simple pero efectivo:

1. Formación

    1.1 Conocer las capacidades de la herramienta

    1.2 Conocer la problemática del negocio

2. Tomar una decisión para comenzar a trabajar

3. Cada 6 semanas/meses ajustar la forma de trabajo

4. Goto 2

 

Según El Bruno, esto surge como conclusión de una Mesa Redonda con la gente de MadridDotNet donde se compartieron experiencias de administración de código fuente en cuestiones de branching, merge, archivos históricos, la maldición del checkout exclusivo y otras cuestiones.

Recomiendo su lectura, es un post cortito y ameno.

Hasta la próxima !

Tags: ,

Gestión de Proyectos | ALM

ALM Day 1–Exitósa jornada de ALM sobre Team Foundation Server

por Daniel Laco  3. marzo 2011

 

Ayer 2 de Marzo realizamos exitósamente el evento de ALM (Application Lifecycle Management) sobre TFS.

La jornada se desarrolló en las instalaciones del MUG.

La sala estaba completa, y la inscripción se completo varios días antes de las charlas.

Se pueden bajar las presentaciones aquí

INVEST en User Stories y SMART Tasks

por leticia  23. febrero 2011

User Stories

Una historia de usuario (User Story) describe funcionalidad valiosa para el usuario, equivale a un requerimiento funcional. Las historias de usuarios se redactan desde el punto de vista del usuario final, en un lenguaje simple, permiten que clientes y desarrolladores puedan acordar el trabajo conjunto a realizar de una manera efectiva.

¿Qué debe poseer una buena historia de usuario?

·        Interacción con el cliente: Se deben obtener de las reuniones realizadas con el cliente.

·        Definición: Las historias deben de ser claras, redactadas en un formato entendible por el usuario, para evitar confusiones. Debe capturar la esencia y no los detalles.

·        Valoración: Deben de poder priorizarse por el usuario.

·        Confirmación: Los clientes deben contribuir a validarlas, indicando de qué manera las probarían para aceptar el desarrollo realizado, mediante los tests de aceptación.

Sigla 'INVEST'  Para las User Stories

 I-Independent: Es deseable que las historias no se solapen conceptualmente, permitiendo que se puedan desarrollar independientemente una de otra.

 N-Negotiable: No se considera a una historia de usuario como contrato, ya que la misma no es lo suficientemente detallada, no obstante su definición alcanzará para que pueda ser estimada y planificada. La comunicación con el cliente permitirá luego delimitar su alcance y obtener su detalle. Una historia de usuario puede cambiar a lo largo del proyecto de desarrollo, por lo que se negociará con el cliente hasta lograr la funcionalidad definitiva.

 V-Valuable: La historia de usuario debe tener valor para el cliente. El equipo debe lograr que el cliente perciba el valor en los casos en que el mismo proviene de otros aspectos que no son apreciables “a simple vista” (por ejemplo aspectos técnicos específicos de arquitectura).

E-Estimable: Una buena historia puede ser estimada. No es necesario que sea de manera exacta, sino lo suficiente para que ayude al cliente a priorizar y planificar su implementación. La condición de estimable está relacionada con su condición de negociable, puesto que es difícil estimar historias que no se comprenden. Cuanto más grande se la historia o menos se entienda, más inexacta será su estimación. La experiencia del equipo influirá considerablemente en obtener mejores estimaciones conforme avance el proyecto.

S-Small: Una historia de usuario representa idealmente  unos pocos días de desarrollo. Una historia grande deberá subdividirse en otras más pequeñas (Split). Frases como “me llevará más de un mes”  deben alertar al equipo de que no se conoce cuál es el alcance de la historia o bien que no se entiende su total implicancia.

T-Testable: Toda historia de usuario (y requerimiento no funcional) debe de poder testearse. El hecho de contar con tests en forma temprana ayuda a los desarrolladores a verificar la exactitud del requerimiento y las necesidades reales. El mismo usuario colaborará con el equipo si sabe y comunica cómo probar la historia, evidenciando en caso contrario que la historia no está clara o que no refleja suficiente valor.

Tareas

Toda Historia de Usuario refleja lo que el cliente desea, pero no refleja lo que el equipo debe de considerar para su desarrollo. Al equipo le corresponde evaluar cada historia y descomponerla en tareas que desarrollo, y así asumir con confianza el compromiso de completarlas  en la iteración acordada.

Sigla 'SMART'  Para las tareas

S- Specific: Una tarea necesita ser específica de manera que cualquiera puede entender de qué se trata. Esto ayuda tanto a comprender la tarea como parte de un total.

M-Measurable: Que la tarea pueda medirse significa que se pueda marcar como “hecha”. El alcance de este término puede ser acordado dentro del equipo y con el cliente, aunque necesariamente implica cumplir  que se haga lo que se propuso, con los test incluidos y el código refactorizado.

A-Achievable: Las tareas deben ser “logrables”, para lo cual  todo miembro del equipo puede pedir ayuda cada vez que lo necesite para garantizar el cumplimiento.

R-Relevant: Cada tarea tiene sentido para el desarrollador, pero además es necesario poder explicar y justificar ante el cliente la misma cada vez que lo requiera.

T-Time boxed: Cada tarea debe tener una duración acotada (ideal un día…), no necesariamente formal pero que sí contribuya a anticipar  la necesidad de ayuda cuando la tarea es más compleja que lo esperado.

 

Viviana Chelini y Leticia Medela

 

Fuente: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Tags:

Gestión de Proyectos | Metodologías y Procesos

ALM DAY 1 - Buenos Aires

por Alejandra Federico  11. febrero 2011

ALM Day 1 – Buenos Aires

 

El 2 de Marzo se realizará en el auditorio del MUG la primera jornada de ALM (Application Lifecycle Management), donde Vemn Sistemas participará como orador.

El evento es organizado por el MUG y Microsoft, donde el objetivo es exponer ante la comunidad técnica el uso de Team Foundation Server (TFS) 2010 como solución ALM para la integración de roles. Está dirigida a Analistas de negocios, Analistas Funcionales, Arquitectos, DBAs, Desarrolladores, Testers, etc.

 

Temario:

 

\      ¿Cómo cambiar la cultura de una organización? (Patricia Scalzone)           

\      Administración de Proyectos con TFS 2010 (Eric Delahaye)

\       Integración de proyectos de Base de Datos al desarrollo (Maximiliano Accotto)

\       Mejora de la calidad del software con manejo de versiones en TFS 2010 (Guadalupe Casuso – Juan Pablo Díaz)

\      QA & Testing (Victor Passador)

\      Administración de Requerimientos usando Sharepoint (Alan Sheinkman)

 

Es una jornada gratuita.

Más información e inscripción en MUG 

 

Tags:

ALM | Eventos | Gestión de Proyectos | Metodologías y Procesos | TFS

TFS y los productos de terceras partes (cont.)

por Victor Passador  3. enero 2011

Hace unos días publiqué un post donde mencionaba los recaudos mínimos que deberíamos considerar al momento de instalar algún Add-on para TFS (vale también para VS).

Como no quiero que me consideren “apocalíptico” ni mucho menos trataré, por un lado, de mostrar las herramientas que nosotros hemos instalado y utilizado largamente y que nos han facilitado la vida en muchas oportunidades (o que estamos testeando con TFS 2010). Por el otro, me gustaría que ustedes comenten acerca de las experiencias que han tenido para que este post sirva, de alguna manera, como referencia de las herramientas que todo administrador o usuario de TFS debiera tener en su toolkit.

Empiezo yo:

Administración General

  • Team Foundation Server Tools 2010: Un viejo conocido, en su versión para TFS 2010, que entre otras cosas incluye:
    • Alerts Explorer: UI gráfica que permite suscribirse a los diferentes eventos del servidor (cambio de un work-item, build terminado, nuevo check-in, etc.)
    • TFS Backups: administra un schedule para backups de la base de datos de configuración, de los proyectos de la colección, sharepoint (si se instaló con la integración de esa herramienta), reporting services (ídem)
    • Best Practices Analyzer: Verifica problemas de deploy, data usage, etc.
    • Pack de políticas de check-in
    • Mejoras para Team Explorer
    • Editor de Templates
  • Team Foundation Sidekicks: Excelente herramienta de Attrice que permite visualizar/administrar entre otras cosas:
    • Historial de archivos del Source Control
    • Status (cheched out, locks, etc.)
    • Workspaces
    • Labels
    • Etc.

 

Sidekicks

Seguridad

  • Team Foundation Server Administration Tool: Uno de los problemas recurrentes al administrar proyectos de TFS es el de configurar permisos de usuarios. Hay que administrar seguridad tanto en el servidor TFS, el servidor de reportes y el sitio Sharepoint, cada uno con sus particularidades. Esta herramienta permitirá hacerlo todo junto desde un mismo lugar

 

Templates

 

Visual Studio

  • Productivity Power Tools (no es puramente TFS, pero los programadores –y otros- agradecidos) 
    • Solution Navigator: Permite ver clases (y sus miembros) desde el Solution Explorer, con filtros para visualizar solamente archivos abiertos, sin grabar, etc., vistas previas, y más.
    • Tab Well UI: Permite más posibilidades de manejo de ventanas del IDE para uso con múltiples monitores, tabs fijos (para que no desaparezcan cuando hay muchos documentos abiertos), coloreo de tabs según ciertas condiciones (soporta expresiones regulares), etc.
    • Searchable Add Reference Dialog: Ahora podemos hacer búsquedas al agregar referencias a nuestro proyecto !
    • Y mucho más …

TFS Power Tools

Otros

 

Creo que tengo alguna otra más para compartir, pero les dejo la posta a Uds. …

Saludos !

Tags: , ,

ALM | Gestión de Proyectos | TFS

Eligiendo un escenario de deploy para una nueva instalación de TFS 2010

por Victor Passador  29. noviembre 2010

Recientemente, un cliente nos comenta la decisión de incorporar TFS en la empresa como solución ALM.

El desafío que se planteaba era interesante, tenían un proceso medianamente ordenado pero cada uno de los roles involucrados utilizaba sus propias herramientas (algunas de ellas manuales) para administrar los documentos que se generaban, por lo que además de la diversidad de formatos, no existía sincronización entre esos documentos. Mucho menos pensar en algún tipo de versionamiento o workflow de aprobación.

Por su parte, el equipo de desarrollo recibía quejas constantes originadas en el cliente/usuario que apuntaban a la baja calidad del producto entregado. ¿Cómo era esto posible si el equipo contaba con recursos altamente capacitados?. Claramente el problema venía del lado de la mala administración del código fuente.

Con estas limitaciones en la gestión de los diferentes proyectos quedaba claro que no se podía contar con casi ningún tipo de métrica, gráfico o reporte que mostrara el grado de avance (o retroceso…). Tampoco existía la posibilidad de obtener algún indicador que permitiera la detección temprana de desviaciones.

Si bien la decisión estaba tomada, se reconocía asimismo la existencia de algún temor ante la imposibilidad de adaptarse a esta nueva herramienta que se presentaba como un gigante indomable frente a aquellas otras a las que conocían desde hace mucho tiempo. Iríamos por una cambio gradual.

En resumen, se requería una incorporación gradual de TFS al proceso de la empresa, pero con una visión de mediano/largo plazo que escale correctamente a medida que se vayan obteniendo resultados y que se vayan incorporando otras áreas y recursos de la empresa a esta nueva forma de integración. Por lo tanto, teníamos que lograr resultados rápidamente para convencer a los grupos más escépticos y a la vez estar preparados para cuando éstos decidan subirse al nuevo barco.

Arquitectura de servidores

Estaba claro que tanto las bases de datos (Data Services), como los reportes (Reporting Services, Analysis Services), serían instalados en un servidor dedicado distinto al que se usaría como Application Tier. En caso de detectar problemas de performance originados en el Data Tier, podríamos escalar utilizando SQL Server clusters.

Lo nuevo de todo esto es que con la versión 2010 de TFS también podemos escalar el Application Tier. Aparece aquí el nuevo concepto de TFS Farm.

Con esta nueva posibilidad, podemos agregar un nuevo servidor a nuestra Application Tier si se diera alguna de estas situaciones:

  • Necesidad de redundancia en la instalación de TFS
  • Necesidad de mejora de performance
  • Necesidad de restaurar un servidor que ha fallado
  • Necesidad de mover una instalación a otro servidor

 

Con esta arquitectura obtendríamos estos dos importantes beneficios:

  • Soporte de NLB (Network Load Balancing) en Application Tiers: Además de la mejora en performance, obtendremos alta disponibilidad, ya que podría caerse uno de los servidores sin que el usuario se entere. También podríamos aplicar parches individualmente a cada servidor poniéndolo offline sin desconectar a los usuarios.
  • Escalabilidad en Data Tiers: Teniendo más de un servidor SQL, tendremos más flexibilidad, ya que como cada Team Project Collection está en una base de datos independiente, podremos hostearlo como mejor nos convenga.

 

Un tema resuelto.

Organización de los proyectos

Habiendo relevado poco y nada a nivel global, no estaba del todo claro cómo íbamos a organizar los proyectos, y como el cliente no conocía TFS, no podía colaborar demasiado en determinar si usaríamos un sólo Team Project a nivel global y nos manejaríamos con áreas de proyecto para separar sectores (lo que implicaba un trabajo importante de personalización de templates de proyecto) o un Team Project por sector.

Finalmente nos decidimos por esta última opción, ya que si bien no estaba perfectamente delimitado, cada sector de la empresa se dedicaba casi exclusivamente a un sólo producto de software. Con esto, más algunos toques a las queries de work items, podríamos resolver las cuestiones más urgentes y en caso de necesitar un nivel de agrupamiento más alto, tendríamos la posibilidad de armar otras Project Collections.

Otro tema resuelto.

Final abierto (o no tanto …)

Al ser una instalación limpia, fue bastante sencilla y rápida la instalación de los diferentes componentes y la creación del Team Project que utilizaría, inicialmente, el sector que planteó los requerimientos.

Terminada la instalación, y habiendo logrado que los diferentes roles de ese sector pudieran …

… manejar documentos versionados utilizando el Project Portal como punto de acceso y que además, registren requerimientos en un repositorio común,

… que los desarrolladores puedan asociar el código fuente a cada uno de esos nuevos requerimientos y que además tengan la posibilidad de corregir bugs de versiones en producción al mismo tiempo que se desarrollan features de la nueva versión sin que eso implique un riesgo de regresión (gracias a un plan sencillo de branching),

… que se empiecen a generar los primeros reportes de trabajo pendiente y de estado de bugs,

todo esto con una solución (relativamente) sencilla y a la vez escalable, no es difícil imaginar cuál va a ser la reacción de los otros sectores de la empresa.

Hasta la próxima.

Tags:

Gestión de Proyectos | TFS | ALM

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML