MyChannels Documentation

Workflow

Git

Branches

When you have an JIRA ticket related to your branch you should use the ticket name and the ticket number in the branch.

Example: git checkout -B pip-inline-embed-FRA-264

Pull Requests

When you are ready to push your code to GitHub you can create an Pull Request (PR). As a PR title you should also include the JIRA ticket name and number here. Make sure you work with the labels, especially the labels WIP (Work In Progress) and Ready for Review. Remove the WIP label when your PR is ready to be reviewed. Add one or more reviewers. After the Reviewer approves the changes you can safely merge the PR into master. After merging in master you should delete the branch from GitHub.

Rebase

  • Checkout your branch
  • git fetch
  • git rebase origin/master
  • No problems? -> git push -f

Commit messages

Please use the rules defined by Tim Pope.

  1. Summary is 50 chars or less
  2. Body is 72 chars or less
  3. Use present tense (So "Fix" instead of "Fixed")

Example:

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug."  This convention matches up with commit messages generated
by commands like git merge and git revert.

Scrum

Schedule

  • Daily stand-up at 10:00
  • Sprint Planning every two weeks on Tuesday at 11:00
  • Retrospective every two weeks on Tuesday at 10:00
  • Sprint Demo every two weeks on Monday at 15:00
  • Backlog refinement every week on Thursday at 13:00

Explanation

Stand-up aka Daily Scrum

A stand-up meeting (or simply "stand-up") is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short.

Team members briefly (a maximum of one minute per team member) address three questions as input to this planning:

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. What will I do today to help the development team meet the sprint goal?
  3. Do I see any impediment that prevents me or the development team from meeting the sprint goal?

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

  1. What can be delivered in the Increment resulting from the upcoming Sprint?
  2. How will the work needed to deliver the Increment be achieved?

Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Demo and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The purpose of the Sprint Retrospective is to:

  1. Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  2. Identify and order the major items that went well and potential improvements; and,
  3. Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done", if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Sprint Demo aka Sprint Review

A Sprint Demo is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Demo, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.

The Sprint Demo includes the following elements:

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
  • The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
  • The entire group collaborates on what to do next, so that the Sprint Demo provides valuable input to subsequent Sprint Planning;
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Demo is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Backlog refinement

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Browsers we test (THIS SECTION needs an UPDATE)

Browser top 10:

  1. Chrome
  2. Android Webview
  3. Safari
  4. Safari (in-app)
  5. Firefox
  6. Internet Explorer
  7. Edge
  8. Android Browser
  9. Opera
  10. Maxthon

Browser version top 10:

  1. Chrome 56.0.2924.87
  2. Safari 10.0
  3. Safari (in-app)
  4. Android Webview 56.0.2924.87
  5. Chrome 57.0.2987.132
  6. Chrome 44.0.2403.133
  7. Chrome 57.0.2987.133
  8. Chrome 51.0.2704.106
  9. Chrome 58.0.3029.83
  10. Internet Explorer 11.0

OS top 10:

  1. Android (6.0.1, 7.0, 6.0, 5.1.1, 4.4.2, 5.0.1, 5.02….)
  2. Windows (10, 7, 8.1, Vista, XP, 8, Server 2003, NT, 2000)
  3. iOS (10.3.1, 10.2.1, 9.3.5, 10.2, 10.1.1. etc…)
  4. Macintosh (Intel 10.12, 10.11, 10.9, 10.6, 10.7, 10.8)
  5. Linux (x86_64, i686, (not set), armv7l, i586…)
  6. Chrome OS (x86_6, armv7lx…..)
  7. Windows Phone (8.1, 8.0, 7.5, (not set))
  8. BlackBerry
  9. (not set)
  10. Xbox

Top 3 platforms:

  1. Mobile
  2. Desktop
  3. Tablet

Top devices:

  1. Apple iPhone
  2. Samsung (Next one was Huawei on place 14....)

Supported browsers:

  • Chrome (latest)
  • Safari (latest)
  • Firefox (latest)
  • Edge (latest)
  • Internet Explorer 11

Supported devices:

  • iPhone 5,6,7 / last 3 versions
  • Samsung Galaxy (last 3 versions?)

Supported OS:

  • Windows (10, 7)
  • MacOS (last 2,3 versions?)
Edit this page on GitHub
Last Updated: 3/5/2019, 3:24:24 PM

← Design Requirements →