119 lines
8.1 KiB
Markdown
119 lines
8.1 KiB
Markdown
---
|
||
title: Software Project Survival Guide by Steve McConnell
|
||
created_date: 2025-01-07
|
||
updated_date: 2025-01-07
|
||
aliases:
|
||
tags:
|
||
- book
|
||
type: book
|
||
book_name: Software Project Survival Guide
|
||
author: Steve McConnell
|
||
status: 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
|
||
- ![[Pasted image 20250107095858.png]]
|
||
- Individual developers might not prioritise the same needs as the software projects survival needs
|
||
#### 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
|
||
1. To set objectives for the project and have them followed
|
||
2. To know how long the software project will take and how much it will cost
|
||
3. To decide which features are in and which are out of the software
|
||
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
|
||
5. To know the project's status clearly and confidently
|
||
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
|
||
7. To have ready access to project deliverables throughout the project
|
||
##### Project Team's Bill of Rights
|
||
1. To know the project objectives and to clarify priorities.
|
||
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
|
||
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
|
||
4. 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.
|
||
5. 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.
|
||
6. To have my project's status reported accurately to customers and upper management.
|
||
7. 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
|
||
|
||
---
|
||
```query
|
||
Software Project Survival Guide Steve McConnell
|
||
-file: "Software Project Survival Guide by Steve McConnell.md"
|
||
```
|