• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Agile, again....

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #41
    Originally posted by Cirrus View Post
    There's only one thing you need to remember about software development: always break your project into components - as small as you can get. Then you can run each component with a small team (yes - the smaller; the better )

    You do of course need to agree interfaces up front. There are only two things you need to remember about software development: always break your project into components and make sure you define interfaces up front.

    I know you're thinking that trying to define interfaces before you've designed a system can be tricky. So you need to make your interfaces very virtual. There are only three things you need to remember about software development: always break your project into components, make sure you define interfaces up front and make your interfaces very virtual. A classic virtual interface strategy is always to use views when accessing databases. Never write to tables, but always to views. The principle however can be extended to all manner of interfaces: the more layers on the interface; the more chance you can adjust the interface without screwing up your code.

    Componentize and the world is your oyster
    Agreed, but I hope they wouldn't stay views in the final implementation, because unless underlying indexing is good, performance could be a problem.

    the more layers on the interface; the more chance you can adjust the interface without screwing up your code.
    Agree to an extent, however the more application layers you have can increase complexity and degrade performance.

    An example I'll give is you design a data warehouse.
    If it is designed well you should be able to sit multi vendor reporting / dashboard tools on it easily and come up with the same answers regardless.
    If you bury business logic in the reporting tool layer(s), this becomes a lot more difficult to achieve.

    Of course no one will thank you for enforcing this at the time, however everyone will say what a great guy you are, when senior management decide, at a whim, to replace Business Objects with Cognos, or whatever.
    The Chunt of Chunts.

    Comment


      #42
      Originally posted by original PM View Post
      And this is where Agile falls down - it assumes that all tasks can be done in a 1 week sprint therefore anything we desperately need is only 1 week away.

      However this is not the case if you have to hook into third parties etc who will have their own timescales and methodologies.

      Which is why you still need proper architecture management for large projects.

      In fact unless you are doing a front end change to a website which people are just consuming from then I am starting to see that Agile really quickly looses it's benefits.
      Nonsense this is poor planning by a moron

      Comment


        #43
        'Agile' and 'Scrum' aren't the same thing. Just to be clear.

        When I say 'you', I mean 'one'.

        *if* you estimate work early enough in advance that you can make use of a burn-down chart to predict roughly when you can deliver some chunk - or how much you can deliver before some important date, then of course producing estimates is *very* useful.

        If you're estimating at the last minute before working of a task then obviously it's entirely pointless and you're just doing it because " it's the way".

        If you're doing it last minute before the sprint, then that's good too so long as you are doing because you're about to tell a load of stakeholders what they're going to get in 2 or 3 weeks and you plan on delivering to those expectations. Otherwise you're again just mindlessly following a misunderstood formula.

        Meetings are fine. Lots of meetings is fine too. As Cirrus pointed out on page 1 - "Individuals and interactions over processes and tools".

        If your meeting is to facilitate interaction between individuals then of course it's good. If it's because some process says you should have one - then it might not be. Better to have 10 meetings per line of useful code, than to have 1 meeting per 10 lines of broken code.

        Comment


          #44
          Originally posted by original PM View Post
          Now this is the bit everyone needs to avoid.

          This assumption that as the delivery date approaches everyone on the project will start doing 10-12 hour days and work weekends - I have never understood that.

          It is a 'thing' made popular by stupid people who think that delivering a project should be a hard arduous task with pizza until 3 am and everyone living on coffee and doughnuts saying 'Ra Ra Ra' aren't we great.

          For those who have been doing projects for years n years it is no different to any other job - you need to plan and you need to deliver - yes it is often bringing in new concepts etc - but so what.
          I agree with you but you forgot the sleeping bag.

          Comment


            #45
            Originally posted by Bee View Post
            I agree with you but you forgot the sleeping bag.
            'CUK forum personality of 2011 - Winner - Yes really!!!!

            Comment

            Working...
            X