Forming Agile Team

[ivanchenoweth]

Supports the initial developer team and their ability to deliver software regarding consolidating: The team members, backgrounds, agreements, politics, good practices, tooling, testing, metrics, design, planning and everything to make a goal in the quality software industry.

This story "simulates" a Sprint0 onboarding in a real full industrial software project, but in this case is just didactic project, we need to do it in a user story.

Acceptance criteria, DOD or Definition of Done (what need to do to finish the User Story):

1.- Build a Readme.md or a the wiki file with a small guides/runbook of the initial project (stakeholders) and all the user stories, the git-workflow, starting boilerplate code (tech-stack), architecture, and good practices and agreements with the PO.

2.- Include in the repository, the initial w/diagnostic DB connection boilerplate code

3.- Screenshot of your local environment working (every developer)

• [ ] DOR or Definition of Ready (check if each is pretty clear what to do):

BDD (Gherkin Language):

• Scenario 1:

Understanding the project, agreeing on the boilerplate code (tech-stack), architectural, the list of tooling, good practices, testing, metrics, design, etc., and planning the dev going to use

• Given: Needs of the project
• And: Get all the information without questions
• When: Start the sprint
• Then: Shows the project (git repository) with a shared the document and the boilerplate code

TASKS

Minimal tasks splitting to do:

• [ ] Discuss/Research about Epic/Sprint business needs and training about Agile
• [ ] Make a repository named FinalPoject shared with the PO and members.
• [ ] Make a branch named: "US0" with the document and boilerplate code of the project
• [ ] Make the agenda for the spring planning with all the stories involved
• [ ] Let finish source code (Document of workflow and good practices and agreements) in the: "US0" master branch, with the commits of the tasks
• [ ] Make a pull-request to a master with all co-workers approvals +1 for all the co-workers
• [ ] Code review Dev 1 (works good in your local)
• [ ] Code review Dev 2 (works good in your local)
• [ ] Placeholder
• [ ] Merge and deploy to the DEV (Development), STG (Quality Assurance), or PROD (Production) stage if apply

Important links related :

• https://about.gitlab.com/2018/03/05/gitlab-for-agile-software-development/
• http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how
• http://www.caroli.org/splitting-crud-stories
• https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/
• https://www.atlassian.com/git/tutorials/comparing-workflows
• https://www.collab.net/services/training/agile_e-learning
• https://scrum.menzinsky.com/2015/03/que-es-el-sprint-0-actualmente-hay.html

Is necessary use Architecture project with Async Repository pattern by Service having Dependency Injection

• • MVC Java service and repository patterns
• https://social.technet.microsoft.com/wiki/contents/articles/39621.asp-net-mvc-solution-architecture-project-with-async-repository-pattern-by-service-having-dependency-injection-by-unity-page-1.aspx

Proposal of a basic git-workflow ![image](/uploads/dec7094b64e1e3bb45cc43f

[ivanchenoweth]

Supports the initial developer team and their ability to deliver software regarding consolidating: The team members, backgrounds, agreements, politics, good practices, tooling, testing, metrics, design, planning and everything to make a goal in the quality software industry.

This story "simulates" a Sprint0 onboarding in a real full industrial software project, but in this case is just didactic project, we need to do it in a user story.

Acceptance criteria

1.- Build a Readme.md with a small document of the plan of your project (stakeholders) and all the user stories, the git-workflow, starting boilerplate code (tech-stack), architecture, and good practices and agreements with the PO.

2.- Include in the repository, the initial w/diagnostic DB connection boilerplate code

3.- Screenshot of your local environment working (every developer)Acceptance criteria, DOD or Definition of Done (what need to do to finish the User Story): 1.- Build a Readme.md with a small document of the plan of your project (stakeholders) and all the user stories, the git-workflow, starting boilerplate code (tech-stack), architecture, and good practices and agreements with the PO. 2.- Include in the repository, the initial w/diagnostic DB connection boilerplate code 3.- Screenshot of your local environment working (every developer)

[ivanchenoweth]

TEMPLETE OF TECHNICAL TASKS, WORKFLOW AND REMINDERS

These are at least tasks splitting have to be included:

• [ ] Discus the solution with the team (analyze similar app given) and make new agreements.
• [ ] Create a unit tests (if apply)
• [ ] Create a view (if apply)
• [ ] Create a controller(if apply)
• [ ] Create a service (if apply)
• [ ] Create the migration and the user model (if apply)
• [ ] Code review Dev 1
• [ ] Code review Dev 2 (if exist >2 developers)
• [ ] Profiling (web app only)
• [ ] Create automated or/and functional tests (QA team)

Reminder to dont' forget good practices of git add, commit and push

NOTE: The above tasks are suggested in all the user stories, we could remove them for the next user's story (didactic propose)

• [ ] Create the branch named : feat/US2 from develop branch
• [ ] Make code changes (Use/reuse)
• [ ] Make a pull request feat/US2 to develop to the team for approvals including the instructor one
• [ ] Create a Pull request of the branch to the QA branch (1 approval)
• [ ] Proposal of where could be deployed in a cloud for a QA scenario (if devops apply)
• [ ] Create a Pull request of the branch to master branch (1 approval in Devops team)
• [ ] Prepare to deliver to production (Include date - code freeze, QA, and Devops team)
• [ ] Move to done