<commit_before>= Lab 05 Work Management: Kanban and further use of git.

In this lab, you will extend the pipeline to support Kanban work management coupled with further git techniques.

Lab objectives:

* Develop a manual Kanban board and convert it to an automated system.
* Learn the basics of git feature branching workflow.
* Add at least 3-5 small features to your product, using your team's agreed end to end workflow.

As in https://github.com/dm-academy/aitm-labs/blob/master/Lab-04/04-tech-lab.adoc[Lab 04], it is recommended you have 2 terminal sessions open, one for X windows, the other for product development.

== Manual Kanban

Using either whiteboards or large Post-it sheets, create a kanban board for your team/product. The precise structure is up to you, but it should include:

* Incoming feature work & todos
* Story development
* Feature development
* Testing
* Deployment

Each column is "owned" by the appropriate person on your team, from the organizing you did in https://github.com/dm-academy/aitm-labs/blob/master/Lab-04/04-tech-lab.adoc[Lab 04].

Use small Post-its for the features as they move from left to right.

[cols="2*", options="header"]
|====
|Kanban column |Owner
|Incoming feature work & todos |Product owner
|Story development | Business analyst
|Feature development |Developer
|Testing | QA analyst
|Deployment | Tools specialist
|====

Start with this sequence as a baseline. Understand you may adapt it; please be prepared to share your reasoning if you do.

* Product owner conceives high level idea
* Business analyst writes story
* Developer adds a new feature (addition example)
* Developer asks QA to approve (manual pull request)
* QA person commits it to master
* Tools person moves it to production (via cara reprovision)

You are to do this multiple times. Add 3-5 additional features (each at least some words and an object result - see example below) to the generated web page, considering each one as a feature.

Do  2-3 features manually and 2-3 features with an automated kanban tool.

The first time you go through this, the entire team should go through each step, with the appropriate team member leading the activity.

After that, you may be able to accelerate things. This is where some self-organization comes in. Do not use the suggested team structure as a cage. You will find the developers likely have the most work. How can you all work together to deliver features more quickly?

== Git feature branch, with Java example.

IMPORTANT: Although branching workflow in a development organization would be mainly the concern of dev, qa & tools, the entire team should understand this section - you are all accountable as individuals to know this material.

You need to elaborate your git branching strategy so that features have their own branches, and you can have more than one developer working at a time.

Read as a team these two sections on git workflows:

* https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow[Centralized Workflow]
* https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow[Feature Branch Workflow]
(It is not required to read the further sections on Gitflow or forking workflow, but you may wish to do so for your own professional development. Source workflow is a critical topic for development organizations and the examples here are only the simplest.)

We have been doing the centralized git workflow. For this lab you are to work with the feature branch workflow approach.

NOTE: We do not have a capability for automated git pull requests within Calavera. (We do not use Github *within* Calavera. We just use plain git.)
Therefore, your pull requests will have to be handled manually in your Kanban workflow. More below.

The following picture, similar to the Atlassian tutorials, may be of help. (First draft as of 2016-03-11.)

image::workflow.png[]
=== Identify a new feature
Your product feature idea can be extremely simple. Some good starter examples would be:

* Add two numbers together
* Display the team name
* Display a given irrational number to 10 places

Write the idea down, with appropriate detail. For this lab, keep it simple. You might want to have two attached sticky notes: one identifying the task, and the other to actually carry the idea to the BA.

Product owner, your Kanban task is now ready for the business analyst - it meets the definition of done. Do not pull anything more into your queue until this task has been pulled ahead. Instead, if it takes them more than a few minutes to pull your task, go help folks downstream clear their lane.

=== Write a new story
As BA, you should formalize the story more:

"As a user of the website, I want to see two numbers added together so that I have that information."

"As a user of website, I want to see a greeting that is meaningful so that I know which team's site I am accessing."

"As a user of the website, I want to see the number pi displayed to 10 places so that I may have that knowledge."

Business analyst, once it is written in this form, your Kanban task is now ready for QA - it meets the definition of done. Do not pull anything more into your queue until this task has been pulled ahead. Instead, go help folks clear their lane.

=== Develop the new feature

Developer, pull the story from the BA into your queue.

Here we will create a new feature development branch by using the `git checkout -b some-feature master` command.

(You will give your feature a name appropriate to your new feature)

NOTE: A common mistake is to `su publicxx` but then not change to the new home directory. `cd` should always be the next command you execute after `su` for these labs. You do *not* want to remain in your student home directory.

Go:

 :~/Calavera$ vagrant ssh manos5
 vagrant@manos5:~$ cd /home/hijo
 vagrant@manos5:/home/hijo$ git checkout -b feature/add-numbers master
 Switched to a new branch 'feature/add-numbers'

You have added a new branch and switched to it. You can test this:

....
vagrant@manos5:/home/hijo$ touch x
vagrant@manos5:/home/hijo$ git add x<commit_msg>clarification<commit_after>= Lab 05 Work Management: Kanban and further use of git.

In this lab, you will extend the pipeline to support Kanban work management coupled with further git techniques.

Lab objectives:

* Develop a manual Kanban board and convert it to an automated system.
* Learn the basics of git feature branching workflow.
* Add at least 3-5 small features to your product, using your team's agreed end to end workflow.

As in https://github.com/dm-academy/aitm-labs/blob/master/Lab-04/04-tech-lab.adoc[Lab 04], it is recommended you have 2 terminal sessions open, one for X windows, the other for product development.

== Manual Kanban

Using either whiteboards or large Post-it sheets, create a kanban board for your team/product. The precise structure is up to you, but it should include:

* Incoming feature work & todos
* Story development
* Feature development
* Testing
* Deployment

Each column is "owned" by the appropriate person on your team, from the organizing you did in https://github.com/dm-academy/aitm-labs/blob/master/Lab-04/04-tech-lab.adoc[Lab 04].

Use small Post-its for the features as they move from left to right.

[cols="2*", options="header"]
|====
|Kanban column |Owner
|Incoming feature work & todos |Product owner
|Story development | Business analyst
|Feature development |Developer
|Testing | QA analyst
|Deployment | Tools specialist
|====

Start with this sequence as a baseline. Understand you may adapt it; please be prepared to share your reasoning if you do.

* Product owner conceives high level idea
* Business analyst writes story
* Developer adds a new feature (addition example)
* Developer asks QA to approve (manual pull request)
* QA person commits it to master
* Tools person moves it to production (via cara reprovision)

You are to do this multiple times. Add 3-5 additional features (each at least some words and an object result - see example below) to the generated web page, considering each one as a feature.

Do  2-3 features manually and 2-3 features with an automated kanban tool.

The first time you go through this, the entire team should go through each step, with the appropriate team member leading the activity.

After that, you may be able to accelerate things. This is where some self-organization comes in. Do not use the suggested team structure as a cage. You will find the developers likely have the most work. How can you all work together to deliver features more quickly?

== Git feature branch, with Java example.

IMPORTANT: Although branching workflow in a development organization would be mainly the concern of dev, qa & tools, the entire team should understand this section - you are all accountable as individuals to know this material.

You need to elaborate your git branching strategy so that features have their own branches, and you can have more than one developer working at a time.

Read as a team these two sections on git workflows:

* https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow[Centralized Workflow]
* https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow[Feature Branch Workflow]
(It is not required to read the further sections on Gitflow or forking workflow, but you may wish to do so for your own professional development. Source workflow is a critical topic for development organizations and the examples here are only the simplest.)

We have been doing the centralized git workflow. For this lab you are to work with the feature branch workflow approach.

NOTE: We do not have a capability for automated git pull requests within Calavera. (We do not use Github *within* Calavera. We just use plain git.)
Therefore, your pull requests will have to be handled manually in your Kanban workflow. More below.

The following picture, similar to the Atlassian tutorials, may be of help. (First draft as of 2016-03-11.)

image::workflow.png[]

=== Identify a new feature
Your product feature idea should be extremely simple. It is more important to move several simple features through the pipeline end to end, than to spend all your time building something complicated.

Some good starter examples would be:

* Add two numbers together (we will start with this)
* Display the team name
* Display a given irrational number to 10 places

Write the idea down, with appropriate detail. For this lab, keep it simple. You might want to have two attached sticky notes: one identifying the task, and the other to actually carry the idea to the BA.

Product owner, your Kanban task is now ready for the business analyst - it meets the definition of done. Do not pull anything more into your queue until this task has been pulled ahead. Instead, if it takes them more than a few minutes to pull your task, go help folks downstream clear their lane.

=== Write a new story
As BA, you should formalize the story more:

"As a user of the website, I want to see two numbers added together so that I have that information."

"As a user of website, I want to see a greeting that is meaningful so that I know which team's site I am accessing."

"As a user of the website, I want to see the number pi displayed to 10 places so that I may have that knowledge."

Business analyst, once it is written in this form, your Kanban task is now ready for QA - it meets the definition of done. Do not pull anything more into your queue until this task has been pulled ahead. Instead, go help folks clear their lane.

=== Develop the new feature
NOTE: The lab provides a detailed walkthrough of adding two numbers together. If your team consists of advanced Java developers, feel free to build your own story from the start. Otherwise, you should do this example first before moving on to other features of your own creation.

Developer, pull the story from the BA into your queue.

Here we will create a new feature development branch by using the `git checkout -b some-feature master` command.

(You will give your feature a name appropriate to your new feature)

NOTE: A common mistake is to `su publicxx` but then not change to the new home directory. `cd` should always be the next command you execute after `su` for these labs. You do *not* want to remain in your student home directory.

Go:

 :~/Calavera$ vagrant ssh manos5
 vagrant@manos5:~$ cd /home/hijo
 vagrant@manos5:/home/hijo$ git checkout -b feature/add-numbers master
 Switched to a new branch 'feature/add-numbers'

You have added a new branch and switched to it. You can test this:

....
vagrant@manos5:/home/hijo$ touch x
vagrant@manos5:/home/hijo$ git add x
{'fraction_non_alphanumeric': 0.05261085295739151, 'fraction_numerical': 0.006458218476805545, 'mean_word_length': 4.262329050973891, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 8, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 12, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '80837', 'n_tokens_mistral': 3325, 'n_tokens_neox': 3137, 'n_words': 1963}