Part III. Practices
ALL TEAMS—EVEN TEAMS WITH GREAT PEOPLE WHO WORK REALLY WELL TOGETHER—HAVE HABITUAL problems. And when they do, the problems are bigger than the individual people on the team. It's both frustrating and difficult when you just know your team is technically capable of solving their problems, but somehow they keep succumbing to them.
That's where changing the way you work can have a big impact on how your team works. And that's what practices are all about: finding a better way to do things so that your team doesn't get stuck on the same old problems.
The world is full of books about building software: some great, some good, some not so good. The not-so-good books claim to tell you "the right way" to build software. The good and even great ones will tell you that they have a good way—not necessarily the way—to build software. What they all have in common is practices.
It's pretty easy to get overwhelmed with practices, because it seems like there are dozens of ways to do any one thing on a project. Just deciding how you'll describe how your users will use the software can be a challenge. Will you use user stories? Use cases? Textual use cases or visual, UML-style use cases? Or maybe more traditional stimulus-response sequences (which predate both use cases and user ...
Get Beautiful Teams now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
