Use that damn wiki because you’ve got issues

Posted on 15 Januar, 2011

Introduction

This third iDevBlogADay post describes the combination of the previously outlined issue tracking and knowledge management that ultimately culminates in the creation of a digital hub for everything iOS related at Spielhaus.

The Problem

Using specialized tools for specific purposes is a good practice in nearly all situations. However, we humans have a hard time when it comes to multitasking. Constantly switching tools while working is not ideal. Especially when the end goal is to keep track of a complex process such as iOS development. Managing one’s knowledge in one place and tracking issues in another, is fine until the need arises to combine bits and pieces from both systems. The ideal supporting environment would be an ecosystem where problem descriptions (issues) are placed along with stored knowledge. If the tools involved don’t provide this feature, the developer needs to take care of it himself. Again, this is not ideal because every free mental resource should be dedicated to problem solving and not be used for gathering supporting info.

But what’s wrong with the status quo?

As with the former posts – the point is still valid: Nothing is wrong unless you want to give up potential of optimization.


Combining issue tracking with knowledge management

If you followed the previous posts it’s not hard to guess that two software packages built by the same developers were meant for each other. Jira (issue tracking) and Confluence (wiki) can be set up to cooperate. The objective is supposedly simple – show relevant issues right on specific wiki pages together with insightful statistics.
Jira can be set to trust queries from Confluence (and vice versa). The workflow involves telling Jira to trust Confluence and then add gadget links from Jira to Confluence.

Gadgets can display charts, the output of search filters or links to other tools – all of this in the context of issue tracking.
I would like to demonstrate this with our flagship app Today Todo. The main wiki page functions as a container for all enclosed pages – each sub-page contains specialized information. When accessing the Today Todo page, I can already see all background information concerning the project. It would be great if I could see the relevant issues from Jira.

As you can see from the screenshot, I can pull in any number of issues related to the development of Today Todo. These are by no means static lists. The content is fetched remotely from Jira and displayed on the wiki page. Furthermore clicking any links (or chart slices) forwards to the corresponding issue(s) in Jira.
This way we have built a cockpit with all relevant info for the project. I resisted the urge to go crazy with charts and extensive analysis data. I have only included the tasks for the actual and the next version together with the feature requests (not visible). These gadgets can be placed anywhere on the wiki concluding their greatest benefit of encapsulating the supporting material with the problem description. Similar to connecting data and code in object-oriented programming. When Trung and I are working on one topic – say implementing a “seamless synching of data between instances of Today Todo” – we have the problem description (feature request) together with all supporting material about synching right in one place.

Conclusion

Since I wanted to keep this post short – that’s all about it for now. I hope that this series of posts helped some of you with this exciting voyage of ours that iOS development turns out to be.
I am not sure what will follow next week now that I am done with my favorite topics. However these <insert app here> post mortems seem be en vogue and maybe it is time to review what worked and what didn’t for Today Todo and Spielhaus over the last year.

Comments are closed.