Do you have a plan for project growth? A project will eventually have problems when it grows too big:
• Performance - The project has grown so big it's slowing down.
• Risk - Users spend most of their time in this project. The project is too big to fail!
• Management - Keeping the project up and running rather than getting the job done.
When we experience growing pains in a project we are also much less likely to use new functionality, as it's just too painful to implement changes to the project.
That great feature or functionality – if you have growing pains, you'll probably not use it!
So, how can we change this and keep our projects small and nimble? Here are some common scenarios to consider:
The way we manage our customization is intertwined with our project approach:
Single project approach
When starting with ALM, it's very tempting to put everything into one big project:
1. One ALM project contains multiple "mini-projects" (for example products or releases)
2. The project grows
3. The project is copied and redundant data is deleted manually
This approach can work if the "mini-projects" are fairly small with a limited lifespan. However, it is not suitable for a 24/7 environment due to project maintenance and downtime.
Master project approach
A better approach is to introduce a "master project". This is simply a project used to store the common customization. New projects will be created as a copy from the master:
This encourages the use of multiple projects, but any customization changes must be applied manually to each project.
Template project approach
The full ALM edition allows the creation of projects of the type "template", this project type allows linking and sharing of customization:
This approach provides the option of both shared template customization as well as individual project customization.
For more information on this topic, please refer to the Project Topology Best Practices.
Reporting is a big reason why many are stuck in a "single project approach" for too long. Think about these options instead:
- Review your old reports
Old or discontinued reporting functionality is still in use today, there could be better or faster reports available.
- Rewrite External reports
External reporting using the OTA API is a very popular option. However, the REST API introduced the option to run on 64-bit Office and non-Windows machines.
- Try ALM Business View reports
Business Views are great for both graphs and Excel reports. They will also allow for cross-project reporting If you use full ALM
The amount of data can be the biggest cause of growing pains as well as forcing you into keeping bloated projects alive:
- Manage the size of attachments
It's possible to block file uploads and use links instead of files to limit the size growth.
- Save test scripts outside the project and only store the results in ALM
- Find and access relevant data through Global Search
- Reuse data with Libraries and Baselines
With full ALM you can create, import, compare and synchronize data changes across projects
The scenarios to consider for long-term success:
- Project structure – single/master/template approach
- Strategy for handling customizations/reports/data
- Growth – keep projects small and nimble
How do you handle growing pains in your projects? Please share with the community in the comments.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.