![]() Ask what should happen if a particular step in the process fails or (even worse) if it’s taking ages and might never finish. Make them think what should happen if things do not go as planned. Very likely the flow you have drafted together is the happy flow⁴. You have to guide them by asking the right questions. Of course you can’t just ask them to do it, since they wouldn’t know where to start. Now that you share the language and the understanding of the problem, let them define the acceptance criteria and the tests. Who knows the edge cases of the business process you’ll be implementing? Who would come to you with “last minute changes” after they had seen your work in progress for the first time? Who will identify some new edge cases after golive, causing the scope creep? Yes, that’s the problem owner. What you’re building now is referred to by the DDD as the ubiquitous language. Keep in mind that every action also deserves a good name. Note down that there is a relation between the terms you yet need to explore.ĭon’t focus only on objects. Note down both terms in your glossary, along with the definitions given by both teams. Don’t ask them to decide how we’re going to call it (yet). This might mean that you have just identified a concept that plays a different role for these different teams. ![]() Some other terms will trigger discussions between the business people. Some terms will be new to you, but all the business people will feel comfortable about them. Now it’s the time to describe the problem together. Some good quality stickies might help as well. Get yourself some coffee and a large sheet of paper. If you’re in a room with business people from different teams then most likely you’re not the only one confused. You just heard a fascinating story in a language you don’t fully understand. Encourage them to use their natural business language. They will use vocabulary specific to the systems they’re used to. Tip: some business people will try to bridge the gap between them and you by making an effort to talk in technical terms. You want to know how they perceive the problem. Listen actively and don’t try to correct them. Ask the problem owners to describe the problem in their own words. This disables the teams from understanding the problem their software is supposed to solve.Īs a developer, let the product owner, the project manager or whoever with a good network in the organization connect you to the problem owners. The worst scenarios I’ve seen involved a business person describing the past solution, the analyst noting it down as the requirements and the developers blindly rebuilding the solution described by the business person, including misunderstandings emerging on the line. In a traditional IT organization there might be a chain of people passing the information between the business and the developers. If you ask the problem owners for the solution, they will suggest ones they had seen in the past, which is not necessarily the best. Business problems can be solved in many ways. The primary goal of your software is to solve a business problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |