12 KiB
title, created_date, updated_date, aliases, tags, type, book_name, author, status
| title | created_date | updated_date | aliases | tags | type | book_name | author | status | |
|---|---|---|---|---|---|---|---|---|---|
| Software Project Survival Guide by Steve McConnell | 2025-01-07 | 2025-01-07 |
|
book | Software Project Survival Guide | Steve McConnell | not_started |
Software Project Survival Guide by Steve McConnell
- 🏷️Tags : #01-2025 #book
Summary
[!summary] Summary 3 Sentences only!
- What are the main ideas?
- If I implemented one idea from this book right now, which one would it be?
- How would I describe the book to someone else?
Ideas and Thoughts
[!info]+ Inspiring Questions
- Did you think about other concepts from other books?
- Do the concepts fit to your past, to your memories?
- Can you relive them and reflect them from a different angle?
- We should define exact goals that are measurable: What does the software need to do? What's its accuracy?
Clippings
Intro
- Software projects fail because of
- lack of knowledge of software project conduct
- lack of resolve --> indecisiveness, procrastination, low confidence, inconsistency
- References
- Key Practices of the Capability Maturity Model, Version 1.1 by Software Engineering Institute (SEI)
- Recommended Approach to Software Development, Revision 3 by NASA Software Engineering Laboratory (SEL)
The Survival Mindset
- The only outcome considered a failure is total collapse
- Success: meet cost, schedule and quality goals within engineering tolerances (+- 10% of goal)
- Survival Needs
- Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air)
- project not canceled, team not fired, adequate physical working conditions
- meeting personal promises for schedule and functionality
- Project team must be satisfied that the project can be completed at all before it can worry about the schedule or budget
- !
- Individual developers might not prioritise the same needs as the software projects survival needs
- Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air)
Stakeholders
Each group involved in the project must respect the rights of the other parties. And each group's survival needs must be thoroughly satisfied such that they can focus on higher level needs. Usually this is the Customer and the Project Team:
Customer's Bill of Rights
- To set objectives for the project and have them followed
- To know how long the software project will take and how much it will cost
- To decide which features are in and which are out of the software
- To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
- To know the project's status clearly and confidently
- To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
- To have ready access to project deliverables throughout the project
Project Team's Bill of Rights
- To know the project objectives and to clarify priorities.
- To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
- To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
- To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
- To approve effort and schedule estimates for any work that Team will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
- To have my project's status reported accurately to customers and upper management.
- To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.
Survival Check
This tool is a quick check to verify that the essential characteristics for the survival are met. In the book a 👍🏼 or a 💣 is used. We will use a box just like below for every chapter.
[!question] Survival Check - Survival Training
- 👍🏼 Project team's survival needs are being met
- 👍🏼 The customer and the project team agree to respect each other's software project rights - 💣 The agreement in principle is not followed in practice
Software Project Survival Test
The idea of the survival test is to check the chances of survival of a project in different stages and to act upon the neglected areas if needed. There is a list of questions that will be answered with 0-3 points, 3 being fully qualified. The questions are separated into the following categories
- Requirements
- Planning
- Project Control
- Can progress be tracked and viewed by team members?
- defect tracking, source control, project management software
- Risk Management
- up to date list of risks to the project
- Personnel
- Do we have all technical expertise?
- Are there enough team members and are they committed?
Most projects have a score <50.
| Score Range | Rating | Description |
|---|---|---|
| 90+ | Outstanding | A project with this score is virtually guaranteed to succeed in all respects, meeting its schedule, budget, quality, and other targets. In terms of Chapter 1's project needs hierarchy, such a project is fully "self-actualized." |
| 80-89 | Excellent | A project at this level is performing much better than average. Such a project has a high probability of delivering its software close to its schedule, budget, and quality targets. |
| 60-79 | Good | A score in this range represents a better-than-average level of software development effectiveness. Such a project stands a fighting chance of meeting either its schedule or its budget target, but it probably won't meet both. |
| 40-59 | Fair | This score is typical. A project with this score will likely experience high stress and shaky team dynamics, and the software will ultimately be delivered with less functionality than desired at greater cost and with a longer schedule. This kind of project stands to experience the greatest benefit from applying the plan described in this book. |
| < 40 | At Risk | A project with this score has significant weaknesses in the major areas of requirements, planning, project control, risk management, and personnel. The primary concern of a project in this category should be whether it will finish at all. |
[!question] Survival Check - Survival Test
- 👍🏼 Project scores at least 60 on the Survival Test
- 👍🏼 The project scores less than 60, but corrective actions are planned to improve its score. - 💣 The project team doesn't follow through on the planned corrective actions.
Survival Concepts
[!Quote] An investment made in process at the beginning of the project produces large returns later in the project
Processes are important because they make the development more productive and resistant in the long term. Example processes are:
- formally write down requirements
- use a procedure to control additions and changes to the requirements
- Do reviews of all requirements, designs and source code
- Develop a written Quality Assurance Plan, including a test plan, review plan and a defect tracking plan.
- Create an implementation plan that defines in which order the components are developed.
- Automated source code control (e.g. git)
- Revise Cost and schedule after each milestone
If teams do not invest in process at the beginning of the project, the amount of time spent for process and thrashing (i.e. unproductive time) will increase (see Figure 3-3).
!
On the contrary, teams which establish processes in the beginning (overhead) will spend less and less time on thrashing and processes as the project moves on.
!
[!Quote] Overhead of a cancelled Project If you think that attention to process is needless overhead, consider that the overhead of a canceled project is 100 percent.
[!warning] Opposite Views
- Processes limit developer's creativity
- --> Set up an environment where creativity is still possible.
- Developers feel best in environments where they are the most productive.
- Research shows that in regulated environments people feel more productive.
Upstream and Downstream
Upstream contains all early work of a project, such as requirements definition and architecture design. Downstream refers to later parts such as construction and system testing.
Defects cost more (50-200 times more), the earlier in the project they are inserted as illustrated in the figure below.
!
Please note that the cost grows exponentially, which multiplies the effect.
[!Quote] Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture.
Remember that just because no code is being written in the beginning that doesn't mean it is delaying the real work, but rather it is laying the groundwork for the project's success.
Erring on the side of too much process is marginally more expensive, versus erring on too little process can be way more expensive (50-200x) in the long run. This is because of the cone of uncertainty, which illustrates that upstream decisions affect downstream decisions, but not vice-versa.
!
[!Quote] Early in the project you can have firm cost and schedule targets or afirmfeature set, but not both.
[!question] Survival Check - Survival Test
- 👍🏼 Project leadership understands the critical role of well-defined processes and supports them.
- 👍🏼 The project's processes are generally oriented toward detecting as many problems upstream as possible.
- 👍🏼 Project leadership recognises that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses.
Survival Skills
Software projects are inherently complex and therefore need to be planned, controlled and made sure that the progress is visible, people are supported to do the project's work. The risks should be tracked and constantly redeveloped.
Planning
Risk Management
Project Control
Project Visibility
Peopleware
User Involvement
Product Minimalism
Focus on Shipping Software
Software Project Survival Guide Steve McConnell
-file: "Software Project Survival Guide by Steve McConnell.md"