INTRODUCCION A SCRUMMANAGER

El origen: la crisis del software Esta es una leccin de 0 puntos. Usted ha obtenido 0 punto(s) sobre 0 hasta ahora. El desarrollo de software es una actividad compleja y reciente, que ha enerado su conocimiento en un periodo muy breve, en comparacin con otras actividades profesionales! desde la aparicin de m"quinas que para ser #tiles necesitaban ser pro ramadas.

$a aparicin de componentes que cada dos a%os doblan la capacidad de sus antecesores&ley de 'oore( nos ha rodeado en menos de cuatro d)cadas de m"quinas capaces de procesar miles de millones de operaciones por se undo ('*+,-). En ./01 E2345 ocupaba una superficie de .10 m6, pesaba 70 toneladas, y ofrec8a una capacidad de proceso de 70.000 instrucciones por se undo. En 6006 El microprocesador ,entium 39 a 6 :h; ocupaba una superficie de 6.< mm6 y ten8a una capacidad de proceso de =.700 '*+,- (>'illions of theoretical operations per second) En la actualidad son cuatro los factores que i !ri en un rit o acelerado a la industria del "ardware. ?e ellos, tres son consecuencia de la ley de 'oore!

3ncremento constante de la capacidad de operacin. 'iniaturi;acin @educci de costes para la produccin de hardware

y a )stos se ha sumado en la #ltima d)cada El avance de las comunicaciones entre sistemas. $a consecuencia es obvia! ordenadores potentes, que pueden llevarse en el bolsillo y en permanente coneAin con randes sistemas, redes de comunicacin p#blicas, sistemas de locali;acin :,-, etc.

Estas cuatro l8neas de avance han e#tendido el $ %ito de a!licaci&n del "ardware, e incrementado al mismo rit o e#!onencial la co !le'idad de los siste as en los que se inte ra. $os ordenadores ya no son m"quinas #tiles slo para la banca o el ej)rcito. -e encuentran presentes en todos los "mbitos, por su capacidad de proceso y de comunicacin pueden ofrecer soluciones a sistemas cada ve; m"s complejos. Este es el escenario creado por la industria del hardware, y que en las tres #ltimas

d)cadas ha implicado a los desarrolladores de software en retos a los que no han respondido con solvencia.

Este problema se identific por primera ve; en ./1B, a%o en el que la or ani;acin 24*+ celebr la primera conferencia sobre desarrollo de software, y en la que se acu% el t)rmino >crisis del softwareC para definir a los problemas que sur 8an en el desarrollo de sistemas de software, cuyos proyectos siempre terminaban tarde, desbordando los presupuestos y con problemas de funcionamiento. *ambi)n se acu% el t)rmino >ingenier(a del softwareC para describir el conjunto de conocimientos que eAist8an en aquel estado inicial. 2uestra profesin es muy reciente, se podr8a decir que a#n adolescente (si no una ni%a) y que no cuenta todav8a con una base de conocimiento maduro. 5uando en los 10 y sobre todo en los <0 y B0 empe;aron a hacerse habituales los ordenadores, sur ieron los primeros >h)roes,C que sin m"s informacin que los manuales del operativo y el len uaje de pro ramacin, se reman aban delante del teclado para desarrollar las primeras aplicaciones. Dasta los <0 los ordenadores fueron m"quinas van uardistas y eAcesivamente caras. El ej)rcito y la banca eran los #nicos sectores que se las permit8an, y fueron los militares los primeros escarmentados, de !ro)ectos en los que el software sie !re llega%a tarde* al ) nunca+ con de asiados errores ) des%ordando todas agendas !re,istas. 4l unas referencias #tiles para comprender cu"les eran los conocimientos estables para el desarrollo de software en ./1B son!

El

En ./16 se public el primer al oritmo para b#squedas binarias. 5. EFhm y :. Gacopini publicaron en ./11 el documento que creaba una fundacin para la eliminacin de >:o*oC y la creacin de la pro ramacin estructurada. En ./1B los pro ramadores se debat8an entre el uso de la sentencia :o*o, y la nueva idea de pro ramacin estructuradaH ese era el caldo de cultivo en el que Eds er ?ijIstra escribi su famosa carta >:o*o -tatement 5onsidered DarmfulC en ./1B. $a primera publicacin sobre pro ramacin estructurada no vio la lu; hasta ./<0, publicada por $arry 5onstantine, :lenford 'yers y Jayne -tevens. El primer libro sobre m)trica de software fue publicado en ./<< por *om :ilb. El primero sobre an"lisis de requisitos apareci en ./</ t-r ino .Crisis del software. "ace referencia a:

$os problemas que el software libre plantea a la continuidad de las empresas de desarrollo de software. /os !ro%le as co unes ) frecuentes en los !ro)ectos de software: des%orda iento de agendas* !resu!uesto ) !ro%le as de funciona iento del resultado0 4l descenso de precios que afecta al software debido al aumento de la oferta (cada ve; hay m"s empresas y marcas de pro ramacin) y al software libre. -e refiere al creciente descenso de profesionales en el sector de la pro ramacin.

/A TESIS: Ingenier(a* gesti&n !redicti,a ) !rocesos Esta es una leccin de 0 puntos. Usted ha obtenido 0 punto(s) sobre 0 hasta ahora. ?esde ./1B hasta la fecha han sido muchos los esfuer;os reali;ados por los departamentos de inform"tica de las universidades, y por or anismos de estandari;acin y asesor8a para identificar las causas del problema y definir pautas est"ndar para la produccin y mantenimiento del software. $os esfuer;os desarrollaron en las tres #ltimas d)cadas del si lo pasado tres "reas de conocimiento que se revelaron como estrat) icas para hacer frente a la crisis del software! K 3n enier8a del software

:estin predictiva de proyectos ,roduccin basada en procesos.

INGENIER1A DE/ SO2T3ARE *)rmino acu%ado en la conferencia de la 24*+ de ./1B, al definir la necesidad de una disciplina cient8fica que, como ocurre en otras "reas, permita aplicar un enfoque sistem"tico, disciplinado y cuantificable al desarrollo operacin y mantenimiento del softwareH es decir, la aplicacin de la in enier8a al software. El proyecto m"s consensuado hasta la fecha para definir las "reas de conocimiento que comprender8an una in enier8a del software es el -JEE+L.

GESTI4N DE 5RO6ECTOS 5REDICTI7A $a necesidad de profesionali;ar la estin de proyectos sur i en los =0, en el "mbito militar, para abordar el desarrollo de complejos sistemas militares que requer8a coordinar el trabajo conjunto de equipos y disciplinas diferentes, en la construccin de sistemas #nicos. $a industria del automvil si ui los pasos de la militar, aplicando t)cnicas de estin de proyectos para la coordinacin del trabajo entre "reas y equipos diferentes. 5omen;aron a sur ir t)cnicas espec8ficas, histo ramas, crono ramas, los conceptos de ciclo de vida del proyecto o descomposicin en tareas (JE- JorI EreaIdown -tructure). $a estin de proyectos predictiva o cl"sica es una disciplina formal de estin, basada en la planificacin, ejecucin y se uimiento a trav)s de procesos sistem"ticos y repetibles. En los B0 se definieron los objetivos que la estin de proyectos deb8a cumplir para poder considerar que el trabajo concluye con )Aito! -e ejecuta en el tiempo planificado. -in desbordar el presupuesto estimado. -atisfaciendo las necesidades del cliente @eali;a las funcionalidades que necesita. $as reali;a correctamente y sin errores. En la actualidad, se #n el estudio peridico, que desde .//0 reali;a -tandish :roup, escasamente uno de cada tres proyectos de desarrollo de software termina en )Aito.

5aracter8sticas de la estin de proyectos predictiva Establece como criterios de )Aito! obtener el producto definido, en el tiempo previsto y con el coste estimado. 4sume que el proyecto se desarrolla en un entorno estable y predecible. El objetivo de su esfuer;o es mantener el crono rama, el presupuesto y los recursos. ?ivide el desarrollo en fases a las que considera >ciclo de vidaC, con una secuencia de tipo! concepto, requisitos, dise%o, planificacin, desarrollo, cierre.

5RODUCCI4N 8ASADA EN 5ROCESOS -obre el principio de calidad de Gur"n, empleado con buenos resultados en los procesos de produccin industrial! M$a calidad del resultado depende b"sicamente de la calidad de los procesos empleados en su produccinM, se desarrollaron tambi)n para la industria del software modelos de procesos (3-+ /0007, 5''3,

3-+ .==00...) para que las empresas puedan alcan;ar los cuatro beneficios clave de la produccin basada en procesos! N @epetibilidad de resultados. 4l conse uir que la calidad del resultado sea consecuencia del proceso, producir aplicando el mismo proceso aranti;a la homo eneidad de los resultados. N Escalabilidad. Es una consecuencia de la repetibilidad. 2o slo un equipo consi ue resultados homo )neos en todos los proyectos, sino que los obtienen todos los equipos. N 'ejora continua. 4l aplicar metaOprocesos que trabajan sobre los propios procesos de produccin, midiendo y anali;ando los resultados se obtienen los criterios de estin necesarios para aplicar medidas que mejoran de forma continua la eficiencia y calidad de los procesos base, y por tanto de los resultados. N Un InowOhow propio, consi uiendo finalmente una empresa que sabe hacer, porque su modelo de procesos termina conteniendo un activo valioso de la or ani;acin! el conocimiento clave para hacer las cosas bien, con eficiencia y de forma homo )nea. De los 9: a los ;: las !rinci!ales $reas de conoci iento desarrolladas ) a!licadas a la industria del software !ara e'orar sus resultados "an sido: <Indica la res!uesta correcta= :estin O 3n enier8a O ,roduccin basada en procesos O de de de del en procesos del la confi uracin requisitos !ro)ectos software cadena concurrente software evolutivo

O Gesti&n !redicti,a > Ingenier(a > 5roducci&n %asada en !rocesos O ,roduccin O 3n enier8a de O 4se uramiento de calidad 3n enier8a O ?esarrollo O ,roduccin basada en procesos O

/A ANT1TESIS: Agilidad Esta es una leccin de 0 puntos. Usted ha obtenido 0 punto(s) sobre 0 hasta ahora. PEl modelo predictivo es el #nico posibleQ. P$os criterios para determinar el )Aito slo pueden ser el cumplimiento de fechas y

costesQ P,uede haber proyectos que no ten an como finalidad reali;ar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculadosQ PR si el cliente no estuviera interesado en saber si el sistema tendr" 60 600 funcionalidades, si estar" en beta 1 meses o 6 a%osQ P-i su inter)s fuera poner en el mercado antes que nadie un producto valioso para los clientes, y estar continuamente desarrollando su valor y funcionalidadQ Sui;" en al unos proyectos de software el empe%o en aplicar pr"cticas de estimacin, planificacin, in enier8a de requisitos sea un empe%o vano. Sui;" la causa de los problemas no sea tanto por una mala aplicacin de las pr"cticas, sino por la aplicacin de pr"cticas inapropiadas. Sui;" se est)n enerando >fiascosC al eAi ir a los clientes criterios de adquisicin, y al aplicar a los proyectos procesos de estin predictivos, cuando se trata de proyectos que no necesitan tanto arant8as de previsibilidad en la ejecucin, como valor y fleAibilidad para trabajar en un entorno cambiante. En mar;o de 600., .< cr8ticos de los modelos de mejora basados en procesos, convocados por Lent EecI, que hab8a publicado un par de a%os antes el libro MEAtreme ,ro rammin EAplainedM en el que eApon8a una nueva metodolo 8a denominada EAtreme ,ro rammin , se reunieron en -alt $aIe 5ity para discutir sobre el desarrollo de software. En la reunin se acu% el t)rmino >')todos T ilesC para definir a los que estaban sur iendo como alternativa a las metodolo 8as formales! 5''O-J (precursos del 5''3), ,'3, -,35E(proyecto inicial de 3-+ .==00), etc. a las que consideraban eAcesivamente >pesadasC y r8 idas por su car"cter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo. $os inte rantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como >'anifiesto T ilC, que son los principios sobre los que se basan estos m)todos. Dasta 600=, entre los defensores de los modelos de procesos y los de modelos " iles han sido frecuentes las posturas radicales, qui;" m"s ocupadas en descalificar al otro que en estudiar sus m)todos y conocerlos para mejorar los propios. 'anifiesto (http!UUwww.a ilemanifesto.or ) Estamos poniendo al descubierto mejores m)todos para desarrollar software, haci)ndolo y ayudando a otros a que lo ha an. 5on este trabajo hemos lle ado a valorar! T il

4 los individuos y su interaccin, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentacin eAhaustiva. $a colaboracin con el cliente, por encima de la ne ociacin contractual. $a respuesta al cambio, por encima del se uimietno de un plan.

4unque hay valor en los elementos de la derecha, valoramos m"s los de la i;quierda Virmado por! Lent EecI, 'iIe Eeedle, 4rie van EenneIum, 4listair 5ocIburn, Jard 5unnin ham, 'artin Vowler, Games :rennin , Gim Di hsmith, 4ndrew Dunt, @on Geffries, Gon Lern, Erian 'aricI, @obert 5. 'artin, -teve 'ellor, Len -chwaber, Geff -utherland, ?ave *homas.

7alora os $s a los indi,iduos ) su interacci&n que a los !rocesos ) las "erra ientas0 Este es posiblemente el principio m"s importante del manifiesto.

,or supuesto que los procesos ayudan al trabajo. -on una u8a de operacin. $as herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento t"cito, sin personas con conocimiento t)cnico y actitud adecuada, no producen resultados. $as empresas suelen predicar muy alto que sus empleados son lo m"s importante, pero la realidad es que en los a%os /0 la teor8a de produccin basada en procesos, la rein enier8a de procesos ha dado a )stos m"s relevancia de la que pueden tener en tareas que deben ran parte de su valor al conocimiento y al talento de las personas que las reali;an. $os procesos deben ser una ayuda y un soporte para uiar el trabajo. ?eben adaptarse a la or ani;acin, a los equipos y a las personasH y no al rev)s. $a defensa a ultran;a de los procesos lleva a postular que con ellos se pueden conse uir resultados eAtraordinarios con personas mediocres, y lo cierto es que este principio es peli roso cuando los trabajos necesitan creatividad e innovacin. 7alora os $s el software que funciona que la docu entaci&n e#"austi,a0

,oder ver anticipadamente cmo se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un MfeedbacIM muy estimulante y enriquecedor que enera ideas y posibilidades

imposibles de concebir en un primer momento, y dif8cilmente se podr8an incluir al redactar un documento de requisitos detallados antes de comen;ar el proyecto. El manifiesto no afirma que no ha an falta. $os documentos son soporte de documentacin, permiten la transferencia del conocimiento, re istran informacin histrica, y en muchas cuestiones le ales o normativas son obli atorios, pero se resalta que son menos importantes que los productos que funcionan. 'enos trascendentales para aportar valor al producto. $os documentos no pueden sustituir, ni pueden ofrecer la rique;a y eneracin de valor que se lo ra con la comunicacin directa entre las personas y a trav)s de la interaccin con los prototipos. ,or eso, siempre que sea posible debe preferirse reducir al m8nimo indispensable el uso de documentacin, que enera trabajo que no aporta un valor directo al producto. -i la or ani;acin y los equipos se comunican a trav)s de documentos, adem"s de perder la rique;a que da la interaccin con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas. 7alora os contractual0 $s la cola%oraci&n con el cliente que la negociaci&n

$as pr"cticas " iles est"n especialmente indicadas para productos dif8ciles de definir con detalle al principio del proyecto, o que si se definieran as8 tendr8an al final menos valor que si se van enriqueciendo con retroinformacin continua durante el desarrollo. *ambi)n para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de ne ocio del cliente. ,ara el desarrollo " il el valor del resultado no es consecuencia de haber controlado una ejecucin conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece l8neas divisorias de responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor. En el desarrollo " il el cliente es un miembro m"s del equipo, que se inte ra y colabora en el rupo de trabajo. $os modelos de contrato por obra no encajan. 9aloramos m"s la respuesta al cambio que el se uimiento de un plan ,ara un modelo de desarrollo que sur e de entornos inestables, que tienen como factor inherente el cambio y la evolucin r"pida y continua, resulta mucho m"s valiosa la capacidad de respuesta que la de se uimiento y ase uramiento de

planes preOestablecidos. $os principales valores de la estin " il son la anticipacin y la adaptacinH diferentes a los de la estin de proyectos ortodoAa! planificacin y control para evitar desviaciones sobre el plan. ?Cu$l de las siguientes res!uestas contiene los cuatro !rinci!ios del anifiesto $gil@ O 4 los individuos y su interaccin por encima de los procesos y las herramientas O $os procesos de mejora continua por encima de la documentacin eAhaustiva. O $a colaboracin con el cliente por encima del software que no funciona O $a respuesta al cambio por encima del se uimiento de un plan 4unque hay valor en los elementos de la derecha, valoramos m"s los de la i;quierda O 4 la interaccin de los individuos con los procesos por encima de la comunicacin escrita O $a colaboracin con el cliente por encima de la ne ociacin contractual. O $a estin de los cambios, por encima del mantenimiento de la planificacin. O El software que funciona por encima de la documentacin eAhaustiva. 4unque hay valor en los elementos de la derecha, valoramos m"s los de la i;quierda O 4 los individuos y su interaccin por encima de los procesos y las herramientas O $os procesos de mejora continua por encima de la documentacin eAhaustiva. O $a colaboracin con el cliente por encima del software que no funciona O $a respuesta al cambio por encima del se uimiento de un plan 4unque hay valor en los elementos de la derecha, valoramos m"s los de la i;quierda O 4 los individuos y su interaccin por encima de los procesos y las herramientas O $a respuesta al cambio por encima del se uimiento de un plan O El software que funciona por encima de la documentacin eAhaustiva O $a colaboracin con el cliente por encima de la ne ociacin contractual

A E'ercicio de Re!aso: /ecciones B a C $a 3n enier8a del software

Valso

es

una

de

las

in enier8as

t)cnicas

m"s

veteranas. @espuesta

$a estin de proyectos predictiva establece como criterios de )Aito de un proyecto! obtener el producto definido, en el tiempo previsto y con el coste estimado. @espuesta
9erdadero

$a produccin basada en procesos se basa en el principio de calidad de Gur"n, empleado con buenos resultados en los entornos de produccin industrial! M$a calidad del resultado depende principalmente de la calidad de los procesos empleados en su produccinM. @espuesta
9erdadero

En 4 osto de 600= en una reunin promovida por -E3 (-oftware En ineerin 3nstitute) en la que participaron .< t)cnicos y cr8ticos de los modelos de mejora, se

acu% el t)rmino M')todos T ilesM y se redact el M'anifiesto T ilM. @espuesta

Valso

?e los cuatro postulados del 'anifiesto T il, el primero afirma! M9aloramos m"s a los individuos y su interaccin que a los procesos y las herramientas @espuesta
9erdadero

$a estin predictiva de proyectos tiene en cuenta que el proyecto se desarrolla en un escenario de ne ocio muy r"pido que aporta incertidumbre, cambios frecuentes en los requisitos y la necesidad de ofrecer resultados en el menor tiempo posible. @espuesta
Valso

Co !leta los "uecos En ./1B, en la primera conferencia de la 24*+ sobre desarrollo de software se acu% el t)rmino @espuesta
crisis del softw are

,ara referirse a los problemas habituales en los proyectos de pro ramacin. El proyecto m"s consensuado hasta la fecha para definir el cuerpo de conocimiento de la in enier8a del software es el @espuesta
-JEE+L

-elecciona la respuesta correcta ?esde los a%os <0, hasta finales del si lo pasado se han dise%ado modelos, pr"cticas y est"ndares que desarrollan tres "reas de conocimiento que toman por estrat) icas para mejorar la situacin! in enier8a del software, estin predictiva de proyecto y @espuesta
produccin basada en procesos

$a estin de proyectos predictiva o cl"sica es una disciplina formal de estin basada en la @espuesta
planificacin

@espuesta

ejecucin

y @espuesta

se uimiento

5u"l de las si uientes 2+ es uno de los beneficios clave de la produccin basada en procesos! @espuesta
'ejora del clima laboral

Conoci iento en e,oluci&n continua Esta es una leccin de 0 puntos. Usted ha obtenido 0 punto(s) sobre 0 hasta ahora. 5uestionar lo conocido es el motor de la evolucin del conocimiento. 2o es nuevo. Ra lo formul ,latn, es la base de la teor8a dial)ctica , y como recuerdan 2onaIa y *aIeuchi, en Ditotsubashi on Lnowled e 'ana ement (*aIeuchi W 2onaIa, 6000) este patrn dial)ctico de tesis, ant8tesis y s8ntesis

diri e la evolucin del conocimiento! ant8tesis que cuestionan las tesis anteriores, y producen nuevas posturas de s8ntesis que a su ve; har"n el papel de tesis en el si uiente ciclo evolutivoH formando as8 una espiral de evolucin y perfeccionamiento continuo. $a evolucin del conocimiento si ue el patrn dial)ctico de tesis X ant8tesis y s8ntesis.

$os modelos basados en procesos han sido la MtesisM que inicia el conocimiento para desarrollar sistemas de software. $a a ilidad es su ant8tesis, y estamos enerando en estos a%os la s8ntesis! el resultado que se enriquece de ambos, y lo ra un conocimiento m"s completo y depurado En los B0 y /0 comien;a a cristali;ar la primera base de conocimiento! la tesis. $os modelos de procesos espec8ficos! 3-+/000O7 5''Ys, -,35EO3-+ .==00 , Eootstrap, etc 4plicacin del mismo patrn predictivo de estin de proyectos, aplicado en otras in enier8as! ,'3 , 3,'4 . ,rimer borrador de consenso sobre el cuerpo de conocimiento de la 3n enier8a del -oftware! -JEE+L (3EEE 5omputer -ociety, 6000). En los /0, lle a la difusin y aplicacin de este conocimiento. En al unos "mbitos da buenos resultados, y en otros enera la r)plica Mdial)cticaM! El 'anifiesto T il, que cuestiona la valide; de los modelos basados en procesos y la estin predictiva para el desarrollo de software. -e radicali;an las posturas entre ambas l8neas y se enera (y se est" enerando) la tensin entre contrarios que mueve la evolucin dial)ctica del conocimiento.

4l unos

ejemplos

de

esta

tensin!

MLa diferencia entre un atracador de bancos y un terico de CMM es que con el atracador se puede negociarMZ MLa evaluacin en CMM depende ms de una buena presentacin en papel que da la calidad real del producto de software. Tiene que ver ms con el seguimiento a ciegas de una metodologa que con el desarrollo y puesta en produccin de un sistema en el panorama tecnolgicoM. Len +rr , 5'' versus 4 ile ?evelopment! @eli ious wars and software development . MSi uno pregunta a un ingeniero de software tpico si cree que CMM se puede aplicar a los m todos giles! responder o con una mirada de sorpresa o con una carca"ada #ist ricaM.

@ichard *urner y 4purva Gain, 4 ile meets 5''3! 5ulture 5lash or 5ommon 5ause . En los #ltimos a%os se apuntan ya las tendencias de la evolucin hacia la s8ntesis! En estos momentos autoridades de la 3n enier8a del -oftware como Earry Eoehm y @ichard *urner hablan de balancear la a ilidad y la disciplina (Eoehm W *urner, 6000) 3-+ comprueba y anuncia que los modelos desarrollados funcionan en unos entornos, pero no en otros, y ha creado ya comit)s para desarrollar versiones m"s li eras ($aporte W 4pril, 600=). -ur en iniciativas de normali;acin como 'o,ro-oft que buscan puntos intermedios entre ambos eAtremos. 'uchos profesionales plantean dudas sobre ambos eAtremos, y prueban me;clas y soluciones h8bridas .

Estamos determinando la primera oposicin en la espiral dial)ctica del conocimiento de la 3n enier8a del software. Es un momento confuso, en el que ya no est" tan claro el norte y resulta dif8cil orientarse. Era m"s cmodo en .//= por ejemplo. 5on la tesis desarrollada, y sin haber despertado a#n su ant8tesis " il, sent8amos que hab8amos alcan;ado la verdad. Sue ya sab8amos cmo desarrollar software. Sue era cuestin aplicar pautas de in enier8a en fases secuenciales, con estin predictiva... 4hora estamos a mitad de resolucin entre esa tesis y su ant8tesis " il. $a contradiccin produce desconcierto, pero adem"s en nuestro caso, la velocidad de comunicacin facilitada por 3nternet, y el apresuramiento eneral del entorno, hace que se solapen las tres tendencias del ciclo. 3-+ .==00, 5''3, -crum, ?-?', EAtreme ,ro rammin , etc. son randes aportaciones y es mucho lo que se puede aprender de ellos, pero es iluso pensar de cualquiera de ellas que es $a -olucin. El conocimiento siempre estar" evolucionando, y no tardar"n mucho en quedar mejorados. $os libros sobre 5''3 o -crum de hoy, cuando los leamos dentro de pocos a%os ser"n teAtos de conocimiento desfasado. -crum 'ana ement no es un modelo basado en procesos, o en a ilidad. 2o es ni tesis ni ant8tesis. En este momento hace s8ntesis aprendiendo tanto de los aciertos como de los errores de ambosH y que es posible racias al conocimiento aportado, y se une a el para avan;ar en la espiral del conocimiento que mejora nuestro trabajo.

Scru Manager es un software %asado en: $os procesos

arco de conoci iento !rofesional !ara desarrollo de

$a mejora continua a trav)s de un modelo de in enier8a de procesos. -8ntesis del conocimiento que han enerado la a ilidad y los procesos. $a respuesta no es correcta.

/a e !resa co o siste a Realidad sist- ica de las organiDaciones $a realidad sist)mica de las or ani;aciones un principio de -crum 'ana er. Una empresa es un sistema de m#ltiples componentes y facetas y las acciones y estrate ias en cualquier "rea tienen implicaciones y necesitan respuestas y alineacin con el resto. $a empresa se debe estionar como una realidad #nica, y no como un conjunto de departamentos m"s o menos independientes y comunicados. 3mplantar a ilidad en la empresa como sistema tiene muchas m"s implicaciones que implantar a ilidad en el departamento de pro ramacin. ?esde la visin y cultura de la empresa, hasta las t)cnicas de pro ramacin, pasando por el "rea de recursos humanos, comercial, contabilidad, calidad, etc. porque implica, o deber8a implicar, a aspectos como la seleccin y estin de las personas, la venta y formali;acin de contratos, los modelos, pr"cticas de trabajo, su institucionali;acin y formacin... ?os aspectos muy importantes antes de comen;ar la implantacin de un modelo " il son! En primer lu ar reali;ar un an"lisis del perfil de produccin y de la identidad de la empresa! cu"l es la relevancia de los procesos y de las rutinas, del trabajo y del talentoH cu"les las caracter8sticas de los proyectos en cuanto a innovacin, estabilidad de requisitos, tama%o... En se undo, un dise%o y una estrate ia de implantacin, tomando el criterio de fleAibilidad de -crum 'ana ement! tomar, modificar o desarrollar las pr"cticas m"s adecuadas para usar los principios de la a ilidad. En definitiva adaptar las pr"cticas a la or ani;acin, y no al contrario. 5ada empresa tiene su propia estructura or ani;ativa, m"s o menos compleja y

m"s o menos parecida a otras. ,ara -crum 'ana er, las "reas de la or ani;acin que deben estionarse de forma sist)mica en la implantacin o mejora de modelos de produccin son las polari;adas en estos tres rupos! 'ana ement o erencia ,royecto ,roducto 'ana ement! Treas de responsabilidad sobre la visin, estrate ia, t"ctica, valores y cultura de la or ani;acin. ,royecto! Treas de responsabilidad en la comunicacin y estin de los recursos y las personas implicadas en el desarrollo de los proyectos de la empresa. ,roducto! Treas de responsabilidad en la in enier8a y construccin de los productos o servicios desarrollados por la empresa.

Antes de co enDar la i !lantci&n de un siste a $gil en una e !resa es reco enda%le: @eali;ar un an"lisis de identidad de la empresa, y con su resultado dise%ar un dise%o de pr"cticas y procesos y una estrate ia de implantacin, adecuada a la realidad de la or ani;acin. ?ar formacin al personal t)cnico sobre pr"cticas " iles! inte racin continua, *??, refactori;acin, etc. 5rear, si no lo hubiera un departamento de 4 ilidad en la or ani;acin. ?ar formacin al personal t)cnico sobre pr"cticas " iles! inte racin continua, *??, refactori;acin... y al personal comercial sobre el papel y las responsabilidades del cliente en un proyecto " il.

Reconsiderando: !ersonas > !rocesos > tecnolog(a -crum 'ana er reconsidera dos v)rtices del tri"n ulo cl"sico de los factores de produccin! ,ersonas O ,rocesos y *ecnolo 8a. 5rocesos: 2o todo lo que etiquetamos como procesos son la misma cosa. En al unos las personas ayudan al MprocesoM, y en otros son los MprocesosM los que ayudan a las personas. En el primer caso el proceso es el prota onista, el que sabe cmo hacer el trabajo

y la persona se inte ra en el sistema como instrumento, como operario de apoyo. En el se undo el art8fice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lo rar m"s eficiencia y no diluir el esfuer;o en rutinas mec"nicas. $a principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. $a clasificacin de 2onaIa y *aIeuchi entre eApl8cito (contenido en los procesos y la tecnolo 8a), y t"cito (contenido en la persona). -crum 'ana er abre una distincin, considerando que los MprocedimientosM de trabajo pueden ser! MprocesosM cuando tienen el conocimiento clave y por tanto operan en sistemas de conocimiento eApl8cito, y MrutinasM ayudan a las personas, que son quienes tienen el conocimiento clave, y por tanto operan en sistemas de conocimiento t"cito.

$os modelos de estin y mejora basados en procesos, centran el foco de la produccin en los procesos y la tecnolo 8a, como los elementos m"s valiosos de la produccin.

-u ant8tesis, las pr"cticas " iles, focali;an el valor de la produccin en las personas.

?esde el punto de vista de -crum 'ana er, ambas opciones son posibles, pero cada una para un entorno diferente. En entornos de produccin industrial que centran el conocimiento en los procesos y tecnolo 8a empleada, las personas aportan trabajo para auAiliar a los procesos y la tecnolo 8a, y el valor del resultado depende principalmente de los primeros. -in embar o para las empresas del conocimiento que trabajan en escenarios r"pidos e innovadores, el principal valor es el talento de las personas. 5ersonas En este v)rtice -crum 'ana er apunta que MpersonasM no es un factor #nico. -on dos! trabajo y conocimientoH y que el rado de valor de cada uno en el producto es determinante en decisiones de estin y modelos de produccin.

?Cu$l de las siguientes afir aciones es correcta@

-crum mana er considera que los procedimientos pueden ser procesos o rutinas. $lama rutinas a las que contienen eAplicitado el conocimiento clave para reali;ar el trabajoH y que las personas que intervienen deben aportar trabajo y conocimiento en mayor o menor medida, se #n las caracter8sticas de cada caso. En los entornos basados en procesos, las personas deben aportar, principalmente, conocimiento. En los entornos basados en rutinas, las personas deben aportar, principalmente, trabajo. -crum 'ana er considera que los procedimientos pueden ser procesos o rutinas. $lama procesos a los que contienen eAplicitado el conocimiento clave para reali;ar el trabajoH y que las personas que intervienen deben aportar trabajo y conocimiento en mayor o menor medida, se #n las caracter8sticas de cada caso.

Ma!a del escenario ,isto desde Scru

Manager

?esde los B0 son muchos los modelos y pr"cticas que desde or ani;aciones de investi acin, estandari;acin, y la propia industria se han desarrollado como propuestas de solucin a los problemas habituales de los proyectos de software. -on tantos que su mera relacin se antoja como una sopa de letras en la que resulta dif8cil identificar qu) es cada uno! ,'E+L, 5'', ?-?', 5rystal, 3-+ .==00, @U,, [,, -crum, 3*3$, 4-?, ,@325E 6, $E42, *??, etc. @esulta que los M"rbolesM no nos dejan ver que el MbosqueM tiene una estructura, o un MmapaM relativamente simple que nos permite comprender qu) es cada uno, y hace m"s f"cil tomar decisiones para apuntar al conocimiento de unos u otros se #n queramos trabajar m"s sobre procesos o rutinasH sobre prediccin o a ilidad. $os criterios que dibujan el mapa son! Day 'odelos y ,r"cticas. $os primeros dicen SU\ hay que hacer, y los se undos cmo se deben hacer. Unos trabajan con conocimiento eApl8cito (,@+5E-+-) y otros con conocimiento t"cito (@U*324-). y en ambos casos!

los hay con foco en una de las "reas clave identificadas en -crum 'ana er ( estin de proyecto, desarrollo de producto o estin de la or ani;acin) $os de "mbito lobal que cubren las tres "reas clave de la or ani;acin.

CRITERIO: MODE/OS E 5RFCTICAS Modelo 2o definen M5]'+M hacer las cosas, sino MSU\M cosas se deben hacer para conse uir los mejores resultados. @elacionan, como por ejemplo 5''3 que se debe llevar a cabo la estin de la confi uracin, estin de proyecto, medicin y an"lisis, desarrollo de requisitos, validacin, etc. pero sin prescribir formas, modelos ni herramientas concretas. Unos se centran slo en un "rea de la or ani;acin ( eneralmente proyecto). estin de

'odelos centrados en un "rea ( estin de proyecto) T iles! 5rystal, ?-?', $ean, representaciones " iles de Unified ,rocess (+pen U,, +U', 4U,, EssU,), '-V ,redictivos! ,'E+L, ,@325E6 R otros abarcan todas las "reas de la or ani;acin implicadas en el desarrollo de software $os modelos m"s conocidos de este tipo son 5''3 e 3-+ .==00. *ienen dos finalidades! ..O ,ara mejorar! 5omo uin en los procesos de mejora, que indica cu"les son las "reas que se deben ir abordando. 6.O ,ara evaluar! 5omo criterio para medir a una or ani;acin cmo de bien lo hace, se #n cu"ntas de las cosas que dice el modelo, est" cubriendo adecuadamente. @elacin de modelos con car"cter lo al!

Easados en procesos! 5''3, 3-+ .==00 T iles! -crum 'ana er ($a necesidad de abordar la a ilidad desde la visin de la empresa en su conjunto es una de las ra;ones de evolucin hacia -crum 'ana er) 5r$cticas ?icen M5]'+M hacer las cosas! cmo describir y estionar los requisitos (historias de usuario, elementos de bacIlo ...), cmo estimarlos, cmo reali;ar las reuniones para validar con el cliente, cmo reali;ar el mantenimiento del cdi o, las pruebas, la inte racin...

5r$cticas: T iles! e[treme ,redictivas! 3*3$ ,ro rammin , -crum, V??, 5?*, E9+, *??

CRITERIO: 5ROCESO O RUTINA 5omo se ha eApuesto en la leccin anterior, -crum 'ana er diferencia en los procedimientos de trabajo entre procesos y rutinas. 5uando el procedimiento de trabajo contiene la mayor parte del conocimiento necesario para obtener el resultado (conocimiento eApl8cito), se trata de un proceso. 5uando son las personas las poseedoras del conocimiento clave para obtener el resultado (conocimiento t"cito) entonces los procedimientos de trabajo son rutinas.

SegGn la clasificaci&n e#!uesta* Scru

Manager es:

Es un conjunto de pr"cticas basadas en procesos enfocadas en el desarrollo t)cnico. Un modelo basado en procesos (conociminto eApl8citado en los procesos y la tecnolo 8a), de "mbito lobal (las tres "reas clave de la empresa). Es un conjunto de pr"cticas " iles enfocadas en el "rea de proyecto. estin de

Un modelo basado en rutinas (conocimiento t"cito de las personas), de "mbito lobal (las tres "reas clave de la empresa). Ma!a del escenario ,isto desde Scru Manager

?esde los B0 son muchos los modelos y pr"cticas que desde or ani;aciones de investi acin, estandari;acin, y la propia industria se han desarrollado como propuestas de solucin a los problemas habituales de los proyectos de software. -on tantos que su mera relacin se antoja como una sopa de letras en la que resulta dif8cil identificar qu) es cada uno! ,'E+L, 5'', ?-?', 5rystal, 3-+

.==00,

@U,,

[,,

-crum,

3*3$,

4-?,

,@325E

6,

$E42,

*??,

etc.

@esulta que los M"rbolesM no nos dejan ver que el MbosqueM tiene una estructura, o un MmapaM relativamente simple que nos permite comprender qu) es cada uno, y hace m"s f"cil tomar decisiones para apuntar al conocimiento de unos u otros se #n queramos trabajar m"s sobre procesos o rutinasH sobre prediccin o a ilidad. $os criterios que dibujan el mapa son! Day 'odelos y ,r"cticas. $os primeros dicen SU\ hay que hacer, y los se undos cmo se deben hacer. Unos trabajan con conocimiento eApl8cito (,@+5E-+-) y otros con conocimiento t"cito (@U*324-). y en ambos casos!

los hay con foco en una de las "reas clave identificadas en -crum 'ana er ( estin de proyecto, desarrollo de producto o estin de la or ani;acin) $os de "mbito lobal que cubren las tres "reas clave de la or ani;acin.

CRITERIO: MODE/OS E 5RFCTICAS Modelo 2o definen M5]'+M hacer las cosas, sino MSU\M cosas se deben hacer para conse uir los mejores resultados. @elacionan, como por ejemplo 5''3 que se debe llevar a cabo la estin de la confi uracin, estin de proyecto, medicin y an"lisis, desarrollo de requisitos, validacin, etc. pero sin prescribir formas, modelos ni herramientas concretas. Unos se centran slo en un "rea de la or ani;acin ( eneralmente proyecto). estin de

'odelos centrados en un "rea ( estin de proyecto) T iles! 5rystal, ?-?', $ean, representaciones " iles de Unified ,rocess (+pen U,, +U', 4U,, EssU,), '-V ,redictivos! ,'E+L, ,@325E6 R otros abarcan todas las "reas de la or ani;acin implicadas en el desarrollo de software $os modelos m"s conocidos de este tipo son 5''3 e 3-+ .==00. *ienen dos finalidades! ..O ,ara mejorar! 5omo uin en los procesos de mejora, que indica cu"les son las "reas que se deben ir abordando.

6.O ,ara evaluar! 5omo criterio para medir a una or ani;acin cmo de bien lo hace, se #n cu"ntas de las cosas que dice el modelo, est" cubriendo adecuadamente. @elacin de modelos con car"cter lo al!

Easados en procesos! 5''3, 3-+ .==00 T iles! -crum 'ana er ($a necesidad de abordar la a ilidad desde la visin de la empresa en su conjunto es una de las ra;ones de evolucin hacia -crum 'ana er) 5r$cticas ?icen M5]'+M hacer las cosas! cmo describir y estionar los requisitos (historias de usuario, elementos de bacIlo ...), cmo estimarlos, cmo reali;ar las reuniones para validar con el cliente, cmo reali;ar el mantenimiento del cdi o, las pruebas, la inte racin... 5r$cticas: T iles! e[treme ,redictivas! 3*3$ ,ro rammin , -crum, V??, 5?*, E9+, *??

CRITERIO: 5ROCESO O RUTINA 5omo se ha eApuesto en la leccin anterior, -crum 'ana er diferencia en los procedimientos de trabajo entre procesos y rutinas. 5uando el procedimiento de trabajo contiene la mayor parte del conocimiento necesario para obtener el resultado (conocimiento eApl8cito), se trata de un proceso. 5uando son las personas las poseedoras del conocimiento clave para obtener el resultado (conocimiento t"cito) entonces los procedimientos de trabajo son rutinas.

SegGn la clasificaci&n e#!uesta* Scru

Manager es:

Un modelo basado en rutinas (conocimiento t"cito de las personas), de "mbito lobal (las tres "reas clave de la empresa).

Es un conjunto de pr"cticas basadas en procesos enfocadas en el desarrollo t)cnico. Es un conjunto de pr"cticas " iles enfocadas en el "rea de proyecto. estin de

Un modelo basado en procesos (conociminto eApl8citado en los procesos y la tecnolo 8a), de "mbito lobal (las tres "reas clave de la empresa).

Scru

Manager: agilidad fle#i%le ) siste ica0

-crum 'ana er es un modelo eneral de estin de entornos de produccin basados en rutinas, esto es, entornos en los que es m"s relevante el conocimiento t"cito de las personas, que el eApl8cito contenido en los procesos y la tecnolo 8a.

-crum 'ana er se clasifica mejor como modelo que como conjunto de pr"cticas, porque a diferencia de )stas, no prescribre M5]'+M deben hacerse las cosas, (bacIlo s, historias de usuario, reuniones...) ni que )stas deban hacerse de una determinada maneraH sino MSU\M cosas deben hacerse. -e centra m"s en los principios de la a ilidad y los procesos, que en formas concreatas, y sobre los principios, y las caracter8sticas de la empresa y el proyecto, determina los procedimientos de trabajo. Esta es su caracter8stica de fleAibilidad! adaptar los procedimientos a la empresa, y no al contrario. R se trata adem"s un modelo sist)mico o lobal, porque la implantacin de -crum 'ana er implica no slo al "rea de estin de proyectos, o de solucin t)cnicaH sino a las dos, junto con el Mmana ementM de la empresa! su or ani;acin, estrate ia y cultura.

Scru

Manager es un

odelo .fle#i%le.0 Esto quiere decir:

Sue son las pr"cticas las que deben adaptarse a la or ani;acin para transmitir los principios de a ilidad y procesos en el rado adecuado a la empresa y sus proyectos. Sue las empresas deben tener una respuesta fleAible para adaptarse a las pr"cticas que eAi e la estin " il en todas sus "reas.

Sue es un modelo que puede implementarse simult"neamente con otros como 5''3, 3*3$, 3-+ .==00, ?-?', [,, etc. E'ercicio de re!aso ?7erdadero o falso@ $a a ilidad ha sido la respuesta de ant8tesis a los principios de 3n enier8a del -oftware desarrollados desde los <0 hasta finales del si lo pasado. @espuesta
9erdadero

$a implantacin de la a ilidad se debe estionar considerando a la or ani;acin como una realidad sist)mica, y no como un conjunto de departamentos m"s o menos independientes y comunicados. @espuesta
9erdadero

-crum 'ana er considera que los procesos son los procedimientos de trabajo en los que el conociminto clave es aportado por las personas. @espuesta
Valso

,ara mejorar las formas de trabajo hay MmodelosM y Mpr"cticasM. $os primeros se

centran

m"s

en

definir
9erdadero

MSU\M

hacer,

los

se undos

en

M5]'+M

hacerlo. @espuesta

Co !leta los "uecos

$a evolucin del conocimiento si ue el patrn @espuesta

dialectico

! tesis O

ant8tesis y s8ntesis. En el primer ciclo de la espiral de avance de conocimiento de mejora en los desarrollos de software, e[treme ,ro rammin se situar8a en la @espuesta
antitesis

, 5''3 en la @espuesta

tesis

y -crum 'ana er en la @espuesta

sintesis

$os tres factores cl"sicos de la produccin son! personas, tecnolo 8a y @espuesta

procesos

. -crum 'ana er denomina a los procesos! procedimientos, y considera que )stos pueden ser procesos o @espuesta ellos el conocimiento
rutinas

, se #n ten an o no eAplicitado en para desarrollar el resultado.

clave

2ota! es indistinto el uso de may#sculas o min#scular O ,ara evitar equ8vocos y por limitacin de la plataforma 'oodle, las palabas de resupuesta NO DE8EN //E7AR ACENTOS.

Selecciona la res!uesta correcta

$os procedimientos basados en procesos necesitan el trabajo de las personas, y los basados en rutinas necesitan su @espuesta punto
un modelo conocimiento

?esde el es @espuesta

de

vista

'odelo

,r"ctica,

5''3

. para la mejora del desarrollo, mantenimiento y operacin de los sistemas de software, y -crum es @espuesta
Un conjunto de buenas pr"cticas

-crum

'ana er es un modelo de

estin @espuesta

fleAible

, y @espuesta

sist)mico