Tempo IDE Tracker T-404-LOKA

Tempo IDE Tracker T-404-LOKA Students Instructor Alexander Björnsson Áslaug Eiríksdóttir Snorri Hjörvar Jóhannsson Examiner Benedikt Hólm Þórðarson Karl Andrés Gíslason Acknowledgements We would like to thank our product owners, Árni Geir Úlfarson and Stefán Einar Stefánsson for their patience with our questions and their invaluable feedback. Our contact at Tempo, Þórey Rúnarsdóttir for providing us with our workspace and proofreading our design document. Our gratitude also extends to our instructor, Áslaug Eiríksdóttir for her reli- ability, patience and willingness to lend us her time during this project. And our examiner, Karl Andrés Gíslason, for giving valuable critique through the course of this project. We couldn’t have done this without you. Thank you for the semester. Háskólinn í Reykjavík T-404-LOKA Contents 1 Introduction2 2 The Extensions3 2.1 The Product...............................4 3 Risk Analysis4 3.1 About..................................4 3.2 The Risk Analysis Table........................6 3.3 Results and Encounters.........................7 4 Design8 4.1 The Project Stack............................8 4.1.1 Project Management......................9 4.1.2 Development Pipeline...................... 10 4.1.3 The Extensions......................... 11 4.2 The Design Document......................... 11 4.3 READMEs............................... 11 5 Work Method 11 5.1 Methodology.............................. 11 5.1.1 Meetings............................. 12 5.1.2 Story Points........................... 13 5.2 The Sprint Plan............................. 14 6 Sprints 14 6.1 Sprint 0................................. 14 6.2 Sprint 1................................. 15 6.2.1 Sprint 1 Burndown....................... 16 6.2.2 Backlog............................. 16 6.3 Sprint 2................................. 17 6.3.1 Sprint 2 Burndown....................... 18 6.3.2 Backlog............................. 18 6.4 Sprint 3................................. 19 6.4.1 Sprint 3 Burndown....................... 20 6.4.2 Backlog............................. 20 6.5 Post Sprint / Sprint 3.5........................ 21 6.6 Sprint 4................................. 22 6.6.1 Sprint 4 Burndown....................... 22 6.6.2 Backlog............................. 23 6.7 Sprint 5................................. 24 6.7.1 Sprint 5 Burndown....................... 25 6.7.2 Backlog............................. 25 3 Háskólinn í Reykjavík T-404-LOKA 6.8 Sprint 6................................. 26 6.8.1 Sprint 6 Burndown....................... 27 6.8.2 Backlog............................. 27 6.9 Sprint 7 & 8............................... 28 6.9.1 Sprint 7 & 8 Burndown..................... 29 6.9.2 Backlog............................. 29 6.10 Project Status.............................. 30 6.10.1 The Status of the IDEs..................... 31 6.10.2 Sublime............................. 32 6.10.3 Work Times........................... 32 7 Continuous Integration 34 7.1 The Build Pipeline........................... 35 7.1.1 Clean/Setup........................... 35 7.1.2 Unit Tests............................ 36 7.2 Testing and quality assurance..................... 36 7.2.1 Deployment........................... 37 8 User Interface 38 9 API 41 9.1 Atom & Visual Studio Code...................... 41 9.2 Jetbrains IDEs............................. 42 10 Conclusion 42 A Design Document 43 B User Documentation 47 C Project Backlog 50 References 53 1 Háskólinn í Reykjavík T-404-LOKA 1 Introduction Tempo is the company behind one of the most popular extension in the Jira project management eco-system. Among it’s features is a timesheet management tool where users can record and log work hours. Recording of work hours is an important part of software development. Devel- opment teams typically keep record of the tasks they’ve completed, and how long it took them to complete them. By doing so, they can predict the amount of man hours needed to complete tasks similar to the ones kept in their records. The recording of work hours can be done through a simple work-clock found in many working environments, or timesheet solutions like the one presented by Tempo. Done manually, human error can interfere with record-keeping, and inaccurate records can lead to misinformed decisions being made by a team. Further, in software development, developer diligence is required for the recording of work hours. If a developer does not keep record of his work hours, he will need to fill any missing fields at some points with data gathered from, at worst, guesswork. This project was commissioned by Tempo with the intent to automate the recording of work hours through their services by developing a suite of Integrated Development Environment (IDE) extensions. 2 Háskólinn í Reykjavík T-404-LOKA 2 The Extensions The purpose of the extensions, going by the name Tempo IDE Tracker, is to allow users to automatically recording their work investment. This is made possible by building upon Tempo’s Tracker API. These trackers, seen in figure1, function similarly to stopwatches. They can then be tied to a Jira issue-key, which is then mapped to a Jira issue. One of Jira’s features is the creation of project backlogs and populating them with user stories, known and reported bugs, and tasks to be completed. Jira refers to each of these items as an issue, and generates for them an issue-key upon creation. Figure 1: Tempo Trackers as seen on Jira A common convention among development teams making use of Jira is to name their code-base in accordance these issue-keys. Using figure1 as an example, a developer might encounter a software bug and report it through Jira. This bug will then have an issue-key generated: TP-10. To work on fixing this bug, the developer will then create a new code-base branch using his choice of version control system, and name said branch with the issue-key, TP-10. The functionality of a Tempo IDE Tracker is therefore two-fold; to determine the branch name at any time; and to communicate with Tempo’s Tracker API to create, start and stop Trackers. The following is a storyboard of the extension in use: 1. The User: Opens his IDE. 2. The Extension: Starts a tracker named after the user’s branch. 3. The User: Switches branches. 4. The Extension: Stops any active trackers, and starts a new tracker based on the name of the current branch. 3 Háskólinn í Reykjavík T-404-LOKA 5. The User: Clicks the extension icon inside his IDE to signal that he doesn’t want his time tracked. Then heads off to a meeting. 6. The Extension: Stops any active trackers. 7. The User: Comes back from the meeting, sits down and clicks the extension icon to signal the he wants his time tracked again. 8. The Extension: Starts the tracker again. For information regarding the extension’s UI, see Section8. 2.1 The Product The final product and deliverables to the company includes: The design and development of three extensions for Atom, Visual Studio • Code and the Jetbrains development environments. Jetbrains IDE compati- bility is as follows: – IntelliJ IDEA – CLion – PyCharm – WebStorm – PhPStorm – DataGrip (with GitIntegration[1] installed) Infrastructure for future development • Documentation • – Design Document 4.2 – User Manuals in the form of README.md files. 4.3 3 Risk Analysis 3.1 About An initial risk analysis was created and maintained through the duration of the project. For the risk analysis an estimation was done on the probability of risk and the impact it could have on the project. These estimates were on the scale of 1 - 10. A risk factor was calculated by multiplying the risk and impact estimates to get 4 Háskólinn í Reykjavík T-404-LOKA a better view of which risks were the most important to address. Each risk was assigned a guarantor that would watch for the development of the risk and be the first responder if it would come to pass. 5 Háskólinn í Reykjavík T-404-LOKA 3.2 The Risk Analysis Table Description Response Probability Impact Risk Guarantor Factor Jira Service Un- Migrate over to 3 8 24 Snorri availability another project management tool (Asana) Project Scale Reduce project 2 9 18 Benedikt out of scope scope Team member Catch up in later 5 3 15 Snorri becomes ill sprints Team member Rest of team 4 3 12 Benedikt unreachable must pick up slack Losing a team Reduce project 1 10 10 Benedikt member scope Tempo API un- Work with sup- 1 10 10 Alexander availability port to get it fixed Team member Try working 1 8 8 Snorri becomes ill over from home a prolonged and/or reduce period scope Dev machine Replace or re- 2 3 6 Team failure pair machine API token stor- Switch to an- 1 2 2 Alexander age security other encryption compromised service Version control Switch to an- 1 2 2 Alexander system fails other version control Build Machine Run setup 1 2 2 Snorri Crashes (Jenk- scripts ins) Table 1: Risk Analysis 6 Háskólinn í Reykjavík T-404-LOKA 3.3 Results and Encounters Many of the risks mentioned were encountered in the lifetime of the project. During the final sprints it was decided that the project was out of scope by one extension. That was the Sublime extension. This will be further discussed in section 6.10.2. The second risk that was encountered quite frequently was that team members were unreachable. This is understandable since a lot of work was done remotely and from different time zones. This was remedied by having all members install the Slack app on their phones and laptops. Development machine failure and build machine crashes were two risks that were encountered frequently. Two team members’ laptops went out of order for long periods causing them to need to borrow laptops. The risk was mitigated by the fact that the version control system used by the team stores the entire code- base. The Jenkins Continuous Integration Machine crash was another risk that was encountered early in the development cycle. This was mitigated greatly by the scripted setup process for the machine. The downtime was about a day, but could have been a lot higher if this eventuality had not been prepared for.

Load more