When speaking with business analysts every day I find many of them if not nearly all of the people do not feel comfortable with having RUP on their resume. However when these same people further review RUP they find they have been performing multiple elements of RUP for a very long time.
I also find it interesting that almost every BA role is asking for BAs with RUP experience. These are also the same opportunities where the RUP methodology will not be applied to the extent implied.
I know I do this because I'm probably a perfectionist with a methodology. I think a good comparison would be if I've done all of the parts of a programming language. For instance...I may have experience with VB, but I've never coded VB.net. Many clients want VB.net experience. I have all of the coding, logic, and problem solving tools that I've used for years, but I don't have the one key element.
I guess if I were having heart surgery, and my doctor said he or she had experience with surgery and could do all of the aspects of your basic surgery. I'd decline to have that doctor work on me, if they hadn't done heart surgery before. In fact, I'd want to know I wasn't one of the first patients as well.
I don't think RUP is heart surgery, but I think BA's want to KNOW the methodology and experience it before being a point person for a business.
I think a lot of business analysts see RUP as something as difficult as heart surgery, but I don't think it has to be. RUP is based on the following software principals:
1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Continuously verify software quality. 6. Control changes to software.
Not one of these principals is groundbreaking or new. I would propose that most BAs feel comfortable with these ideas and have even used a majority of them in their past work.
Lastly, like coffee there are many flavors of RUP. RUP is designed to be an adaptable framework and most companies have changed it to best meet their company specific needs. Instead of using the full-blown, highly caffeinated RUP, most companies have de-caffeinated it and added lots of cream and sugar.
So when most companies post BA positions for RUP heart surgeons most of the time a general BA practitioner will do just fine.
Well said Jason. Isn't there a point where you're not really using the methodology, but you're just putting a name to the way you'd like to display your analysis. I can't tell you how many times I see the business tell me they want a diagram to do everything but make coffee for the office, when there really is no readable diagram that will accomplish that. Customization is great, but many times I find that the business wants to adjust the methodology before they understand the artifacts.
4 comments:
When speaking with business analysts every day I find many of them if not nearly all of the people do not feel comfortable with having RUP on their resume. However when these same people further review RUP they find they have been performing multiple elements of RUP for a very long time.
I also find it interesting that almost every BA role is asking for BAs with RUP experience. These are also the same opportunities where the RUP methodology will not be applied to the extent implied.
What the RUP?
I know I do this because I'm probably a perfectionist with a methodology. I think a good comparison would be if I've done all of the parts of a programming language. For instance...I may have experience with VB, but I've never coded VB.net. Many clients want VB.net experience. I have all of the coding, logic, and problem solving tools that I've used for years, but I don't have the one key element.
I guess if I were having heart surgery, and my doctor said he or she had experience with surgery and could do all of the aspects of your basic surgery. I'd decline to have that doctor work on me, if they hadn't done heart surgery before. In fact, I'd want to know I wasn't one of the first patients as well.
I don't think RUP is heart surgery, but I think BA's want to KNOW the methodology and experience it before being a point person for a business.
I think a lot of business analysts see RUP as something as difficult as heart surgery, but I don't think it has to be. RUP is based on the following software principals:
1. Develop software iteratively.
2. Manage requirements.
3. Use component-based architectures.
4. Visually model software.
5. Continuously verify software quality.
6. Control changes to software.
Not one of these principals is groundbreaking or new. I would propose that most BAs feel comfortable with these ideas and have even used a majority of them in their past work.
Lastly, like coffee there are many flavors of RUP. RUP is designed to be an adaptable framework and most companies have changed it to best meet their company specific needs. Instead of using the full-blown, highly caffeinated RUP, most companies have de-caffeinated it and added lots of cream and sugar.
So when most companies post BA positions for RUP heart surgeons most of the time a general BA practitioner will do just fine.
Well said Jason. Isn't there a point where you're not really using the methodology, but you're just putting a name to the way you'd like to display your analysis. I can't tell you how many times I see the business tell me they want a diagram to do everything but make coffee for the office, when there really is no readable diagram that will accomplish that. Customization is great, but many times I find that the business wants to adjust the methodology before they understand the artifacts.
Post a Comment