mai 2010Monthly :

Scrum and Agile Built Into Microsoft Team Foundation Server

In Answering some common questions about Urban Turtle we answer some questions and present some of the orientations we took in designing Urban Turtle.

One of the main orientation is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

We believe this orientation is what allows us to have a product that installs on the server in less than two-minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon ;)

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

In the release that we have for you this week (June 2nd), we deliver a bunch of enhancements including a productive way to use Areas. The upcoming release will most likely focus on a feature we call Perspective that will allow you to work seamlessly in Urban Turtle on a subset of work items making it a charm to do multi-teams and grouping projects together. We will also focus on enhancing user experience in a couple of key places.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

Pre-release of GreenPepper for C++ is available!

We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis.

So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework.

Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google.

Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages ;-) )

Want to see what a fixture source code looks like? Below a C++ header file sample :

CalculatorFixture.h

using namespace greenpepper;

using namespace type;

CLASS_FIXTURE_BEGIN(CalculatorFixture)

public:

CalculatorFixture(void);

IntegerType a;

IntegerType b;

void setA(IntegerType a);

void setB(IntegerType b);

IntegerType getA();

IntegerType getB();

IntegerType sum();

REGISTER_METHODS_BEGIN()

REGISTER_PROCEDURE_1(setA, IntegerType)

REGISTER_PROCEDURE_1(setB, IntegerType)

REGISTER_METHOD_0(getA, IntegerType)

REGISTER_METHOD_0(getB, IntegerType)

REGISTER_METHOD_0(sum, IntegerType)

REGISTER_METHODS_END()

CLASS_FIXTURE_END(CalculatorFixture)

If you want to start using executable specifications within you C++ projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here.

Kind regards.

Why DCI is the right architecture for right now

InfoQ runs a very interesting video of Jim Coplien about Data-Context Interaction.

“Uncle bob completly misses the point by assuming that professionalism is about doing TDD”.

“Dynamic languages got popular for the wrong reasons

“people get religious about details that don’t matter, and very very few people are talking about the big picture”

“scrum is all about common sense, but common sense is really uncommon”

“teams are effective, and to be effective they have to be small. 3 is better than 5″

Product vision and Strategic Design

When I coach Scrum teams, I usually spend a significant amount of time working with the Product Owner to teach her how to create an effective product vision, one that will act as a guiding light for the Scrum team and stakeholders.

I don’t want to delve into the details of product envisioning activities. I usually use a number of workshops and techniques to produce some (or all) of the following artifacts:

  • Elevator statement
  • Product box
  • Business goals
  • User goals
  • Value drivers
  • Key attributes and capabilities
  • Risk assessments
  • etc.

What I’m interested in talking about is the activity of defining the product quality attributes and how strategic design (in the Domain Driven Design sense) fits in. Thinking about the quality attributes is key to defining “done”. Product quality attributes give meaning to the product being potentially shippable.

Among the quality attributes, some will pertain to the external quality of the product, like usability, securability or availability for instance. Others will focus on the internal quality. This is the case of maintainability, modularity, evolvability, etc.

Yesterday, I was out for beers with my colleague Ernst Perpignand and Greg Young. Greg was in Montreal to give his Domain Driven course and we (at Pyxis) sponsored the event by hosting the course in our Laval office. Of course during the evening we talked about CQRS, Event Sourcing, write and read models and all the stuff Greg likes to talk about. Needless to say I had a great time.

Those discussions made me realize how important it is to communicate that context maps are strategic outputs of the product vision activities. There are good reasons why Eric Evans talks about strategic design when he discusses bounded contexts and distillation. He refers to the conceptual core of the system as the “vision” of the system. It is indeed the guiding vision for internal quality attributes of the product. Determining our own bounded context and its relationships to others is both a political and business decision. We need to understand where the potential for ROI lies to design and architecture in consequence.

Un coach agile dans les pièces automobiles – Sprint 1 planning

Le premier sprint n’aura pas sa pleine capacité puisque des membres doivent terminer des assignations sur d’autres projets ou seront absents. Malgré ceci, la capacité du sprint n’est pas trop handicapée, principalement parce que le sprint comporte 2 jours calendrier de plus. L’équipe a choisi ainsi pour que les sprints débutent le lundi et se terminent le vendredi. Comme l’équipe n’a pas rédigé beaucoup de stories, elle prend presque toutes celles rédigées durant le sprint 0 pour le sprint 1, et y ajoute 2 spike. Même si théoriquement la sommes des heures estimées peut être fait durant le sprint 1, l’équipe n’est pas confiante de pouvoir tout réaliser les stories correspondantes. Finalement, peut-être que les estimations n’étaient pas aussi bonne qu’elles en avaient l’air… Alors l’équipe laisse une story de côté. Il l’amorceront s’ils ont assez de temps.

La pression est beaucoup sur le PO qui devra rédiger beaucoup de stories pour remplir le backlog, sinon le sprint 2 sera mince.

Pour la deuxième partie du planning, l’équipe discute de détails plus technique dont la mise en place des environnements nécessaires. L’équipe sent qu’elle a assez d’information pour débuter, alors on applique de façon collective la loi des 2 pieds!

L’équipe semble déjà prendre des bons plis. Au diner, il y avait 3 membres de l’équipe, le ScrumMaster et moi. Le bureau du ScrumMaster est physiquement dans un autre édifice que le reste de l’équipe, alors les membres de l’équipe ont lancé au ScrumMaster “Pourquoi tu ne demandes pas que ton bureau soit amené avec nous?” J’aime ca!

Pyxis Technologies a gagné un MercadOr dans la catégorie « pratiques novatrices en ressources humaines » !

Jeudi soir, nous avons été récompensés pour nos pratiques innovantes en ressources humaines par Laval Technopole. C’est la reconnaissance de pratiques différentes, de notre groupe de ‘coaches internes’ à la mise en place d’une coopérative de travailleurs actionnaire, en passant par une organisation du travail souple et basée sur la responsabilité individuelle et l’engagement. Tout en maintenant un climat de travail en accord avec notre raison d’être : “Pyxis aide les organisations de développement logiciel à devenir des endroits où les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de ce qu’elle propose à ses clients et en accompagnant ceux-ci.”

Lire l’article du Courriel Laval sur l’événement.

Imposterizing checked exceptions

I have been frustrated many times by some of Java’s checked exceptions. I’m sure you can recall some of your own experiences where you wished a CheckedException was a RuntimeException instead.

Let me share a useful exception idiom that I’ve been using for a long time and on lots of projects, which I call the ExceptionImposter.

We all know the Java standard libraries use checked exceptions to signal problems that can only occur at runtime either if we have screwed up or if something really bad has happened – something we cannot do anything about anyway. Personally, since I use Java reflection capabilities a lot, I have to deal with the InstantiationException and the IllegalAccessException too often for my taste.

For example, whenever I want to dynamically instanciate a class, even if I know the code should never fail, the underlying Java code throws a checked exception and I end up with code that looks like this:

 ... try { return WebDriverFactory.class.cast(webDriverFactoryClass.newInstance()); } catch (Exception shouldNeverOccur) { // now what? } ... 

If I know that the webDriverFactoryClass has a public no-arg constructor that does nothing, the code cannot fail. If it fails, it could be that something is wrong with my environment or that I made an error while programming the class. That’s something I will catch during my development cycle but that I don’t expect to occur afterwards. I cannot just ignore the exception, because if something really went wrong, the application will not behave correctly and I will have a hard time diagnosing the failure and finding the source of the error.

I know I must throw another exception and I want that exception to be a runtime exception because there’s nothing useful the calling code can do about the error. I can wrap the exception into some generic RuntimeException but that’s not very satisfying. It will not help me find the error and it will add another level of nesting and make the stack trace harder to read. I find we already have too many levels of nested exceptions which make framework exceptions very hard to read.

I could also write my own wrapper to rethrow a checked exception. It think it would be slightly better, since I can now name the error, but what still annoys me is that other level of nesting and the longer stack trace.

Instead, I use the ExceptionImposter to mimic the checked exception and turn it into a runtime exception:

 ... try { return WebDriverFactory.class.cast(webDriverFactoryClass.newInstance()); } catch (Exception shouldNeverOccur) { ExceptionImposter.imposterize(shouldNeverOccur); } ... 

Here’s how it works:

 public class ExceptionImposter extends RuntimeException { private final Exception imposterized; public static RuntimeException imposterize(Exception e) { if (e instanceof RuntimeException) return (RuntimeException) e; return new ExceptionImposter(e); } public ExceptionImposter(Exception e) { super(e.getMessage(), e.getCause()); imposterized = e; setStackTrace(e.getStackTrace()); } public Exception getRealException() { return imposterized; } public String toString() { return imposterized.toString(); } } 

As you can see from the following test case, the ExceptionImposter looks like the real exception as much as possible:

 public class ExceptionImposterTest { private Exception realException; @Test public void leavesUncheckedExceptionsUnchanged() { realException = new RuntimeException(); assertSame(realException, ExceptionImposter.imposterize(realException)); } @Test public void imposterizesCheckedExceptionsAndKeepsAReference() { realException = new Exception(); RuntimeException imposter = ExceptionImposter.imposterize(realException); assertTrue(imposter instanceof ExceptionImposter); assertSame(realException, ((ExceptionImposter) imposter).getRealException()); } @Test public void mimicsImposterizedExceptionToStringOutput() { realException = new Exception("Detail message"); RuntimeException imposter = ExceptionImposter.imposterize(realException); assertEquals(realException.toString(), imposter.toString()); } @Test public void copiesImposterizedExceptionStackTrace() { realException = new Exception("Detail message"); realException.fillInStackTrace(); RuntimeException imposter = ExceptionImposter.imposterize(realException); assertArrayEquals(realException.getStackTrace(), imposter.getStackTrace()); } @Test public void mimicsImposterizedExceptionStackTraceOutput() { realException = new Exception("Detail message"); realException.fillInStackTrace(); RuntimeException imposter = ExceptionImposter.imposterize(realException); assertEquals(stackTraceOf(realException), stackTraceOf(imposter)); } private String stackTraceOf(Exception exception) { StringWriter capture = new StringWriter(); exception.printStackTrace(new PrintWriter(capture)); capture.flush(); return capture.toString(); } } 

Backlog strategy question…

Situation :

You have one project with 100 developers organized in Scrum of Scrum.

Question :

Do you go with one Product Backlog or multiple Product Backlogs or something in between?

Share/Bookmark

Next Release – Final Sprint with Finish Line on June 2nd

In Urban Turtle’s Next Destination we listed the features that the team intended to produce for the first sprint of the release scheduled for June 2nd. I am as very happy product owner because the team delivered everything that was intended for the sprint and we have more killer features in the next and final sprint of this release.

The main feature is the integration of areas in the planning board. We were not pleased with the way we had develop this feature in our TFS 2008 version. We think we have a better design that will please all users. We are eager to release it on June 2nd to have your feedback.

As always, feedback is greatly appreciated as comments here or on the forum.