Comments for Ken Schwaber le recuerda a Microsoft que agilidad y procesos son conceptos enfrentados at http://www.navegapolis.net , comment 1 to 4 out of 4 comments http://www.navegapolis.net Fri, 19 Mar 2010 02:59:17 +0100 FeedCreator 1.7.2 http://www.navegapolis.net/content/view/220/62/#comment-1159 Juan, me gusta un poco más tu apreciación última. Aunque disponer de técnicas de elicitación de requerimientos, no son una peculiaridad de Scrum. CMMI enseña todas las técnicas necesarias para la toma de requerimientos y como priorizarlos. Me gusta de Scrum que tiende a ofrecer una herramienta sencilla en lugar de requerir herramientas automatizadas para esa práctica en particular. Pero hay que ver cuando intentar luego de mucho rato, obtener rastreabilidad de requisitos a lo largo de proyectos que fueron mutando con el pedido de los clientes. Sobre todo cuando el mismo proyecto es aplicado en distintos países y cada uno tiene su propio estilo. Lo ágil de de serlo cuando se requiere esfuerzo para responder a preguntas que apuntan a la história de un artefacto. Saludos, Javo. - Javo Thu, 24 Jan 2008 21:06:44 +0100 http://www.navegapolis.net/content/view/220/62/#comment-1158 Gracias por haber creado este punto de opinión. En lo personal disiento con ambos principalmente por que hay comentarios que hacen emblemático a un personaje en particular y por otro lado hay comentarios que detrimentan a otro, cuando en ambos casos hablamos de personas que administran gran cantidad de personas al rededor de múltiples proyectos concurrentes y se las han arreglado para posicionarse con sus ideas y principalmente por que las desarrollaron. Ahora yendo a lo concreto, creo de algún modo que Scrum no sirve más que para Gestionar un proyecto, es decir a niveles administrativos para seguimiento y control, tanto como para la estimación del tiempo y los recursos para la construcción, es decir que puede ser utilizado como modelo para gerenciar y podría ser tremendamente útil en las PA Gerenciales. Instruye en buenas prácticas pero no representa un proceso completo en si mismo. Sin embargo Scrum no facilita las herramientas utilizadas para el desarrollo en si, con lo cual mínimamente debes utilizar un modelo de otro tipo como XP si prefieres seguir en lo Ágile. Nosotros no nos hemos apartado de los gant por que nos dan gran visibilidad y en forma ágil podemos ver los corrimientos o reubicamos los recursos. Creo que la herramienta a utilizar e indistinta. Puedes tener todo tu Backlog en un Excel, en un aplicativo Access o una aplicación de construcción propia como nosotros (Lotus) y puedes tener cada uno de los Sprint en un MSProject o si prefieres el software libre en un OpenProj. Siguen siendo los principios ágiles abiertos a múltiples interpretaciones, y las herramientas orientadas Ágiles tienden a ser cada día más complejas por que se ha dado cuenta el mundo que con pequeñeces no es posible generar inteligencia en la industria del software. Que usan para gestionar los riesgos? o para conocer la disponibilidad de los recursos IT? o para ponderar los costos? herramientas de cualquier tipo que sirvan al propósito. - Javo Thu, 24 Jan 2008 21:00:12 +0100 http://www.navegapolis.net/content/view/220/62/#comment-148 Hola Mario! Muchas gracias por tu reconocimiento y por leer Navegapolis. Efectivamente compartimos el inter�s por Scrum y por la gesti�n �gil, y es cierto que no resulta f�cil ni afirmar, ni negar que Scrum sea un proceso. �Proceso o t�cnica?. �Es proceso cuando define QU� hacer, y t�cnica cuando detalla C�MO hacerlo?. Este podr�a ser un buen criterio, y con el riesgo de estar confundido, interpreto as� a Ken: Scrum es una t�cnica, y coincido contigo en que Scrum tiene mucho de proceso. Porque como t�cnica, (una forma concreta de hacer), o tiene detr�s, o est� dibujando un proceso (qu� es lo que se hace). Prescribir c�mo hacer las reuniones diarias, o la priorizaci�n de requisitos en un backlog, implica que se han formado procesos para definir y priorizar requisitos, para asignar responsabilildades, etc. (Aunque con ingenier�a inversa). Juan Palacio - Invitado Sun, 11 Dec 2005 11:24:56 +0100 http://www.navegapolis.net/content/view/220/62/#comment-146 Hola Juan! Antes que nada, quer�a felicitarte por tu magn�fico blog. Confieso que lo he descubierto hace muy poco, pero ya lo tengo entre mis lecturas habituales. Es evidente que tenemos muchos intereses comunes, empezando por Scrum y el Agile Project Management, as� que supongo que era cuesti�n de tiempo que nos encontr�ramos. He le�do la respuesta de Ken, con la que - como t� - estoy de acuerdo en lo fundamental, aunque har�a alguna matizaci�n - joder, qu� atrevimiento: \"matizar\" a Ken Schawber!! ;-D S� que he tenido la impresi�n de que t� y yo no hemos interpretado de la misma manera este fragmento: [I]\"I commented at the time that Scrum and Agile were barely processes, more techniques for making change within the development and wider organization. This change is very similar to what any organization encounters when using lean techniques, and the implementation process takes years\"[/I] En mi opini�n, lo que Ken dice es que Scrum y otros m�todos �giles son a duras penas procesos - aqu� discrepo con �l, pero bueno -, sino m�s bien t�cnicas que, como el famoso [I]Lean Toolbox[/I], se utilizan para introducir cambios de amplio alcance en una organizaci�n... cambios que de hecho llevan a�os. Ken se lamenta de no haber podido hablar previamente con Randy para [I]\"to correct the impression he may have given others that Scrum and Agile aren\'t that hard, just a little twist\"[/I]. El problema del que habla Ken aqu� es que tanto MicroSoft como IBM pretenden hacer creer a la comunidad de desarrolladores que introducir pr�cticas �giles es una bobada, super-facilito gracias a sus [I]\"Solution Frameworks\"[/I] y dem�s ejercicios de marketing. Ken se lamenta de que esto no har� m�s que complicar a�n m�s el trabajo de esa peque�a comunidad de desarrolladores en Microsoft que pretenden cambiar una cultura [I]\"hierarchical, command and control\"[/I] desde dentro. En resumen, Ken nos avisa de que no hay atajos f�ciles a Scrum... y es una advertencia que merece la pena tomar en serio. Scrum, como cualquier m�todo �gil, requiere de un entorno - tanto f�sico como cultural - \"amable\" con los valores que asume como punto de partida. Un intento de introducir Scrum se puede ir al carajo porque el DG no comprenda \"qu� hacen las mismas ocho personas todos los d�as por la ma�ana alrededor de la m�quina de caf�\". Otro d�a hablaremos de si Scrum es o no un proceso - que por supuesto lo es! ;-) Ah y el propio Ken en su libro Agile Project Management explica c�mo llevar un Product Backlog a un Gantt... Claro que eso no significa que le guste ;-) Mario L�pez de �vila [URL=http://nodos.typepad.com]nodos en la red[/URL] - Invitado Sun, 11 Dec 2005 08:31:36 +0100