Jira is a proprietary issue tracking product, developed by Atlassian. It provides bug tracking, issue tracking, and project management functions. Although often styled using all-capital letters as “JIRA”, the product name is not an acronym, but a truncation of Gojira, the Japanese name for Godzilla, itself a reference to Jira’s main competitor, Bugzilla. It has been developed since 2002. According to one ranking method, as of June 2017, Jira is the most popular issue management tool.
Why is Jira used?
JIRA is basically an issue and project tracking tool which allows us to track any project related work by following a proper workflow. Enlisted below are few reasons which determine the usage of JIRA:
- Able to track project progress from time to time.
- JIRA use-cases include project management, feature implementation, bug tracking, etc.
- Work-flow can be easily customized as per our requirement.
- Along with issue tracking, history of the work done on issues, when, what and by whom can also be tracked.
- JIRA is platform independent and can run anywhere.
Report Types generated in JIRA
There are multiple reports available in JIRA which are used to show the project statistics throughout the project life cycle. There are general reports available for analyzing issues as well as different reports for Scrum projects and Kanban projects.
Following are the general reports generated as and when required for analyzing issues:
- Average Age Report
- Created vs Resolved issue Report
- Pie Chart Report
- Recently created Issue Report
- Resolution Time Report
- Time Tracking Report
- User Workload Report
- Version Workload Report
- Workload Pie chart Report
Following are the examples of reports generated for Scrum projects:
- Sprint Report
- Control chart
- Burndown chart
- Cumulative Flow diagram
- Epic Report
- Release Burndown
- Velocity chart
- Version Report
Following are the examples of reports generated for Kanban projects:
- Control chart
- Cumulative Flow diagram.
For generating reports for your project, follow the below steps;
- Navigated to desired project dashboard.
- Click on Reports tab from left-hand side to view different reports.
- Click on Switch report to view the different report.
Issue Creation in JIRA
1) Log in to your JIRA account by using valid credentials and get directed to the dashboard.
2) Click on ‘Create’ button displayed and you will be navigated to a window for creating an issue.
3) Enter all the necessary details as required to create an issue. As you can see in the below image:
In Project field, project for which we are creating an issue is selected. In this example: STH_Learning(STHL) is selected from the dropdown containing all the available projects.
In Issue type field, the nature of the issue is selected from the dropdown which contains option like Bug, Task, Improvement, Story, New Feature, etc. In this example, ‘Bug’ is the nature of the issue.
Summary field contains the one line title of the issue which imparts the critical information about the issue in a summarized way. The more effective the issue headline, the more you can show the criticality of the issue. Of course, the headline should be easily understood without any chances of misinterpretation. The example I have taken here, however is not much critical.
The Reporter is the one who reports the issue. In most of the cases, the name of the Project manager is selected in this field.
In Description field, the detailed description of the issue is written. As you can see in the below example screenshot, Steps to reproduce the issue, Actual result, Expected result are included in the description.
In Affect Version field, the current build version the project is selected in which the issue has been encountered.
Fix version field is basically selected by the concerned developer people, who choose the version as and when the work for the particular issue has been finished and the issue has been fixed.
Priority field defines which issue should be considered first to be fixed. Tester selects the priority of the issue from the dropdown based on its effect on the application. This example issue is basically of a Medium priority.
In Attachment field, any video or screenshot related to the issue is being uploaded.
In Environment field, operating system and browser details are mentioned on which issue has been encountered.
4) After all the details have been completed, Click on ‘Create’ button displayed on the window to create the new issue.
5) Issue id is generated which can be used in future reference for tracking the progress of the issue.
Security in JIRA
Security setting for any issue is defined or say set either at the time of creation of the issue or while editing the issue. The basic reason for security setting is to restrict the user access to the issue so that not all users are able to work on that issue. Security setting also allows the access of the issue to the member of chosen security level.
Asana is a web and mobile application designed to help teams track their work. It was founded in 2008 by Facebook co-founder Dustin Moskovitz and ex-engineer Justin Rosenstein, who both worked on improving the productivity of employees at Facebook.
History of ASANA
Moskovitz and Rosenstein left Facebook in 2008 to start Asana (named after a Sanskrit word meaning “yoga pose”), which officially launched out of beta in November 2011. The company announced that they had closed a $1.2 million angel round in the spring of 2011 from investors including Ron Conway, Peter Thiel, Mitch Kapor, Owen van Natta, Sean Parker, and former Facebook Director of Mobile Jed Stremel, followed by a $9 million USD Series A round in investment led by Benchmark Capital in late November 2011. On July 23, 2012, Asana announced a new round of funding — Peter Thiel and Founders Fund, along with existing investors Benchmark, Andreessen-Horowitz, and Mitch Kapor, have invested $28 million in Asana; Thiel also joined Asana’s Board of Directors. According to a New York Times article and someone briefed on the funding, the investors valued the company at $280 million. Some of Asana’s high-profile clients include Airbnb, Dropbox, Disqus, Foursquare, MeUndies, ListenFirst Media, Pinterest, Stripe, Aimia, Zendesk, General Electric, Samsung, Harvard University, Tesla Motors, NASA, and Uber.
Why is ASANA popular?
Asana is web based software-as-a-service designed to improve team collaboration. It focuses on allowing users to manage projects and tasks online without the use of email.
Each team can create a workspace. Workspaces contain projects, and projects contain tasks. In each task, users can add notes, comments, attachments, and tags. Users can follow projects and tasks and, when the state of a project or task changes, followers get updates about the changes in their inboxes.
In May 2013, Asana launched Organizations, which enables companies to adopt Asana at enterprise scale. Organizations added an Asana Team Browser, a user dashboard, employee auto-join and IT administration abilities related to provisioning and permissions. In January 2015 Asana released its native Android app.
In June 2012, Asana announced a new feature called Inbox that aims to help teams minimize the use of email. As one step towards building a “post-email application”, Asana’s Inbox shows “updates to tasks, comments, due date changes, and other status updates people would normally reserve for email.”
In April 2012, Asana released its API to third-party developers. Asana is integrated with productivity tools including Dropbox, Evernote, Google Drive, Harvest, Instagantt, Jira, Zendesk, and DigiSpoke.
Business Plans of ASANA
$9.99 per member per month; billed annually. Powerful enough to run an entire business.
All the power of Premium, plus more control and support. Clients like Uber, etc use this plan.
What is PHABRICATOR
Phabricator is a complete set of tools for developing software. Included apps help you manage tasks and sprints, review code, host git, svn, or mercurial repositories, build with continuous integration, review designs, discuss in internal chat channels, and much more. It’s fast, scalable, and fully open source.
Completely open-sourced, startup tested, and enterprise scalable. PHABRICATOR contains no special editions or user limitations. It’s completely free, and always will be. Download Phabricator and install on your own local hardware.
Keep your team focused on building your products. If you’re not interested in maintaining your own infrastructureLeave the backups, updates, and maintenance to PHALICITY.
Pre-Commit Code Review
Review others’ code with Differential, because they can’t be trusted.
· Shows code so you can look at it.
· Leave helpful comments and anecdotes.
· Challenge the intern’s test plan.
· Gently place bad code back in the author’s queue.
Supports Git, Mercurial, and SVN
Host Git, Mercurial, and Subversion repositories with Diffusion, or connect an existing repository elsewhere.
· Can host repositories locally.
· Observe repositories hosted elsewhere.
· Publish any repository to mirrors.
· Proxy a repository for reading from another source.
· Scale to multiple servers.
Audit Source Code
Phabricator supports post-commit auditing, either as a primary workflow or, when coupled with Herald, allows rule based triggers to get an extra set of eyes on your code.
· When used with pre-commit code review, provides additional coverage where it matters to you most.
· If you can’t review, cover what you can with Audit.
· Use Herald to trigger audits on whatever phase the moon is in.
Customizable Task Management
Plan features, track bugs, and award tokens. Maniphest lets you customize input forms, use custom fields, and has a rich API.
· Keeps track of lots of bugs.
· You can assign them to people.
· Maybe you could fix them, eventually. (optional)
· Build unique task forms for every department.
Command Line Tools
The arcanist command line tool gives you CLI access to most of Phabricator’s functionality.
· Runs lint and unit tests before code review.
· Emits patches that usually auto-apply.
· Runs on Linux, Mac OS X
· Also “runs” on Windows.
With Conpherence keeping up with where your team is having lunch is just a few clicks away.
· Chat with co-workers
· about work.
· Like Slack, but nowhere as good.
· Seriously, Slack is way better.
· Join our chat sometime.
Phabricator is under active development, and have accepted patches from hundreds of unique contributors to date.
· Most patches make it better.
· Only some break it.
· Written in PHP so literally anyone can contribute, even if they have no idea how to program.
· Even babies and dogs can contribute (with supervision).
Broad Appeal: A new feature must be useful to many different users at many different organizations.
Also, these users and organizations must actually exist in reality, not just as hypotheticals. Will essentially never implement a feature which solves a problem for only you personally or only your organization.
Problem Fit: A feature must represent a good solution to a real problem which we have a deep understanding of.
Sometimes, problems are really rooted in cultural, organizational, or process concerns. Will usually decline to implement features which work around cultural or organizational problems, and recommend you try to fix those problems instead.
We must understand problems before we implement features to solve them. If we do not understand the problem we’re solving, we can’t maintain the feature.
Robust: A feature must be secure, scalable, and reliable.
Will generally decline to implement features which have significant security, scalability, or reliability concerns which we cannot overcome.
Supportable: A feature must be reasonably easy to maintain, test, and support.
Will generally decline to implement features which are very difficult to test or maintain or likely to be confusing or overwhelming for a new user. (may be able to find a similar approach which is easier to understand.)
Features which add a new configuration option or checkbox generally make the product more difficult to maintain and support, and face a higher barrier to upstream adoption.
General Purpose: Prefer features which solve many different problems for many different organizations over features which solve a narrow set of problems.
After gaining a deep understanding of the problems several organizations face, can often build a general purpose toolset for an entire problem domain.
Aligned WithStarmap: A feature must align with our long term plans for Phabricator, and generally be a cohesive and consistent part of the product and platform.
Will decline to implement features which conflict or interfere with our overall plans.
The developers of PHABRICATOR say :
Our primary goal in planning is to maximize throughput. By planning, we’re trying to identify how we can build the most valuable things in the shortest amount of time.
Creating an accurate long-term forecast is not a planning goal. Forecasting is a means to an end: the real goal is throughput. Forecasting can help with this, but it is not intrinsically valuable. If the goal of planning was to create accurate long-term forecasts above all other concerns, the best plan would be “we will do nothing” followed by doing nothing. This would always be accurate.
For some companies, accurate forecasting may be important to throughput. It is difficult to coordinate across teams to accomplish large strategic goals without good scheduling and forecasting capabilities. If you have multiple teams, high communication overhead, developers with specialized expertise, complicated dependencies between projects, external timelines, or goals bound to hard scheduling requirements (like a launch window, the construction of a datacentre , or hardware fabrication), good scheduling and forecasting may be important to achieving throughput because the cost of changing direction is very large.
However, we have a small team and essentially all of our strategic goals are software goals that can be accomplished iteratively and paused and resumed at any time. Our product and process are architected to support iterative development. We can reassign development resources freely and have a very low overhead and few technical dependencies or external timelines. The cost for us to completely rewrite our plans is nearly zero.
In almost every case that we have an opportunity to improve throughput by rewriting plans, we’ll do so. This improves throughput overall, but makes long-term forecasting impossible.
Integration of New Information
Because our goal is to maximize throughput and we can rewrite plans very cheaply, we frequently rewrite plans when new information becomes available which allows us to develop a better plan with higher throughput. For example, here are some kinds of information we might learn which might cause us to change our plans:
· We may learn of very important issues like security vulnerabilities.
· We’re heavily driven by our understanding of problems and use cases, and often change our plans in response to changes in this understanding, but cannot always anticipate how users will receive or interact with a feature before we build it.
· Some kinds of changes can be made more efficiently if we complete multiple features in the same area of the codebase at the same time. If something gets prioritized, this often means that it makes sense to prioritize adjacent changes so they can be completed more efficiently, even if they wouldn’t otherwise have been a priority: one planning change can cascade into many planning changes.
· Some aspects of our business are driven by customers and contracts, and we cannot always anticipate the business needs of customers. We may learn that they have new needs, or that their needs have changed.
· We sometimes start building something and realize it’s a lot harder or easier to build than we’d thought, for a variety of product or technical reasons. This could lead to us making planning changes.
Companies built on PHABRICATOR
Thank you for reading such a long article, hope you get some insights into how a good software project management tool can be evaluated.