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

XP for third party component vendor

Expand Messages
  • escamoteur_burkhart
    Hi, Im very exited about XP and just read the second Edition of XP explained cover to cover. On topic wasn t touched that would be importand for our company.
    Message 1 of 4 , Jun 30, 2006
    • 0 Attachment
      Hi,

      Im very exited about XP and just read the second Edition of XP
      explained cover to cover.

      On topic wasn't touched that would be importand for our company.

      In most examples the projects are customer specific developments for
      a specific customer, so regular deployment was no problem.

      Our products are most of the time sold to govermantal organisations
      and there a roll out is not so easy, because we have not a web based
      application, but one that has to be installed at a lot of locations.

      But thats only one problem, the second one is more critical. We also
      sell a lot of our products to system integrators that have to rely
      on defined interfaces to integrate our components into their
      products.

      When using XP it can be exspected that also public interfaces will
      change often. Thats something that won't be accepted by the customer
      because we can't force him to adapt their systems every month and do
      a new deployment to his customers.

      How can we deal with this situation.

      Best regards

      Thomas
    • Jeffrey Fredrick
      I don t believe using XP means you d need to change your public interfaces more frequently. If anything I believe you d actually have fewer interface changes
      Message 2 of 4 , Jun 30, 2006
      • 0 Attachment
        I don't believe using XP means you'd need to change your public
        interfaces more frequently. If anything I believe you'd actually have
        fewer interface changes because you wouldn't be tempted to add any out
        of speculation that "we'll need this later anyways". I also think
        you'd have fewer regressions on your existing interfaces as a result
        of your acceptance tests.

        Jtf

        On 6/30/06, escamoteur_burkhart <mail@...> wrote:
        >
        > When using XP it can be exspected that also public interfaces will
        > change often. Thats something that won't be accepted by the customer
        > because we can't force him to adapt their systems every month and do
        > a new deployment to his customers.
        >

        --

        http://www.developertesting.com/
      • Phlip
        ... That means, once a week, you will install a new version to a lot of locations, each running a previous version, and you will automate the test which
        Message 3 of 4 , Jun 30, 2006
        • 0 Attachment
          escamoteur_burkhart wrote:

          > Our products are most of the time sold to govermantal organisations
          > and there a roll out is not so easy, because we have not a web based
          > application, but one that has to be installed at a lot of locations.

          That means, once a week, you will install a new version to a lot of
          locations, each running a previous version, and you will automate the
          test which confirms each install.

          (You might also >cough< manually test each install.)

          Any bugs you find installing should get unit-test fixes. Capture such
          bugs with tests. If a bug was in an installer script, you will write a
          test that parses that script with Regex looking for the bug.

          > But thats only one problem, the second one is more critical. We also
          > sell a lot of our products to system integrators that have to rely
          > on defined interfaces to integrate our components into their
          > products.

          Then each time you acceptance test, you will integrate with mockups of
          all those pre-defined interfaces, and many more.

          > When using XP it can be exspected that also public interfaces will
          > change often. Thats something that won't be accepted by the customer
          > because we can't force him to adapt their systems every month and do
          > a new deployment to his customers.

          An internal interface is subject to refactoring. A published interface
          is part of your customer's requirements. It's a User Story. Each one
          gets a Usertest. So such interfaces will be impossible to freely
          refactor, and your developers will work around and within them.

          --
          Phlip
          http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
        • Phlip
          ... Just a note: These locations are in your lab. Get a bunch of dead Pentium IIIs, wire them up, install your customer s environment on them, ghost their hard
          Message 4 of 4 , Jun 30, 2006
          • 0 Attachment
            Phlip wrote:

            > escamoteur_burkhart wrote:
            >
            > > Our products are most of the time sold to govermantal organisations
            > > and there a roll out is not so easy, because we have not a web based
            > > application, but one that has to be installed at a lot of locations.
            >
            > That means, once a week, you will install a new version to a lot of
            > locations,

            Just a note: These locations are in your lab. Get a bunch of dead
            Pentium IIIs, wire them up, install your customer's environment on
            them, ghost their hard drives, and install install install.

            > each running a previous version, and you will automate the
            > test which confirms each install.

            This way, when the time comes to really install to a real customer,
            you have much higher confidence that stuff will work.

            --
            Phlip
            http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
          Your message has been successfully submitted and would be delivered to recipients shortly.