sábado, diciembre 31, 2011

Administración de Riesgos en Scrum

Hace unos meses apareció una gran duda en mi mente: ¿Cómo se acoplan la administración de riesgos en Scrum u otras metodologías ágiles? Luego de haber leído mucho sobre metodologías ágiles y también sobre Riesgos, no recuerdo haber leído en ninguna parte el nexo entre estos dos temas.

Realmente es algo de lo que todavía no se habla mucho dentro de las metodologías ágiles, no existe ningun template o framework oficial. En las metodologías clásicas tipo PMI, se presta mucha atención a los riesgos, ocupando una de las áreas de conocimiento del PMBOK. Al comienzo del proyecto se listan los riesgos, se discuten con el equipo y otros interesados, se le asigna una probabilidad y un impacto, se calcula la severidad, se acepta el riesgo o se prepara un plan de mitigación si vale la pena. Lamentablemente, este plan queda generalmente abandonado cuando se está acercando la fecha de entrega del proyecto y el ritmo de trabajo aumenta. El PM es el dueño de la administración de riesgos en el proyecto y tiene que dedicarle esfuerzo y tiempo al control y monitoreo de estos.

En Scrum, parte de la administración de riesgos es implícita, dentro del framework: Al usar Sprints cortos, realizar reuniones y revisiones periódicas, mantener comunicaciones más eficientes y manejar a un equipo autoadministrado trabajando cerca con el cliente, priorizando, inspeccionando y adaptándose a los cambios y a nueva información. Sin embargo no todo está contemplado por las prácticas de scrum, el mismo Ken Schwaber lo reconoce: “Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management.”. Hay ciertos riesgos que son externos al proyecto, y que deben ser administrados por el equipo. Alguno de estos son:
  • Riesgos políticos involucrados en la relación del equipo con el product owner, y de la posición e influencia de esta persona dentro de la organización.
  • Riesgos financieros y legales.
  • Riesgos de trabajar con otras empresas y de tercerizar.
  • Factores de infraestructura y medio ambiente del equipo de trabajo.
  • Riesgos de integración e interdependencia con otros proyectos, conflictos de recursos.
  • Distribución o implementación del producto

Para cerrar este artículo, podemos concluir que se necesita administración de riesgos en proyectos manejados por Scrum, enfocados más afuera que adentro, ya que Scrum ayuda a minimizar riesgos de alcance, calendario y calidad mediante sus principios y prácticas. Scrum es ingenuo en asumir que el desarrollo de software se hace en un vacío, sin que nada pueda afectar al proyecto fuera del equipo. Aunque asumamos que el equipo trabaja correctamente con riesgos técnicos y que otros riesgos inmediatos de calendario se contienen trabajando incrementalmente y utilizando buenas practicas, hay que monitorear y administrar riesgos y problemas fuera del desarrollo del producto. El correcto manejo de estos riesgos externos puede hacer la diferencia entre un éxito y un fracaso.

Fuentes: La fuente principal que nutre este artículo es el blog Building Real Software de Jim Bird. Luego también saque información de Thushara Wijewardena en el blog Projectized y de Agile101. Estos dos últimos proponen un acercamiento ágil de la administración de riesgos, les recomiendo que le pequen una mirada.

martes, diciembre 20, 2011

Agile Software Development with Scrum

"Agile Software Development with Scrum" de Ken Schwaber y Mike Beedle es el primer libro escrito sobre Scrum. Es un buen libro pero no es grandioso, los autores reconocieron en una ocasión que fue escrito a las apuradas para ser presentado a tiempo en una conferencia. Lo leí porque hace pocos meses me certifiqué como ScrumMaster y mi instructor fue el mismo Mike Beedle.

Al ser tan "primitivo", no existen varios conceptos "modernos" de Scrum que hoy tanto se usan como las historias de usuario y la estimación en puntos de historias de usuario (o user story points), una práctica que junto a Scrum, es un avance muy significativo en la gestión de proyectos de software.

Lo que mas valoro de este libro primero es que haya sido escrito, permitiendo a mucha gente adoptar Scrum, y a que muchos otros mejores libros sobre el tema hayan sido escrito, como "Agile Project Management with Scrum" de Ken Schwaber (uno de los coautores del libro en cuestión). 

Para cerrar el artículo, vale mencionar que este libro me hizo reflexionar sobre la variable abierta en Scrum, que es el scope del sprint. Teniendo un equipo y un tiempo de sprint fijo, lo que puede variar en un sprint es el scope, siempre que se logre alcanzar el objetivo y se logre consenso con el product owner. 

Si se sienten curiosos y quieren ver como Scrum fue concebido inicialmente, les recomiendo que lean este libro, pero solo como material histórico, no para aplicar sus conceptos al pie de la letra ya que está bastante desactualizado. Como primer lectura sobre Scrum, les recomiendo el libro de Ken Schwaber mencionado arriba y para consejos prácticos no dejen de leer "Scrum and XP from the Trenches" de Henrik Kniberg.

jueves, noviembre 17, 2011

¿Es Darth Vader un buen Project Manager o no?

El temible y malvado Darth Vader, uno de los personajes mas famosos de la saga de Star Wars, puede ser visto como un project manager, uno muy efectivo. O a lo sumo eso piensa Brandon Koeller en su entretenido e interesante artículo en Geekwire. Acá les dejo las diez razones que el autor enuncia:

Number 10: Vader prioritized brutally. Over the course of Vader’s pursuit of the Rebel Alliance, you see him set and pursue priorities according to their strategic value. When he knew the plans for the Death Star had been leaked, he focused on mitigating that risk. When Luke came on the scene, he shifted priorities to recruit him to the Dark Side! Vader paid close attention to the happenings of the galaxy, evaluated the impacts of any given issue, and went after the highest priorities…time after time. No emotional attachments, no personal agendas…just the right thing to do to preserve the Imperium, and see his project through to successful completion. In project management, if you can’t prioritize, you won’t get anything done, let alone anything done well.

Number 9: Vader made decisions based on objective data, not whims. Remember that Imperial officer who had to report to Vader that they had lost Han Solo in the asteroid field, and he choked him? That was some decisive action! Vader consistently evaluated the performance of his team, and made changes to fix problems when the team didn’t perform. Sure, there may have been some fear and terror, but put all that aside. The inclination to objectively evaluate the performance of your team and not accept substandard performance is an important one. Project teams needs to feel safe and supported, but they also need to know that the project goals need to get met, and if you aren’t delivering on your commitments, changes need to get made. Thank you, Vader, for making tough choices to accomplish your goals!

Number 8: Vader made commitments, and worked hard to keep them. If you think of the Galactic Empire as something of a SCRUM project, the Emperor would have to be playing the Product Owner role. Of course, in SCRUM/Agile, the team makes commitments to achieve predefined goals over the course of any given sprint or iteration. Darth did this with the Emperor many times, and he worked REAL hard to make sure those commitments were met. I mean, how did he manage to get that second Death Star operational so quickly anyway? Hard work, that’s how. Vader understood the importance of commitments, and more importantly, the significance of fulfilling them. Trust in teams is built on commitments.

Number 7:
Vader took time to re-charge, relax, and get some perspective. Projects and the achievement of project goals can often feel like super-high stakes. Everyone on the team is motivated to solve the problem, and get to done. Conflict is inevitable in that kind of environment, and a good project manager needs to get in there and confront those issues head-on. Of course, this can be exhausting, emotionally and intellectually. Vader understood this, and was careful to take time out of his busy project schedule to relax, meditate, and give himself room to gain some perspective about what was really important. Remember that awesome rehab egg thing he had in his quarters? Good project managers care, and they need to express that care, but they also need to maintain objectivity, which means they need to give themselves the time and space to regain perspective.

Number 6: Vader managed risk and expectations…pre-emptively. Remember that time when Darth Vader went to Cloud City, bought off the management, then lured Han, Leia, and Chewbacca into a trap? Genius. The amount of planning and forethought that went in to that little exercise must have been epic. After some serious prioritizations, Vader perceived the highest risk to his Galaxy, and made a plan to mitigate the risk stat! Additionally, you saw him having conversations with team members all over the place making sure they understood clearly what his expectations were with regards to the achievement of goals. Good project managers think about their projects defensively, and act to protect them aggressively.

Number 5: Such a persuasive fellow. Of all Vader’s substantial capabilities, perhaps his most effective one was his ability to persuade people to do what he needed done. With the exception of his own kids (in his defense, have you ever tried to get your kids to do something?), he did a pretty great job of getting people to cooperate (whether through fear, obligation, or The Force!). The Imperium was so enormous, so full of complexities…it must have been a serious challenge to navigate that and convince people that his vision of the project was one that they could all get behind.

Number 4: Vader picked a methodology and stuck with it…until it didn’t work. In keeping with the commitment to objectivity in performance, Vader picked his methodology of fear, manipulation, and aggression, and stuck with it, until it was clear that the methodology was not working anymore. Everyone knows that Vader betrayed his Emperor to save Luke from certain death upon Luke’s refusal to join the team in a certain role. Vader saw that his previous methods of fear and intimidation didn’t seem to work with Luke, or any of the rebels any longer. Boom! Change of tactics to get the job done.

Number 3: No problem is too big to tackle. Sure, Vader had an enormous skepticism that served him well in managing risk. All good project managers need that ability. But good project managers also have to be optimistic enough to push through tough challenges and look for solutions, however improbable their success. The point at which the Rebels had slipped off the imperial radar screen, and holed up on Hoth…Vader was feeling pretty lost at that point, you know? Where the devil had those pesky rebels gone off to? How the bantha poodoo was Vader going to find them in the enormity of the galaxy? What is that? Send out thousands of spy droids to random planets and see what turns up? Low probability of success, but still better than zero? Done! Vader’s optimism and confidence in his team’s ability to overcome all obstacles is an excellent lesson in persistence.

Number 2: It is never too late to do the right thing. Everyone is presented with choices that have questionable moral consequences. The right thing is almost always something to be wrestled with. One of the most profound moments in Vader’s career came when he took responsibility for all the morally wrong things he did, and did the right thing. He never thought it could atone, but he did the right thing anyway. Project managers will make thousands of choices in the course of a project…some of which may be of questionable moral fiber including the omissions of details, avoided conversations, hidden pieces of data all to paint a better picture of the project. Good project managers will take the time to reflect on their choices, and re-make the choices they don’t feel good about. The right thing is crucial to trust on a team, even if the right thing is a hard thing.

Number 1: Vader was never afraid of getting his hands dirty. Every project will have boundaries drawn around the responsibilities of specific roles being played, and Vader knew his own role in the imperial project. But he never asked anyone to do anything that he wasn’t willing to do himself, and he made sure he had a clear understanding and appreciation for the hard things that his team had to execute on. This, I think, is what made Vader better than just good. No detail was overlooked. He didn’t micro-manage, necessarily. He got involved in the work of the project, and his team followed him because they knew he understood and was invested in the project’s success! Whether he was force-choking a non-performing admiral, or flying a tie-fighter, he contributed to the team’s success anyway he could.

Michael Pruitt de VMC Consuting retruco a Brandon Koeller en su artículo, mencionando que esta equivocado en el punto 10, donde dice que Vader priorizaba. Michael piensa lo siguiente:

I believe he is making the classic mistake of taking specific characteristics common to one type of project contributor and extrapolating an extreme example of that characteristic as something different.

Darth Vader is a project manager who lets his emotional attachments and personal agendas drive decisions, and that’s not good project management.

When Koeller says, “Vader prioritized brutally,” I think he is confusing Vader’s single-mindedness with prioritization. When we talk about prioritization in project management, we usually mean ordering the relative importance of an objective, deliverable or other unit of work. Prioritization paired with a clear strategic objective allows teams to identify the features that we believe will achieve that objective and then stack rank them in order of priority. Then you can pursue features based on that ranking. To ensure that workable solutions or products are delivered within constraints, you need to have the ability to prioritize and use that prioritization to keep projects focused on the highest value work. Vader is single-mindedly pursuing the Rebellion because that’s the task the Emperor assigned him.

Prioritization can be adaptive and is a characteristic of facilitators and project managers. Single-mindedness at work is a trait that allows us to focus on specific tasks and focus on them to completion. This isn’t really a core trait of a Project Manager; it’s a characteristic of individual contributors.

No me digan que esto no fue interesante. Para mi Darth Vader se torno obsesivo y perdió el control en un momento, pero al final hizo lo correcto :)

lunes, noviembre 14, 2011

The Art of Project Management

The Art of Project Management de Scott Berkun me atrajo inicialmente por su titulo, ya que ciertamente ser un buen Project Manager es un arte, además de ser una habilidad que puede desarrollarse.

El libro esta separado en tres secciones: planes, habilidades y management. Aunque el libro no esta enfocado en ninguna metodología, es bastante orientado a PMI y hay varias secciones que lo reflejan. Por ejemplo el libro se extiende demasiado en como desarrollar una visión, documentarla, planificar y escribir especificaciones. Eso es lo negativo que saco de este libro.

Lo mas jugoso es cuando comenta como comunicarse y relacionarse efectivamente, como tratar con la gente (ver mi artículo de tácticas de guerrilas tomadas de este libro) y como manejarse en el ambiente político empresarial. En estas ultimas secciones, mas blandas podría decirse, Scott Berkun hace honor al titulo del libro para comentarnos su experiencia y entendimiento de lo que es ser un buen Project Manager.

Les dejo una de las frases mas interesantes del libro para cerrar este articulo: 

Trust is built through commitment but lost through inconsistent behavior. Leaders must develop enough trust that people will bring issues to them during crises instead of hiding them. Trust, then, is at the core of leadership

jueves, noviembre 10, 2011

Certified SrumMaster!

El 21 y 22 de Octubre del 2011 asistí al curso de Certified ScrumMaster de la Scrum Alliance (En el instituto Kleer en Buenos Aires)  dictado por Mike Beedle, uno de los fundadores del Agile Alliance y uno de los autores del Manifiesto Ágil.

El curso fue valioso, aunque no aprendí muchas cosas nuevas (debido a que vengo practicando y leyendo sobre Scrum hace tiempo), Mike fue muy claro para transmitir ciertas cualidades básicas de Scrum a las cuales tal vez no le daba mucha importancia, enriqueciendo mi conocimiento sobre el tema. Aproveche para sacarme una foto con Mike uno de los días:
Mike de remera negra y yo de remera blanca
Luego del curso, hay que rendir un examen online muy sencillo de 35 preguntas en Scrum Alliance y luego uno ya puede considerarse un Certified ScrumMaster y puede crear su perfil en el sitio web de Scrum Alliance (ver el mio!).

Vale la pena hacer el curso, pero lo ideal para aprender bien Scrum es practicarlo laboralmente y tener a alguien que sepa mas que uno como un coach. Leer sobre el tema también aporta lo suyo.

sábado, noviembre 05, 2011

Release Planning en Scrum

Una de las criticas mas grandes a Scrum es que se centra en el corto plazo. Se dice que con Scrum no se puede planear a largo plazo, que no se puede tener visibilidad a futuro, y esto no es cierto. Generalmente cuando uno empieza a practicar Scrum pasa eso, uno se concentra en los Sprints, en ir mejorando cada vez, restándole importancia a largo plazo. A mi me paso y me encontré en una situación donde tenia mucho trabajo por delante y poco tiempo para la entrega del proyecto.

La practica de Release Planning en Scrum te permite tener visibilidad a largo plazo. Para practicarla, se necesita que el Product Backlog este estimado en User Story Points (que todas las User Stories tengan un valor) y también se necesita conocer la velocidad del equipo (cuantos Story Points se pueden hacer por Sprint). Con esto, uno se puede reunir con el Product Owner y preparar un release plan de N Sprints. Como los Sprints tienen duración fija y la cantidad de Story Points que el equipo completa por Sprints debe tender a un numero mas o menos predecible (con mayor cantidad de Sprints esto mejora), se puede armar un plan dividiendo las user stories del Backlog en sprints y obtener una fecha de finalización del proyecto, o de una parte del mismo que se quiera lanzar a producción.
Es muy importante actualizar este release plan una vez por Sprint, ya que se tienen nuevas User Stories, nuevas prioridades y tal vez una velocidad mejor o mas predecible. Si solo lo hacemos luego del primer Sprint, no va a ser nada confiable.

miércoles, noviembre 02, 2011

Tácticas de Guerrilla

Un buen PM nunca tiene que rendirse ante un problema. Si nos enfrentamos con algo que es importante para el proyecto hay que actuar agresivamente y usar todos los medios necesarios para encontrar la respuesta o resolver el problema. Todos tratamos de evitar el conflicto, pero en este tipo de situaciones hay que cuestionar a la gente, desafiar asunciones y buscar la verdad, sin importar lo incomodo que esto sea para todos (aunque hay que tratar de minimizar este efecto negativo). La diligencia gana batallas. Hay que buscar alternativas y ser implacable, pero utilizando el sentido común, lo ideal es buscar la forma astuta de resolver los problemas. Hay que ser implacable en espíritu pero astuto en acción.

Estas palabras fueron tomadas del libro "The Art Of Project Management" de Scott Berkun y sirven para introducir ciertas tácticas de guerrilla que el autor aplico para lograr lo necesario para cumplir con sus objetivos (Algunas son riesgosas y tienen que aplicarse con cuidado) Disfrutenlas!

Know who has authority. Don't waste time arguing with people who have no control or influence over the issue. To be effective, you need to know who makes decisions or influences a particular issue or situation. Find out who it is (it's not always the most senior person in the room, and the identity of the person may change from issue to issue), get time with him one-on-one, and make your case. Or, at least find out what she truly objects to. If you can't get to the most influential person (Sally, the VP), find the person who has the greatest influence on her (Sally's best employee). Go to the highest point on the chain you can reach. Warning: don't end-run people. Go to the point of authority, but invite the opposing viewpoint if necessary, or disclose to him what you're doing. "Look, we disagree, but we can agree that it's Sally's decision. I'm going to go talk to her about this tomorrow. I'd like you to be there."

Go to the source. Don't dillydally with people's secondhand interpretations of what someone said, and don't depend on written reports or emails for complex information. Find the actual person and talk to him directly. You can't get new questions answered by reading reports or emails, and often people will tell you important things that were inappropriate for written communication. Going to the source is always more reliable and valuable than the alternatives, and it's worth the effort required. For example, if two programmers are arguing about what a third programmer said, get that third programmer in the room or on the phone. Always cut to the chase and push others to do the same.

Switch communication modes. If communication isn't working, switch the mode. Instead of email, call them on the phone. Instead of a phone call, drop by their office. Everyone is more comfortable in some mediums than others. (Generally, face to face, in front of a whiteboard, trumps everything. Get people in a room with a whiteboard if the email thread on some issue gets out of control.) Don't let the limitations of a particular technology stop you. Sometimes, switching modes gets you a different response, even if your request is the same, because people are more receptive to one mode over another. For anything consequential, it's worth the money and time to get on a plane, or drive to their office, if it improves the communication dynamic between you and an important co-worker.

Get people alone. When you talk to someone privately, her disposition toward you is different than when you talk to her in a large group. In a meeting, important people have to craft what they say to be appropriate for all of the ears in the room. Sometimes, you'll hear radically different things depending on who is in earshot. If you want a frank and honest opinion, or an in-depth intense conversation, you need to get people alone. Also, consider people of influence: if Jim trusts Beth's opinion, and you want to convince Jim, if you can convince Beth first, bring her along. Don't ambush anyone, but don't shy away from lining things up to make progress happen.

Hunt people down. If something is urgent and you are not getting the response time you need, carve out time on your schedule to stake out the person's office or cubicle. I've done this many times. If he wasn't answering my phone calls or emails, he'd soon come back from a meeting and find me sitting by his door. He'd usually be caught so off guard that I'd have a negotiating advantage. Don't be afraid to go after people if you need something from them. Find them in the coffee room. Look for them in the café at lunchtime. Ask their secretary what meetings they are in and wait outside. Be polite, but hunt and get what you need. (However, please do not cross over into their personal lives. If you hunt information well, you shouldn't ever even need to cross this particular line.)

Hide. If you are behind on work and need blocks of time to get caught up, become invisible. On occasion, I've staked out a conference room (in a neighboring building) and told only the people who really might need me where I was. I caught up on email, specs, employee evaluations, or anything important that wasn't getting done, without being interrupted. For smaller orgs, working from home or a coffee shop can have the same effect (wireless makes this easy these days). I always encouraged my reports to do this whenever they felt it necessary. Uninterrupted time can be hard for PMs to find, so if you can't find it, you have to make it.

Get advice. Don't fly solo without a map unless you have to. In a given situation, consider who involved thinks most highly of you, or who may have useful advice for how you can get what you need. Make use of any expertise or experience you have access to through others. Pull them aside and ask them for it. This can be about a person, a decision, a plan, anything. "Hey Bob, I'd like your advice on this budget. Do you have a few minutes?" Or, "Jane, I'm trying to work with Sam on this issue. Any advice on the best way to convince him to cut this feature?" For many people, simply asking their advice will score you credibility points: it's an act of respect to ask for someone's opinion.

Call in favors, beg, and bribe. Make use of the credibility or generosity you've developed a reputation for. If you need an engineer to do extra work for you, either because you missed something or a late requirement came in, ask her to do you a favor. Go outside the boundaries of the strict working relationship, and ask. Offer to buy her dinner ($20 is often well worth whatever the favor is), or tell her that you owe her one (and do hold yourself to this). The worst thing that can happen is that she'll say no. The more favors you've done for others, the more chips you'll have to bank on. Also, consider working three-way trades (e.g., in the game Settlers of Cattan) if you know of something she wants that you can get from someone else. It's not unethical to offer people things that will convince them to help with work that needs to be done.

Play people off each other. This doesn't have to be evilif you're very careful. If Sam gives you a work estimate of 10 days, which you think is bogus, go and ask Bob. If Bob says something less than 10 days, go back to Sam, with Bob. A conversation will immediately ensue about what the work estimate really should be. If you do this once, no engineer will ever give you bogus estimates again (you've called bullshit). However, depending on Sam's personality, this may cost you relationship points with him, so do it as tactfully as possible, and only when necessary. Good lead programmers should be calling estimate bluffs on their own, but if they don't, it's up to you.

Stack the deck. Never walk into an important meeting without knowing the opinions of the important people in the room. Always arrive with a sense for who is likely to support your opinion and who is likely to be against it, and have a strategy developed for navigating through it all (see Chapter 16). If something important is at stake, make some moves to sway those against you, or to rally their support, before the meeting. Don't lie, manipulate, or mislead, but do seriously prepare and understand the arguments and counterarguments that will come up.

Buy people coffee and tasty things. This sounds stupid, but I've found that people I've argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don't like the person, make the invitation and invest the 20 seconds of effort it requires. Even if he says "No, why can't we talk here?", you've lost nothing. Moving the conversation to a different location, perhaps one less formal, can help him open up to alternatives he wouldn't consider before. Think biologically: humans are in better moods after they've eaten a fine meal or when they are in more pleasant surroundings. I've seen PMs who keep doughnuts or cookies (as well as rum and scotch) in their office. Is that an act of goodwill? Yes...but there are psychological benefits to making sure the people you are working with are well fed and associate you with good things.

sábado, octubre 22, 2011

Los Valores de Scrum

Ken Shwaber identificó los cinco valores de Scrum en su libro "Agile Software Development with Scrum": compromiso, enfoque, transparencia, respeto y coraje. Scrum se basa en todos estos valores para llevar adelante un proyecto, podría decirse que son el corazón de Scrum. Repasemos uno por uno:

  • Compromiso: Estar dispuesto para comprometerse a una meta. La metodología la da a las personas la autoridad que necesitan para cumplir con sus compromisos. Scrum no es posible sin que todo el equipo este prestando atención y cumpliendo los compromiso asumidos.
  • Enfoque: Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada más. Alguien lo hará por ti (El ScrumMaster tiene la obligación de desbloquear al equipo y protegerlo de interrupciones o distracciones innecesarias)
  • Transparencia / Honestidad: Scrum mantiene todo acerca del proyecto visible a todos. Todos participan.
  • Respeto: Los individuos estamos formados por nuestros orígenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar. Sin respeto, no puede existir una comunicación efectiva.
  • Coraje: Tener el coraje para comprometerse, actuar y ser honesto. El coraje es la cualidad del espíritu que te permite enfrentarte al peligro sin mostrar miedo. Requiere coraje comunicar problemas, identificar impedimentos, pedir, recibir y dar ayuda.

El resultado de creer y practicar en estos valores lleva a comportamientos positivos que resultan en entregables frecuentes que nos permiten trabajar éticamente. Todos sabemos los roles, ceremonias y artefactos de Scrum, pero sin adoptar estos valores, el enfoque no funcionaria correctamente.

lunes, septiembre 12, 2011

The Best Software Writing I

"The Best Software Writing I: Selected and Introduced by Joel Spolsky" es un libro que recopila varios artículos de distintos blogs de gente que escribe bien sobre software. Recalco el bien porque ese fue el objetivo principal del autor, ya que mucha gente escribe sobre software, pero pocos logran hacerlo eficazmente o con estilo.

Joel Spolsky es conocido por su blog Joel on Software. Lei sus dos libros, Joel on Software y More Joel on Software, realmente dos libros muy buenos, pero con este no la pego (tal vez por eso nunca se extendió esta colección, solo salió el volumen uno).

Los artículos son interesantes, y hay varios de ellos que son excelentes, pero hay algunos que no son muy entretenidos o son muy técnicos. También la variedad de temas hace que el libro sea poco coherente, aunque es algo esperable de una compilación de artículos. Les dejo la lista de todos ellos y subrayo los mejores para que los busquen en los blogs de los respectivos autores, les recomiendo esto antes que conseguir el libro.

Ken Arnold - Style Is Substance 
Leon Bambrick - Award for the Silliest User Interface: Windows Search
Michael Bean - The Pitfdalls of Outsourcing Programmers
Rory Blyth - Excel as a Database
Adam Bosworth - ICSOC04 Talk
danah boyd - Autistic Social Software
Raymond Chen - Why Not Just Block the Apps That Rely on Undocumented Behavior?
Kevin Cheng and Tom Chi - Kicking the Llama
Cory Doctorow - Save Canada's Internet from WIPO
ea_spouse - EA: The Human Story
Bruce Eckel - Strong Typing vs. Strong Testing
Paul Ford - Processing Processing
Paul Graham - Great Hackers
John Gruber - The Location Field is the New Command Line
Gregor Hohpe - Starbucks Does Not Use Two-Phase Commit
Ron Jeffries - Passion
Eric Johnson - C++ -- The Forgotten Trojan Horse
Eric Lippert - How Many Microsoft Employees Does it Take to Change a Lightbulb?
Michael "Rands" Lopp - What to do when you're screwed
Larry Osterman - Larry's Rules of Software Engineering #2: Measuring Testers by Test Metrics Doesn't
Mary Poppendieck - Team Compensation
Rick Schaut - Mac Word 6.0
Clay Shirky - A Group is its Own Worst Enemy
Clay Shirky - Group as User: Flaming and the Design of Social Software
Eric Sink - Closing the Gap
Eric Sink - Hazards of Hiring
Aaron Swartz - PowerPoint Remix
Why the lucky stiff - A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes)

lunes, agosto 22, 2011

Consejos prácticos para Managers

Les dejo 10 muy buenos consejos para Managers. El autor de esta lista es Steve Tobak, y la creo tomando a los mejores CEOs con los que trabajo en sus 30 años de experiencia.
  1. Mantenerse tranquilo y no perder el sentido del humor en tiempos de crisis.
  2. Siempre dar feedback a la gente cuando se equivoca
  3. Ser el jefe, pero comportarse como un miembro más del equipo, nunca perder la humildad.
  4. Bajar la guardia, relajarse y ser uno mismo fuera del trabajo.
  5. Apoyar y apostar por la gente en la que uno cree.
  6. Complementar las debilidades del equipo.
  7. Destacar las fortalezas de cada miembro del equipo.
  8. Siempre contar las experiencias mas duras de tu carrera y las lecciones que aprendiste.
  9. Hacer lo correcto.
  10. Hacer lo que hay que hacer, pase lo que pase.
Lean el artículo completo si les intereso!

domingo, agosto 07, 2011

Showstopper!

Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft de G Pascal Zachary cuenta desde la concepción como fue desarrollado el primer Windows NT en Microsoft. Se centra en el personaje de David Cutler, un desarrollador, que junto a su equipo de desarrollo de sistemas operativos de Digital Equipment Corporation (DEC) fue seducido por Microsoft para desarrollar desde cero NT.

Este fue un proyecto de una magnitud increíble que reunió cientos de personas. El libro comienza contando los últimos días de David Cutler en DEC, que cuando le cancelan el proyecto actual en el que estaba, el desarrollo de un nuevo sistema operativo, es atraído por el propio Bill Gates para desarrollar Windows NT, con el objetivo de lograr un sistema operativo que destrone a Unix y sea la base del futuro.

El autor luego cuenta todo el ciclo de desarrollo, el lento avance del proyecto. También hace hincapié sobre la vida de muchos miembros del equipo, sus logros, frustraciones y problemas. Cuenta sobre las batallas políticas dentro de Microsoft, los problemas familiares de mucha gente por casi vivir en la oficina por lograr que este producto salga al mercado.

Es una novela entretenida para entender los objetivos de Microsoft en el momento (1988 a 1993) y como se manejo un proyecto realmente histórico.

martes, julio 19, 2011

One Minute Manager

Este libro me dejó un sabor amargo. The One Minute Manager, de Kenneth Blanchard y Spencer Johnson, es un libro muy corto que describe tres aspectos sobre un buen manager, o lo que los autores consideran un buen manager.

One Minute Goal Setting: La idea es dejar por escrito todos los objetivos del trabajo de una persona y que estos estén validados y entendidos por ambas partes. Es un punto valido para manejar las expectativas y dejar en claro el rendimiento esperado en una cierta tarea.

One Minute Praisings: Esto se basa en destacar aspectos positivos de una persona cada vez que se descubre que alguien hizo algo bueno. No estoy en contra de destacar a la gente, pero la forma en la que los autores comunican esto es muy triste. Da el ejemplo de que los refuerzos positivos se usan con los chicos y con los animales, y que debemos usarlos con los adultos también. No me gusta este enfoque. Les dejo el extracto del libro donde explica esto:
“We use this concept all the time with kids and animals, but we somehow forget it when we are dealing with big people—adults. For example, at some of these Sea Aquariums you see ‘round the country, they usually end the show by having a huge whale jump over a rope which is high above the water. When the whale comes down he drenches the first ten rows.
“The people leave that show mumbling to themselves, That’s unbelievable. How do they teach that whale to do that?’
“Do you think they go out in the ocean in a boat,” the manager asked, “and put a rope out over the water and yell, ‘Up, up!’ until a whale jumps out of the water over the rope? And then say, ‘Hey, let’s hire him. He’s a real winner.’ ”
“No,” laughed the young man, “but that really would be hiring a winner.”
The two men enjoyed the laugh they shared.
“You’re right,” the manager said. “When they captured the whale, he knew nothing about jumping over ropes. So when they began to train him in the large pool, where do you think they started the rope?”
“At the bottom of the pool,” answered the young man.
“Of course!” responded the manager. “Every time the whale swam over the rope—which was every time he swam past—he got fed. Soon, they raised the rope a little.
“If the whale swam under the rope, he didn’t get fed during training. Whenever he swam over the rope, he got fed. So after a while the whale started swimming over the rope all of the time. Then they started raising the rope a little higher.”
“Why do they raise the rope?” asked the young man.
“First,” the manager began, “because they were clear on the goal: to have the whale jump high out of the water and over the rope.
“And second,” the One Minute Manager pointed out, “it’s not a very exciting show for a trainer to say, ‘Folks, the whale did it again.’ Everybody may be looking in the water but they can’t see anything. Over a period of time they keep on raising the rope until they finally get it to the surface of the water. Now the great whale knows that in order to get fed, he has to jump partially out of the water and over the rope. As soon as that goal is reached, they can start raising the rope higher and higher out of the water.”
“So that’s how they do it,” the young man said. “Well, I can understand now how using that method works with animals, but isn’t it a bit much to use it with people?”
“No, it’s very natural in fact,” the manager said. “We all do essentially the same thing with the children we care for. How do you think you teach them to walk? Can you imagine standing a child up and saying ‘Walk,’ and when he falls down you pick him up and spank him and say, ‘I told you to walk.’ No, you stand the child up and the first day he wobbles a little bit, and you get all excited and say, ‘He stood, he stood,’ and you hug and kiss the child. The next day he stands for a moment and maybe wobbles a step and you are all over him with kisses and hugs.
“Finally the child, realizing that this is a pretty good deal, starts to wobble his legs more and more until he eventually walks.

One Minute Reprimands: Se basa en comunicar claramente cuando alguien hace algo mal, para corregir el comportamiento en ese preciso instante. Esto está bueno, no estoy a favor de "guardar" estos incidentes para la evaluación de rendimiento anual o semestral, es mejor comunicar errores al instante.

El libro luego desalienta el contacto del manager y el "subordinado" fuera de estas tres prácticas, y no estoy de acuerdo en eso. También el libro parece estar escrito como para niños de primaria. Los tres aspectos del libro tienen valor, pero el estilo para comunicarlos no es inteligente, se puede ver como una sátira.

domingo, julio 17, 2011

Aspectos que distinguen a los mejores PMs

Hace poco me encontré con un artículo muy interesante del IAAP donde se describen los aspectos que distinguen a los mejores Project Managers, tomados del libro "Alpha Project Managers: What the top 2% know that everyone else does not" de Andy Crowe y no quiero dejar de compartirlos con ustedes!

1. Actitud y Creencia

Según el estudio, si bien tienen niveles de estrés similares a los demás, “los alfas” encuentran la manera de disfrutar más de su trabajo y de verse más relajados cuando no están en él.

2. Foco y Priorización

El 75% de los entrevistados mencionó que la sobrecarga de información y tareas era una de las principales fuentes de estrés en el trabajo (tanto alfas como no-alfas). No obstante, “los alfas” suelen contestar menos correos y dedicar menos tiempo a reuniones comenta el autor. El estudio encontró que todos ellos tienen alguna clase de sistema para poder enfocarse y priorizar los aspectos críticos del proyecto, dejando más rezagados los demás.

3. Comunicación

Según el libro un PM pasa el 90% de su tiempo comunicándose. Ante la pregunta obligada sobre su capacidad de comunicación, todos los entrevistados contestaron con niveles altos. :-) Sin embargo, al hablar y cruzar información entre los stakeholders de “los alfas” algunos atributos extra comenzaron a surgir: interrogan respecto a las expectativas de los stakeholders, buscan feedback, tratan de entender a la audiencia, buscan ser predecibles y poner foco siempre en lo relevante.

4. Enfoque

Todos los entrevistados esbozaron un enfoque de proyecto similar, destacando las bondades y la importancia de planificar antes de actuar. Sin embargo, “los alfas” demostraron dedicar más del doble de tiempo a esta tarea.

5. Relaciones y conflicto

“los alfas” mostraron interés y foco en mantener en estado saludable sus relaciones laborales. Varios comentaron la necesidad de separar los problemas de las personas y de identificar los posibles conflictos en forma temprana (para desactivarlos antes de que se manifiesten). A su vez cada uno tiene algún tipo de estrategia específica para lidiar con estos temas.

6. Alineamiento

Para que un proyecto sea exitoso deben ocurrir múltiples alineamientos: el del proyecto con la estrategia de la compañía, el del equipo de trabajo y los stakeholders.

“los alfas” son particularmente exitosos en aspectos tales como motivación del equipo y manejo de expectativas. Esto hace que cuenten con interlocutores altamente alineados durante el proyecto.

7. Manejo de «issues»

“Los alfas” otorgan una importancia mayor al manejo de issues que los no alfas (incluida en este manejo la definición clara de qué es y qué no es un issue). Pasan tanto tiempo trabajando en ellos, como trabajando antes para que no se convierta en tales (prevenir en lugar de curar, agrego yo).

8. Liderazgo

En este aspecto el libro comenta que lo que distingue a “los alfas” es que ellos no sólo gestionan los proyectos, sino que los lideran. Esta diferencia que para algunos puede ser sutil, en realidad es crucial a la hora de lograr resultados. Y además esta cualidad no se restringe solamente a los miembros del equipo de proyecto, sino que se extiende también a los stakeholders y a los clientes.

martes, julio 12, 2011

More Joel on Software

"More Joel on Software: Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, ... or Ill Luck, Work with Them in Some Capacity" es el segundo libro de Joel Spolsky que compila varios artículos de su blog.

Joel continua fiel a su estilo. Este libro, del mismo formato que el primero, es entretenido de principio a fin, no hay desperdicio.

El articulo mas interesante del libro cuenta un review de Bill Gates a un documento que Joel escribió trabajando en Microsoft. El libro se divide en las siguientes secciones:
  • Managing People
  • Advice to Potential Programmers
  • The Impact of Design
  • Managing Large Projects
  • Programming Advice
  • Starting a Software Business
  • Running a Software Business
  • Releasing Software
  • Revising Software
Si les interesa, les sugiero que le peguen una mirada a su blog y luego consigan el libro. Altamente recomendado!

jueves, junio 30, 2011

Más fundamentos en contra de trabajar por objetivos

Joel Spolsky (autor de Joel on Software) también considera que trabajar por objetivos es dañino. Joel cuenta que tratar desarrolladores inteligentes como si estuviesen en jardín de infantes no es un fenómeno aislado. Casi todas las empresas tienen un programa de incentivos que es insultante y degradante de alguna forma.

Cuenta que en las empresas donde él trabajó, la época más estresante del año era el periodo de las evaluaciones de desempeño. En ellos el tenía que escribir "anónimamente" sobre su superior (algo que raramente se hace honestamente), y luego autoevaluarse para que su superior "tenga esto en cuenta" para la evaluación de desempeño. Luego obtenía un valor numérico en varias categorías, como por ejemplo "trabaja bien con otros". Este sistema nunca tomaba en cuenta el hecho de que la gente tiene habilidades y talentos únicos que son necesarios para que un equipo funcione bien.

Las evaluaciones de desempeño resultaban estresantes porque mucha gente cuyos talentos eran significativos pero no estaban descriptos en las escalas tradicionales no tenían evaluaciones de desempeño positivas. Ciertas contribuciones altamente necesarias eran pasadas por alto. Obviamente, las evaluaciones de desempeño negativas tienen un efecto devastador en la moral. Evaluar a alguien positivamente, pero no tan positivamente como esa persona espera es altamente negativo también. Lo interesante y triste es que las evaluaciones positivas no afectan la moral ni la productividad. La gente que las obtienen ya son productivos. Para ellos, una evaluación positiva los hace sentir como que estuviesen trabajando para obtener la evaluación positiva, como perros trabajando por un hueso, en vez de profesionales que realmente se preocupan por la calidad de su trabajo.

Todos creemos que hacemos un buen trabajo, sea esto cierto o no. Es un truco que la mente nos juega para que nuestra vida sea placentera. Entonces, si todos pensamos que hacemos las cosas bien, y las evaluaciones son meramente correctas (algo que no es difícil de lograr), entonces casi todos vamos a estar desilusionados por nuestras evaluaciones. El costo en la moral es altísimo. Aunque las evaluaciones se hagan honestamente, las consecuencias de las evaluaciones de desempeño son baja moral, renuncias y roces entre miembros de los equipos por celos, entre otras cosas.

Estudios demuestran que gente que espera recibir un premio por completar cierta tarea se desempeña peor que la gente que no espera recibir premios. Los incentivos no pueden existir en el ambiente de trabajo. Todo esquema de competencia laboral, de premios y castigos, hasta el viejo truco de reconocer a la gente que hace las cosas correctamente, hacen más bien que mal. Darle a alguien un premio implica que la persona solo hizo el trabajo por ese premio. Esto implica que no son lo suficientemente independientes para trabajar sin que les den obsequios, y esto es insultante y degradante.

En otro articulo de Joel, donde explica el sistema de compensación de su empresa, comenta que los bonos traen demasiados problemas y se convirtieron como las propinas en los restaurantes: Todos las esperan, entonces no pueden ser utilizadas para recompensar el buen desempeño.

Espero que alguna vez esto cambie. Con una política salarial abierta, un salario competitivo, equidad interna y buenos beneficios, se puede lograr mucha mayor satisfacción que con cualquier bono.

lunes, junio 27, 2011

Trabajar por objetivos, ¿conviene?

Trabajar por objetivos, y obtener un bono por su cumplimiento, es una práctica muy común actualmente. Nunca me sentí a gusto ser medido de esta forma y últimamente varios artículos que encontré me hicieron dar cuenta de que no estaba muy errado con lo que pensaba y con lo que mi instinto me decía.

Básicamente trabajar por objetivos crea cierta competencia, la cual es mala entre las personas que estando en una misma organización deberían colaborar juntas en beneficio de ésta. Además, muchas de estas puntuaciones se dan por azar. Las evaluaciones son una forma de “dirigir” sin mirar a las personas, sin conocerlas y sin estar en el día a día de su trabajo, lo que permite gestionar desde el desconocimiento.

Les dejo once razones para dejar de gerenciar por objetivos:
1.- No se puede conocer el verdadero rendimiento de los empleados por la puntuación obtenida por ningún método, el azar y el sistema organizativo tienen una influencia del 95%.

2.- Destruye la colaboración entre los empleados, departamentos y unidades creando una competencia dañina.

3.-Denigra la función del directivo, reduciéndola a mero administrativo o juez que premia o castiga con puntuaciones que le son ajenas y normalmente sometidas a reglas y porcentajes que le son impuestos.

4.- No es el objetivo lo que ayuda a mejorar, sino el método. ¿Con qué nuevo método vamos a obtener mejores resultados?


5.- Produce desmoralización entre las personas.

6.- Favorecee hacer trampas y el engaño para conseguir la mejor puntuación.


7.- Está basado en el falso supuesto de que la mayoría de personas solo se esfuerzan por premios y castigos.


8.- Saber poner objetivos departamentales entre los que no exista alguna forma de incompatibilidad es, en la mayoría de los casos, imposible sin el conocimiento sistémico adecuado. Ya sea en el corto o en el largo plazo, el despliegue de los objetivos de una organización conduce a objetivos incompatibles.


9.- La consecución de resultados óptimos en un proceso puede perjudicar al conjunto de la empresa. A lo anterior cabría añadir que según Alfie Kohn en “Punished by Rewards” los incentivos económicos, en la mayoría de las sociedades de hoy, solo tienen utilidad en 3 casos: a) En tareas repetitivas
b) Cuando la cantidad es más importante que la calidad

c) En resultados a corto plazo

10.-Los costes de evaluación los ahorraremos ya que son costes de ineficiencia de directivos y gestión administrativa de las evaluaciones, así como medios informáticos.


11.- Muchos de los aspectos más importantes de una empresa son inmedibles.

La solución es el liderazgo, la dirección en el día a día, el conocer a los empleados, hablar con ellos con frecuencia, entenderlos y saber cómo hacen las cosas, en ayudarles a mejorar y evitar errores mejorando continuadamente el sistema.


Fuente: La ciencia del Management según las ideas de W. Edwards Deming

lunes, junio 13, 2011

Joel on Software

Joel on Software es un libro que compila varios artículos del blog de Joel Spolsky (no dejen de suscribirse). El subtitulo del libro es: "...And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity".

Joel es un desarrollador que comenzó trabajando en Microsoft, luego paso por varias empresas y finalmente fundó Fog Creek Software, su propia compañía. Desde 1999 nos relata su experiencia en el mundo del desarrollo de software, abarcando todos los aspectos conocidos.

Sus puntos de vista y comentarios son muy interesantes. Ver como crece el y su compañía, como aprende del . Además, Joel es un muy buen escritor y todos sus artículos son muy entretenidos. Altamente recomendado!

martes, mayo 31, 2011

Evaluación de conocimientos de Scrum en scrum.org

Les recomiendo a todos que evalúen sus conocimientos de Scrum en scrum.org. Hay un test gratuito de 30 preguntas muy interesantes, que se sugieren hacer en 60 minutos pero se pueden terminar en mucho menos, yo lo hice en 10' y me saque un 75% :).

También hay links a recursos para capacitarse y finalmente tests pagos para certificarse oficialmente. Voy a explorar un poco mas para ver si valen la pena.

Take the Scrum Open Assessment!

sábado, abril 30, 2011

Lean Software Development: An Agile Toolkit

Lean Software Development: An Agile Toolkit, de Mary y Tom Poppendieck cuenta como adaptar y luego aplicar los principios "lean" utilizados por las industrias clásicas en el desarrollo de software, concentrándose en la aplicación de metodologías ágiles.

Las ideas "lean" iniciadas por Toyota son totalmente compatibles con el desarrollo de software ágil. Pensar aplicar principios de la industria al software nos remite a metodologías clásicas orientadas a un plan (tipo PMI), pero esto es porque estamos copiando las ideas de la linea de montaje de Taylor en Ford. La industria avanzo muchísimo en todo este tiempo y hay que aprovechar esto.

Estos son los siete principios "lean":
  1. Eliminate Waste: Whatever gets in the way of rapidly satisfying a customer need is waste.
  2. Amplify learning: Chefs are not expected to get a recipe perfect on the first attempt; they are expected to produce several variations on a theme as part of the learning process.
  3. Decide as late as possible: Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation.
  4. Deliver as fast as possible: Compressing the value stream as much as possible is a fundamental lean strategy for eliminating waste.
  5. Empower the team: Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work.
  6. Build integrity in: Research has shown that integrity comes from wise leadership, relevant expertise, effective communication, and healthy discipline; processes, procedures, and measurements are not adequate substitutes.
  7. See the whole: When individuals or organizations are measured on their specialized contribution rather than overall performance, suboptimization is likely to result.
Los conceptos de este libro son muy interesantes y me dieron otro punto de vista del desarrollo ágil. Lamentablemente el libro no esta muy bien escrito, no es para nada ameno y cuesta leerlo. Tengo que buscar otro libro del tema escrito por otros autores, aunque Mary y Tom Poppendieck son muy conocidos y respetados en el ambiente.

martes, abril 26, 2011

Managers Vs. Líderes

Les dejo una comparación entre managers y líderes de John Kotter del libro "What Leaders Really Do" :


Realmente no hay mucho que agregar a este cuadro. La comparación es muy clara y la descripción de los lideres esta alineada a los principios ágiles del desarrollo de software. Sin dudarlo se obtienen muchos mejores resultados liderando un proyecto que administrandolo o gerenciandolo. Esto no quiero decir que no hay que tener en cuenta las tareas de un manager, pero hay que enfocarse en liderar. Cierro con esta frase del mismo autor:

"No one has yet figured out how to manage people effectively into battle; they must be led"

domingo, marzo 20, 2011

Scrum and XP from the Trenches

"Scrum and XP from the Trenches: How we do scrum, an Agile War story", es un libro (que inicialmente fue un ensayo) de Henrik Kniberg que describe como aplico el autor el framework de Scrum en su trabajo.

La mayoría de los libros que uno lee sobre metodologías, procesos o frameworks son teóricos. Es enriquecedor leer teoría, pero luego cuando uno quiere aplicarla al día a día se da cuenta que falta bastante conocimiento para hacerlo. Esto me paso cuando quise aplicar Scrum inicialmente con solo conocimientos teóricos, estuve muy lejos de hacerlo bien. Por suerte con la ayuda de un coach, que me indico que puntos tenía que mejorar, tuve éxito. Solo con teoría es imposible, ya que uno se olvida
o no le presta la atención a ciertas cosas que son vitales.

Si uno no tiene la suerte de tener un coach o alguien que pueda guiar en la implementación de scrum, este libro les va a resolver el problema. Henrik no se preocupa en explicar mucho sobre teoría, ya que aunque repasa los conceptos brevemente, recomienda que lean un libro sobre teoría antes de comenzar con su libro.

El libro está dividido en todas las ceremonias y artefactos de scrum, y como él los desarrollo, como tuvo éxito con todo el framework. Baja la teoría a la práctica, y eso es muy valioso. Lo recomiendo sin dudarlo. Bajalo aquí, la edición en PDF es gratuita!

jueves, febrero 10, 2011

Spikes en Scrum

Un Spike en Scrum es una tarea de investigación que se compromete en un Sprint. Es una manera excepcional de trabajar cuando sentimos que no tenemos suficiente información para darle al cliente una expectativa realista de lo que hay que hacer. El objetivo del Spike es averiguar esa información para poder bajar a tierra esas expectativas y poder realizar una estimación adecuada a la cual el equipo se pueda comprometer en la siguiente reunión de planeamiento del próximo Sprint. El resultado de la tarea es un documento con la información obtenida en la investigación.

Los Spikes son una muy buena opción para que los equipos verifiquen cosas que no conocen y necesitan conocer para entender la complejidad de cierta funcionalidad para que pueda ser estimada apropiadamente o para simplemente averiguar si algo es técnicamente posible o no.

Los Spikes también son llamados Tracer Bullets (balas trazadoras), ya que te indican una dirección a donde apuntar o a donde ir. La única diferencia entre estos conceptos es que los Spikes tienen una duración preestablecida (time-boxed) y no se trabaja teniendo en cuenta que el resultado va a ser utilizado en el proyecto directamente, mientras que los Tracer Bullets no tienen límite de tiempo y su resultado va a ser utilizado.


Una utilización de los Spikes que apliqué hace poco, es en una relación de dependencia técnica con el cliente. Nosotros teníamos que desarrollar cierta funcionalidad, el front-end de una página web, teniendo en cuenta APIs del cliente. La experiencia siempre nos indicó que esas APIs estaban incompletas, su documentación no era suficiente o que no cumplían el propósito para lo que se las iba a utilizar. Para dejar de errar en las estimaciones de estas funcionalidades dependientes, utilizábamos Spikes para explorar a fondo estas APIs, mejorar su documentación, pedir que las modifiquen para adaptarse a lo que íbamos a construir, y dejar un documento completo para que en el siguiente Sprint puedan ser estimadas y posteriormente desarrolladas correctamente.

martes, febrero 08, 2011

Agile Game Development with Scrum

Agile Game Development with Scrum de Clinton Keith se basa en la aplicación de metodologías ágiles: Scrum (principalmente), Lean y Kanban en la industria del desarrollo de videojuegos.

Básicamente este tipo de proyectos tiene cuatro fases definidas: concepto, pre-producción, producción y post-
producción o cierre. Sin utilizar metodologías ágiles, estos proyectos sufren muchos problemas.

Por ejemplo, se gasta mucha plata para tener un prototipo jugable y darse cuenta si el proyecto vale la pena o no. Aplicando Scrum, es posible tener entregas parciales jugables que nos dan una idea temprana de a donde se dirige el juego y si vale la pena continuar el proyecto (cuanto antes nos enteremos de esto, mucho mejor).

Luego es muy común que en las etapas de producción se descubra que ciertos conceptos que no se cerraron en pre-producción, temas no terminados o evaluados al 100%, causen mucho retrabajo y la necesidad de cortar ciertas partes del juego por temas de presupuesto. Lo que se logra con esto es que se termine lanzando al mercado un producto pobre. Si se hubiese explorado un concepto a fondo, sin dejar deudas a futuro, como se sugiere en las metodologías ágiles, se podría haber lanzado un producto mucho mas fuerte. Un ejemplo hipotético: para un juego en pre-producción se estableció que el personaje principal puede saltar 10 metros. Sin probar esto, se empezaron a producir los niveles del juego teniendo esto en cuenta. Cuando un productor juego la primera versión del juego (tarde si no se trabaja ágilmente) y vio que este largo era ridículo, se habían creado un montón de niveles teniendo esto en cuenta y el retrabajo va a ser muy costoso. Otro ejemplo puede ser trabajar teniendo en cuenta que las paredes pueden romperse, para luego descubrir que la tecnología actual no soporta eso. Desastroso en ambos casos.

Otro error al dejar deudas a futuro son las interminables "death marches" en el cierre de un juego, donde se hace mucho overtime para cerrar defectos que son mucho mas costosos de cerrar al final del proyecto que si se resolviesen durante la iteración donde son creados. Las metodologías ágiles sugieren terminar lo que se comienza a desarrollar y no dejar los defectos a futuro. Se suelen dejar defectos para un último sprint de estabilización y polishing, siempre que el riesgo de retrabajo sea mínimo.

Muy buen libro para reforzar los conocimientos de Scrum y enterarse bien como se desarrolla un típico proyecto de desarrollo de videojuegos, y como se puede mejorar utilizando metodologías ágiles.