The game is usually played with 24 cards of four colors. The cards are as follows, next to each card there is a single letter that will represent the card for us.
- Ace - A
- King - K
- Queen - Q
- Jack - J
- 10 - T
- 9 - N
nextMove (cardsA, cardsB)
Sunday, April 28, 2019
Code Kata: the card game of war
The card game of war is a very old, but still popular game. I used to play it when I was a child. The game is very suitable for small kids, because it has simple rules and the players don't need to make any decisions - it's enough to follow the rules. In this article, we will try to go through the process of modeling the game of war as a computer program. And as we will see later, the modeling may have some very practical uses. Let's start.
The game is usually played with 24 cards of four colors. The cards are as follows, next to each card there is a single letter that will represent the card for us.
nextMove (cardsA, cardsB)
The game is usually played with 24 cards of four colors. The cards are as follows, next to each card there is a single letter that will represent the card for us.
nextMove (cardsA, cardsB)
Tuesday, February 26, 2019
Requirements discovery
Requirements have a long history in software industry. We all have heard or read terms like: requirements definition, requirements management, requirements decomposition... tons of books, trainings and requirements themselves have been created for software all over the world.
Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.
Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.
In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.
Factors that help us discover requirements:
And last but not least, the Proof of Concept (or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.
To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.
Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.
Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.
In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.
Factors that help us discover requirements:
And last but not least, the Proof of Concept (or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.
To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.
Sunday, January 28, 2018
Attitude is more important than skills
I was fortunate to work with a few development teams that were truly cross-functional. Every developer was able to perform several types of tests, build and deploy the product and develop code in layers of the product. Not many teams are like that.
More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.
This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact with each other and we can hopefully make it more transparent and use it to team's advantage.
Take me as an example - I have had much more development practice in backend than in frontend. Most of frontend designs I created were terrible. But if I were to re-use existing stylesheets and create a design of a sub-page that will be based on the current look and feel of an existing web service, I would be able to do that. Let me try to categorize my development skills a bit further:
- Listen, this is not what I like most and I may not feel comfortable working hand in hand with other frontend developers, finishing their tasks quicker than me. But I am willing to work on this, because we need to be flexible as a team in order to reach our goals. I will need some help from our frontend experts. And please do blame me too much on how long it takes me to complete or if I stumble.
Traditional approach to skillset problem would be for a resource manager to draw up a skillset matrix, have everyone in a team tick off their skills and then assign goals so that people learn things. I'm not saying this method is completely wrong, it can be useful to identify situations we need to address, but look - even without goals for learning new skills most developers are able to do a range of things wide enough to produce a list of categories, like mine above.
Let's make the categories a bit more official. You can come up with your own categories and have more or less then four, but for now let's move on with the ones I proposed.
The drawing on the left serves just to depict the categories and the range of things beyond one's capacity (can't do), so do not pay attention to how much percent each category spans.
With categories suited for your team, you can ask all your team members to consider their skills for themselves and then act fairly upon it, or you can go further and, upon unanimous agreement, arrange a session to talk about each other's skills openly.
The goal is to develop an attitude, within all team members, to be willing to take up most work based on what the team needs to achieve, rather than on "what gives me most fun" or "what increases my self-esteem".
The Product Owner defines the backlog based on what the customers need. It is not their job to define the backlog so that different skillsets in the team are fully utilized. This is why the development team must be able to create a substantial level of flexibility of skill. The way towards it is not that much through analysis and goals as it is through the change of culture and habits.
More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.
This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact with each other and we can hopefully make it more transparent and use it to team's advantage.
Take me as an example - I have had much more development practice in backend than in frontend. Most of frontend designs I created were terrible. But if I were to re-use existing stylesheets and create a design of a sub-page that will be based on the current look and feel of an existing web service, I would be able to do that. Let me try to categorize my development skills a bit further:
- I'm skilled in backend - I'm really good at it, I'm able to develop elegant solutions quickly and I'm also able to mentor others.
- I'm comfortable with testing - I like finding ways to break things, I do not mind going through dozens of repetitive test scenarios. Testing doesn't give me as much fun as backend development, but I feel quite comfortable doing it.
- I'm weak in frontend - you know that already. But I am able to execute the simpler tasks, especially those that are based on existing styles and controls. If I were to work on a completely new wireframe, I would need some support from another developer and even with that it would probably take me some extra time.
- I'm lame when it comes to concurrency - I have rather academic knowledge of the topic, so even if I took much extra time to work on that kind of task and had the help from another developer available, I'm afraid I would let too many bugs through.
- Listen, this is not what I like most and I may not feel comfortable working hand in hand with other frontend developers, finishing their tasks quicker than me. But I am willing to work on this, because we need to be flexible as a team in order to reach our goals. I will need some help from our frontend experts. And please do blame me too much on how long it takes me to complete or if I stumble.
Traditional approach to skillset problem would be for a resource manager to draw up a skillset matrix, have everyone in a team tick off their skills and then assign goals so that people learn things. I'm not saying this method is completely wrong, it can be useful to identify situations we need to address, but look - even without goals for learning new skills most developers are able to do a range of things wide enough to produce a list of categories, like mine above.
The drawing on the left serves just to depict the categories and the range of things beyond one's capacity (can't do), so do not pay attention to how much percent each category spans.
With categories suited for your team, you can ask all your team members to consider their skills for themselves and then act fairly upon it, or you can go further and, upon unanimous agreement, arrange a session to talk about each other's skills openly.
The goal is to develop an attitude, within all team members, to be willing to take up most work based on what the team needs to achieve, rather than on "what gives me most fun" or "what increases my self-esteem".
The Product Owner defines the backlog based on what the customers need. It is not their job to define the backlog so that different skillsets in the team are fully utilized. This is why the development team must be able to create a substantial level of flexibility of skill. The way towards it is not that much through analysis and goals as it is through the change of culture and habits.
Subscribe to:
Posts (Atom)