I'd like to open this presentation with the question: why Atlassian?
Atlassian vs. the World is the first slide.
It shows Atlas, a Greek Titan who carries the Earth on his shoulders.
Why?
Atlassian's core task was to create a set of tools that would suit each company.
Maybe not universal, but possibly the best and matching their needs.
We should be aware that Atlassian isn't the only company on Earth with such products.
For instance, Jira is one of Atlassian's products.
It's right here on this list.
In general, I came across this list on Wikipedia.
It contains 128 tools similar to Jira.
Of course, Atlassian has many more tools than just Jira.
However, I already know that even this list isn't complete.
There are some new products on the market, and each of them is dedicated to a slightly different field.
Why Atlassian then?
Together with my colleagues, we decided that we want to cooperate with a company
which gives us the most possibilities.
Atlassian boasts a very flexible set of tools that you can optimize as you wish to your needs.
That's it, probably.
What do we gain from the basic Atlassian Stack?
It enables us to plan and execute projects, structure tasks within these projects,
collaborate with clients, both internal and external because our employees are our clients as well;
create documentation and knowledge base of all products we developed for ourselves or our clients;
team collaboration, I'll explain more later about what's the matter with this one.
You can for example eliminate a large chunk of emails that are slippping through the cracks.
This set of tools also allows to work with the code.
This is the basic scope of work we'll be discussing today.
The core tools of the Atlassian Stack are:
Jira Software, Jira Service Desk and Jira Core - these are the fundamental tools for everything else.
Of course, these tools can work independently.
The tools from other two columns can work separately too.
However, we should be aware that Atlassian developed all that in such a way to create an ecosystem,
which is connected and can be an integral whole.
These aren't all the tools, there are more of them. These are just the core ones.
Today, we'll focus on several different tools.
Apart from the products you see here, be aware that Atlassian isn't only about the products
but also their support.
If our licence is active, we have Atlassian's support.
Marketplace meaning the apps that extend Atlassian's flexible tools even more.
Community is where Atlassian's clients communicate, share best practices. It all works.
Blogs, whether Atlassian's, its clients or its Partners (we also have one), focus on these tools.
Developers and Atlassian University are more advanced channels for those
who want independently develop and actively take part in the development of Atlassian's tools and plug-ins.
Like we do.
The apps we see here are the ones we'll focus on today: the basic three from Jira,
Confluence as the support in writing documentation,
and Bitbucket as the code control repository.
Plus, of course, Marketplace but this will be frequently mentioned through the presentation.
What has Jira Core to offer?
Most importantly, clear and intuitive user interface.
Honestly, when I used Jira for the first time, I was impressed.
It took me half a minute to learn where is what and for what I can use it.
With other tools similar to that, UI wasn't that clear. It took some time,
sometimes, I had to ask someone from another team "why this?", "where is it?",
"how can I do this?", "oh, I actually can't".
When it comes to Jira, it's very clear and easy, which you'll experience soon.
A work review from multiple perspectives; we'll discuss it in detail on the next slides.
Easy-to-use and powerful search engine, the tool that is very often underrated,
as well as JQL (Jira Query Language), the proprietary language developed by Atlassian.
Work reports - because, as we all know, we often need to report what happens in the system.
Building different functionalities; workflow;
elastic configuration;
thorough permission control;
and integration with other tools and plug-ins.
We'll be exploring all of this in Jira Core.
Moving to the user interface.
What stands out is the multitude of elements.
We can already see what is displayed on the screen in Jira.
On the left, there's the panel with issues/tasks in progress.
The most important information is in the middle.
At the top, there are elements for different actions: editing these issues,
assigning to people, cloning, copying, linking, creating subtasks, etc.
The variety of options available in the workflow.
Below is section with details about our issue.
Here are only the basic fields like issue type, priority, affected versions, etc.
This Details section is extendable, meaning that we can configure our project, add addtional fields
and make them visible when creating an issue.
Of course, an empty field won't be displayed on the screen.
Description is a text field with the basic wiki markup.
In this case, I used a short text, linked a file, created a table with two examples of our logo.
Below are attachments which we can see by clicking on the section.
Underneath, we have "Issue Links".
If there are any issues connected to each other, then we'll find them here.
Subtasks are the subissues that need to be done, often by other people.
And below that we have activity.
On the right, there are people responsible for the issue.
In this section, there are assignees and reporters.
Remember that if we create more "people" fields, no matter how we'll name them,
approvers or watchers, they will also be displayed in this section.
Next is date section where we have:
the due date, the date when the issue was created and updated.
This section, just like the People section, can be also extended.
We can enable or disable time tracking, depending on whether we need it on this issue.
An interesting thing is that we can include time estimation of subtasks into the parent issue's time tracking.
Another section is HipChat Discussions.
I haven't mentioned HipChat, but some of you probably know
that HipChat is Atlassian's messaging app for businesses.
So, there's the possibility to integrate your Jira with other tools.
Jira Core, project management app.
You can see here an example of the most messy dashboard ever.
After logging in to Jira, we're directed to our dashboard.
On the top left, we see our kanban board,
a pie chart in the middle,
on the right, we have preview of various issues.
Of course, you can customize your dashboard to match your needs.
Activity stream,
current vs. resolved chart.
In general, there are several dozens of gadgets we can choose from to be displayed on our dashboard.
We can customize the amount of columns and where these gadgets are placed.
Rememer that you can create more than one dashboard
to create different perspectives for various users, teams, sometimes clients or managers.
It all depends on us.
Easy-to-use and powerful search engine.
This slide won't show the full potential of Jira when it comes to searching.
There are also microsites (in here it's project selection),
task and idea are the selected types of issues,
status, the issue's reporter, and more.
The more fields we select for the filter, the shorter the result will become.
You can do it in a blink of an eye,
from selecting to displaying the results.
It also depends on our instance, if it's Server or Cloud,
yet it works smoothly anywhere.
Atlassian did their best to make searching efficient and fast.
There are times when we need to find more and dig deeper for more detailed information
or invert something.
Imagine that our company has a thousand employees,
and we want to view this one specific employee and all her issues.
We simply select this employee from the list of a thousand other people,
and we see all the issues assigned to her.
But, what if we want to select all employees but this one user?
There's no easy way of selecting 999 users, and exclude this specific one.
It would be illogical.
You can use other methods, i.e. JQL
so a textual description where you can replace "equal to" with "not equal to" in the code.
Then we know that we'll select all users but this specific one.
The textual description presented below is an example of a somewhat modified filter
which I use in my work everyday to see all issues assigned to or reported by me.
Work reports.
It would take some time to go into details about what each of these reports stand for
so I won't do it,
but remember that there are different types of reports:
workload pie chart report,
version workload,
user workload,
time tracking.
We can extend our choice in reports by using plug-ins.
Are there more core elements of Jira Core?
Creating your own functional workflows.
On the slide, you see a workflow originally implemented in Jira.
Remember that you can customize each of these elements:
change their name;
add a new step;
delete a label that's already in there;
change transitions between the elements,
so these arrows that show the specific transitions - for example, Stop Progress or Reopen.
There can be many more transitions, and we can customize how each of these appear.
We can configure: who can perform this transition,
what are the additional input validators,
what fields are obligatory,
what additional permissions you need,
maybe being linked to other issues or systems.
Performing a transition can carry out any additional processing, i.e.
by completing task A, complete task B, its subtasks or update other information within a specific issue.
You have a free hand in adding post functions.
What we can do with our transitions somewhat depends on the plug-ins
which will extend our post functions.
Elastic configuration.
Here we have administration panel for a project.
I won't go into each of these elements.
But, you sure can see that in almost every name we use "scheme".
Meaning that we're not doing only one configuration for a specific project,
but we're creating a configuration scheme either for fields, issue types, displayed elements,
or what someone can do within the task.
All of these are saved as schemes which we can use in various places and projects.
We can also create a couple of lookalike projects assigned to different people
and we can use the same schemes again without other changes but the assigned people.
As you can see, configuration is very elastic,
we can create schemes, use them in various projects, modify them,
which gives us a great potential for our projects and whole Jira.
Thorough permission control.
A good deal of small companies don't realize how important permission control is,
not because of lacking trust but for smoother project executions.
Here are some of these permissions:
who can close issues,
create issues,
delete,
edit,
link to other issues,
modify a reporter (this one is rarely used),
move,
resolve,
or who can administer or even just browse the issues within a project.
On the right, who can add, edit, and delete comments.
These are just a few types of the permissions we have available in Jira.
And here we have information about who can do what, for example:
close an issue,
someone who's a project administrator
or belongs to the service desk team.
Of course, we can edit all the elements on the right side,
meaning that we can add specific people, user groups,
people with specific roles, such as approvers,
we have a free hand in configurating all this.
Integration with other tools and plug-ins.
I've mentioned Marketplace apps about three times already, but remember that there's still more of that.
Here we have, for example, integrations with other systems.
At the top, we have HipChat box, the internal communication system -
on the top left we have rooms, on the bottom left we have people we have conversation,
beside that there are also issues highlighted in blue, for example DF-138.
Every issues has its own room where people can have converstations
and where we can find the activitiy in this issue.
On the bottom right, there's a section dedicated to Tempo Timesheets.
The representants of Tempo are here with us, so there's an opportunity to talk with them.
This plug-in extends Jira to include accurate time tracking reports, work callendars.
It's worth to consider this plug-in.
That's all when it comes to Jira Core.
Now is the time for Jira Software.
Jira Software includes everything that's in Jira Core
plus Kanban and Scrum boards,
the latter of course with sprints and backlog,
as well as additional issue types: Epic and Story.
in general, we create our own issue types, naming and configuring them as we wish
to make them work in a specific way.
But, Epic and Story are quite specific, because they have different functions
which are predefined by the system.
Anyone who works in Scrum knows what Epic and Story are for.
Jira Software adds to the standard Jira Core reports the Agile ones,
such as burndown charts,
estimations, sorry, maybe some...
Sorry, I was miles away for a moment there.
We'll get back to the reports in a moment.
Integration with other tools and plug-ins.
This last point is like in the case of Jira Core,
however these integrations are quite different.
Kanban boards meaning our sticky notes which we place in the columns,
each of these columns can stand for the statuses in our workflow,
but we can also place several flows in a column if they won't colide with the transitions.
Plus, what we see on such issues is closely connected with what filtres we created earlier for them.
As I already mentioned for Jira Core, we use default or advanced (JQL) filtres for issues,
And we base the board view on these advanced search results,
so we can limit our board to what we need to see.
At the top, there's also "Quick Filters" with "Only My Issues", "Recently Updated" and "On Fire".
These are also exemplary quick filters to sieve out the issues we're not interested in at this particular moment.
We can do much more, but there's not enough time to talk about all this.
Here we can see how we work on Kanban board.
Generally, you take one issue, SKP-10 and
drag it to the right status (Done, Hold, etc.),
and it will stick there.
Dedicated issue types: Epic and Story,
I've mentioned them earlier already so we can move forward.
And what we see here is of course an issue type scheme for a software project.
It's not a closed list, so we can edit it and add new issue types,
and each of them may function differently.
Scrum boards and sprints.
What's the difference between Kanban and Scrum boards?
Ignore the right sidebar, it's a preview of an issue.
This panel is the same in both Kanban and Scrum boards.
Here we have information about the issue.
What does Scrum have that Kanban does not?
At the top is displayed information "0 days remaining. Complete sprint."
It's clear that we run out of time in the sprint and we can finish it now.
After we finish a sprint, we receive a report which sums up the sprint.
We can save it in our Confluence, which we'll discuss later.
On the left, we have an administration panel of the whole project, and not only the issues.
Here we have backlog, active sprints and releases.
In Kanban, we wouldn't have active sprints nor the backlog, we would have just a board.
After we finish the sprint, at the bottom right is displayed an information
about what was done, what wasn't done, and what to do with what wasn't finished -
- if we should to place it back into the backlog or put it in the next sprint.
Backlog is a list of issues/tasks to do.
At the top, we have our first sprint "Lech for Forum".
Below, there's our second sprint "NSP Sprint 5", and after that is "Lech 2".
Everything else that's not in the sprints, is listed underneath our planned sprints in the long list.
If we want to put an issue/task into our sprint, we can simply drag it there,
just like we did earlier with dragging tasks between the columns in Kanban.
On the left, there's a column with versions and Epics.
Clicking on either of these columns,
we can eliminate from our backlog all issues/tasks
which aren't included into this Epic or version.
In this view, we're able to see how many issues are in this version.
Here we can't see it, but we also can create a new issue in this version or Epic.
On the right, there are three colours: blue, yellow, and green.
This is our story points estimation, connected to the realization of our ongoing sprint.
Story points can be also replaced with time estimation.
Agile reports come in handy, but we won't discuss them in detail.
For those who have never used Jira,
most of the Agile reports are very simple and obvious to use,
I love the Control Chart personally
which enables us to examine
how our work proceeds,
and to uncover the bottlenecks in the process.
Cumulative Flow offers us the same options.
We can discover when we come across any problems,
when we moved something forward.
In general, these are very useful reports.
Integration with other tools and plug-ins.
This screen is from TestFLO, a plug-in developed by Deviniti.
TestFLO adds the possibility to create test cases and cycles,
as well as executing them within an issue.
The middle section is for test cases.
This element is displayed where we can usually find the Description on the default issue view.
And on the right, we have additional information,
waiting, executed,
these are of course steps within a test.
Then we have Actions, so what we can do with such test cases.
Defects connected to the test case, if we have any as an issue type.
And, afterwards, is information about the Agile sprint.
This was an example of a plug-in which is directly integrated with Jira.
However, below there's a screenshot showing that
this is just an integration with an external tool to work with code.
How is it integrated?
We can simply link a project with a code source,
for example Bitbucket (we'll discuss it later) -
the execution of an issue in Bitbucket will also be visible in an issue connected to this change.
Jira Service Desk.
This time it's Jira Core plus Customer Portal.
If the view of an issue I showed earlier was chaotic for you,
or you know that some of your coworkers prefer a clearer view when reporting an issue,
then the Customer Portal is for you.
Creating an issue via the Customer Portal is even simpler and clearer than in Jira.
And you won't need to email or call anyone to report issues anymore,
because you'll be able to effortlessly do this in Customer Portal.
Here we have 3 screenshots of how Customer Portal looks like.
On the top left, we have an exemplary Customer Portal,
where we select one of the sections from the left column:
Common Requests, Accounts, Hardware, Software, Servers and Infrastructure.
And next to this column, there are the specific request types
that you can report in each specific section.
Of course, the request types vary depending on the section.
Remember that they are also configurable.
So, each of these elements and the length of this list can be arranged separately.
Moreover, we don't have to limit ourselves to one Service Desk within one license.
In general, each Service Desk is a separate project,
meaning that we can create several Service Desks:
one for our A team,
another for B team,
another for our external clients,
and another for our Partners.
What do we have here?
Here is another example of a different Service Desk.
So it's clear that they're configured differently.
And on the top right, we have a screenshot showing the dashboard with issues displayed for a reporter.
This dashboard is a simplified queue of issues reported by the user,
either open, closed, created by the user or within an organization,
which has access to shared issues.
SLA timers and live issue queues.
I called it live issue queues for a reason.
Why live?
When it comes to issues queues, we can use either ITIL or any other process,
just as we saw earlier with query search in Jira Core or issues queue next to an issue's view.
In Service Desk, issue queues are live because they're updated automatically.
Not every 15 minutes like, for example, gadgets on our Jira dashboard,
not manually by clicking F5 on the keyboard or refreshing the page.
They update automatically as soon as something changes within an issue,
and will be visible on this queue.
On the left, we have a full list of our queues.
This exemplary list was created by Atlassian,
and under this list we have the "new queue" button that enables us to create our own queue,
which will also use JQL to filter our issues that we want to keep track of.
We also have SLA timers.
Time to resolution according to the settings of SLA timer.
There's nothing to add here, because we can see everything on the example,
where we breached SLA, SLA is about to breach,
issues realised within the time limit,
or paused issues, because we can also configure our SLA timer to pause when needed.
And, automation.
This element is crucial because it enables us to automate some actions within one Service Desk,
for example when the reporter of an issue adds a comment.
Imagine that the issue was done, the reporter added a comment, and the issue is reopened.
For example, this automation option "be aware of urgent issues" can send an email to a right person,
either a reporter or asignee of an issue,
this email can inform that, for example, the issue is about to breach or already breached the SLA.
Other automation options are for example queuing issues,
setting customer expectations,
or creating our custom rule.
In my opinion, "update when a linked issue changes" is an interesting option.
Why is it important?
With Jira Service Desk and Jira Software license, we can create a special link
which will work in such situation:
client reports an issue via Customer Portal,
something isn't working in our app and makes it impossible to work,
our Service Desk agent who received this issue knows that's a complex issue,
can't fix it himself nor can she commission a quick realisation,
so it goes to developers who need to fix this issue.
Of course, developers work on Jira Software,
which makes these elements independent in a way.
But, when we set this automation option "update when a linked issue changes",
we can be sure that when the developers will finish they work,
and everything will be approved, tested, and on production,
meaning that the issue will be closed,
then, the linked issue in Service Desk is automatically closed as well,
and our client is informed that the issue was dealt with.
Knowledge base (self-service) and plug-ins integration.
Honestly, when we at Deviniti implemented Service Desk for the first time,
we noticed something interesting:
our clients were more eager to report issues,
because, as you know, we build apps
and sometimes there's a bug or an idea for development to one of the plug-ins.
And that's what we get from our clients.
Either way, our clients were more eager to report issues via Customer Portal than via Jira.
Moreover, our clients were reporting us even less issues with for example configuration,
when we linked our Service Desk to our knowledge base.
Thanks to this, whenever they wanted to report an issue,
they immedietly got a clue about how to solve it.
We can see it on this example: when we write an entry "printer",
two first results are articles from our Confluence knowledge base.
Only under these two articles, we have options to report this issue,
if we haven't found the solution in the articles.
How does such an article looks like?
By clicking on the first link on the list, we're directed to the article with solution.
This article is pretty simple, accessed directly from Confluence knowledge base,
and gives us the solution for our issue.
If our client is satisfied with the solution, they can click on the thumbs up icon which is under the article.
Or, if the article doesn't solve their problem, then they can click thumbs down.
Of course, we can access such data in reports,
to see how many article with solutions for an issue are really valuable,
and to see how many times users reported issues even after reading an article and what were these issues.
Here we have an example when someone writes this entry "printer", ignores the two first links to articles,
and clicks on the icon of the specific section.
The user is directed to the page where he can create an issue.
This page consists of simple field, summary, and some additional information.
These are three basic fields, but we can add more fields on the Customer Portal.
Even though our user didn't click on the article on the main page,
and when he started entering "printer problem" in the summary,
our knowledge base suggested the possible solutions for his problem,
this time displaying them on the rights side of the form.
On the top right of the screen, we have an exemplary list of plug-ins
which can extend the functionalities of Service Desk.
This list contains over 600 apps.
So, if you have a specific requirements for Service Desk,
then you can easily extend its possibilities.
As I can see, on this list are also Deviniti's plug-ins,
meaning that we also offer extensions for Service Desk.
Moving to Confluence.
We already mentioned its knowledge base used to give ready solutions to our users in Service Desk.
Confluence also offers us a documentation storage, a wiki-based team collaboration tool,
a flexible content editor,
and the possibility to import the content.
These are the most basic information about what we can do with Confluence,
and there's much more of this, but we don't have enough time to discuss all of this today.
So, starting with knowledge base.
On this example, I chose red instead of blue for my header.
Let's say it plays a key role in customer service.
So, I created a special knowledge base space on my Confluence
where we save all of our information and which is directly linked to my Service Desk.
Meaning that if I use this "search for a solution" search engine,
I'll get the same solutions our client found earlier on Customer Portal.
However, I can define my search results in a different way.
I can define, for example, that I want only the solutions about a specific subject area or with a specific label.
So, we can modify our search results.
All of the elements on Confluence - horizontal lines, additional information,
browse by topic or recently updated articles sections - everything we see on this space
is only an example of our creativity.
We can modify every space on Confluence, either knowledge base or any other, as we wish.
In the left column, we have a shared element called Page Tree with all the spaces we use.
Here we have another example of a knowledge base space for Deviniti's TestFLO plug-in.
This was our first knowledge base for our Service Desk,
and it contains over 20 "how-to" questions and over 20 "troubleshooting articles".
From these over 40 articles, we obtained insight to
how much our clients can do by themselves if we give them the chance.
This is only an example of a single page.
It's very simple, but in general we can design our pages better.
And, if we're not too big fans of the interface,
we can use for example the app from RefinedWiki,
it's an extensive plug-in expanding the visual and navigational possibilities in Confluence.
Of course, it's only an addition to Confluence.
Next, we have documentation and wikipedia.
This is an example of our start page for our plug-in TestFLO and its documentation.
It contains a few columns divided into sections with specific information.
Of course, there is a search engine under the FAQ section,
and it will also direct us to the right chapter listed in the left column.
It's only an example of a simple page,
because we aim for simplicity, as does Atlassian.
When it comes to pages in Confluence, some say that they don't like it.
Truth be told, Confluence isn't a tool that must wow us during the purchase.
We buy it for its functionalities.
People use Confluence in various ways only after working on it for some time.
And this is one more documentation example of our another plug-in, IssueSYNC.
These pages look differently.
We can, for example, show or hide the content of specific sections,
hyperlinks in blue that will direct us to the right elements,
graphics.
We can also add some multimedia materials.
We'll talk about it soon.
But, moving to the team collaboration.
Beside the wikipedia and Service Desk, this is the core functionality of Confluence.
To a large extent, Confluence is able to change the communication in our company.
Thanks to this, we can eliminate a chunk of emails;
those who work with emails a lot know how often there's a lost attachment or CC and BCC recipients.
Sometimes, such things just happen.
On the screen, it's only an exemplary page of team collaboration.
This is my team of three, among them is a key user - someone who collaborates with the other two.
On this team space are some additional tables, i.e. a list of subpages with meeting notes.
There's an additional button "create new meeting note" created by me;
when I click this button, I'm directed to a page with a predefined template dedicated to meeting notes.
This is a simplified example of such a dedicated page.
Here we have additional information about the date of the meeting,
the attendees - we put @ (at mention) before the attendee's name.
We all use it in social media when we mention something and we want this person to be notified.
The same goes for Confluence - if we use @, then the right person is notified via mail and Confluence
that they were mentioned in such article, on such page, and they should check it.
After attendees, we have goals of the meeting.
Then, we put discussion items into a simple table.
Another interesting thing is action items, which has not only @ but also check boxes.
By using @ after the checkbox and writing something there,
the mentioned person will be notified that there is a new task assigned to them in Confluence.
This isn't linked directly to Jira, but we can do that.
However, Confluence has Tasks section, where each person can view tasks located on various pages.
We use it regularly,
especially when it comes to big projects where we have to write down a great deal of things in documentation,
check up dozens of elements, mostly on the beginning of the project.
Below, there's Comment section, where we as well can use @ to notify the right person.
And on the right side, we have inline comments - the yellow strip along the comment means that
this comment is linked to this text highlighted in yellow.
The same functionality is in Office, where we add inline comments to only the element we're interested in
and not to the whole page, which saves us the unnecessary scrolling down the whole document.
We can create threads from inline comments.
As we see on this example, there are only two replies,
but communication of our team can be based on such threads to a specific element.
Flexible content editor.
I've already mentioned design and RefinedWiki,
but here we have an example of a demo starting page created by me.
This example shows that Confluence can be appealing and clear.
An image on the top of the page, below that a YouTube video,
then section with our employees, where we can create some structure, list people,
import data from their profiles,
or link an email to make contact with someone easier.
On the right, there's a news feed, which is a RSS section which shows new articles,
we can also define if we want to display whole articles, only the headlines, how many of the news, etc.
Below news feed, we have "helping hand section" with two different search engines.
We've already discussed these search engines earlier:
the first one that directs us to Service Desk to find answers for most common questions,
and if we won't find there any, we can create a Service Desk ticket by clicking on the link.
It's not predefined, but we can create it ourselves.
The second search engine is for TestFLO plug-in with the direct link to documentation.
This is only an example of the starting page, but how does it look when we edit it?
Well, let's ignore this element on the top right for now.
On the left, we see a bit of the image from before,
widget connector which contains video from YouTube,
"Our People" section with users,
as we can see there's this element which imports data from the users' profiles from our user base,
meaning that whenever something changes in our base, the data in this section will update automatically.
These elements are divided into panels,
we can work on various sections.
On the right, we also have such elements as:
search engines as configurable element,
text with hyperlinks,
list with favourite pages, which wasn't displayed earlier because there were none there,
and another panel with another elements.
Is it difficult?
No.
It's very easy, very intuitive.
Each of these elements visible here are like another Lego pieces we add to our design.
We can do it by selecting macro, which we can see on the top right.
List of these macro contains about 60 or more elements,
and each of them has different configuration or possibilities to display content, aggregate, etc.
Really, these elements have countless possibilities.
Additionally, some apps can add new elements to these macros and enable us to use them on our pages.
Also, Confluence is a means to dynamically import content.
We all probably know these icons.
What's the big idea of this content import?
There's a few options:
first - when we have Word files, we can add such document as attachement to our page,
then we can use macro which will display it as element on our page.
We can edit this document from there, it will direct us to Word,
we can make changes in the file, save them, exit Office, and it will be automatically updated on the page.
Another way to do this is to use import option.
We create a new page, import the file to the page, and it will be automatically displayed on the page.
If the file has more than one page and includes appropriate sections, it will be imported as a page tree.
Second - Excel.
Our excel file will be displayed,
but remember that it won't be the whole Excel with its advanced formulas,
because Confluence won't be able to restore them.
But the basic Excel file without any scripts will be displayed correctly for sure.
Third - PowerPoint presentations.
We also can import PowerPoint presentations to enable other users go through them.
For example, when we create a section for new employees.
Whenever someone new joins the company, they need to go through OSH instructions,
how to work with tools, etc,
they're sent to this learning section where he can browse through the PowerPoint presentation.
They can do it in Confluence without downloading the file to open it in PowerPoint.
The last one is PDF.
We can display such file as well.
It's worth to remember that we can also export single pages to Word and PDF.
Additionally, we can also export whole spaces to PDF, Word, and even XML.
Last but not least, Bitbucket.
I don't know how much time we have left, so I'll go through it quickly.
We should make it in 8 minutes.
What is Bitbucket?
Bitbucket is a code repository based on Git.
In general, every developer knows what Git is.
Bitbucket is a Git overlay which allows us to work with the code in more non-developer, business-like way.
It makes work easier for developers, for example creating new code branches in this tool.
As you probably already guessed, Bitbucket integrates with Jira.
This integration enables us to view our code branch in Jira.
By adding Jira issue key to the title of a code branch, we link Jira issue with our branch.
Bitbucket's integration with Jira issue view, integration with HipChat.
On the left screenshot, we have this column which in Jira is on the right.
In this column is People section, Dates section,
Collaborators in case of Service Desk issues,
and Development with data visible thanks to Bitbucket.
This data contains information about branches, commits, and pull requests.
We'll talk about pull requests in a moment.
On the right, we also have detailed information from Bitbucket Server about commits listed on the left screen.
and we can go directly from Jira to these commits in Bitbucket.
And the same goes for branches.
Additionally, we can create a branch directly from a Jira issue.
Next, in the left column we have HipChat discussions.
I don't have HipChat integrated here, but remember that such integration with Bitbucket is possible.
Actions on Jira issues.
I think I mentioned it earlier when we talked about Jira Software.
What we see here is a very clear view of the whole process of creating and merging the code branches.
When we merge code with the master, or main, branch at some point,
we can automatically make a transition on our issue in Jira Software.
This can happen when we integrate Jira Software with Bitbucket.
Pull request, so a request for a merge of the code, and code review.
All this is displayed in one place.
Generally, we have a list of pull requests, also visible in this panel we've seen earlier.
In this view, we see their status - if they are merged or declined.
There's additional information about who were the reviewers of this code
So, our pull request is a request for a merge of our code branch with the main source,
but we can't do this merge ourselves.
There's someone who supervises merges.
When someone accepts our code, then it can be merged to the main source.
It's a good thing when we have a junior developer or whoever,
or it's simply our policy that every piece of code needs to be verified by another developer or a tester.
And, work progress reports.
It's just like in the case of other tools discussed earlier, so I won't talk about the details here.
As you can see, there's quite a lot of reports.
We have various possibilities to display these reports, charts, what they contain,
what was the work progress through some time, what were the versions, etc.
That's all from me.
If you have any questions after this presentation, I'm here at your disposal to talk.
Không có nhận xét nào:
Đăng nhận xét