Etiquetado: southworks

Team City organizational setup alternatives

The way we decided to manage the continuous integration process is to have one build server per project, that is an exclusive virtual machine with a Team City install running on it. These strategy gives each team full control over the server without having to worry about other projects.

Other alternative, that I think is more frequently used, is to have only one build server for the whole organization and several build agents. When using this strategy the build server concentrate the all build configurations, checkouts the code and delegate to an agent the execution of the build steps. If you have two projects with incompatible software requirements (i.e. one project running on Windows and other on Linux), then you could setup one Windows agent and Linux agent.

Last week I setup an environment following this second alternative. I took 2 machines, in the first one I installed a full TeamCity environment: server and agent, and in the second one I installed just an agent. It was very straight forward. One additional benefit of this setup is that it allows run builds in parallel.

Técnicas para administrar el backlog de proyecto

La semana pasada como parte de mis tareas cotidianas en Southworks, estuve trabajando en la capacitación de un nuevo compañero. Como parte de la capacitación le expliqué algunas técnicas que solemos utilizar para manejar el backlog de nuestros proyectos y luego de hacerlo decidí ponerlo por escrito para que esté accesible para la comunidad en general. Este es el link al post que escribí (está en inglés)

Ojala les resulte útil.

Backlog management Tips

In this post I want to share some tips about this topic.

Backlog basics (or preliminary definitions)

Some people tend to think that a backlog is just a simple list of items. I don’t think that is true; I try to use the word backlog to refer to a list of items that are prioritized and estimated. Of course, the prioritization is done by the customer while the estimation is done by the technical team.

What are the items in the backlog? Depending on the context, the items can by user stories, use cases or simply tasks. When working on a development project I try to avoid having tasks in my backlog because in many cases tasks do not add value to the customer who prefers user stories. In most cases, what really adds value to the customer is working software and that is represented by a group of user stories.

The backlog is commonly used to organize work but is also used to provide visibility of the project’s status .

Backlog recommendations

Make the status EXPLICIT

A very common strategy to show the status in a consumable way is to use a semaphore pattern (green-yellow-red): Done, In progress, Blocked, Pending. Using this convention is very easy to detect smells. For example, if there are many yellow stories it could mean that there is too much work in progress, and you are not focused on completing specific stories.

Note: if you are using a dashboard, then the status is given by the position of the item in the dashboard.


Limit the work in progress

Completed items are the only real measure of progress, so you should focus on completing items instead of accumulating stories in progress. This leads us to the following question: How many stories can be in progress at the same time? There is no single answer; it depends on the length of time, but each person should work on ONE item at a time. In a particular situation it could be that two items are closely related, so you could decide to work on them both at the same time. But if you have 3 team members and 10 items in progress, you should look at the situation.

INVEST in SMART

When working with user stories, it is good practice to keep the INVEST acronym in mind:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable Testable

Beyond user stories, I think these considerations are very useful when creating a backlog, no matter what your items are.

Other famous acronym related to planning and very used when defining goals is SMART:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-boxed

More information about these acronyms can be found here.

My backlog

The following picture is a screenshot of the backlog of my current project. I have highlighted some important properties:

Chau 2011

¡Adentro! se fué el 2011 y tal como lo dijera en su momento: 2010 fue un año bisagra y con 2011 empezó una nueva etapa. Entre los hechos destacados de esta nueva etapa debo mencionar:

Respecto de eventos fui orador en Codecamp y en Smalltalks,  participé activamente en el Agiles2011 y en el AO Tour y dicté un workshop en el contexto de ASSE/JAIIO.

Otro punto que quiero destacar es que he mantenido mi constancia en este blog. Durante 2011 escribí 88 post superando las 66 que había escrito durante 2010. Este incremento de casi 30% también se correlaciona con la cantidad de visitas que paso de casi 7.000 en 2010 a casi 11.000 durante 2011. Intentar superar estos números durante 2012 será sin duda una gran desafío.

Bueno, es todo, chau 2011. Me despido no sin antes agradecer a los lectores de este blog deseándoles un gran 2012 y esperando poder seguir aportandoles mis 2 centavos durante este nuevo año.

¡Salud!