• 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!

Progression towards Project Management...

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

    #31
    Originally posted by malvolio View Post
    As for BAs, I agree that too rigid a paper system is counter-productive and risky, but you do need a template to work with. That's the strength of people who really understand UML and its underlying approach - sadly that's not me!
    I don't see the relevance of the reference to UML here. Please elaborate.

    Comment


      #32
      most damn useful advice i have had off this board!

      will try to see what i can do to ease my fears of having the p*ss taken out of me!

      That's the strength of people who really understand UML and its underlying approach - sadly that's not me!
      Had a quck google of UML - looks very complex - is it worthwhile?

      Comment


        #33
        Originally posted by original PM View Post

        The one point I can never understand is why there seems to be an insistence that PM should work in or come from an IT background.
        Agreed. friends who are project managers in the building trade have no idea about IT and why should they?
        "Israel, Palestine, Cats." He Said
        "See?"

        Comment


          #34
          Originally posted by malvolio View Post
          As for BAs, I agree that too rigid a paper system is counter-productive and risky, but you do need a template to work with
          Agreed. However as a contractor BA I have to fit in with what the customer wants me to deliver

          Originally posted by malvolio View Post
          That's the strength of people who really understand UML and its underlying approach - sadly that's not me!
          And luckily for me, that's my field.
          "Israel, Palestine, Cats." He Said
          "See?"

          Comment


            #35
            I'm no kind of expert on UML myself, but it is a formal protocol for developing Use Cases and inter-process dependencies. Like all such things, if you are aware of it and understand the methodology you follow the core principles almost automatically (like most PMs follow Prince, or key bits of it, without really realising it). Doing such work in a logical and controlled manner is a good way not to miss important bits of information.

            I suspect at heart it's merely SSADM writ large with a fancy toolkit - truly there is nothing new under the sun...
            Blog? What blog...?

            Comment


              #36
              UML is an excellent tool for designing large or complex systems and where it needs to capture complex business requirements.

              It keeps everyone on the same page and does wonders in cutting down on misunderstood-requirements-syndrome, since it communicates back to the business what has been 'captured' during all those meetings, and it communicates forward to the development teams what is required.

              Knowing it gives you a very strong advantage in keeping up with BAs. Since UML hit version 2.0, it is quite suitable as a more generic Business Analysis and modelling tool as well as being a System design tool (as it was originally intended).

              In a Prince2 context, its diagrams can be added to the Product Descriptions (which in turn form part of the Work Packages). Also, it is a serious reference later in the project (or not-so-later if you are doing some Agile as well), when it comes to testing - especially UAT when you have good quality Use Cases.
              Last edited by beercohol; 23 April 2008, 14:45.
              When you encounter speed humps, sound your horn in protest.

              Comment


                #37
                Originally posted by beercohol View Post
                UML is an excellent tool for designing large or complex systems and where it needs to capture complex business requirements.

                It keeps everyone on the same page and does wonders in cutting down on misunderstood-requirements-syndrome, since it communicates back to the business what has been 'captured' during all those meetings, and it communicates forward to the development teams what is required.

                Knowing it gives you a very strong advantage in keeping up with BAs. Since UML hit version 2.0, it is quite suitable as a more generic Business Analysis and modelling tool as well as being a System design tool (as it was originally intended).

                In a Prince2 context, its diagrams can be added to the Product Descriptions (which in turn form part of the Work Packages). Also, it is a serious reference later in the project (or not-so-later if you are doing some Agile as well), when it comes to testing - especially UAT when you have good quality Use Cases.

                Can a developer generate working code from UML?

                Comment


                  #38
                  Originally posted by beercohol View Post
                  doing some Agile
                  Read that with the same tone of voice you'd use if you said 'doing some coke'. It livens up my dull writing!
                  When you encounter speed humps, sound your horn in protest.

                  Comment


                    #39
                    Originally posted by beercohol View Post
                    ....It can be a real shocker to learn that a developer spent 4 days looking busy and only having changed one line of code (which was a comment rather than actual code).

                    This can indicate several things.. He may be distracted with personal issues on his mind, may be procrastinating, may be preparing to walk, may not have a clear understanding of what he needs to be doing, may be burned-out.

                    Err yes possibly, but could also indicate a complex, badly documented / commented block of code, or difficult to replicate bug that has taken time to fix.

                    Don't get too hung up on metrics
                    Do what thou wilt

                    Comment


                      #40
                      Originally posted by Dark Black View Post
                      Err yes possibly, but could also indicate a complex, badly documented / commented block of code, or difficult to replicate bug that has taken time to fix.

                      Don't get too hung up on metrics
                      Of course, yes. A good example of encountering this is when you get nudged into an existing project that is already several months in, and needs rescue because the other PM has been fired/given Prozac-leave.
                      When you encounter speed humps, sound your horn in protest.

                      Comment

                      Working...
                      X