#Hololens – About DevOps, ALM and #Unity3D

Hello.

When you start to work on a Hololens project, one of the first things you learn is “Unity3D is different“. Besides the graphical aspects and the paradigm shift, there is an important point to keep in mind.

 

Even if a Unity project is a collection of files, you can’t go with something easy as control all those files with a version control system (in example, TFVC or Git). In order to take control over the complete lifecycle in a project-oriented way, you need to consider some special nuances.

As well, I’ve been learning in baby steps mode. The truth is it has been an interesting experience. The use of tools like Visual Studio Tools for Unity, made much easier to transfer some the knowledge we already have working with Visual Studio, to the Unity3D environment. However, you can also go one step further. And here it is essential to read this MSDN article, Application Lifecycle Management (ALM) with Unity Apps.

This article describes some detailes insights on the wollowing topics on the use of Unity and Team Foundation or Team Services tools:

  • Agile Tools
  • Modeling
  • Code
  • Build
  • Testing
  • Improve Code Quality
  • Release Management
  • Monitor with HockeyApp (sigh!)

Sections like versioning files, details on how Unity works different and the best thing is to read some official documentation of Unity: Using External Version Control Systems with Unity. Another similar scenario, is that arises with the compilation, where the recommendation is to automate the collection and generation of packages using command line MSBuild.

The truth is that it is a document to take into account and a good basis to know what we need if we want to create quality with Unity3D and Visual Studio apps.

Greetings @ Toronto

El Bruno

References

Advertisements

#Hololens – Sobre DevOps, ALM y #Unity3D

Hola.

Cuando comienzas a trabajar en un proyecto para Hololens, una de las primeras cosas que aprendes es que “Unity3D es diferente”. Además de los aspectos gráficos y del cambio de paradigma, hay un punto importante a tener en cuenta.

Si bien un proyecto de Unity es una colección de archivos, la solución no es tan simple como controlar TODOS con un sistema de versionado de archivos (TFVC o GIT, por ejemplo). Tener un control sobre el ciclo de vida de los mismos, orientados a proyecto, requiere algunas sutilezas especiales a tener en cuenta.

Pues bien, yo he ido aprendiendo a tropezones. Y la verdad es que ha sido una experiencia interesante. Herramientas como Visual Studio Tools for Unity hacen que muchos de los conocimientos que ya poseemos trabajando con Visual Studio, puedan ser fácilmente traspasados a Unity3D. Sin embargo, también puedes dar un paso más. Y aquí es fundamental leer este artículo de MSDN, Application Lifecycle Management (ALM) with Unity Apps.

En el mismo se realiza un recorrido sobre el soporte en Unity de herramientas de Team Foundation o Team Services en los apartados

  • Agile Tools
  • Modeling
  • Code
  • Build
  • Testing
  • Improve Code Quality
  • Release Management
  • Monitor with HockeyApp (sigh!)

Lo interesante, es que en apartados como por ejemplo el control de archivos, se nos explica que Unity trabaja diferente y que lo mejor es leer un poco de documentación oficial de Unity: Using External Version Control Systems with Unity. Otro escenario similar, es el que se presenta con la compilación, donde la recomendación va por automatizar la compilación y generación de paquetes utilizando command line en MSBuild.

La verdad es que es un documento a tener en cuenta y una buena base para saber lo que necesitamos si queremos crear apps de Calidad con Unity3D y Visual Studio.

Saludos @ Toronto

El Bruno

References

#Podcast – #Agile at enterprise level, and another couple of interesting experiences

wall-climbing-boss

Hi!

After a couple of weeks of silence now is time to publish a new episode in my Podcast. In today’s episode, I am lucky to be with 4 great friends. And, after talking with them for a long time about personal experiences when we work with Agile projects, it was time to gather them all together and see what opinion we have on diverse topics such as:

  • Agile as a trend
  • What happens when we do Scrum of Scrum?
  • Can a junior teamwork without a coach?
  • Why do we use the rate as a measure of progress?
  • The cone of the uncertainty
  • Work product-oriented or project-oriented
  • When estimates are used as a mechanism for micro-management
  • Chess as an agile framework similar
  • When you modify a Scrum and works, is it still Scrum?
  • When a project Waterfall is masked with Scrum or the reverse

I’ve put all the references that I have found on some of the issues we are talking about. And although this time arrived 90 minutes, I think that you as a lesson learned for next time, if we see that the podcast “is estira¨ as is done in 2 episodes.”

As always many thank and I hope you enjoy it. Podcast Link

Saludos @ Toronto

El Bruno

References

#Podcast – Digital vs. physical boards, a bit of ALM, Jeff Bezos 2 pizzas rule and more (Spanish)

hololens-tfs-kanban-board-02

Hello!

New podcast episode, this one talking about digital boards versus physical boards with Luis Fraile (@lfraile) and Pablo Escribano (@_pabloescribano). Actually that’s how we started, then by the way we started talking about ALM, best practices, and various other topics.

For these 50 minutes, we think ans shared our point of view for several questions

  • We let carry by the fashions?
  • Automate everything we do worth it?
  • Do the physical tools facilitate creativity?
  • Is Guardiola a benchmark in management of equipment?
  • The tools used to build teams?
  • It digital is destroying the Amazon?

And also we call Jeff Bezos 2 pizzas rules for meetings, we referenced to DotNet Rock and much more! .

I hope that you enjoy this one.

 

download

Greetings @ Toronto

El Bruno

References

#Podcast – NTN 18 – Tableros digitales vs físicos, un poco de ALM, la regla de las 2 pizzas de Jeff Bezos y más

hololens-tfs-kanban-board-02

Hola !

Nuevo episodio esta vez para hablar sobre Tableros Digitales versus Tableros Físicos con Luis Fraile (@lfraile) y Pablo Escribano (@_pabloescribano). En realidad así empezamos, luego por el caminos empezamos a hablar de ALM, de buenas prácticas, y varios temas más.

Durante estos 50 minutos, nos planteamos varios temas

  • Nos dejamos llevar por las modas?
  • Vale la pena automatizar todo lo que hacemos?
  • Las herramientas físicas facilitan la creatividad?
  • Es Guardiola un referente en gestión de equipos?
  • Las herramientas sirven para para construir equipos?
  • Lo digital está destruyendo el Amazonas?

Y también nombramos la regla de las 2 pizzas de Jeff Bezos, referenciamos a DotNet Rock y mucho más ! Si hasta nos han quedado varios temas para futuras sesiones.

Espero que lo disfruten.

Ir a descargar

Saludos @ Toronto

El Bruno

References

#Podcast – ALM with Visual Studio, Cloud development and some news before #Build2016

devops banner

Hola !

Hoy es día de publicar un nuevo podcast para la serie de NTN. En el episodio de hoy hablaré con Luis Fraile (@lfraile) (ALM MVP desde que recuerdo) sobre la historia de algunas herramientas de Microsoft. Hablaremos también sobre las capacidades que tenemos hoy para desarrollar con entornos InPremise o Cloud. Y, si bien la idea original era hablar sobre DevOps, nos fuimos por otros caminos y lo dejamos para un podcast futuro (con algún otro invitado especial).

El podcast se puede escuchar aquí http://www.ivoox.com/11030611

Ir a descargar
Saludos @ Toronto

-El Bruno

References

#Podcast – ALM with Visual Studio, Cloud development and some news before #Build2016

devops banner

Hi !

Today is day for a new podcast for the NTN series. In today’s episode I’ll talk with Luis Fraile (@lfraile) (ALM MVP since I remember) about the history of some Microsoft Dev Tools until today. We will also talk a little about some capabilities that we have today if we want to creates app and use InPremise or Cloud dev scenarios. And, even if the original idea was to talk about DevOps, we must leave this idea for a future podcast.

You can listen the podcast here http://www.ivoox.com/11030611

Download

Greetings @ Toronto

-El Bruno

References

[#ALM] Is your team too big?

pizza_cover

Hello!

For us, the developers, when we talk about the ideal size of a team, we always tend to think in the number 7. It may be because of the Scrum and agile methodologies influence, but it seems that 7 is a number that we all feel comfortable. Today April 15th, I strongly believe that 7 is the ideal size for a team.

However, in a team of this size we often don’t have all of the capabilities required to be able to bring forward a product that add real value. At some point, we will need to interact with some Subject Matter experts on a specific topic (technical or business), perhaps people from marketing, finance, etc. Although they are spontaneous interactions, from time to time, this type of interaction can become the arrival of a new member into the team.

And so without giving us, what started as a team of 7 people working on a project has become a group of 35 people with a very different dynamic. This change also involves the involuntary creation of processes to work. And we all know this is the path to the dark side: processes lead to bureaucracy, the bureaucracy tends to bore people, boring people are not productive, etc.

At Amazon they have a rule which is great

 “If you need more than 2 pizzas to feed a team, then the team is too big.”

This is known as the Two-Pizza team rule (link). It is at this point where you have to stop the progress of the project for a day and begin to check if there are points where you can improve. Surely, this will not be an easy or quick process, but it is necessary. One of the best examples I’ve read on this point is how the Visual Studio Team has adapted working his way to finish creating an agile culture at Microsoft (link)

So now you know, if when on a Thursday of beers you get to invite the team and have to ask more than 2 pizzas.Then, it is ideal to think if the team is not too large and what can be done to change the dynamics of the same.

Saludos @ La Finca

/El Bruno

PD: Source Image >> http://robertkaplinsky.com/work/giant-pizza/

[#ALM] Es tu equipo demasiado grande?

pizza_cover

Hola!

Los que somos desarrolladores, cuando hablamos del tamaño ideal de un equipo siempre solemos pensar en el número 7. Puede ser por la influencia de Scrum o de las metodologías ágiles, pero el 7 es un número con el que todos nos sentimos confortables. Hoy 15 de Abril, yo firmo ese número como el tamaño ideal para un equipo de trabajo.

Sin embargo, un equipo de esas dimensiones nunca suele contar con todas las capacidades que se requieren para poder sacar adelante un producto que aporte valor. En algún momento, necesitaremos interaccionar con expertos en algún tema específico (técnico o de negocio), tal vez gente de marketing, finanzas, etc. Si bien son interacciones espontáneas, en determinados momentos, este tipo de interacción puede convertirse en la llegada de un nuevo integrante al equipo.

Y así sin darnos cuenta, lo que se inició como un equipo de 7 personas trabajando en un proyecto se ha convertido en un grupo de 35 personas con una dinámica muy diferente. Este cambio también involucra el nacimiento involuntario de procesos internos para trabajar. Y todos conocemos el camino al lado oscuro: los procesos llevan a la burocracia, la burocracia tiende a aburrir a las personas, las personas aburridas no son productivas, etc.

En Amazon tienen una frase que es grandiosa

 “Si necesitas más de 2 pizzas para alimentar a un equipo, es que es demasiado grande”.

Esto se conoce como el Two-Pizza team rule (link). Es en este momento donde hay que detener por un día el avance del proyecto y comenzar a revisar si existen puntos donde se puede mejorar. Seguramente, este no será un proceso fácil ni rápido, pero es necesario. Uno de los mejores ejemplos que he leído sobre este punto es cómo el equipo de Visual Studio ha ido adaptando su forma de trabajo para terminar creando una cultura ágil en Microsoft (link)

Así que ya sabes, si cuando en un jueves de cervezas te toca invitar al equipo y tienes que pedir más de 2 pizzas. Ese momento, es ideal para pensar si el equipo no es demasiado grande y qué se puede hacer para cambiar la dinámica del mismo.

Saludos @ La Finca

/El Bruno

PD: La imagen es de >> http://robertkaplinsky.com/work/giant-pizza/

[#ALM] Visual Studio Online free eBook (eng)

Hello!

Excellent news if you are looking for some new content to add in your Kindle. If you are looking for a good intro for manage agile projects using Visual Studio Online as main platform, you’ve to thanks our Microsoft Press friends. They now give you the chance of free download the following book: ‘ Managing Agile Open-Source Software Projects with Microsoft Visual Studio Online “

7345.9781509300648_7AF19707

I take a quick look to the book I have to say that I really liked the book. I know a little about the topics covered in the book

Chapter 1, “Triage of ideas”
Chapter 2, “Getting ready”
Chapter 3, “Building the working solutions”
Chapter 4, “Raising the quality bar”
Appendix 1, “Supporting toolbox”
Appendix 2, “Eating your own dogfood is key”

As if it were a real book I “jump to a random page” and I’ve been reading from there for about 1 hour. This book is always interesting to review these concepts and the truth that the book does so in a very pleasant way.

100% recommended and Kudos to the team of Microsoft!

Saludos @ Madrid

/El Bruno

Source: http://blogs.msdn.com/b/microsoft_press/archive/2015/04/09/free-ebook-managing-agile-open-source-software-projects-with-microsoft-visual-studio-online.aspx

Descarga: Download the PDF (9.31 MB)