An Intern college project with Red Hat
Project selection
I spend some time thinking about a possible project , talking to colleges and consulting with management to decide a appropriate project. After this process the idea for the project was decided upon from a suggestion by my manager.
Project Objective
The objective of this project is to develop a tool Kujira that a user can extract and present analysed data from JIRA in an accessible graphical manner. Kujira uses Jira-miner an existing tool.
Jira-miner allows a user to write searches in JavaScript that return finely grained report data from JIRA. Jira-miner in its current format requires users with a very technical/ programming background to extract and query data from JIRA. It is not designed for a novice user. Jira-miner doesn’t generate graphs at this time.
The outcome for Kujira is that it can be used for any project in JIRA and can be used by a wider group of users.
The project was a joint project with another intern. As software development is rarely done by a lone programmer in industry it is thought that building this project as part of an Agile scrum team would be a beneficial learning experience.
PRD (overview of how a project starts)
The initial planning and documentation was done over a two week period in which we put together the PRD(Product Requirements Document). To begin with we started modelling the project in a white boarding session. We later moved the to modelling diagrams that we used to generate users stories for the Product Requirement Document. This was a very useful exercise as it taught us how any Red Hat product is started from the ground up.
Agile Scrum (learn by osmosis)
Work was managed through JIRA. Two weeks of work is a sprint. In a sprint we expected to have a demonstration of our work carried out in the sprint. We had five development sprints. All Agile ceremonies were held for the project
We had five development sprints managed by our scrum master. Agile means flexibility as in if you need to change something in your work flow to increase productivity you do it. We had a two week working sprint which ended on a Friday. We changed to finish on a Sunday as it was a college project and homework was required. We had a sprint review on a Monday morning in which we review the previous sprint to show what was achieved and to see what was positive and what was negative about our sprint and what we can do to improve in the next sprint.
Git flow(Forking and PR review)
The git work flow was something new to us as all college projects up until this were solitary endeavors and commits to master were the norm. So learning forking and PR review merging and re-basing was a matter of course in the joint project. This was more reflective of an actual work environment and a useful learning tool.
Small Team project (pros and cons)
We had a number of issues around Git where PR were being merged in the wrong order when done by the reviewer (leading to detached heads and merge conflicts). A decision was made that the owner of the branch was the person best suited to merge the branch.
We also had issues over how long it would take for a ticket to be peer reviewed which resulted in one developer waiting on the other in order to proceed. So it was decided that for progress to be made we would not wait for review before opening another task. Downside of this is that code is being built on unreviewed code.
