ALM sessions 12 - Planeta ALM
•
0 recomendaciones•480 vistas
ALM sessions 12 - Planeta ALM. Charla sobre trabajo con equipos distruibuidos con Visual Studio 2010 ALM.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (16)
Destacado
Destacado (20)
Similar a ALM sessions 12 - Planeta ALM
Similar a ALM sessions 12 - Planeta ALM (20)
Más de Bruno Capuano
Más de Bruno Capuano (20)
Último
Último (19)
ALM sessions 12 - Planeta ALM
- 1. Planeta ALM ALM Sessions „12 Bruno Capuano @elbruno Jesus Salas @vs_anywhere MVP Visual Studio ALM CTO bcapuano@gmail.com jesus.salas@vsanywhere.com Avanade VS Anywhere www.elbruno.com www.vsanywhere.com
- 2. About Me >> @elbruno Bruno Capuano MVP – ALM bcapuano@gmail.com Avanade www.elbruno.com
- 3. Avanade Fast Facts About Us – More than 60 locations in 20 countries worldwide – US$953 million revenue in FY10 – More than 20% average yearly growth since our inception in 2000 Our customers Currently serve more than 600 customers as trusted advisor Realize 97% satisfied customers •Our services Results for customers in all industries Backed by Accenture and Microsoft 3
- 4. Conocimiento experto: Certificaciones y competencias Certificaciones Competencias • La primera empresa por certificaciones en empleado 24 Competencias Gold de Microsoft, • La primera empresa por certificaciones como desarrollador de más que cualquier otro socio plataformas .NET • La primera empresa por certificaciones en Dynamics CRM • La primera empresa por certificaciones en Dynamics AX • La primera empresa por certificaciones en SharePoint • 30 arquitectos y Masters de elite certificados de Microsoft “Los partners son clave en nuestro negocio, Microsoft no sería lo que es sin sus socios de negocio. Para nosotros es una satisfacción contar con partners como Avanade que ofrecen un valor añadido a los clientes y comparten con Microsoft su filosofía de trabajo. Desde aquí quiero felicitar sinceramente a Avanade, porque han demostrado una gran maestría en su trabajo y una fuerte entrega con los clientes, además de lograr destacar entre otros muchos partners. Contar con partners como Avanade es lo que hace que Microsoft sea la compañía que es”. Ana Alonso Directora de Soluciones y Alianzas en EPG de Microsoft Ibérica en conocimiento experto 4 de Microsoft
- 5. ¿Por qué equipos distribuidos?
- 6. ¡Esas no son las reglas de AGILE¡
- 8. Error Escenario muy común: El MegaTeam - Programadores baratos en Bangalore - Testers baratos en Manila - PMs baratos en Chicago - Funcionales en Madrid
- 9. El MegaTeam GMT -6 GMT +1 GMT +5 GMT +8 ¿Cómo configuro las Builds nocturnas? ¿Cómo mido el avance real de un proyecto “siempre en marcha”? ¿Cuándo organizo mi Daily Scrum? ¿Cómo gestiono la comunicación?
- 10. Así suele terminar el MegaTeam - Solo hay un canal de comunicación, que resulta ser algo parecido a una referencia circular - Las culpas se reparten entre cada ubicación - Por lo general no hay “conciencia de equipo” - Etc …
- 11. ¡Esta es la solución! ¿Cuál es la solución? (que por lo general suele ser esta)
- 12. Visual Studio ALM Veamos un ejemplo real: - Equipos distribuidos entre - Madrid, Málaga, Buenos Aires y Nordics - TFS en Madrid, coordinación local desde Madrid - VS2010, Expression Blend, TFS, TFS Power Tools y Lync
- 13. Visual Studio ALM Lecciones aprendidas: - Se necesita una semana para definir el modelo de trabajo. Todos los participantes deben estar de acuerdo con el mismo. - Es importante celebrar una reunión con los participantes para definir las bases del proyecto: qué, cómo, cuándo y dónde - Los canales de comunicación deben ser fluidos y bidireccionales - Las iteraciones deben ser frecuentes para poder evaluar los resultados esperados - En base a los resultados se debe mejorar
- 14. Pero … y si quiero ir más lejos Demo – Visual Studio Anywhere
- 15. Planeta ALM ALM Sessions „12 Bruno Capuano @elbruno Jesus Salas @vs_anywhere MVP Visual Studio ALM CTO bcapuano@gmail.com jesus.salas@vsanywhere.com Avanade VS Anywhere www.elbruno.com www.vsanywhere.com
Notas del editor
- What I mean by de-Agile is tailoring Agile to fit your team by taking out processes that don’t make sense and tweaking those that need to be modified to suit your needs. In a distributed team environment, de-Agile is mostly about removing the sense of being distributed. You need to educate each team member about the additional communication responsibilities required when working with remote team members and emphasize the importance of being open and available. Everyone on the team needs to be committed to making Agile work in this environment, and managers -- including the top tier -- must support the tools and processes required.If you want your team to adopt Agile practices, you might need to play the roles of facilitator and mentor at some point. The de-Agile route will inevitably have some rough spots as your team figures out both its shared and unique needs.The following sections include information I have found especially helpful in enabling de-Agile for distributed teams.Effective distributed Agile development is about minimizing the impact of distribution. Mainstream Agile processes work well for teams of 10 to 15 people, but what if your team is much larger? Paper-based, face-to-face strategies start to fall apart as the team size grows and the team distribution begins to span multiple time zones. You can still use Agile processes for larger, distributed teams. You just have to be willing to adjust your processes to accommodate the reality of your team’s environment.Finding the right mix of talent at every location is critical when the team is distributed. If you centralize one type of work at one location, you can lose opportunities to benefit from local talent. For example, you might know of an excellent developer you can’t hire because your development team is in another country. Lost talent adds to your company’s total recruitment costs.Distributing your processes and tasks as well as the development work is also key. In the centralized model just described, you also risk being stuck if your company needs to scale up -- or shut down -- a location. For example, having all your developers in one country, all your projects managers in another country, and all your testers in yet another country isn’t the way to optimize the functioning of distributed teams. This type of setup often leads to one-directional information flow and can result in chaos and the blame game if things go wrong. You also risk the continuity of particular functions if you need to close down one location, say, the one where all the product managers work. Factors such as domain complexity and technical complexity can also complicate recruiting and retaining the right set of people within a distributed team.