5. Time and Change Management Flashcards
1
Q
Describing a task
A
- unique identifier
- longer label description
- list of concrete task outcomes
- list of deliverables
- task dependencies
- estimated duration
- task lead, sub-team
- risk
- history of progress in completing tasks
2
Q
Task duration estimation problems
A
- complexity of the task
- political priority
- availability of clear outcome for the task, by which progress is measured
- availability of software metrics on which to base estimates
- availability of previous similar tasks to base estimates
- experience of the team making estimates based on the previous task
3
Q
Estimating Task
A
- estimating task is dificult
- some say is fruitless
- necessary for budgeting and wider planning
- help identify poorly understood tasks and force
refinement - various methods for estimation
- dephi
- market testing
- empirical
- algorithmic
4
Q
Estimating difficulty scales
A
linear
fibonacci 1, 2, 3, 5, 8, 13, 21
5
Q
Project velocity
A
- amount of work during a single sprint
- predict the velocity of an iteration
- estimate the number of iterations - keep track using burndown chart
6
Q
Problem: parallel development
A
- project team permits uncontrolled change to master copy
- no agreed system to preserve a previous working version of master copy
- team does not have procedure to notify others on changes
7
Q
Change control items
A
- source code files
- configuration files
- build scripts
- default app config files
- user documentation
- requirements specifications
- version control tool config
8
Q
Non-change control items
A
- compiled binaries
- 3rd party library
- compiled document formats eg pdf
- auto-generated source code file
- client-side IDE config
- log files
9
Q
Revision/ version/source change/ control system/ repositories
A
- software tool for maintaining the history of changes to a set of controlled items
- core workflow
- make local changes
- receive update from remote repository
- resolve conflict - submit local change to remote repository
10
Q
Types of version control system
A
centralized
distributed
11
Q
commits/ changes/ revisions comprises of:
A
- unique id
- id of parent commit
- changes to a set of changes control items
- any added change control items
- any removed change control items
- meta data –> change author, time stamp, log message
12
Q
Why is Commit Id needed
A
- need a way to uniquely reference a commit within repository
- centralised system like subversion use global revision number that gets incremented after every one commit
- distribute system relies on one-way hash function to generate a unique fixed-length Digest of the content of the commit
hash(parent_id, author, timestamp, message, changes) = fixed_length_digest
13
Q
Commit log messages
A
- teams agree their own standards
- general good practices
- describe purpose of commit
- avoid multiple purposes
- explain why commit is made and link to issue
- explain how commit addresses the issue
- short meaningful title - configure message editor in git terminal to implement commit messages for consistency
14
Q
What is Branching, what is it useful for
A
- practice of maintaining multiple development lines based on a common history within single controlled repository
- useful for:
- experimenting with the implementation of new features
- undertaking a substantial reorganization
- supporting a specialized variant
- creation of a release - different branching strategies
15
Q
Trunk based development
A
- clearer visibility of progress
- reduce risk of merge conflict
- requires developers to break changes to master into smaller increments
- increased risk of broken code in master
16
Q
Feature branching
A
- greater freedom to develop new features in isolation
- convenient for managing code reviews
- encourage longer period between integration
17
Q
Stage branching
A
- allow changes to be tested in UAT environment before going live
- change cannot be merged directly to deployment
- may configure for every feature branch
18
Q
Naming convention
A
- follow convention for common branches
- master/trunk/main
- UAT/staging/preproduction
- deployment/production - use hierarchical naming
- eg. feature/webapp/spash…
19
Q
Branching strategies
A
- collection of branching practices
- standard published strategies
- GitHub Flow
- Git flow
- GitLab Flow - managing branch growth
- delete branch
- commit squashing
20
Q
Release and dependency management
A
break codes into smaller modules with separate compilation pipelines
agree and configure a release management process for each module using a release repository
