Bridging the Communication Gap
Metadata
- Author: Gojko Adzic, Boris Marcetic, and Marjory Bisset
- ASIN: B008YZ993W
- ISBN: 0955683610
- Reference: https://amazon.co.uk/dp/B008YZ993W
- Kindle link
Highlights
Some ideas are even borrowed from Prussian military tactics from the nineteenth century and their current implementation in the US Army. — location: 228
There is a huge difference between this and missing a still target and then going back to have another go at hitting it. — location: 264
Gerald Weinberg and Donald Gause suggest that the difference between disappointment and delight is not a matter of delivering software, but how well the delivery matches what clients expected. — location: 267
be careful about expectatjions!
Changes get implemented directly without updating specifications, leading to differences between code and system — location: 310
Unfortunately, this comforting feeling quickly goes away if you think about the fact that these guys have the biggest guns in the world and that they misunderstand orders twice in every three times. — location: 349
People in homogenous groups often tend to make decisions to minimise conflicts and reach consensus without really challenging or analysing any of the ideas put to discussion. — location: 501
Unless everyone involved understands the business goals, there is a high risk of missing the target. — location: 545
We should not dive straight away into how to implement something, but rather think about how the finished system will be used — location: 568
Relationship between examples, tests and requirements — location: 589
The resulting military doctrine was called Auftragstaktik, or mission-type tactics, — location: 619
Today it survives as Mission Command in the US Army. — location: 620
We can bridge the communication gap by communicating intent, getting different roles involved in nailing down the requirements and exploiting the relationships between tests, examples and requirements. We can use realistic examples consistently throughout the project to avoid the translation and minimise the effect of the telephone game, saving information from falling through the communication gaps. — location: 646
Automate verification of the acceptance tests. — location: 655
Focus the software development effort on the acceptance tests. — location: 656
There are no abstract requirements, and we have examples to describe all the edge cases. — location: 684
In test-driven development, developers write tests to specify what a unit of code should do, then implement the code unit to satisfy the requirement. These tests are called unit tests, as they focus on small code units. — location: 700
In Sources of Power[4], Klein cites a paper by Karl Weick entitled Managerial thought in the context of action[14], which suggests a modified template for an effective commander’s intent document: Here’s what I think we face Here’s what I think we should do Here’s why Here’s what we should keep our eye on Now, talk to me — location: 1167
be used as a basis for later discussion, especially if we need to get them signed off by a senior stakeholder. — location: 1401
Once the acceptance criteria for the next phase of the project are captured in acceptance tests, — location: 1612
Mike Scott wrote27 that in his organisation acceptance tests are used to measure the progress of development, in a metric called running tested features. — location: 1628
Focusing the development just on the things expected by acceptance tests helps a great deal to prevent just-in-case code from leaking into the system. — location: 1632
Acceptance tests also rarely check purely technical edge cases, — location: 1769
The representative set of examples, formalised into acceptance tests and connected to the code by test automation, plays the role of a live specification of the system – the authoritative source of what the system does and how it behaves. — location: 1849
noticing inconsistencies and unclear definitions when — location: 1855
With domain knowledge and understanding shared among team members and a comprehensive acceptance test suite based on realistic examples, — location: 1915
At the beginning of development, changes to software are quick and simple. As the code base grows, it becomes harder to modify. A simple change in one area often causes problems in a seemingly unrelated part of the code. — location: 1932
Common symptoms of problems — location: 1949