Tarea 20140407_02_GB: Unidad 2, continuacin en base a Respuesta de

Unidad 1:

Tarea 20140320_01_GB: Eleccin de una herramienta online

para utilizar metodologas giles: Investigar online y recomendar una herramienta para emplear metodologas giles.

Respuesta de GB1:

Por el tipo de mis proyectos hice una comparacin (ver archivo PDF) para ver

si mi primera eleccin era la adecuada y tomara kamban. La herramienta

online para kanban que elegira es:

http://www.simple-kanban.com/

En comparacin para mi proyecto de la Unidad 2 aqu en el curso tomara

tambin:

http://virtualkanban.net/http://virtualkanban.net/?es (Open Source)

pues esta ltima es en espaol y por ello me parece ms simptica, pero no he

probado su eficiencia.

Nuestros equipos no pueden reunirse diariamente y se maneja todo

digitalmente. Hasta ahora llevamos paralelamente el uso de podio (varios

proyectos a la vez pero no ms de 5 personas) y zoho (1 proyecto solamente,

que es el manejo de nuestra pgina web), que nos sirve de documentacin

tambin y enva diariamente un reporte de las tareas - para ello una persona

debe tomar la gestin del proyecto que es la persona generalmente que tiene el

contacto con el cliente.Tampoco podemos especificar iteraciones de duracin

pareja pero igualmente las tratara de lograr. Por ello tambin probara:

http://www.icescrum.org/en/: IceScrum. Herramienta Scrum y Kanban. Ofrece

las opciones de operacin, consulta y estimacin de historias de usuario.

Permite aadir historias de usuario a la pila de producto, dividir el tiempo en

Sprints y mover estas historias de la pila de producto a cada uno de los Sprint.

(GNU)

Algunos puntos no me quedaron claros como la asignacin de roles a personas

especializadas (x ej. traductores) - no slo de secuencias en kanban - ya que se

pueden llevar varios proyectos en el mismo tablero.

Un saludo,

Graciela

de Thomas Wallet - martes, 1 de abril de 2014, 08:37:

Para discutir en el foro requiero trabajar mis conceptos primero y luego los

pondra a discussion segn las preguntas que me han surgido:

1) Caractersticas de la Priorizacin gil

Cules son las caractersticas de la priorizacin en su lugar de trabajo?

Se toma en cuenta las caractersticas claves de la priorizacin gil?

Si en donde trabajo, una empresa cuya oferta se basa en servicios de

asesoramiento, hablo con las personas (Product Owners = PrOws) que

aprueban la vialidad de un proyecto y dan un tiempo de prueba (6 meses) para

proponer mejoras, tanto de su parte como del equipo, demostrando las

ganacias obtenidas, podra decirse que en base a lo leido en la Unidad 2

aceptan y usan no conscientemente - pero si intuitivamente - parte de lo

indicado por las metodologas giles para dar margen a la priorizacin relativa bajo el concepto de costo/beneficio y una estructuracin del trabajo con empleados, autnomos, adems en este caso, los mismos socios, que sea

apta a la politica empresarial.

La calculacin de esta relacin es basada en:

1) El costo se basa en infrastructura que permita un ritmo mensual de ciclos semanales fijos para entregas (publicaciones y eventos) que a su vez

determinan tareas que requieren una gestin de mejoras, cambios o

reacciones que agregan funcionalidades progresivas y permite sostener la

estructura de un equipo y la gestin con solidez. Aqu encuentro los

conceptos de "incremental, iterativo y timeboxed y de poca granularidad

incluso, pues luego la misma aumenta en el ciclo.

2) el aporte de beneficios: a) ganancias generadas en mi caso encargada del inbound marketing para

producir acercamiento y elevar la confianza con informacin hasta lograr la

venta del servicio y luego la permanencia del cliente- y

b) menciones y reconocimientos por organizaciones que son guas pblicas para elevar la aceptacin general como la apertura a cooperaciones y

fusiones

La asociacin de ambos resultados dan la base de confianza (reducir la

incertidumbre para encarar ese esfuerzo) y animarse a proyectos que no

aportan directamente una ganancia pero s la nocin de funcionalidad, que

aqu podra llamarse ganar reconocimiento, lo que implica tambin un alto grado de informacin y disposicin al riesgo.

Cmo se podra mejorar?

Para costear nuevas funcionalidades primero hay que lograr que el resultado

baje la incertidumbre de encarar ese esfuerzo, especialmente en los autores.

Una solucin sera aqu segn mi parecer elevar el grado de informacin para

la eleccin del temario de publicaciones y adems optimizar el ciclo poniendo

como pulmn extra al fin de semana para descansar con la publicacin pendiente a entregar el lunes y un equipo que realmente entienda el estilo del

autor y sea su sparring partner para no sentir que est slo con esta responsabilidad.

2) Estimaciones

En qu se diferencian las estimaciones giles de las estimaciones tradicionales?

1) El desarrollo de software, como la redaccin de publicaciones, es una actividad creativa y que requiere trabajar sin un condicionamiento de

una calculacin lineal, tambin hay una continua exigencia de aportes

de conocimientos y novedades para captar ms pblico. La actividad es

ms adaptativa al momento y no predictiva, pues hay que tomar decisiones

sobre la marcha, por supuesto respetando un ciclo de desarrollo y el

resultado pruebas para evaluar que la entrega parcial sea comercializable, por ejemplo por idiomas, por regiones nacionales o internacionales, por

tipos y tamaos de empresas, siendo cada clasificacin un nuevo ciclo.

2) El desarrollo tradicional, con sus etapas, produce todo el valor (el proyecto) normalmente en un lote solo. En todo momento, el 100% del

proyecto est siendo procesado y 0% ha sido terminado. Finalmente se

llega al momento donde todo el proyecto es entregado y debe funcionar

de un contexto a otro y alli se dan los ltimos toques, puede ser que hasta haya fallas que produzcan la prdida de imagen. Los mtodos

giles buscan incrementalmente entregar valor. En el caso de desarrollar

software se consigue agregando al producto funcionalidad en cada iteracin

y manteniendolo siempre funcionando. En el caso de las publicaciones se

buscan los profesionales que escriben en su lengua maternal y se analiza el

feedback publico, luego se decide con la prxima funcionalidad y se

entregan las versiones idiomticas con su localizacin por regiones y

acuerdos internacionales y se van agregando anexos por ejemplo por

semanas o meses al tema base para mantener la expectativa y aumentar la

complexidad para que los clientes identifiquen si necesitan asesoramiento y

se acerquen a exponer su situacin personal. Tambin los autores afianzan

as sus conocimientos y las interrelaciones con otras reas

complementarias.

3) https://www.udemy.com/blog/agil-vs-en-cascada-evaluando-los-pros-y-los-contras/

El modelo en Cascada puede ser descrito esencialmente como un

modelo lineal de diseo de software. Como su propio nombre

indica, la metodologa en cascada hace uso de un proceso de diseo

secuencial. El desarrollo fluye secuencialmente del punto inicial al

punto final, con varias etapas diferentes: Concepcin, Iniciacin,

Anlisis, Diseo, Construccin, Pruebas, Implementacin y

Mantenimiento. giles: Los Pros

Las giles ofrecen un modelo de diseo increblemente flexible,

fomentando planes adaptativos y el desarrollo evolutivo. Pueden

describirse como una forma libre de diseo de software. Los

desarrolladores trabajan en pequeos mdulos cada vez. La

realimentacin del cliente ocurre simultneamente al desarrollo,

como las pruebas del software. Esto tiene una serie de ventajas,

especialmente en entornos de proyectos donde el desarrollar

necesita ser capaz de responder a los cambios en requisitos de forma

rpida y eficaz.

Las metodologas giles pueden ser especialmente beneficiosas en

situaciones donde los objetivos finales de los proyectos no estn

claramente definidos. Por ejemplo, si est trabajando con un cliente

cuyas necesidades y objetivos son un poco vagos, es probable que

valga la pena emplear la metodologa gil. Los requisitos del cliente

se clarificarn gradualmente a medida que el proyecto avance, y el

desarrollo puede ser fcilmente adaptado para cumplir estos nuevos

evolutivos. La gil es tambin una excelente opcin para el diseo

de software experimental.

Por ltimo, esta metodologa tambin facilita la interaccin y la

comunicacin la colaboracin es ms importante aqu que el diseo. Debido a que la interaccin entre los diferentes diseadores

y participantes es clave, es especialmente propicia para entornos

orientados de trabajo en equipo. Distintos desarrolladores trabajan

en distintos mdulos a travs del proceso de desarrollo y luego

trabajan para integrar todos estos mdulos en una pieza nica de

software al final del proyecto.

En Cascada: Los Pros

El nfasis en la metodologa en Cascada se centra en la

planificacin del proyecto y por lo tanto antes de comenzar

cualquier tipo de desarrollo se necesita un plan y una visin claras.

Debido a que el mtodo en cascada requiere una amplia

planificacin por adelantado, se puede iniciar el software con

bastante rapidez. Tambin puede estimar plazos y costes de manera

ms precisa, lo que sin duda suele complacer a los clientes.

Por otra parte, los procesos de desarrollo en Cascada suelen ser ms

seguros por estar orientados a la planificacin. Por ejemplo, si un

diseador sale del proyecto no es un gran problema, como el

mtodo en Cascada requiere una amplia planificacin y

documentacin, un nuevo diseador puede fcilmente tomar el

relevo del antiguo diseador, siguiendo el plan de desarrollo sin

problemas.

giles: Los Contras

Aunque su flexibilidad es grande, las metodologas giles no tienen

la estructura de la metodologa en Cascada y eso hace que presente

algunos inconvenientes. Los proyectos giles suelen ser difciles de

predecir, desde los plazos hasta los costes. Sin un plan determinado,

todo tiene un aire vago y nebuloso.

Adems, como hemos comentado anteriormente, se necesita la

participacin activa e intensa de los usuarios durante todo el proceso

gil. Esto puede resultar problemtico por varias razones. En primer

lugar, este mtodo de desarrollo puede consumir bastante tiempo,

mucho ms costoso en tiempo que el mtodo en Cascada. Y,

adems implica que los diseadores deben estar comprometidos

mientras dure todo el proyecto. Si un diseador deja un proyecto en

Cascada a la mitad, probablemente no sea un problema demasiado

grande ya que el proyecto est basado en una planificacin. En el

caso del mtodo gil, sin embargo, el desarrollo est mucho ms

basado en la persona. El que una persona deje el proyecto podra ser

desastroso.

En Cascada: Los Contras

La metodologa en Cascada es increblemente estricta e inflexible.

Modificar el diseo del proyecto en cualquier fase del proyecto

puede ser una autntica pesadilla y una vez que una fase se ha

completado, es casi imposible hacer cambios. As que, si est

pensando utilizar el mtodo en Cascada, necesitar reunir todos los

requisitos con antelacin. Adems, el problema con la metodologa

en Cascada es que la realimentacin y las pruebas se aplazan

demasiado tiempo en el proyecto. De forma que si hay un problema,

es muy difcil reaccionar a l, requiriendose una sustancial cantidad

de tiempo, esfuerzo y a veces de dinero.

Entonces, Cul es Mejor?

Cuando se trata este asunto, debemos decir que ninguna

metodologa gil o en Cascada es de por s mejor que la otra. Dicho

esto, cada mtodo tiene sus aplicaciones. El mtodo en Cascada

suele ser mejor para proyectos estticos, donde no es tan posible que

demasiados cambios surjan durante el proceso de desarrollo. Por el

contrario, el mtodo gil suele ser una mejor opcin para proyectos

pequeos donde los cambios son muy probables durante el proceso

de diseo. An as, tenga en cuenta que estas son pautas y

sugerencias generales. Realmente, cuando se trata de elegir una

metodologa no existe una opcin correcta o equivocada. Necesita

entender qu metodologa es ms apropiada para su proyecto y sus

necesidades.

Qu tcnicas de estimacin usamos y que tan bien nos va?

Tcnica de Estimacin en la situacin actual:

Cada autor no tiene una fecha de entrega ni exigencia de hacerlo, luego que

entrega el texto el ciclo funciona bien y en cada iteracin tanto el autor

tiene un beneficio y el equipo tambin, que registra semanalmente y puede

cobrar mensualmente:

La unidad bsica de pago es la hora de trabajo de 45 y con valor diferencial

segn sea autor, traductor, lector, programador de operativo de web, diseador,

etc. cada tarea o publicacin no puede llevar ms tiempo aunque el tiempo de

entrega es de 24 hs.

Ahora me faltara, para hacer una estimacin clara de las entregas e introducir

una mejora como xej. hacerlo en dos etapas una para clasificar y otra para

producir, pues la problemtica que yo veo es que no hay seguridad del equipo:

El objetivo sera subir el promedio de autores regulares de semana a

semana en el caso de newsletter o bien mensuales, si son por ejemplo

artculos.

Para ello comenzara los ciclos los jueves con los reportes al medioda y el

pedido de confirmacin de publicacin hasta el viernes a las 10 hs. como

respuesta.

Cada autor me debera clasificar el jueves: el pblico objetivo de su

publicacin, dndome primero el ttulo o tema (no el texto terminado que me lo

dara el lunes), empresas grandes o PYMES y Start-Ups, idiomas, etc. para yo

preparar al equipo y eliminar tiempos de espera. El lunes se recibe el texto,

entonces el fin de semana sera un pulmn extra de tiempo para los

autores y el lunes se publicara, por ej. la versin en lengua materna, luego a 3

das de monitoreo y adaptaciones y en cada da una version idiomtica con un

resumen de reacciones de cada traductor a entregar a las 24 hs. segn la

newsletter o el artculo se acumulan dichos resultados para establecer la

prxima fase de publicacin.

3) Definicin del Valor de Negocio

Cules son los componentes que permitiran definir el valor de negocio en su

organizacin?

El valor del negocio en mi organizacin se determina sobretodo por la cantidad

de clientes nuevos y los nuevos contactos del portfolio empresarial que fueron

atraidos a travs de este proyecto. Mi situacin actual es p/ que el proyecto

sobreviva que de cada 3 publicaciones en un idioma debe haber una

captacin de cliente (que hace referencia a una accin de marketing),

sabiendo que tengo 5 autores alemanes multiplicados en por lo menos 4

idiomas con iteraciones que agregan funcionalidad en tres semanas ms.

Entre semana y semana se debe hacer un reporte de la reaccin del pblico de

las publicaciones y eventos de las 3 semanas anteriores y se clasifican las

publicaciones de la semana. Para ello uso programas de optimizacin de

buscadores, afiliacin, sistemas de voting, mailing serial a clientes C-D y con

carpetas impresas a los A-B y los potenciales, etc.

Para aumentar la CALIDAD que hace deseable a la publicacin tanto para los lectores como para los autores es la EXPRESIN de conceptos fiscales y

legales SIMPLE y respaldada por la posibilidad de seguimiento tomando

la prctica como base para describir ms profundamente esos conceptos y

manteniendo ese nivel simple y enlazado con las publicaciones anteriores,

que estn a disposicin del lector tambin: Al sistema de gestin de autores

lo tengo ya programado en TYPO3 con modulos de aviso y comparacin de

textos para hacer las traducciones, aprobacin, que se basa en trabajo en pares

de correccin y versin para la lista de los diferentes medios como condiciones

de portales y revistas especializadas tambin. Aqu es importante mantener en

un rea especializada al mismo grupo interno y de outsourcing para ese rea

pues reduce muchsimo el es3 del autor! 3 personas internas de la empresa

llevan las 6 pginas en internet, los boletines informativos, que no se dividen

en reas especializadas y los eventos.

Etapa de aumento de funcionalidad de web:

En este momento estamos programando la clasificacin de todas las noticias y

profesionales por reas automatizando las mscaras de profiles y los formatos

de publicaciones para Liquid Design/Responsive.

Ve algn criterio adicional a los que vimos a tener en cuenta para cuantificar el valor de negocio?

1) Tomara a esta empresa de asesoramiento como modelo para planificar mi proyecto de gestin gil para la organizacin de publicaciones de

tericamente 250 autores (que realmente bajan a 25 mensualmente y si hay

mucho trabajo que viene de mandantes/clientes puede ser a 5 promedio

semanalmente) pues se ha considerado para priorizar lo que d mayor

aumento del valor del negocio y que se debe repensar el delegar tareas, sosteniendo que cada publicacin tiene una funcionalidad DOBLE:

a) de reconocimiento pblico de la capacidad de cada rea de la empresa

que es representada por un socio que son las personas de contacto por reas

especializadas y a su vez

b) de reconocimiento pblico de cada miembro de cada rea especializada,

aunque no sea socio y as tiene la oportunidad de hacerse conocer

individualmente por su capacidad profesional como autor lo que trae

satisfaccin por mejoras en su reputacin y premios. Aunque implica una

obligacin es una capacitacin constant y da mayor oportunidades a su carrera

Qu facilidad tiene o no tiene la(s) herramienta(s) que investigaron en la unidad 1

para el manejo del valor de negocio?

IDEA: Entre las 10 hs y 12 hs del viernes puedo asociar persona con tarea,

hasta ahora manualmente y hacerlo como una PILA de product o historias

del usuario (user stories), y ponerlo en tarjetas (virtuales), cada una aportando valor de negocios incremental e individual.

Una historia es un requerimiento de negocios visto desde el punto de vista de

un usuario. Se escriben con el siguiente formato:

"Como xxx, quiero hacer yyy con el objetivo de zzz", donde, xxx es el tipo de

Usuario (quien), yyy es lo que el sistema debe permitir realizar (el qu) y zzz

es el beneficio o valor buscado (el por qu).

"Como AUTOR, quiero LECTORAR DE-VERSIN con el objetivo de

PUBLICARLO", donde xxx es el tipo de Usuario (quien), yyy es lo que el

sistema debe permitir realizar (el qu) y zzz es el beneficio o valor buscado

(el por qu).

Las condiciones de satisfaccin de los objetivos suelen ponerse en forma de

pruebas de aceptacin que se realizarn, indicando cmo debe comportarse

el sistema (o BDD, Behaviour Driven Development) con el formato "Dado

aaa, cuando se produzca bbb, entonces ccc", donde aaa es la situacin en la

que se encuentra el sistema, bbb es un evento que lo har cambiar y ccc es el

resultado. Esta tcnica permite evitar la aparicin de errores por malos

entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es

recomendable no empezar a desarrollar en una iteracin sin antes haber

escrito los casos de prueba, especialmente por que es ms barato escribir

texto y pensar en cmo desambiguar los requisitos que arreglar errores

importantes debido a su mal entendimiento.

Pero en la prctica no hace falta usar estos formatos, cualquier sintaxis

donde la accin sea clara y el beneficio buscado sea entendido por todos es

suficiente. Si no partimos de cero, podemos simplemente tomar los

requerimientos en cualquier formato que estn escritos (por ejemplo casos

de uso).

Estimacin con Planning Poker

El product backlog es, para ser exactos, una lista priorizada y estimada de

historias. Por ahora slo tenemos historias. Falta estimarlas y priorizarlas. El

proceso de estimacin se puede hacer utilizando una tcnica llamada

planning poker (pker de planificacin). El objetivo del planning poker es

obtener una medida de tamao relativo de todas las historias respecto a s

mismas.

La teora es que resulta relativamente fcil decir "A es ms grande que B y

que C" [no voy a entrar en detalle respecto a cmo efectuar planning poker,

dejndolo para otro artculo]. Lo importante de efectuar planning poker

sobre todo el backlog (a efectos de la planificacin) es que da como resultado

que todas las historias han sido estimadas con muy poco esfuerzo. Pero no

en das/hombre como se hara tradicionalmente. Planning poker produce

estimaciones en una medida arbitraria de tamao llamada story points o

"puntos de historia". Los story points son especficos de cada equipo, no

pueden compararse entre diferentes equipos y a veces ni siquiera entre

diferentes proyectos del mismo equipo. Lo nico que indican es el tamao

relativo que tiene cada funcionalidad del backlog respecto a las dems. Lo

importante es que ahora tenemos el tamao total del proyecto estimado en

una unidad llamada story points, y esto nos va a servir de mucho.

Priorizacin

La etapa de priorizacin es sencilla y depende exclusivamente del Product

Owner. Sabiendo ya el tamao de las historias, debe priorizarlas por valor de

negocio. Notar que tambin es posible comenzar con la asignacin de valor y

despus aportar el tamao, en todo caso, la priorizacin se realiza

balanceando el valor respecto al coste y respecto a los riesgos de cada

objetivo.

Una manera rpida de empezar a asignar valor a las historias es dividirlas en

3 grupos, segn sean imperativas, importantes o cosmticas/prescindibles

(de manera que si se llega a una fecha de entrega predeterminada y no se

han completado por lo menos hemos aportado el mximo de valor posible).

Dentro de cada grupo nos resultar ms fcil realizar una ordenacin relativa

por valor y despus asignarlo.

La prioridad puede cambiar todo el tiempo; pero el tamao en story points

debe mantenerse fijo con la estimacin original (o sea: como regla general,

no reestimar). Si aparecen historias nuevas, deben estimarse utilizando el

mismo criterio que se utiliz originalmente.

Ahora bien: todo esto todava no nos dice nada respecto a cunto durar o

costar el proyecto; pero al menos es un paso ms respecto a como

estbamos antes, que solo tenamos el ballpark estimate. Si slo pudiramos

averiguar a cuntos das/hombre o das/equipo equivale un story point,

tendramos nuestra estimacin, y luego nuestra planificacin.

Duracin y proyeccin a partir de la velocidad del

equipo

El ltimo paso, por lo tanto, es calcular la velocidad del equipo completando

objetivos a lo largo de las iteraciones. As pues, la velocidad es la cantidad de

story points que se completan por iteracin. Calcularla es sencilla: solo hay

que sentarse y esperar. En dos -como mximo tres- iteraciones, tendrs una

idea bastante clara de cul es la velocidad del equipo y por lo tanto el tamao

y duracin del proyecto. Mientras tanto se puede ir construyendo el

burndown chart, cosa que no me animo a traducir (grfico de quemado?). El

burndown chart nos muestra en el eje Y la cantidad total de story points del

proyecto, y sobre el eje X las iteraciones. Cada vez que se finaliza una

iteracin, se completa un punto del grfico, indicando la velocidad en ese

ciclo.

Si tenamos una fecha prefijada en la que queremos terminar el proyecto,

esto nos permite calcular la velocidad terica a la que tendremos que ir para

alcanzar esa fecha. El burndown chart permite rpidamente y en todo

momento ver dos estadsticas vitales para la planificacin: la estimacin

actual de cundo va a estar terminado el 100% del proyecto; y la estimacin

del porcentaje de proyecto que va a estar terminado cuando lleguemos a

cierta fecha.

Conclusin

La estimacin y planificacin gil permiten as en todo momento saber cul

es la fecha estimada de finalizacin del proyecto, y en qu iteracin estar

lista determinada funcionalidad. Un beneficio adicional que nos brinda es

que de existir complicaciones severas, que pongan en juego la factibilidad

del proyecto, stas generalmente se ven expuestas bien temprano,

permitiendo cancelar el proyecto antes de incurrir en grandes prdidas. Por

esto, sumado al hecho de que el desarrollo iterativo e incremental garantiza

que en todo momento se cuenta con el producto listo para ser entregado

(por ejemplo software funcionado), est el hecho de que los mtodos giles

disminuyen enormemente los riesgos tradicionales en el desarrollo de

proyectos.

4) Visin

Busque en la web formatos para describir la visin del proyecto y ejemplos

correspondiente.

http://aspgems.com/blog/ansueta/sin-perder-de-vista-la-vision-de-conjunto

Kelly Waters nos da algunas claves para no perder de vista la visin de conjunto

(the big picture) durante el desarrollo de un proyecto gil. Aqu os dejo una

traduccin libre: "Cuando utilizamos un enfoque basado en el desarrollo gil, no

hay grandes especificaciones ni diseos inamovibles. El alcance del proyecto

vara. Algunos requisitos evolucionan, y otros nuevos van emergiendo. Las

funcionalidades crecen, cambian y desaparecen a lo largo de todo el ciclo de vida

del proyecto. En este entorno variable, la cuestin es: qu podemos hacer para

no perder de vista la visin de conjunto? Aunque el desarrollo gil consiste, en

gran parte, en trocear los objetos hasta conseguir pedazos pequeos y

manejables -para obtener, por ejemplo, el product backlog y el sprint backlog- es

muy importante no perder de vista el contexto global, para que nos sirva como

gua y referencia a lo largo de todo el proceso. Este contexto se nos presenta en 3

formas principales:

Contexto de negocio Contexto de proyecto Contexto de la solucin

Contexto de negocio ALGUNAS PREGUNTAS TILES: Cul es la visin de

negocio? Cules son los retos y las oportunidades desde el punto de vista del

negocio? Cules son los objetivos de negocio a corto, medio y largo plazo?

Quines son los clientes? Por qu compran y para que utlizan las solucin que

vamos a desarrollar? Qu les gusta y qu no les gusta del proyecto? Quin es la

competencia y cmo son sus soluciones?

Sin esta informacin global de contexto, cualquier equipo de desarrollo est

trabajando con una gran desventaja. La gente de desarrollo puede ser muy

innovadora y si los equipos de desarrollo cuentan con una visin interna real del

contexto de negocio, pueden ser mucho ms proactivos. Con esta informacin,

es mucho mas probable que las soluciones innovadoras emerjan a la superficie.

Contexto del proyecto Muchos de los elementos definidos en la fase de inicio de

un proyecto tradicional siguen siendo importantes en un entorno de desarrollo

gil. ALGUNAS PREGUNTAS TILES: Cules son los problemas especficos o las

oportunidades que el proyecto intenta abordar? Cul es la visin para el

proyecto? Cules son los objetivos del proyecto? Cul es el enfoque? Cul es

el coste previsto y el plazo de entrega? Cules son los beneficios y cmo se van

a conseguir? Quin trabajar en el proyecto y cul ser su estructura?

Las respuestas a stas y otras preguntas constituyen una gua de referencia

importante para el equipo. Esta gua se hace ms necesaria si cabe en un

desarrollo gil, en el que hay libertad para cambiar las cosas durante todo el

proceso. Con esta informacin, el equipo dispone de algunos parmetros con los

que trabajar, y tiene claro cules son los resultados esperados. Contexto de la

solucin

He escrito varios posts sobre cmo escribir buenas historias de usuario. Me gusta

que sean tan pequeas, autoexplicativas y manejables. Hacen que las cosas

resulten sencillas. Pero, qu deberamos hacer antes de llegar al detalle de las

historias de usuario? Es importante enmarcarlas dentro del contexto global de la

solucin. Las siguientes herramientas pueden ayudarnos:

Mapa (roadmap) de producto de "alto nivel" (no entra en detalles). Utilizando una lnea de tiempo amplia -por ejemplo, meses o trimestres- este mapa nos permite destacar las funcionalidades clave del producto y los diferentes hitos principales que se producen a lo largo del proyecto. A diferencia de un plano, un mapa de producto es indicativo y evoluciona a medida que las cosas cambian. Proporciona al equipo una estructura del plan de sprints, y ayuda a identificar las prioridades y a establecer los objetivos de cada sprint.

Visuales de alto nivel. Pueden ser wireframes o maquetas con las pantallas clave, un storyboard conceptual para el interfaz de usuario, etc. Sea cual sea su forma, este boceto de alto nivel debe mostrar cmo funcionar la solucin desde la perspectiva del usuario. No hace falta que estos visuales especifiquen todas las pantallas, ni todas las funcionalidades. La solucin final ni siquiera tiene que mostrar el mismo aspecto de los visuales (de hecho, casi nunca lo hace). Pero constituye una buena gua para arrancar el proyecto porque cubre los escenarios principales a los que se va a enfrentar el usuario-tipo.

Arquitectura (de alto nivel) de la solucin. No hace falta que sea un diseo detallado. Lo que necesitamos es una arquitectura que nos sirva para entender las tecnologas clave, la estructura del producto, y cmo se comporta la solucin desde una perspectiva tcnica. Puede ser una imagen que vaya evolucionando. Algo as como el boceto que dibujamos en una pizarra al iniciar el proyecto, pero complementado con los detalles que vamos aadiendo a medida que el proyecto avanza y tomamos decisiones tcnicas.

Resumen: Un equipo de desarrollo gil necesita trocear las cosas en

pequeos fragmentos y hacer las entregas de manera incremental.

Para hacerlo, resulta especialmente importante tener en mente el

contexto general. Mi consejo es que utilices herramientas-gua de

alto nivel, ligeras y muy visuales (objetivos del proyecto, mapa de

producto, arquitectura de la solucin), y las mantengas pegadas en

la pared junto con las historias de usuarios y las tareas diarias.

Podis leer el post original aqu.

Opcionalmente escriba la visin de un proyecto suyo.

Visin de mi proyecto:

Aumentar la capacidad empresarial de proyeccin en el futuro a travs de

la estructuracin de un proceso de reconocimiento de sus facultades y

calidad - tanto a nivel global, como local y sobretodo individual - y la

aportacin de valores a la sociedad y as mismos que se redituen en

seguridad y la continua optimizacin de los servicios que prestan, entre

ellos la actualizacin informativa para ayudar.

http://www.proyectosagiles.org/skills-equipo-agil

5) Planificacin, monitoreo y adaptacin

Qu practicas/tcnicas de planificacin, monitoreo y adaptacin usan en su

organizacin? Cules de las que no se usan les parecen ms fciles de implementar?

Ms difciles?

Time-sheets basados en la registracin por duracin de tareas pero

reguladas con un parmetro que indica el promedio de las personas que ya

realizaron o realizan esa tarea para su comparacin, Cada uno trabaja en

un archivo EXCEL otorgado por el sistema de controlling.

Escala de precios por servicios en paquetes que llevan a un objetivo del

cliente y que garantizan segn la experiencia la cantidad de horas

empleadas y last areas estndares realizadas. Extras se toleran segn su

magnitud o se habla con el cliente por una oferta complementaria que se

regula por un acuerdo de honororarios y las Condiciones Generales y

particulares del negocio.

No hay reuniones diarias, slo se trabaja en base a guas de pproyectos en

podio/zoho y cada tarea se amplia por email.

Cules estn soportada en la(s) herramienta(s) estudiadas en la unidad 1?

Es interesante el soporte a travs de EXCEL que ofrece virtual kanban y

sera interesante ver cmo se podra implementar

6) Mtricas

Intente calcular o recolectar cada una de las mtricas presentadas para uno de sus

proyectos. Qu dificultas surgen? Qu mtricas/indicadores soporta la(s)

herramienta(s) estudiada(s) en la unidad 1?

VALOR:

El mayor problema fue el calculo de mi k (renta fija de 2% pero segn los proyectos disponibles tendra que basarme en un k de 10% por lo menos, y

eso que en Alemania se considera muy poca inflacin) para el VAN/NPV comparativo de cul proyecto convena prorizar (en base a lal flujo de caja

tenido en el ultimo ao) ms y mi IRR/TIR, llegu a la conclusion que es

mucho ms dificil de entender y no muy manuable (si quiero ganar un 30%

tendra que ser de 2,5%).

Lo importante es diferenciar en un proyecto si hay inversion inicial o bien

hay que diferenciar si la entrada de dinero es realmente de una inversin o de una reinversin de la ganacia del mismo proyecto para usar el k o el

IRR/TIR.

Si el valor del IRR/TIR es mayor que el costo del capital, se debera priorizar

el proyecto y si es menor no hacerlo.

Segn algunos estndares entiendo por las cifras que manejo que por

iteracin una publicacin (seminal) costara 500 a la empresa por lo que 3 publicaciones seran 1500 y por ello el condicionamiento de lograr un cliente

con un mnimo de ganancia de 3000 uros menos los costos relativizados al proyecto (poliza de seguro, alquiler, equipos, licencias, etc sumaron 250) igual sigue siendo conveniente. Si se aseguran 5 publicaciones siempre como

mnimo y pasan a una media de 25 semanalmente es un muy buen rango)

De estas cifras trate de configurar el ROI y el EVMtambin, alli creo que no

tengo problemas para priorizar este proyecto.

Establecer un ritmo para hacer las iteraciones fijas y dar los cycle time (4

das), lead time (7 das) y touch time (3 hs) segn lo indica Kanban es un

buen indicador para ver la VELOCIDAD de cuntas features x iteraciones

CALIDAD: Establecer en cada iteracin los escaped defects es una premise muy importante de Lean que en publicaciones arruina la imagen

del autor

Creo que el mayor aporte que me puede dar usar Kanban virtual es en

agilizar las parejas personas/publicaciones y alli me concentrara momentaneamente en hacer un esquema para su verificacin y la

estructuracin de la tareas en darle a travs de una funcionalidad ms

valor o definer as entonces un MMF.

Comparta y discuta estas preguntas con sus colegas y compaeros de trabajo de su

empresa.

Comparte en el foro su respuesta a la pregunta.

La comparacin de herramientas (Open Source) la hare en cuando haya

terminado la comparcin de eficiencias y determiner si mi propuesta aqu

es corrector para lograr las parejas ms rapidamente:

1) http://www.simple-kanban.com/ 2) http://virtualkanban.net/?es 3) http://www.icescrum.org/en/

otras que se recomendaron en el curso son

4) Redmine y Agilo (sugerencias del grupo)