100% de acuerdo con Francisco. El rol del "Analista" tradicional cambia considerablemente al pasar a un equipo Agile/Scrum. Lo más usual es que se transforme en Product Owner, o parte del equipo del Product Owner..
Aquí les dejo una traducción de Mike Cohn sobre Analistas Ágiles: http://www.martinalaimo.com/es/2010/01/analistas-agiles/ Saludos! Martín. 2010/4/19 Francisco Tufró <[email protected]> > 2010/4/19 Juan Pedro Fisanotti <[email protected]>: > > El día 19 de abril de 2010 17:57, Jonathan Leibiusky > > <[email protected]> escribió: > >> > >> > >> 2010/4/19 Gaston Ramos <[email protected]> > >>> > >>> El Mon, 19 de Apr de 2010, a las 04:19:15PM -0300, Sebastián Bernardo > >>> Galkin dijo: > >>> > > TeraCode BA SA, empresa líder en desarrollo de software > offshore, > >>> > > incorpora Analistas Programadores Ruby SemiSenior > >>> > > y Senior para importante proyecto. > >>> > > >>> > Todavía se usa el término "Analista Programador"? Suena tan 90's... > Cuál > >>> > era la diferencia con "Programador"? estos > >>> > últimos tienen la capacidad de análisis menos desarrollada? > >>> El análisis del sistema sólo lo pueden hacer "los analistas" y el > >>> programador > >>> simplemente traduce este análisis a líneas de código, es el intérprete > del > >>> analista digamos :). > >>> > >>> > >> > >> Si... pero convengamos que éste concepto está empezando a desaparecer de > a > >> poco. Quizás en algunos proyectos super grandes, con presupuestos muuuy > >> grandes y para entidades tipo bancos, etc, todavía existe una separación > muy > >> clara. > >> > > > > Sigue estando mucho en entidades que siguen trabajando con > > metodologías tradicionales, en cascada, etc. > > Pero en entornos que usan metodologías más tirando a lo Agile, eso no > > existe así. Todos trabajan mucho más integrados, como equipo y no como > > jerarquía. Y donde hay separación de roles no es con ese criterio, > > porque se busca que los desarrolladores sean "dueños" de lo que > > escriben, que piensen, y no que simplemente sean intérpretes > > diagrama->código. > > > Totalmente de acuerdo. > En los equipos agile y sobre todo en SCRUM la idea de miembros de > equipo interdisciplinarios es lo que se busca. > De todas formas, está claro que identificar un problema y poder > interpretarlo y encontrarle una solución no es lo mismo que > programarlo. > Hay muchos "programadores" en el mundo, pero pocos que sepan sobre > estructuras de datos eficientes para resolver tales problemas, o que > tengan experiencia identificando las necesidades de alguien y > transformarlas en un software que las resuelva. > Por eso es tan valiosa la gente que puede formar parte de un equipo > agile, porque tiene capacidad para poder hacer un poco de todas estas > cosas. > > > > > -- > > fisa - Juan Pedro Fisanotti > > _______________________________________________ > > Ruby mailing list > > [email protected] > > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > > > > > > -- > Francisco Tufró > [email protected] > http://www.franciscotufro.com.ar > http://www.dias-felices.com.ar > http://www.myspace.com/diasfelices > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > -- Martín Alaimo Certified Scrum Practitioner & PMP http://www.martinalaimo.com
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
