Loading ...
Sorry, an error occurred while loading the content.

Seven habits of highly successful customers

Expand Messages
  • Desilets, Alain
    My previous post got me thinking about this... It strikes me that a lot of the discussion in this forum has been process oriented. We talk a lot about whether
    Message 1 of 3 , Aug 16, 2005
    • 0 Attachment
      My previous post got me thinking about this...

      It strikes me that a lot of the discussion in this forum has been process oriented. We talk a lot about whether U* design should be done completely upfront or throughout the development phase, how much interaction there should be between U* experts and developpers, who should "own" the UI, etc...

      Those are important issues, but one of the thing I like most about XP in particular, is that it is not about process, but more about a small set of REALLY USEFUL practices for developpers. Sort of the "12 habits of highly successful development teams". Applying even one of those practices (TestDrivenDevelopment for example) already boosts your productivity tremendously, and when you practice more than one, their effects seem to compound each other. Moreover, each of them provides immediate and visible benefit, so they quickly become addictive. When I make a change to the code and break a test that I wrote 10 minutes ago, I know that writing that test paid for itself already. When I refactor a 2 page long method into 5 smaller methods and find that I now understand what it does and can more easily do the change I need to make to it, I immediatly feel the benefit of that refactoring. When I integrate my changes with the CVS version, I feel satisfaction at having delivered working code to the rest of my fellow developpers. I feel this kind of immediate gratification several times a day.

      So here is my question to you U* folks. If you were to define a small (say less than 12) set of U* practices with similar properties (individually useful, provide immediate and visible benefit), what would those be?

      For those of you who do not know the XP practices, see this page:

      http://www.extremeprogramming.org/rules.html


      Hum... It seems the number of practices has gone up from 12 to 28 since the last time I looked at them ;-). But on closer inspection, the additional practices are small practices that used to be part of a bigger ones (for example, Test-driven development seems to have been split into a number of smaller practices).

      ----
      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada
    • Adrian Howard
      On 16 Aug 2005, at 15:43, Desilets, Alain wrote: [snip] ... [snip] /Good/ question :-) My little list of guidelines includes: * The UI is code Don t treat the
      Message 2 of 3 , Aug 16, 2005
      • 0 Attachment
        On 16 Aug 2005, at 15:43, Desilets, Alain wrote:
        [snip]
        > So here is my question to you U* folks. If you were to define a
        > small (say less than 12) set of U* practices with similar
        > properties (individually useful, provide immediate and visible
        > benefit), what would those be?
        [snip]

        /Good/ question :-)

        My little list of guidelines includes:

        * The UI is code

        Don't treat the UI as separate from the code base. Having a good
        clean simple UI is /just as important/ as having good clean code. Get
        this across to the development team and most of your job is done.

        * UI concepts should be reflected in the code

        If your UI has a whole bunch of Wibble Buttons that look and behave
        in the same way then there should be a WibbleButton abstraction in
        the code somewhere.

        * UI concepts should be reflected in the tests

        You can't automate usability testing. You can automate some aspects
        of it. Do so.

        * Use persona

        For those who've not come across them - little written sketches of
        the expected users' personalities. Have them pinned up in the team
        room. Encourage everybody to ask themselves "What would X do?" in any
        given situation. For more info see <http://www.evolt.org/article/
        Practical_Persona_Creation/4090/56111/>.

        * Code the UI first

        Draft out the UI before you write the code. This does /not/ mean
        design the entire UI of the application before you write the
        application. I like doing it at the planning game stage: when the
        stories are created or when the acceptance tests are being done.
        Incrementally as the project progresses.

        It also does not mean a glorious piece of Photoshop work that you
        want to hang on the wall. Think Agile Modeling. Think paper
        prototypes. Think sketches on the back of index cards. Simple HTML
        pages. Just enough to get the job done.

        * User advocate to the customer

        There should be at least one person in the Customer role who
        understands UI issues and can help shape the stories so they will
        meet user expectations.

        * User advocate to the developer

        There should be at least one person in the Developer role who
        understands UI issues and can help shape the code so it will meet
        user expectations.

        * Coding standards (extended XP practice, consequence of "UI is code")

        Some sort of UI standards should form part of the coding standards.
        Remember you don't have to define all your coding standards up front
        before the project starts. It's a living document that should reflect
        your learning as the project progresses. This applies much more to
        the HIG since they tend to be more project specific and will change
        as the team understands more about the project.

        Also, be sure to create UI standards that people can actually /use/.
        See <http://www.humanfactors.com/downloads/aug04.asp> for some tips.
        Eight pages of single typed 8pt text bad. Pictures good. Big post-it
        notes stuck on the wall - fantastic.

        * Refactor mercilessly (extended XP practice, consequence of "UI is
        code")

        You should treat inelegant UIs as harshly as you treat inelegant code.

        * Collective code ownership (extended XP practice, concequence of "UI
        is code")

        Everybody owns the UI. It's everybody's responsibility to fix
        problems with the UI.

        * The customer is always available (existing XP practice)

        Getting the programmers to guess about customer decisions affects the
        UI just as badly as it does the code.

        * Frequent small releases (existing XP practice)

        Log gaps between feedback from real users affects the UI just as
        badly than the code.

        * User stories are written (existing XP practice)

        Stories are much more user-centric than some more traditional
        requirements gathering processes, and help everybody create a better UI.

        * Pair programming (existing XP practice)

        Spreading the knowledge about the UI is just as important as
        spreading the knowledge about the code.

        * Create spike solutions to reduce risk (existing XP practice)

        Not sure which UI choice will work best? Throw together a prototype
        and try it on some people.

        ----

        Any more for any more?

        Cheers,

        Adrian
      • Desilets, Alain
        -- Alain Désilets wrote: Adrian, I like those guidelines, but many of them seem very code and developper centric. I was thinking more about practices that
        Message 3 of 3 , Aug 17, 2005
        • 0 Attachment
          -- Alain Désilets wrote:
          Adrian,

          I like those guidelines, but many of them seem very code and developper centric.

          I was thinking more about practices that someone acting in a customer role (either as the sole customer or as part of a customer team) can use to make sure that they guide the project properly.
          ----

          On 16 Aug 2005, at 15:43, Desilets, Alain wrote:
          [snip]
          > So here is my question to you U* folks. If you were to define a
          > small (say less than 12) set of U* practices with similar
          > properties (individually useful, provide immediate and visible
          > benefit), what would those be?
          [snip]

          /Good/ question :-)

          My little list of guidelines includes:

          * The UI is code

          Don't treat the UI as separate from the code base. Having a good
          clean simple UI is /just as important/ as having good clean code. Get
          this across to the development team and most of your job is done.

          * UI concepts should be reflected in the code

          If your UI has a whole bunch of Wibble Buttons that look and behave
          in the same way then there should be a WibbleButton abstraction in
          the code somewhere.

          * UI concepts should be reflected in the tests

          You can't automate usability testing. You can automate some aspects
          of it. Do so.

          * Use persona

          For those who've not come across them - little written sketches of
          the expected users' personalities. Have them pinned up in the team
          room. Encourage everybody to ask themselves "What would X do?" in any
          given situation. For more info see <http://www.evolt.org/article/
          Practical_Persona_Creation/4090/56111/>.

          * Code the UI first

          Draft out the UI before you write the code. This does /not/ mean
          design the entire UI of the application before you write the
          application. I like doing it at the planning game stage: when the
          stories are created or when the acceptance tests are being done.
          Incrementally as the project progresses.

          It also does not mean a glorious piece of Photoshop work that you
          want to hang on the wall. Think Agile Modeling. Think paper
          prototypes. Think sketches on the back of index cards. Simple HTML
          pages. Just enough to get the job done.

          * User advocate to the customer

          There should be at least one person in the Customer role who
          understands UI issues and can help shape the stories so they will
          meet user expectations.

          * User advocate to the developer

          There should be at least one person in the Developer role who
          understands UI issues and can help shape the code so it will meet
          user expectations.

          * Coding standards (extended XP practice, consequence of "UI is code")

          Some sort of UI standards should form part of the coding standards.
          Remember you don't have to define all your coding standards up front
          before the project starts. It's a living document that should reflect
          your learning as the project progresses. This applies much more to
          the HIG since they tend to be more project specific and will change
          as the team understands more about the project.

          Also, be sure to create UI standards that people can actually /use/.
          See <http://www.humanfactors.com/downloads/aug04.asp> for some tips.
          Eight pages of single typed 8pt text bad. Pictures good. Big post-it
          notes stuck on the wall - fantastic.

          * Refactor mercilessly (extended XP practice, consequence of "UI is
          code")

          You should treat inelegant UIs as harshly as you treat inelegant code.

          * Collective code ownership (extended XP practice, concequence of "UI
          is code")

          Everybody owns the UI. It's everybody's responsibility to fix
          problems with the UI.

          * The customer is always available (existing XP practice)

          Getting the programmers to guess about customer decisions affects the
          UI just as badly as it does the code.

          * Frequent small releases (existing XP practice)

          Log gaps between feedback from real users affects the UI just as
          badly than the code.

          * User stories are written (existing XP practice)

          Stories are much more user-centric than some more traditional
          requirements gathering processes, and help everybody create a better UI.

          * Pair programming (existing XP practice)

          Spreading the knowledge about the UI is just as important as
          spreading the knowledge about the code.

          * Create spike solutions to reduce risk (existing XP practice)

          Not sure which UI choice will work best? Throw together a prototype
          and try it on some people.

          ----

          Any more for any more?

          Cheers,

          Adrian





          Yahoo! Groups Links
        Your message has been successfully submitted and would be delivered to recipients shortly.