The project progress follows our tried and tested process model or complies with the processes in the development team.
Classic process model
For documentation projects that are entirely in our hands, we use our tried and tested process model. The project is divided here into controllable phases:
- Project plan – we create a project plan that you accept.
- Concept – we write a concept that you accept.
- Input – you deliver the input, we view it.
- Draft version – we write and deliver a draft version that you check.
- Final version – we create the final version that you accept.
- Complete documentation – we produce the complete documentation and supply you with all sources and results.
Here we align ourselves to your release dates and also try to give you short-term support. Contact us as early as possible when you are planning a new release. There is then enough time for a high-quality and complete documentation.
Agile documentation
If you practice agile development with scrum, we can integrate ourselves in your team and your procedures:
- Participation in review and any stand-up meetings
- Use of Jira as input and for documentation tasks
- Iterative documentation
New features can then be quickly documented, and the documentation is checked constantly. Shortly before the release, only the final version has then to be produced.
What input does eolas need?
We use all information that you can give us about the product, for example:
- Specifications
- Jira tasks
- Interviews with developers
- Internal Wikis
- The software itself
A system access for working with the software is very helpful and saves you a lot of explicit knowledge transfer. Access can take place for example via a test installation on our premises, via a VPN-secured remote access, or via a secure website. If this is not possible, we are happy to arrange meetings on your premises.
What is expected from a review?
If you receive a draft for reviewing, ideally someone should read the documentation who has an overview of the product and can answer detailed questions or at least knows someone who can.
This can for example be a technical product manager, a product owner, or an experienced developer.
During the review, you should ensure the following in particular:
- Completeness
- Factual correctness
Don’t worry about language correctness, comprehensibility and formatting: that’s our job. The documents you receive for reviewing have already gone through an internal correction phase in our office.
When do you receive the final version?
As a rule, we agree with you on a delivery date for the final version right at the start of the project. This date often has to be changed due to delays in development or if a reviewer has no time for reviews. We are flexible here and do our best to deliver the documentation in time for the release.