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-ylos-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 trimestreseste 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)