![Contents ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],C](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Similar to Congility 2011
Similar to Congility 2011 (20)
Recently uploaded
Recently uploaded (20)
Congility 2011
- 1. DITA maturity model in a SCRUM environment May 2011, Crawley
- 10. Level 1: Reusable topics E
- 12. Level 2: Standardization C
- 14. Level 3: Automation and integration E
- 16. Level 4: Collaborative content C
- 18. Level 5: Interactive content ecosystem E
- 20. Summary E
- 21. Q&A
Editor's Notes
- This presentation is not about our DITA implementation or migration. A short summary of why we migrated to DITA to provide a bit more context to the rest of the presentation.
- So there we were with a brand-new CMS, DITA implemented, migrated content. Where would we go from here. How could we take this further?
- Then we came across the following DITA maturity model. We noticed that we had already covered a few steps, and this inspired us to move on with DITA, getting more out of our content. It also helped us to phase and plan as the model provides logical incremental steps.
- We started working on our own DITA maturity model.
- We had already gone through this step – it is the one we discussed in an earlier slide on how we adopted and implemented DITA.
- And this is how it reflects in our maturity model. Go over what we invested. And what we got out of it.
- A few words on minimalism. Resulted from customer feedback and a content audit. Things to mention on minimalism? - - -
- Go over what we invested. And what we got out of it.
- Up to now, only PDF. We started experimenting by creating online output without having to tweak too much using the OT. CHM. We started to follow the build procedures that worked with bi-weekly builds -> process new developments coming from the sprints. Our bi-weekly contributions are not in line yet with development. We started using XLIFF to improve communication with our translation office (TO). And we started creating market-specific output using filtering and DITAVAL.
- Go over what we invested. And what we got out of it.
- Explain DoR. Docu in DoR = define what is needed in every user story to build documentation on. In acceptance criteria: define the expections wrt documentation in acceptance criteria. DoD: a user story is not ready until its documentation is ready. Start of bi-weekly documentation deliveries in line with development.
- Go over what we invested. And what we got out of it.
- Go over what we invested. And what we got out of it.