obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-01-09 17:14:02

Browse Source
This commit is contained in:
Claudio Fritsche
2025-01-09 17:14:02 +01:00
parent a2fcc0576c
commit 8e708d46ad
2 changed files with 78 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md
View File

@@ -415,16 +415,86 @@ Once the project started we have the following indicators to show how well we fo
- [ ] Create a project intranet homepage (confluence page) with links to planning, tracking, technical work products and project deliverables. Essentially make a dashboard (see page 93)
#### Risk Management
The goal is to trade small amounts of increased overhead for large amounts of risk reduction.
In order to commit to risk management:
- Describe a risk management approach in writing
- Budget funds for risk resolution and risk removal
- Use risk assessments to update project plans, else all is for nothing
Tools for risk management:
- Planning for risk management
- Assign a risk officer
- play devil's advocate during planning meetings and planning reviews
- needs to have a bit of the attitude: "It will never work"
- senior developer or senior tester
- top 10 risk list
-
- risk-management plan for each risk
- create anonymous risk-reporting channel
- Bad news are not shared easily --> make it anonymous to facilitate. It is crucial that all team members do communicate this
> [!Idea] Use Jira / Github Issues for risk Tracking
> This makes risks visible. People can discuss risks. You can assign responsibility for risk mitigation
##### Risk Management Plans
Answer the following questions for every risk:
- **Why?** Why is a risk-management plan needed for this specific risk? Describe the risk's probability of occurrence, consequences, and severity.
- **How?** How will the risk be resolved in general? Describe the general approach to re- solving the risk. List or describe the options that were considered.
- **What?** What specific steps will be taken to resolve the risk? List the specific steps and deliverables that will be generated in addressing the risk. Include a description of the conditions under which the risk will be upgraded— for example, if the risk cannot be resolved by a specific date.
- **Who?** Who will be responsible for completing each step? List the specific person re- sponsible for completing each step.
- **When?** When will each step be completed? List the completion date for each step.
- **How much?** How much budget is allocated to the resolution of the risk? List the cost of each step that will be taken to resolve the risk.
#### Personnel Strategies
- evaluate managers based on how well they retain project personnell
- professional growth opportunities during the project
- after the project team members should feel better about the company, not worse
> [!Quote] Available vs Good
> It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.
Team dynamics and team bond play a more important role than individual developers' capabilities (slightly behind). This means we need to hire someone who fits into the team.
##### Key Staff-Buildup Questions
- Does the project manager have software experience with one or more projects of a similar size?
- Does project's senior technical staff have knowledge of the kind of software being built and experience on similar successful projects?
- Most teams are comprised of average personnel. Do expectations about the team's productivity match the team members' abilities?
- Will the individuals work well together?
##### Project Team Organization
- Project manager: orchestrate detailed technical work (development, quality assurance, user documentation). Develops software development plan. Is the team's link to upper management.
- Product manager: Business level work: marketing, product packaging, end-user documentation, end-user support. In-house projects: work with groups that use the system to define the software, setup trraining and user support
- Architect: Responsible for conceptual integrity at design and implementation level
- User-interface designer: responsible for conceptual integrity of software visible to end-user.
- End-user liaison: interact with end-user throughout the project. Walk them through the prototype, demonstrate new releases, gather user feedback.
- Developer: detailed design and implementation of software. Responsible for making the software work
- QA/Testers: responsible for Quality Assurance and test activities. Create detailed test plans and perform tests. Find all the ways to break the software.
- Tool smith: Responsible for developing build scripts, maintain versioning system, developing utilities needed by the project.
- Build coordinator: responsible for maintaining and running the daily build and notifying the developers when something breaks the build
- Risk officer: watch for emerging risks and diversion from the development plan
- End-user documentation specialists: generate help files, documentation and instructional materials that end-users will use.
---
## Steps towards the Software release
1. Define requirements
2. Create initial project estimate (budget, schedule, staffing, desired feature set).
3.
1. Define preliminary risks list
2. Define requirements
3. Create initial project estimate (budget, schedule, staffing, desired feature set).
## Document List
- Top 10 Risk List (keeps being updated) including a risk-management plan for each risk
- Software Development Plan
- Risk management approach
- Risk officer
## Tool list
- Anonymous risk-reporting channel
## Review List
- Review Top 10 Risks every 2 Weeks (see page 97)
---
```query
Software Project Survival Guide Steve McConnell