If you have been reading some of the posts that I have written, there are several dealing with working with those groups within or outside your organization that make the components that you use in your software application (with the assumption that most medium-to-heavy complex products use a number of components inside so as to get some great functionality without having to write all that amount of code themselves). Now, there can be several problems when dealing with components:
- You may have no control about the features being built into the next version of the component and whether those features that are indeed built in work well with the product.
- Your features or defects don't fit into the priority of the component and the schedule of the component does not work for you
- The quality of the component that is delivered to you is low enough that you keep finding defects in the component and are unable to accept the component
- And some more ..
And yet most software applications will use components. For example, there makes no sense for individual applications to write code that replicates the connection to media such as DVD's/Blu Ray, etc. Instead, it makes sense to use a ready-made component to do this; and in most cases, the interaction with the component does not cause significant problems.
But there are steps you can take to ensure that you have as much control over your fortune while integrating with the component:
- You retain in regular touch with the component team, both at manager level and at individual team level; this includes a standing meeting that happens at periodic intervals
- Have discussion with the component team about your interactions with the defect database, defect assignment, and a Service Level Agreement about how to ensure that defects are seen early and fixed early
- This next step may seem somewhat resource heavy, but it is very useful. You need to ensure that you have a request pending with the external team that they provide you this component before it is ready; that is, you get regular copies of the component during the development phase. This ensures that you find problems early, rather than later when there are problems found near the release date of the component, and is pretty much almost impossible to fix such defects. Once you are getting the component on a regular basis, you can work out with the QE team about an optimization method to ensure that these deliveries of the component are all tested and any issues are sent off to the team that is making the component, so that these defects or even feature requests can be handled by the component team.
- You may have no control about the features being built into the next version of the component and whether those features that are indeed built in work well with the product.
- Your features or defects don't fit into the priority of the component and the schedule of the component does not work for you
- The quality of the component that is delivered to you is low enough that you keep finding defects in the component and are unable to accept the component
- And some more ..
And yet most software applications will use components. For example, there makes no sense for individual applications to write code that replicates the connection to media such as DVD's/Blu Ray, etc. Instead, it makes sense to use a ready-made component to do this; and in most cases, the interaction with the component does not cause significant problems.
But there are steps you can take to ensure that you have as much control over your fortune while integrating with the component:
- You retain in regular touch with the component team, both at manager level and at individual team level; this includes a standing meeting that happens at periodic intervals
- Have discussion with the component team about your interactions with the defect database, defect assignment, and a Service Level Agreement about how to ensure that defects are seen early and fixed early
- This next step may seem somewhat resource heavy, but it is very useful. You need to ensure that you have a request pending with the external team that they provide you this component before it is ready; that is, you get regular copies of the component during the development phase. This ensures that you find problems early, rather than later when there are problems found near the release date of the component, and is pretty much almost impossible to fix such defects. Once you are getting the component on a regular basis, you can work out with the QE team about an optimization method to ensure that these deliveries of the component are all tested and any issues are sent off to the team that is making the component, so that these defects or even feature requests can be handled by the component team.
No comments:
Post a Comment