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

Fwd: [XP] dev ops split?

Expand Messages
  • Otto Behrens
    ... From: M. Manca Date: 2012/4/24 Subject: Re: [XP] dev ops split? To: Otto Behrens ... Yes, it may happen.
    Message 1 of 3 , Apr 26, 2012
    • 0 Attachment
      ---------- Forwarded message ----------
      From: M. Manca <m.manca@...>
      Date: 2012/4/24
      Subject: Re: [XP] dev ops split?
      To: Otto Behrens <otto@...>


      Il 24/04/2012 18:28, Otto Behrens ha scritto:
      >> I work on embedded projects so for me is common to have engineers
      >> involved in the application software and others involved in o.s.
      >> software. In other project types may be there are engineers working with
      >> a db and others at the application and so on.
      > So it appears as if you have specialist engineers in your team that
      > would work on specific areas.
      Yes, it may happen. I choose to manage all the embedded project as one
      entity to be more agile also in electronics development. This is always
      possible if the project is not too big, if it is big normally I divide
      it in subsystems. So I think it is similar to your situation.
      >
      >> Is reasonable the time spent? And what do you mean for technical tasks
      >> in your specific situation? Why they can take technical tasks? Did you
      >> split user stories in technical tasks and then they can be pulled?
      > The customer is complaining about the time spent there. I think it
      > mostly has to be spent and more. But as a business owner, features in
      > the application is what fancies customers.
      >
      > We prioritise technical tasks such as the ones below in the same list
      > as functional enhancements to the application. The difference is that
      > the tasks below do not add to the project velocity.
      >
      > Technical tasks here involves:
      > - We use www.opscode.com/chef to manage installations and
      > configurations of machines. This involves knowledge of linux, ruby and
      > chef. Running and managing a chef server.
      > - Taking care of and optimising the development process, jenkins (for
      > doing builds and running tests). Automated testing infrastructure.
      > - Test, training and production deployments are automated and that
      > takes some work to keep up (also, the task of building it initially).
      > Scripts are written in ruby. (eg. today we split resource files into
      > different git projects because we run multiple test / production sites
      > on a machine. Previously we had it managed under one project and could
      > not run different versions simultaneously)
      > - Database management, backups, upgrades
      > - Operational issues that jump up like an application server process
      > that dies (know when it does not respond anymore, make sure it starts
      > up again and figure out why it dies)
      > - Factor out some technical debt that is slowing us down /
      > inconsistent in the system
      Ok, now I understand better the situation.
      If the company is not big may be interesting measure how much time you
      spend to manage supporting tools over how much time you spend for
      application specific development. If the value is higher then 30% may be
      better to have a support team taking care of supporting tools.

      In my opinion you should set up a tool set requiring lower effort to
      manage. I know it is simple to suggest but may be hard to realize. You
      already have the 2 more important tools: the source code version control
      system and the continuous integration system. And you have some other
      tools supporting your need. The tools have to be your best advantage so
      I should try to reduce the effort spent to use them. Some other tasks
      seems to me that should be managed outside the development team. If you
      need to solve a hardware crash you shouldn't stop the development team,
      you should have a different team. So may be right to have a development
      team and a development-support team. May be that the development-support
      may support more then 1 development team.


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.