timm
commented
8 years ago Should the key takeaways include other implications?
- Can you say anything about the systems implications for this approach? E.g. design telemetry first,?aggregate data centrally? build a large data store first?
- Or the other implications? e.g. hire as many data scientists as engineers (so instead of analyst-dev-test now you get analyst-dev-test-analytics)?
Best Points
The chapter provides a good overview of the book and why compiling a book on data science in software context is important. If this chapter is to serve the overview of the entire book, I hope it includes a table of content.
Title of chapter
Learning Lessons over Lessons Learnt: Liftoff with Continuous Experimentation Towards Rapid Value Delivery
URL to the chapter
https://github.com/ds4se/chapters/blob/master/muench/Chapter_Muench.md
Message?
The problem of testing the value of features early on is well motivated by the chapter. The chapter is engaging to read and the message is very clear. I also liked seeing the key takeaways paragraph at the end to emphasize that continuous experimentation is necessary to understand that software is addressing a right problem.
A few sentences were rather confusing. Minor points below: "Insights from experiments directly influence frequent deliveries." -- what is "frequent deliveries" here? "usually good in" => "usually good at"
Accessible?
The chapter is very easy and engaging to read.
Size?
The size is appropriate.
Gotta Mantra?
I could not quite understand the term, "Liftoff with Continuous Experimentation" and "Rapid Value Delivery." Also these terms feel mouthful to read. How about "Continuous Experiment to Assess Values Early On"?
Best Points
The chapter is easy to read, and the message is clear. The chapter emphasizes the need of agile-like, continuous assessment based on the software engineering data. The goal is to understand software development is addressing the right problems that customers want the software to address early on and continuously.