Blog de Miguel Llopis

El modelo de desarrollo software en Microsoft

A menudo cuando vemos un gran edificio nos preguntamos cómo lo habrán construido. Cuando vemos las pirámides de Egipto nos asombra conocer los métodos que se emplearon para levantarlas, la gran cantidad de gente involucrada en este proceso “faraónico”.De la misma forma, yo muchas veces me hago la misma pregunta acerca del software.

Ahora estoy teniendo la suerte de ser parte activa en este gran proceso. En mi experiencia actual, el producto con el que más relación directa tengo es BizTalk Server. Para los que no lo conozcáis, BizTalk Server es una tecnología de servidor cuya misión es coordinar todos los servicios de red existentes en un entorno empresarial, algo que se conoce como “orquestación de servicios”.

Dicho con un ejemplo llano, imaginad una rotonda en la que confluyen 7 autopistas, totalmente saturadas de tráfico. BizTalk Server se encargaría de decidir a qué vía da prioridad en cada momento, según lo saturada que esté, entre otros criterios, también se encargaría de optimizar el proceso; es decir, conseguir que estemos el menor tiempo posible metidos en el atasco. Y, por supuesto, que no se produzca ni una sola colisión o choque entre dos vehículos.Para desarrollar este producto, en un cálculo aproximado y rápido, os puedo decir que trabajamos unas 250 personas. Cada una de estas personas tiene una misión diferente, unas virtudes diferentes y una visión particular sobre qué características debería y no debería tener la próxima versión del producto. ¿Cómo se coordina todo esto? Se hace uso de algo de lo que ya os hablé en alguna entrada anterior: los roles en el desarrollo del software. Los roles que existen actualmente en mi equipo, y en la mayoría de equipos de desarrollo en Microsoft ya que es un modelo que aporta muchas ventajas respecto a otros y que se está convirtiendo (si no lo es ya) en un estándar dentro de la empresa (Microsoft Solution Framework, para quien quiera investigar más sobre ello), son los siguientes:

Roles_2

Product Manager: Es el nexo con el cliente, maneja sus expectativas y se encarga del lanzamiento y la publicidad, demostraciones, etc. Es muy parecido al rol de Jefe de proyectos de una consultora clásica.

Program manager: Es más técnico, se encarga de que el proyecto se concluya y se entregue al cliente. Su misión es asegurar que se va avanzando según lo previsto (es lo más parecido a un analista, que podemos encontrar en el modelo clásico de las grandes consultoras) 

 

Developer: Se encarga de desarrollar las aplicaciones dentro de los requisitos que ha marcado el analista y de las restricciones globales del proyecto. Algunos ejemplos de estas restricciones son:              

              •      Que el resultado sea monitorizable

                        Rendimiento en unos rangos

                        Probado para el volumen de datos esperado                                   

                        Técnicamente correcto

Tester : Se encarga no sólo de buscar errores, sino además de garantizar que el diseño funcional está alineado con las expectativas del cliente, vamos con el documento de visión.

Release manager : Se encarga de asegurar que el resultado va a poder ser desplegado en un sistema real, diseña el plan de puesta en producción y lo ejecuta. Este trabajo no se realiza sólo al final del proceso, además de las versiones externas, es decir versiones que estén suficientemente libres de errores, sino que además pueden haber releases internas que también hay que desplegar y probar.

User experience: Es el responsable de lo que tiene que ver con el usuario final, lo que le afecta al usuario final, que los interfaces sean amigables y comprensibles, que el rendimiento sea aceptable, etc.

 

Arquitecto :  El arquitecto de software se encarga de que las piezas de software encajen y de que se elija la mejor tecnología para resolver cada uno de los problemas concretos. También es el responsable de servir de enlace entre los departamentos de TI y de desarrollo.

 

Con todo esto, la infraestructura interna para llevar a cabo el proceso de coordinación, la comunicación dentro del proceso y otra serie de factores, podréis imaginar que es bastante compleja.Pero nunca pensé que pudiera ser fácil, estoy en Microsoft, la empresa líder mundial en software, con productos muy variados: desde sistemas operativos como Windows 9x, XP, 2000, 2003 Server o Vista hasta bases de datos como SQL Server, desde tecnologías y servicios para la web como Windows Live hasta aplicaciones de escritorio como Office, desde aplicaciones de mensajería instantánea como el Messenger hasta completos entornos de desarrollo como Visual Studio, sistemas para PDA's... Podría seguir, pero no quiero aburriros.Tan sólo quería dejar patente lo mucho que se aprende trabajando aquí, y el contínuo desafío, motivación y esfuerzo por la autosuperación que supone trabajar en un nº1.

Feliz Lunes!

Posted: 9/9/2007 22:53 por Miguel LLopis | con 8 comment(s) |
Archivado en:
Comparte este post:

Comentarios

Rodrigo Corral ha opinado:

Aupa Miguel!!!

Tengo algunas preguntitas, no se si me las podrás responder.

¿Utilizáis Team Foundation Server?

¿Qué sabor de MSF utilizáis: CMMI, Agile o aun estáis con MSF 3.0?

Se que hay equipos en MS que usan Scrum, ¿has tenido relación con alguno? ¿Se ve mucho Scrum en MS?

Saludos titán!!!

# September 10, 2007 10:49 AM

Miguel LLopis ha opinado:

Buenas Rodrigo!!

Creo que tenemos una cerveza pendiente cuando vuelva por España...

(Espero que eso responda a tu primera duda)

Un abrazo ;-)

# September 10, 2007 11:08 AM

Rafael Ontivero ha opinado:

Me parece a mi que el "Tester", "El Release Manager" y la "User Experience" se la están pasando últimamente por el forro de los cohones, porque hay Software que clama al cielo por su "calidad".

# September 12, 2007 5:07 PM

Miguel LLopis ha opinado:

Pues yo soy tester y trabajo unas 8-10 horas al dia, cazando bugs y reportandolos de forma MUY detallada, testeando funcionalidades, comprobando que cumplen las expectativas planteadas en el disenyo y las necesidades del cliente (en ese sentido, tambien me centro en la user experience).

Asi que imagino que si, que el trabajo no solo mio sino de otras 15 personas con el mismo rol en mi equipo se lo pasan por el forro...

# September 12, 2007 9:41 PM

Anonimo ha opinado:

Pero Miguel por favor. Rafael se refería al pasado. Esta claro que un equipo de 15 internos en una empresa con cuantos miles de empleados y unos mil productos va a revolucionar aquello.

mira tio, no es por criticar, pero no me toques los cojones. MS ha sacado mierda a punta pala con mucho fallos y donde tu estás han pasado miles de esclavitos (perdona, becarios) y después de tú vendrán miles más. Nadie dice que tu trabajo a de tus 15 compañeros sea una mierda, pero tio, tampoco te pases macho...

# September 12, 2007 10:29 PM

David ha opinado:

Hola Miguel.

Aunque te vayas con Rodrigo Corral a tomarte una cerveza para aclararle todas sus dudas, ¿puedes responderlas aquí? Yo estoy muy interesado en saber las respuestas a esas preguntas.

Gracias.

# September 13, 2007 7:29 PM

Miguel LLopis ha opinado:

"Esta claro que un equipo de 15 internos en una empresa con cuantos miles de empleados y unos mil productos va a revolucionar aquello"

No hablemos sin saber, por favor (y menos dándole patadas al diccionario y a la educación)...

Ese equipo de 15 SDET, del que por cierto soy el unico intern, es para cubrir el rol de tester en un desarrollo en el que intervenimos en total unas 50-60 personas... con lo que se puede hacer el cálculo rápido y deducir que un 25% de los desarrolladores en MS somos SDET.

Sobre el MSF y sus diferentes "sabores", así como de su implantación en Microsoft, podéis buscar cosas por internet o preguntarle a Rafael. Él sabe mucho más que yo al respecto, como ha quedado patente.

Un saludo

# September 16, 2007 11:27 AM

greg ha opinado:

Quisiera saber que empresas de renombre mundial usan esta metodologia o al menos que se conoscan, que se pueda verificar

# October 17, 2008 6:47 PM