Louis-Philippe Carignan

Alan Cooper a donné une présentation à la fin de la conférence Agile intitulée "The Wisdon of Experience".  Il ne parlait pas d'expérience en termes d'ancienneté.  Plutôt, il parlait de "user experience" où comment fabrique-t-on nos logiciels pour que l'expérience entre ces derniers et l'utilisateur soit agréable.  Très intéressant à regarder et à lire les notes à droite pendant que les images défilent.

Cooper a lu son texte comparativement aux deux autres présentateurs.  Il explique pourquoi ici.

Depuis 3 ans, VersionOne publie un sondage qui donne un aperçu des méthodologies Agile utilisées dans l'industrie.

Je trouve que le sondage de cette année est 100 fois meilleur que l'année précédente.  Entre autre, on y retrouve des questions suivantes:

• What are/were the organization's greatest concerns regarding the adoption of Agile development?
• What are the barriers to further adoption of Agile in your current organization?
• Which of the following do you employ within your Agile methods? (différence entre 2007 et 2008)
• What do you think was the leading cause of failed (unsuccessful) Agile projects?
  

How do you remember the Agile Manifesto?

I Party with Rowdy Criminals 2 C Exciting Fights

= IPWRCCCEF

= Individuals and interactions over Processes and tools; Working software over Comprehensive documentation; Customer collaboration over Contract negotiation; Embracing change over Following a plan.

Good post on Jeff Sutherland blog about the purpose of time sheets.

To sum it up:

• They demotivate developers
• 10-15% loss of productivity is the minimum
• Developers have to fake the time to fill them out properly
• Erroneous data is used for reporting and management makes bad decisions
• Customers are deceived
• They have nothing to do with quality code production
• They focus the whole organization on phony data instead of production 

This seems like the buzzword at the Agile conference this year.  I've heard it many many times throughout the conference.  We can put any word at the end of this buzzword, honest:

• High-performance teams
• High-performance organizations
• High-performance processes
• High-performance servers
• High-performance <insert your word here>
  

With words like these, I guess the gap between Agilists and business people is finally closing!

Speaking about business, there was an excellent session about the gap between Agile and upper management: What Are They Doing - What a CIO Wants To Know From An Agile Development Team.  I strongly suggest looking at the presentation (included in the link) and if you're an engineer, focus on the slide of being helpful rather than right!

Code or code not

There is no try 

We use Sandcastle and Sandcastle Help File Builder (SHFB) to generate the SDK of our project.  It's really neat but I always wondered if SHFB could do more.  It's GUI has some plugins and properties that I never really explored.  Dunno why.  Never took the time until last Friday afternoon.

I finally convinced myself that I should click on some of those unknown features.  How come it took me so long to do this?  SHFB supports MAML, Microsoft new online help technology.  In a nutshell, MAML separates the content from the presentation.  Technology wise, it means you write conceptual topics in an XML format based on a schema.  Then, XSLT is applied to your XML document with the help of the Sandcastle engine.  The result is a very nicely formatted Html document.  Pretty nice hey!

What is a conceptual topic?  Well, it can be a glossary, a whitepaper, a how to, a walktrough, etc.  Each topic has its own schema.  The neat thing with SHFB is that you can edit your topic and preview it on the fly.  Personally, the glossary and walk trough topics are my favourites.  SHFB then assembles those topics together and produces a .chm file with all of them.  This .chm file can then be called from your application with a help provider.

DocProject does the same thing as SHFB but it embeds itself in VS .NET.  I tried it out but it wasn't intuitive.  I was lost and didn't know how to produce a conceptual topic on the fly.  Thank God DocProject has good documentation on how to get you started.  But I was still lost with all those folders created for me in my project.  It made me feel like in Visual Studio 6 where all this code was created and I had no idea what it did.  And to create your .chm file with DocProject, you have to compile your project.  Which is a bit weird if you ask me.  And you can't preview it like SHFB.  But with all this bitching, I still have to raise my hat to Dave Sexton for managing this project.

Overall, if you are looking for a tool to leverage your documentation, and I'm not talking about the SDK, check out Sandcastle Help Filder Builder, its definitely worth the time.

Oh, and be sure to download the Sandcastle Styles.  They are need to have the latest styles when generating conceptual topics.
 

That's a very good question if you ask me?  Well, Mary Poppendieck brought some very good points about this at a session during the Agile 2008 conference.

She looked at her bookshelf and browse her old software books to understand what we've been doing in software engineering for the past 40 years.  Interestingly enough, some things that used to be popular (and are coming back) used to exist in the 60s and 70s.  For example:

• Continuous Integration
• Designed-in Quality
  
• Refactoring
• Information Hiding
• Respect for Complexity
• Skilled Technical Leaders
• Learnings Cycles
  
• No seperation of design from implementation
  

These techniques are no silver bullets but they seem to have stood the test of time.  Could these techniques be defining software engineering after all those years?

You can get Mary's presentation on her website.

I attented the Agile 2007 conference.  Their were 4 sessions about Lean:

1. Introduction to Lean Software Development
2. Lean and Agile in the Large
3. The Business Case for Agility - The Lean-Agile Connection
4. Lean Is More - Using Lean Software Developement to Guide Agile Transitions
   

At the Agile 2008 conference in Toronto, this number double to 8:

1. Agile Game Development
2. Value Stream Mapping - Extending Our View in the Enterprise
   
3. Come and Take It!  Lean Pull Applied
4. GTD + Kanban + Round Robin for Product Owners
5. Future Directions for Agile
6. KFC Development - Finger Lickin' Good
7. Estimating Considered Wasteful : Introducing Micro-Releases
8. Starting a Kanban System for a Software Engineering with Value Stream Maps and Theory of Constraints
   

I'm really glad to see more experience reports about Lean, especially the pull system as I think this is just revolutionary.  After presenting Lean to lots of people in my company, the main feeling was that this stuff was pretty neat but nobody knew how to set it up.  Well, people have figured it out and, hopefully, we can learn from their experience.

Les tests unitaires sont très populaires auprès de la communauté Agile mais qu'en est-il des tests d'acceptation?  Ces tests semblent encore flous pour la communauté.  Les outils existants (Fit, Fitnesse, Selenium) ne semblent pas répondre aux besoins de tous.

Quelques membres du groupe Patterns & Practices de Microsoft préparent un livre sur le sujet pour tenter de jeter les bases d'une définition claire des tests d'acceptation.  On peut suivre leur progrès sur le site http://www.codeplex.com/TestingGuidance.

J'aime leur idée de définir ce qu'est les tests d'acceptation et comment s'en servir pour savoir si on peut livrer le produit au client.  Les auteurs proposent un modèle qui, à mon avis, fonctionne dans presque tous les cas.  Au bas complètement de la page d'accueil, il y a un sondage pour connaître votre définition des tests d'acceptation. 

Reputation Institute in New York, USA list the most respected companies each year.  Global results for 2008 are in.  Guess who finishes first...

http://www.reputationinstitute.com/knowledge-center/hall-of-fame#global_winners

Forbes has a slideshow of the top 10 companies. 

I found this API to access Bugzilla through C#.  It goes through XML-RPC .Net to access the web services of Bugzilla.  While the web service is pretty limited (and experimental), it still gives you the ability to fetch the list of closed and opened bugs for a release (or iteration or milestone).  You'll have to dig a little bit to find all the information you need about a bug (look at data member internals in BugInfo).

Imagine pluging this in your continuous integration.  It could generate your list of bugs automatically without changing any reports in Bugzilla.  One more thing you can automate!