Confirmed users
1,193
edits
MDN/Development/Process: Difference between revisions
Jump to navigation
Jump to search
→Organization
| Line 27: | Line 27: | ||
==== Organization ==== | ==== Organization ==== | ||
Tasks in the Sprint Backlog can sometimes become very broad. To avoid this, the team | Tasks in the Sprint Backlog can sometimes become very broad, making the work more intimidating and more difficult to track. To avoid this, the team uses a few different criteria to break them down. | ||
The team uses research tasks whenever possible. For example, when | In general, the team breaks tasks down to be as small as is reasonable. For example, a task for implementing user login might be broken further into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". The team also uses research tasks whenever possible. For example, when building a user login feature, the team might create a task like "Research: What services can we use to power login?". The team discusses the question and shares decisions in an associated Bugzilla bug. | ||
The team sometimes needs to coordinate with IT to complete a feature. When this happens, the feature is broken down by responsibility, with at least one task for the team to complete and at least one task for IT to complete. The tasks are written to be independent, so that the team can mark its tasks as complete even if the IT tasks are progressing more slowly. If more work is needed from the team after IT finishes its tasks, new tasks are open for the team. | |||
The team pays special attention to breaking work down when a feature goes a long time without being merged into the MDN source code repository. When this happens, the work is broken down into one or more back-end tasks and one or more front-end tasks. As back-end tasks are implemented, they are merged without the corresponding front-end tasks. If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing. | The team pays special attention to breaking work down when a feature goes a long time without being merged into the MDN source code repository. When this happens, the work is broken down into one or more back-end tasks and one or more front-end tasks. As back-end tasks are implemented, they are merged without the corresponding front-end tasks. If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing. | ||