Blog dedicado a la calidad del desarrollo de software, procesos, normas, metodologías agiles, externalización IT y cosas relacionadas a la tematica

Que tal, ayer por la noche, mientras veian la final del fut, me encontre con un blog super interesante, todos sus post (o al menos los que vi en su momento) estan relacionado a la ingeniería software, calidad software, procesos, normas, metodologías agiles, externalización IT y cosas relacionadas a la temática.

stio web: http://www.javiergarzas.com

Círculos viciosos en el desarrollo de software

Sin duda, todos los posibles mal viajes en un diagrama.

La importancia del Coaching por parte del líder de proyecto

A mi humilde punto de vista, una de las cualidades de un buen líder de proyecto es la de transmitir de manera clara y original sus conocimientos técnicos que ha adquirido a lo largo de su experiencia profesional.

Debido a los tiempos de entrega tan estrictos, el líder de proyecto debe de tomar el papel pro activo de couch, e ir entrenando a los nuevos en el equipo y orientarlos a las buenas practicas y sobre todo el cómo desarrollar software de calidad al menor esfuerzo (persona/mes).

Dentro de las enseñanzas del líder de proyecto sugiero algunos tópicos:

1.- principios básicos de la programación orientada a objetos.

2.- patrones de diseño.
3.- patrones de arquitectura.

4.- fomentar el seguimiento de nomenclaturas acorde al equipo de desarrollo (nombrado de métodos, clases, proyectos etc etc.)

5.- la importancia de no mal viajarse.

6.- fomentar la humildad, ya que uno de los principales problema de comunicación y una verdadera enseñanza es el ego.

Nota: no soy un experto en el tema, son bienvenidos otros tópicos de enseñanza para hacer retroalimentación, de antemano el objetivo es compartir el conocimiento y aprender todos.

Principios ágiles

Los principios fundamentales de una metodología ágil se pueden resumir:

Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica enaltece la agilidad.
La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

(copy paste con el fin de difundir)
Fuente: http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software

Empresa non-grata

buscando en internet me encontre con un articulo muy interesante que sin duda lo tengo que incluir, para ver el articulo original da click aquí


el articulo trata sobre el desarrollo agil y algunas empresas que no son aptas para hacer negocios factibles ya que no entienden.


-----------------------------------------------------------------------------------------------------------

Hace algunas semanas, nos contactó una empresa con el objetivo de contratarnos para la implementación de un sistema. Había recibido buenas referencias nuestras en su búsqueda de empresas de desarrollo que fueran «confiables» y «trabajaran con calidad».

Luego de una primera conversación telefónica nos reunimos. Nos contó de que se trataba el proyecto y yo les presenté nuestra «filosofía» y «métodos de trabajo». Me pidió que le enviará un correo electrónico contando más sobre estas cosas para discutirlas con sus superiores y ver si realmente eramos lo que buscaban, además me entregó «el documento de requerimientos» del sistema que ellos mismos habían escrito y me dijo casi al despedirnos «Necesito una propuesta económica o cotización de los requerimientos que están en este documento» .

Era un documento muy vago, de 9 páginas y escrito con muchos tecnicismos de su negocio, en realidad no decia mucho, bueno en realidad no decia nada.

No ibamos a hacer la cotización, porque sencillamente no sabíamos que había que cotizar, y probablemente esta empresa tampoco lo sabia. Decidimos escribir un mail explicando lo que podiamos hacer para trabajar juntos, y comenzó un diálogo a través del correo electronico.Quiero compartir la conversación de la cual se pueden sacar algunas conclusiones, pero para nosotros la más valiosa fue que a esta empresa la declaramos persona non grata para trabajar.

Nota: La conversación fue editada para ocultar la identidad del cliente. El texto en gris son sus respuestas.

[1] ==================================================

Estimada Empresa,

Lo que sigue es un resumen de nuestra metodología de desarrollo . Esta es una especie de guía que debemos cumplir ambos y que de nuestra experiencia es la única forma de garantizar el éxito del proyecto.

Por favor, si tienes alguna duda podemos reunirnos para discutirlas en detalle.

De nuestra metodología ágil:

“No podemos cotizar lo que no sabemos cuanto va a tomar en esfuerzo aun…”

Partimos cotizando la(s) primera(s) semana(s) de consultoría (desarrollo) donde hacemos “Story Cards” o levantamiento de requerimientos junto a ustedes.

Es un tiempo intenso (exige muchas horas de ambos) donde en reuniones (participan los desarrolladores y los usuarios de negocio) escribimos en tarjetas los requerimientos del software colocando indicadores (número) del valor de negocio del requerimiento en las tarjetas (1 tarjeta = 1 requerimiento ).

Las tarjetas contienen en una especie de template, algo en la forma:

Para obtener <valor de negocio>
Como <role>
Quiero lograr <objetivo>

Además contienen criterios de aceptación en forma de escenario:

Dado que…
y que…
Cuando…
Entonces…

Todo esto sirve como comunicación entre el usuario y el desarrollador y además crea criterios de aceptación del requerimiento que en cada entrega parcial del software se valida (re-leyendo la tarjeta {“card”} ).

Las prioridades la coloca el usuario (o sea ustedes) por el valor de negocio que representa el requerimiento, es posible re-negociar todo el tiempo las prioridades con el equipo de desarrollo.

Una vez terminada la primera semana de levantamientos de Story Cards (este proceso es denominado ’story-carding’), los desarrolladores le colocan peso en esfuerzo (basado en su experiencia en escenarios similares) . Para esto los desarrolladores pueden separar el requerimiento en requerimientos más pequeños (un requerimiento grande es inestimable en esfuerzo)

Es importante definir bien los criterios de aceptación en las reuniones, pues es la única medida de que se ha terminado el requerimiento.

Para todo lo anterior usamos una herramienta online llamada “Pivotal Tracker” http://pivotaltracker.com

—–

De la implementación:

El entregable de esta primera etapa son los “Story Cards” del sistema más el esfuerzo de construirlo.

Si se aprueba, entonces en la segunda parte (construcción) partimos con el desarrollo de los requerimientos en orden de prioridad. Se crean iteraciones de un máximo de 2 semanas (puede ser de 1 semana). Cada semana tiene un entregable o release donde se ejecutan los criterios de aceptación del sistema junto al usuario de negocios (ustedes).

Si hay cambios (nuevos requerimientos), se crean nuevos story card, se valora la prioridad y en caso de ser alta, se estima y se re-organiza el backlog (pool de requerimientos a implementar en la próxima iteración.)

Del pago del proyecto:

Es siempre contra avance o entregable. El primer pago es una vez terminada la o las semanas de story carding. Los próximos pagos una vez entregados el release en cada iteración.

Se cobrán los avances en cada iteración (cada 2 semanas).

[2] ==================================================

Estimado continuum,

Me parece excelente la metodología AGIL, con la cual he trabajado en el desarrollo de proyectos, pero necesitamos tener una estimación de esfuerzo lo mas pronto posible, de acuerdo a los requerimientos entregados, si tienes dudas al respecto favor enviarlas a la brevedad, para acotar lo mas posible las actividades a desarrollar, ya tenemos la cotización de otros y con toda esta información tomaremos una decisión esta semana a más tardar la siguiente, por lo tanto necesitamos un orden de magnitud de costos para desarrollar este proyecto.

[3] ==================================================

Estimada Empresa,

¿Como puedes estar seguro que las demás empresas que dices que te enviaron cotizaciones entendieron los requerimientos y que estimaron el esfuerzo real?, ¿no has tenido ya pesimas experiencias con esta forma de trabajar?

No podemos estimar lo que no sabemos estimar, sería mentir (que en mi opinión es lo que están haciendo los otros con las metodologias clásicas de cascada) pues los requerimientos que tenemos son muy vagos y una reunión o una llamada telefónica no nos va a ayudar.

De la reunión que tuvimos lo único que rescaté fue que necesitan levantar los requerimientos junto al equipo que los va a desarrollar para poder comunicar que es lo que quieren e incluso para que a ustedes les quede más claro y puedan ordenar las prioridades.

En el mail anterior está la forma en que lo hacemos, si quieres una cotización para competir con los otros en tiempo o esfuerzo entonces preferimos quedar fuera, yo si tengo malas experiencias cuando trabajé en empresas que usaban este modelo y ahora tengo excelentes experiencias usando este nuevo paradigma, pero ambos tenemos que estar convencidos que es lo mejor, sino no funciona.

[4] ==================================================

Estimado continuum,

¿Cuanto tiempo necesitas para hacer el levantamiento que tu indicas y a que costo?

[5] ==================================================

Estimada Empresa,

Un equipo de 2 desarrolladores analistas. Nosotros trabajamos 35 horas semanales, y estarían disponibles para hacer el story-carding, pero ustedes tiene que garantizar el mismo tiempo de disponibilidad del usuario de negocios.

Si no es posible, tenemos que buscar una alternativa como por ejemplo 3 días corridos por 2 semanas o 3 semanas; Esto último en caso que no logremos escribir todo los requerimientos. Lo que si creemos necesario trabajar todo el día (sin interrupciones) para garantizar continuidad.

Entonces el costo aprox del “Story Carding” sería:

2 desarrolladores x [costo-desarrollador-hora-en-UF] UF/h x 24h x [2, 3] semanas = entre xxx.xx UFs (2 semanas) y xxx.xx UFs (3 semanas)

[6] ==================================================

Estimado continuum,

Eso seria factible si decidiramos hacer el proyecto con uds,  lo cual aún está en evaluación junto con otros proveedores, en esta etapa del proceso necesito una estimación de parte de uds de que significa hacer el proyecto en tiempo y costo, pero no es factible que incurramos en un costo (esta semana que llamas story-carding), para que uds nos entregue este dato.

Te invito que nos hagas llegar tus dudas de los requerimientos o tener otra reunión para acotarlos, de manera que con su experiencia en el desarrollo de estos proyectos puedan hacer una estimación

—————–

Notas: En este punto ya tuve deseos de enviar un mail agradeciendo el contacto y que abandonabamos la negociación, esta empresa sencillamente no habia entendido nada y no queria entender. Esperé entonces algunas horas, debatí los mails con algunos de mis colegas en continuum y decidimos que enviariamos un correo más, esta vez un correo estratégico del cual sabiamos que o obteniamos una respuesta esperanzadora o terminaba la negociación, y así lo hicimos.

—————–

[7] ==================================================

Estimada Empresa,

En unas horas más te envio un correo de definición donde te daré algunas cifras y como podriamos hacer para mitigar el riesgo de ambos.

PD: No tenemos dudas en los requerimientos, porque no existen, hay que levantarlos (¿recuerdas los Story Cards?). Al documento que me entregastes le falta mucha información.

[8] ==================================================

Estimada Empresa,

Como lo que estás buscando es tener “Presupuesto en frente” te propongo lo siguiente:

En continuum creemos que cualquier desarrollo de más de 2 meses es demasiado grande para estimarlo adecuadamente en el largo plazo. En nuestra experiencia, siempre se cae en los problemas de:

(A).- Terminar construyendo cosas que en realidad se descubre posteriormente que no son importantes o nunca se usan.
(B).- No poder implementar las sugerencias o requerimientos nuevos que inevitablemente surgen.

En esos casos (proyectos grandes) lo que hacemos es estimar por 8 semanas primeramente y sino alcanzamos, re-estimar por 8 semanas o menos más, y así iterativamente hasta terminar o alcanzar un punto de “Valor de negocio confortable” (a veces ocurre que el cliente se conforma con una parte del sistema que le sirve para operar). Sin embargo no faltan los clientes que piden requerimientos sin valor de negocio porque “creen” que algún día les servirá sin pensar en que estan  afectando el presupuesto.

Entonces, nada garantiza que en 8 semanas se implementen todos los requerimientos con “Valor de negocio” de tu sistema.
La semana de Story Carding (que está incluida en los 2 meses) dirá que tamaño tiene el sistema que quieren construir, ustedes deberán decidir que requerimientos tienen más valor de negocio y por tanto mayor prioridad.

Nosotros estimamos los tiempos de estos requerimientos y los requerimientos que no puedan ser implementado dentro de las 8 semanas debemos renegociarlos en la forma:

(1).- No lo hacemos.
(2).- Estimamos el costo del nuevo desarrollo. Como otro proyecto de X tiempo más (el tiempo que demoren los nuevos requerimientos).

Costo x 2 meses = 2devs x [costo-desarrollador-hora-en-UF] UF/H x 35H/semana x 8 semanas = xxx.xx UF (Total)

…

No obtuvimos respuestas. Fin de la negociación y declaración de persona non grata.

nota: este articulo fue extraido de: http://blog.continuum.cl/archives/163 solo difundí el articulo ya que me parecio muy interesante.

Diseño Ágil con TDD

Por:
               Carlos Blé Jurado y colaboradores.
               Prologo de José Manuel Beas

Érase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián que, además, eran hermanos. Ambos eran los cerditos más listos de la granja y, por eso, el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de ordenador para controlar el almacén de piensos. Les explicó qué quería saber en todo momento: cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes pero les advirtió que, en una semana, quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.

Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir líneas y líneas de código. Algunas eran de un reciente

programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo, pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera pero bueno, esto del software va de reutilizar lo que ya funciona, ¿no? Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabría que, efectivamente, estaba terminada cada cosa. Iván quería conocer, tan rápido como fuera posible, cuántos sacos de grano había en cada parte del almacén porque sospechaba que, en algunas partes del mismo, se estaban acumulando sacos sin control y se estaban estropeando. Como los sacos entraban y salían constantemente, no podía saber cuántos había y dónde estaban en cada instante, así que acordaron ir contabilizándolos por zonas y apuntando a qué parte iba o de qué parte venía, cada vez que entrara o saliera un saco. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén. 

Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván! Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó, además, las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa pero, salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en ningún momento. Claro, todo lo que enseñó lo había probado muchísimas veces antes gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una línea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván.

El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serían necesarias para lo que había pedido Iván, pero tenía un aspecto “muy profesional”.

Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración

desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un 50 % más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré

nada.”. Era una oferta complicada porque, por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Pero, por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis.

Mmmmm.

Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.

Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias.

 Ambos se pusieron rápidamente manos a la obra. Mientras Adrián

arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un webservice que permitía encolar cualquier operación

para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.

Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación, Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso, aprovechó para anotar algunos criterios que luego servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo.

Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dio por concluida la reunión y se dispuso a trabajar. Antes que nada, resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara.

A continuación, se marchó a casa a descansar. Al día siguiente, cogió la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados

con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había

venido desde América a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había

automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y este hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este

Hudson era realmente veloz e incansable! A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Terminaron culpando a todo el mundo. A Iván, porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca, porque había incluido una serie de cambios en

el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices, porque no tenían ni idea de cómo funciona una granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y, a partir de ahí, generar el esqueleto de la

aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se

marchaba, aún renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.

Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado y les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez:

“¿Qué estará haciendo Adrián? ¿Cómo lo llevará?”.

Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando que,

cada vez que arreglaba una cosa, le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde, a duras penas, funcionaba)

y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados... y lo peor de todo: el programa no hacía lo que habían acordado con Iván. Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y que tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.

Moraleja:

Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar “criterios de aceptación”, Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente

que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente.

En este libro que ahora tienes entre tus manos, y después de este inusual prólogo, te invito a leer cómo Carlos explica bien clarito cómo guiar el desarrollo de software mediante la técnica de escribir antes las

pruebas (más conocido como TDD).

nota. este articulo no fue redactado por mi en base al libro, si no que es el prologo del libro, digamos que  hice copy paste y decidí poner el prologo por que es muy muy bueno, claro todo esto con el fin de difundir la información

Libro:

http://www.dirigidoportests.com/wp-content/uploads/2010/02/disenoAgilConTdd_ebook.pdf