If you are not familiar with modules, check out Ansible - Getting Started with Modules.

The debug module can be used to print output.  In this example, "Hello World" will be printed.

---
- hosts: localhost
  tasks:
  - debug: 
      msg: "Hello World"
...

Or like this.

---
- hosts: localhost
  tasks:
  - debug: msg="Hello World"
...

When the play is run, the following should be produced.

TASK [debug]
ok: [localhost] => {
    "msg": "Hello World"
}

Almost always, name is included so that some unique text in included in the output so that you know what debugging task is being executed.

---
- hosts: localhost
  tasks:
  - name: something unique
    debug: 
      msg: "Hello World"
...

Notice here that something unique is included instead of just the text debug.

TASK [something unique]
ok: [localhost] => {
    "msg": "Hello World"
}

In this example, the vars plugin is used to create the foo variable. The debug module can be used to print the output of the foo variable.

---
- hosts: localhost
  vars:
    foo: "Hello World"
  tasks:
  - name: output the foo variable
    debug: 
      var: foo
...

Or like this (notice the single quotes around foo).

---
- hosts: localhost
  vars:
    foo: "Hello World"
  tasks:
  - name: output the foo variable
    debug: 
      var: 'foo'
...

Or like this (notice the double quotes around foo).

---
- hosts: localhost
  vars:
    foo: "Hello World"
  tasks:
  - name: output the foo variable
    debug: 
      var: "foo"
...

When the play is run, the following should be produced, regardless if foo is unquoted, single quoted, or double quoted.

TASK [output the 'foo' var]
ok: [server1.example.com] => {
    "msg": "Hello World"
}

Let's say your vars/main.yml file contains a different username for each environment.

dev_username: "john.doe"
stage_username: "jane.doe"
prod_username: "jack.doe"

Here is how you could define the username using set_fact and vars. In this example, "env" would most likely be set using the -e or --extra-vars command line option.

---
- hosts: localhost
  vars_files:
    - vars/main.yml
  tasks:
  - name: username
    set_fact:
      username: "{{ vars[env+'_username'] }}"

  - debug:
      var: username
...

Often, debug is used along with the register module. In this example, the standard out, standard error, and return code of the ls (list) command will be stored in a variable named "out". You can then print the output using the debug module, like this.

---
- hosts: localhost
  tasks:
  - name: list command
    shell: "ls /tmp"
    register: out

  - name: standard out
    debug: 
      var: out.stdout_lines

  - name: standard error
    debug: 
      var: out.stderr

  - name: return code
    debug: 
      var: out.rc
...

The msg parameter is similar to the var parameter, except that the msg parameter can use Jinja2. Notice the double curley braces {{ ... }}. Jinja2 uses double curley braces for variables.

---
- hosts: localhost
  vars:
    foo: "Hello World"
  tasks:
  - name: output the foo variable
    debug: 
      msg: "{{ foo }}"
...

When the play is run, the following should be produced.

TASK [output the 'foo' var]
ok: [server1.example.com] => {
    "msg": "Hello World"
}

Notice in this example that foo is wrapped in quotes. In Jinja2, when wrapped in quotes, foo is interpreted as a string. If foo were not wrapped in quotes, foo would be interpreted as a variable.

---
- hosts: localhost
  vars:
    foo: "Hello World"
  tasks:
  - name: output the 'foo' string
    debug:
      msg: "{{ 'foo' }}"
...

Which should produce the following.

TASK [output the 'foo' string]
ok: [server1.example.com] => {
    "msg": "foo"
}