Class 4 - Intro to Agile, Working with Stakeholders Flashcards
True or False: It is okay if a system is not deployable at the end of a sprint as bugs can always be fixed in the next sprint
False. The system should be technically deployable at the end of every sprint (code is clean, all tests pass). Deployment should be a business decision
Stable Productivity
A feature similar to one that took 2 weeks at the start of project will take 2 weeks a year later
What things are expected to improve as more time is invested into a project?
- Design and architecture of a software system
- Code structure
- Efficiency and throughput
Fearless Competence
If you see something wrong or dirty, you will fix and clean it
Why is test automation desirable?
Asking humans to do what machines can do is expensive, inefficient, and immoral. Every test that can feasibly be automated must be automated.
What tools can be used to automate UI acceptance tests?
- Selenium
- Espresso
- Robotium
- others…
What is the most honest estimate?
I don’t know
How can you get a more honest estimate for user stories?
- Use relative estimates (story points)
- For time estimations, give a range of possibilities
Perverse Incentives
Incentives that result in unintended negative consequences due to actions people take to receive the incentive. Specifically, do not judge sprint progress based on:
- Story points complete
- # of stories
- # of bugs fixed
Cobra Effect
An attempted solution worsens the original problem (e.g. if a cash reward is given for killing snakes, people will breed snakes just to kill them and make money)
True or False: When you don’t believe something is possible (based on the scope, budget, and time allotted for the project), you should say no
True. Even if you are turning down something the client really wants, it is important to say “no” if something is not feasible.
What can you do to ensure you are continuously learning software engineering?
- Learn at least 1 new language every year
- Read a technical book and a nontechnical book each month
- Take classes
- Participate in local user groups and meetups
- Experiment with different environments
- Stay current
Customer Bill of Rights
- Overall Plan
- Maximize Value
- See Progress
- Change your Mind
- Informed of schedule and estimate changes
- Cancellation
Overall Plan (Customer Bill of Rights)
You have the right to an overall plan and to know what can be accomplished when and at what cost
Maximize Value (Customer Bill of Rights)
You have the right to get the most possible value out of every iteration
See Progress (Customer Bill of Rights)
You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. Customers need to know what progress is made from their point of view.
Change your Mind (Customer Bill of Rights)
You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs
Informed of schedule and estimate changes (Customer Bill of Rights)
You have the right to be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date
Cancellation (Customer Bill of Rights)
You may cancel at any time and be left with a useful working system reflecting investment to date
Developer Bill of Rights
- Requirements
- Quality of Work
- Ask/Receive Help
- Make/Update Estimates
- Accept Responsibilities
Requirements (Developer Bill of Rights)
You have the right to know what is needed with clear declarations of priority
Quality of Work (Developer Bill of Rights)
You have the right to produce high-quality work at all times. Customer can’t ask developers to:
- Produce low-quality work
- Ignore ethical problems
- Harm their reputation
Ask/Receive Help (Developer Bill of Rights)
You have the right to ask for and receive help from peers, managers, and clients
Make/Update Estimates (Developer Bill of Rights)
You have the right to make and update your own estimates
Accept Responsibilities (Developer Bill of Rights)
You have the right to accept your responsibilities instead of having them assigned to you. Developers are responsible for getting the training, help, and information they need to ensure their own success
Inexpensive Adaptability
You should be able to make changes to your codebase quickly and easily without incurring a high cost
