Here is the sequence of events, including the steps
required to execute the task:
1. Raise a ticket.
2. Target to a milestone.
3. Assign to a developer.
4. Create a branch.
5. Make the changes.
6. Merge into the trunk.
7. Resolve the ticket.
Chapter 7
[ 75 ]
Although we use the same sequence of events for both features and bugs, the details
for each are sufficiently different and we only want to deal with an overview here.
One benefit of using tickets to track tasks is that we get a numerical
reference??”the ticket number??”which can be used in branch names and
commit logs to keep everything together.
Adding a Feature
Features could come in from many sources, but ideally they should be controlled by
the development team or??”if they are lucky enough to have one??”their development
manager. Features may be suggested by users, requested by customers, or created by
the developers themselves. Ultimately three decisions need to be made about each
proposed feature: if, when, and who. None of these really need much explanation
beyond what we have already covered in Chapter 1. However, if is worth touching
on again. Not every feature should make the cut when deciding what is going to be
included in our project. There are no absolute rules for this, but if we generally ask
the question whether or not a feature should be included in our application, then the
answer should be no.
Pages:
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103