HowTo:Organize UBIK Development - Revision history

NWE: /* An Epic for every topic */

2023-11-13T11:16:59Z

‎An Epic for every topic

2023-11-10T17:02:25Z

‎A User Story for every task group

2023-11-10T16:57:53Z

‎A User Story for every task group

2023-11-10T16:53:53Z

‎A Feature for every requirement

2023-11-10T16:50:37Z

‎An Epic for every topic

2023-07-26T12:51:18Z

2023-07-25T12:05:45Z

‎Documentation

2023-07-25T11:29:44Z

2023-07-25T11:28:17Z

‎Dividing the project into tickets

2023-07-24T22:31:10Z

@@ Line 16: / Line 16: @@
 Tickets can be managed with any Issue Tracking or Project Management system.
-==== An Epic for every topic ====
+==== An Epic for every work package====
-The project should be segmented into Epics first. An Epic is a large work package corresponding to a topic or an abstract use-case.
+The project should be segmented into Epics first. An Epic is a large work package corresponding to a topic or an abstract use-case, with a time-limited scope.
 For example, Operator Rounds (using the mobile application to do maintenance in a plant) are a classical use-case that can be managed with {{UBIK}}.
 However, for the sake of project management, it makes sense to make sure Epics have a limited temporal scope as well. This means that they should be doable within a short period in time. The benefit of this is that you can collect moments of success more frequently, and you can sell those to the customer, too.

@@ Line 43: / Line 43: @@
 A User Story should be formulated using the following pattern:
 "As a <user>, I want <requirement>, because <reason>."
-E.g., or the Feature "Presentation of MRO objects on the client", we need to do different kinds of things, i.e., customize the ACM, customize the client UI, import work packages from a 3rd party system, etc. For all of those task groups, a User Story can be created to encapsulate the work.
+For most features, we need to do several steps:
-One such User Story could be "As a maintenance worker, I want an ACM customizing for my work packages, because I want to see them on the mobile device."
+Hence, for the Feature "Presentation of MRO objects on the client", there could be multiple successive stories like:
 Every User Story requires a definition-of-done. Those are the acceptance criteria, which can be used to decide whether the Story was done or not. One of these acceptance criteria should always be the peer review, i.e., going over the results with a colleague to check for completeness and optimization on a constructive basis.

@@ Line 37: / Line 37: @@
 ==== A User Story for every task group ====
-Every Feature consists of one or many User Stories, i.e., groups of tasks that can be implemented within one or two weeks.
+Every Feature consists of one or many User Stories.
 A User Story should be formulated using the following pattern:
 "As a <user>, I want <requirement>, because <reason>."
@@ Line 49: / Line 52: @@
 Only after review and acceptance with respect to the definition-of-done / acceptance criteria, should the User Story be considered finished.
 = Functional Spec & Effort Estimation =

@@ Line 30: / Line 30: @@
 A use-case consists of multiple Features, i.e., functional parts or requirements for that use-case.
 In the example of Operator Rounds, one such Feature could be the basic data model, or presentation of {{UBIK}} MRO work packages on the mobile client.
 ==== A User Story for every task group ====

@@ Line 19: / Line 19: @@
 The project should be segmented into Epics first. An Epic is a large work package corresponding to a topic or an abstract use-case.
 For example, Operator Rounds (using the mobile application to do maintenance in a plant) are a classical use-case that can be managed with {{UBIK}}.
 ==== A Feature for every requirement ====

@@ Line 93: / Line 93: @@
 ** Production Environment: Infrastructure details about the prod environment.
-[[Category:Best Practices (internal)|Organize UBIK Development]]
-[[Category:How-To|Organize UBIK Development]]
-[[Category:Resources (internal)|Organize UBIK Development]]
 = Code Management =
@@ Line 117: / Line 117: @@
 ==See also==
 * [[HowTo:Transfer_Meta_Data_between_Environments]]
 [[Category:Best Practices (internal)|Organize UBIK Development]]
 [[Category:How-To|Organize UBIK Development]]
 [[Category:Resources (internal)|Organize UBIK Development]]

@@ Line 85: / Line 85: @@
 * Use-Cases: Provide an overview about the functional side of the project
 * Data Model: Provide an overiew of the data model
-* Customizing Architecture: A big picture of the customizing architecture. E.g., is there a plugin, and what does it do? Are any meta classes customized, and to do what?
+* Architecture: A big picture of the customizing architecture.
 * Infrastructure: Servers, URLs, safe credentials storage (e.g., KeePass), etc. for the respective environment.
 ** Development Environment: Infrastructure details about the dev environment.
 ** Integration Environment: Infrastructure details about the int environment.
 ** Production Environment: Infrastructure details about the prod environment.
-−
 = Code Management =

@@ Line 7: / Line 7: @@
 <!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS -->
 = Project Structure Plan =
@@ Line 47: / Line 37: @@
 Only after review and acceptance with respect to the definition-of-done / acceptance criteria, should the User Story be considered finished.
-[[Category:Best Practices (internal)|Organize UBIK Development]]
-[[Category:How-To|Organize UBIK Development]]
+= Functional Spec & Effort Estimation =
-[[Category:Resources (internal)|Organize UBIK Development]]
 = Requirement Supply Chain =
@@ Line 65: / Line 62: @@
 In general, we recommend adding the supply chain part(s) of a story to the title as a prefix. E.g., "Req.: Story A".
 = Staging & Manual Test Plans =

@@ Line 18: / Line 18: @@
 Effort can be estimated both on task-level and on more abstract levels: For every task, three estimates are provided by the team (optimistic, most likely, and pessimistic), and for every milestone, we can calculate respective sums from the individual tasks. Then, we can use PERT for the final estimate.
-= Dividing the project into tickets =
+= Project Structure Plan =
 {{UBIK}} projects can be large, and it is desirable to split them into a hierarchy of smaller parts or tickets.
 This makes it easier to track the overall progress and to delegate work to project engineers.
-It also allows you to model the dependencies between tasks and to do them in the correct order.
+It also allows you to model the relations between tasks and to plan them chronologically, taking dependencies into account.
+The result is called a Project Structure Plan, and it should be possible to reflect it on a Gantt chart.
 Tickets can be managed with any Issue Tracking or Project Management system.
@@ Line 46: / Line 46: @@
 Only after review and acceptance with respect to the definition-of-done / acceptance criteria, should the User Story be considered finished.
 = Requirement Supply Chain =