Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust (Anglais) Broché – 5 avril 2012
|Neuf à partir de||Occasion à partir de|
Les clients ayant consulté cet article ont également regardé
Descriptions du produit
Présentation de l'éditeur
Software in 30 Days summarizes the Agile and Scrum software development method, which allows creation of game–changing software, in just 30 days. Projects that use it are three times more successful than those that don′t. Software in 30 Days is for the business manager, the entrepreneur, the product development manager, or IT manager who wants to develop software better and faster than they now believe possible. Learn how this unorthodox process works, how to get started, and how to succeed. Control risk, manage projects, and have your people succeed with simple but profound shifts in the thinking.
The authors explain powerful concepts such as the art of the possible, bottom–up intelligence, and why it′s good to fail early all with no risk greater than thirty days.
- The productivity gain vs traditional "waterfall" methods has been over 100% on many projects
- Author Ken Schwaber is a co–founder of the Agile software movement, and co–creator, with Jeff Sutherland, of the "Scrum" technique for building software in 30 days
- Coauthor Jeff Sutherland was cosigner of the Agile Manifesto, which marked the start of the Agile movement
Software in 30 Days is a must–read for all managers and business owners who use software in their organizations or in their products and want to stop the cycle of slow, expensive software development. Programmers will want to buy copies for their managers and their customers so they will know how to collaborate to get the best work possible.
Quatrième de couverture
SOFTWARE IN 30 DAYS
A Radical Approach to Fast, Valuable, and Low–Risk Software Development
Software development doesn′t have to be slow and expensive anymore. The Agile and Scrum software development method allows creation of the game–changing software you need to grow your business in 30 days or less. Projects that use it are three times more successful than those that don′t, and the productivity gain versus traditional "waterfall" methods has been over 100 percent on many projects.
For the business manager, the entrepreneur, or IT manager, Software in 30 Days explains how this unorthodox process works, how to get started, and how to succeed. Learn powerful concepts such as the "art of the possible," "bottom–up intelligence," and why it′s good to fail early. With simple but profound shifts in thinking, you will be able to control risk, manage projects, and deliver your best work possible, faster and cheaper than ever before.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre adresse e-mail ou numéro de téléphone mobile.
Détails sur le produit
En savoir plus sur les auteursDécouvrez des livres, informez-vous sur les écrivains, lisez des blogs d'auteurs et bien plus encore.
Dans ce livre(En savoir plus)
Commentaires en ligne
Meilleurs commentaires des clients
Les premiers chapitres expliquent les raisons pour lesquelles les méthodes traditionnelles ne marchent pas dans 80% des cas.
Très vite les auteurs en arrivent au coeur du sujet, c'est à dire ce qui change avec les méthodes agiles et la manière de les déployer en entreprise. De manière très pédagogique et avec plein d'exemples, les auteurs détaillent les pratiques qui permettent de développer des logiciels plus vite, mieux : des cycles itératifs courts, une planification sur du reste à faire réel, une construction basée sur la valeur ajoutée de chaque fonctionnalité, une recherche d'amélioration continue.
A noter néanmoins, le titre est un peu trompeur : en 30 jours vous n'aurez probablement pas un logiciel "complet", c'est à dire qui répond à 100% à vos besoins. Par contre, à chaque cycle, vous avez des briques qui fonctionnent et sont prêtes à être déployées ou modifiées.
Commentaires client les plus utiles sur Amazon.com (beta)
The book consists of 2 parts and a bunch of appendixes. The first part is the "why" which explains why traditional waterfall development is not suitable today and how an empirical process is better suited for the job.
The first chapter is a "we are in crisis" chapter. Unfortunately, the only data it quotes is the CHAOS report, which has been challenged a lot of time already. Next to that, it provides some anecdotal cases. It introduces the Stacey diagram, which is great, except that it is significantly changed and Stacey doesn't use it himself anymore.
The second chapter introduces the basics of empirical process and shows how it resolves problems in traditional waterfall development. It also summarizes major points on self-organization and the "new new product development game" article that influenced Scrum strongly. Also the third chapter explains the idea of just starting and getting and inspect-adapt loop going and that way evaluating whether Scrum produces any results. And chapter four explains the art of the possible and why transparency is essential and how Scrum assists with that. Chapter four was pretty good.
Then, part 2. Chapter 5 is a short introduction to Scrum. Interestingly enough, it mentions that the ScrumMaster is 'a manager' which felt a bit odd and simplistic. The rest of the Scrum introduction was extremely short, just mentioning terms but not explaining them deeply.
Chapter 6-8 give examples on how to adopt Scrum. From small project team (chapter 6) to the whole organization (chapter 8). Chapter 6 ought to explain how to start Scrum on a project level, but when looking at the chapter, the first half spends time explaining burn-down charts and the second half is trying to convince the world that 30-day sprints are "the right length". I found this somewhat odd as most of the world seems to recommend against 30-day sprints. It even calculates the overhead for shorter Sprints, but that is than contradicted by the Scrum Guide in appendix A which clearly states that the meetings are proportional to the Sprint length.
Chapter 7 talks about "studio level" adoption, which seems to be a part of an organization. It starts with the suggestion to let everyone sign a contract that they'll use Scrum, which felt odd to me. Then it showed a survey for determining how people are aligned with Scrum assumptions, which was pretty good. Then it shows a "dashboard" of metrics for management to use which to me felt a bit simplistic (I know Ken is doing more work on this at the moment, and hope it will improve). It then calls velocity a measure of productivity (which can be quite dangerous) and suggests it to be measured in function points. I'm personally not aware of many Scrum projects that actually use function points, so I felt the mentioning of that was a bit odd. The end of the chapter related to technical dept was quite good again!
Chapter 8 about adopting Scrum to the enterprise was 3 pages. Chapter 9 are the steps of a change project. This mostly is a summary of Kotter's change management ideas. Chapter 10 explains the concept of using Scrum to adopt Scrum, which is a summary of Ken's Enterprise Scrum book.
Appendix 1 is terminology. Appendix 2 is the excellent Scrum Guide, which you can also find online. Appendix 3 is a play-book for adopting Scrum developed by Rally, which didn't seem to have changes much since 2005.
All in all, the book had its good moments followed up by moments that made my head shake. The tone of the book was quite selling, which annoyed me a bit at times. The explanations of Scrum felt mostly shallow and then deep on surprising moments (3 pages on why the Sprint length should be 30 days, about as much as about adoption of Scrum to the enterprise). In general, the book didn't feel like one whole and felt like it was put together in a hurry. I had thought about giving it 3 stars, but think that would be too much as I wouldn't recommend reading this book. If you want a better introduction to Scrum by the same author, pick up the somewhat dated Agile Project Management with Scrum (Microsoft Professional) or just download the Scrum Guide (or alternatives).
I had expected more from two respected and influential people in our industry.
Ken and Jeff's latest book nails it. It starts off with a very real case study involving the FBI and their wasting of millions of dollars in failed software development efforts. The authors then present the why and the how the management team chose and adopted Scrum, getting the product to code complete.
After reading the book, any intellectually honest manager will see the value of empiricism and be crazy not to put Scrum to work on their next or current project.
If you're in just such a situation then this book is perfect for you. Software in 30 Days explains the root causes of your problems and ways to address those problems. It also includes practical steps on how to transition your organisation's approach to software development so that you can end the pain and start getting genuine value from your software development efforts.
(Socializing books is a great way to find out who really wants to come and play. The folks that actually invest the time to READ THE BOOK are the people who are actually ready to play the game.)
This book is an effective and useful tutorial and reference guide for those who are implementing Scrum and are seeking guidance. We have learned quite a lot since Ken's book [Agile Software Development Using Scrum] published in 1996, and this book reflects that learning.
SOFTWARE IN 30 DAYS OR LESS is an important book to add to your in-house library of essential Agile titles. Genuine and authentic Scrum is rare, and this book can help you get there.
I strongly recommend this book.
I also recommend that purchasers of this head over to Scrum.org to download, print, and actively begin reading the current version of Scrum Guide, also authored by Ken and Jeff.
If you are starting in Scrum, you can use the following 3 documents to get you started:
1. This book
2. The current version of the Scrum guide found at Scrum.Org
3. The Agile manifesto value and principles found at:
b. [...] (principles)
Disclosure: The authors are my friends, my book THE CULTURE GAME refers to Scrum frequently, and I believe that Scrum as described in this book has the potential to substantially improve the world of work.