phasing out after roll-out of DevOps Platform to all clients
A Project Board is a shared, online resource for managing projects that involve ITAS (Subscription) Services. It is used by Business Analysts and Users, IT, and Platform and Software Engineers to allow collaboration on projects that go beyond Change Requests to existing, or for new, ITAS Applications. This can include discussing something as simple as the construction of a request to the Data Query Service (DQS) through to designing complex Solutions involving multiple components or workflows.
NOTE: This resource is only available to clients who subscribe to either Enterprise or Premium Services packages
There are seven Lists which can contain one or many Cards, and each of these Cards can represent either a Topic, Project Definition (Category), Project or Development.
Contains Cards representing technical topics and reference data, such as links to shared resources, tokens and user guides.
A Project can be defined as an "collaborative enterprise planned to achieve a specific objective"; in other words it can involve a simple development to a multi-step workflow. For Projects with a common underlying theme or Framework, these can be repeatable processes. Once defined (or categorised) they can be added to this List so that similar future Projects can be tagged accordingly. This will allow the development of re-usable functions and provide an ongoing reference point for knowledge gained during the development life-cycle. A good example of this is ReportFactory; an architectural pattern involving APIs, services and notifications common to every type of report. Each Category should be represented by a Purple Label.
New or existing Projects that are being discussed and fleshed out can be managed through this List. Where possible each should be tagged (using labels) as appropriate to identify services affected/used, Category (as discussed above) and an (optional) unique identifier for the specific project (in order to link related developments - see below). Each Project can be optionally represented by a Pink Label where multiple developments are expected.
Once in development, Projects created above will migrate to this List as the 'reference card' for ongoing work and related developments. To use the ReportFactory example again, the ongoing project is the support and development of the ReportFactory framework and any report built using this pattern. Projects can be Archived if finite and a natural progression to Support can be achieved.
In this context, these are specific, defined developments undertaken by Hivedome software engineers. They will normally (but not exclusively) spawn from a Project and as such will often be linked using the tags as described above, in order to trace through the development life-cycle. In this List Developments are "on hold" and can be further defined through discussion on the Board via comments. Once Approved for Development there are two courses of action:
Both achieve the same effect; identifying developments that are to be added to the backlog (work schedule).
Cards left on this Board (option 1) will be harvested (billed as a TMA). They are automatically synchronised with the Client Approval List on the corresponding Developments Board to ensure they are included in the backlog.
Cards moved across (option 2) will be estimated/costed and an HQ will need to be approved before being added to the backlog.
Both paths will converge on Client Approval on the Developments Board at which point a Delivery Expected date will be assigned (this may be changed over time as scheduling is confirmed).
Once the development has been completed the relevant information will be added (Modlib and/or NG Package references) and the Card moved to this List. At this stage the client can request deployment.
For developments with Cards on the Projects Board this will also trigger the movement to the corresponding Ready to Release List.