SwarmQuestionnaire: mudanças entre as edições
Sem resumo de edição |
Sem resumo de edição |
||
| Linha 60: | Linha 60: | ||
<span style="color:#96160B">'''Member 3:'''</span> 5 years. | <span style="color:#96160B">'''Member 3:'''</span> 5 years. | ||
<span style="color:#96160B">'''Member 4:'''</span> | <span style="color:#96160B">'''Member 4:'''</span> five years. | ||
---- | ---- | ||
| Linha 71: | Linha 71: | ||
<span style="color:#96160B">'''Member 3:'''</span> Intermediate. | <span style="color:#96160B">'''Member 3:'''</span> Intermediate. | ||
<span style="color:#96160B">'''Member 4:'''</span> | <span style="color:#96160B">'''Member 4:'''</span> I would say I have a pretty basic knowledge of ruby, not advanced knowledge at all. | ||
---- | ---- | ||
'''3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?''' | '''3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?''' | ||
| Linha 81: | Linha 81: | ||
<span style="color:#96160B">'''Member 3:'''</span> I do like it. But I also believe it does not fit everywhere. It does depend on the people and activities involved. | <span style="color:#96160B">'''Member 3:'''</span> I do like it. But I also believe it does not fit everywhere. It does depend on the people and activities involved. | ||
<span style="color:#96160B">'''Member 4:'''</span> | <span style="color:#96160B">'''Member 4:'''</span> I think it is a really interesting method to equilibrate knowledge in the team. However, this was the first time I used mob programming. | ||
---- | ---- | ||
'''4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?''' | '''4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?''' | ||
| Linha 91: | Linha 91: | ||
<span style="color:#96160B">'''Member 3:'''</span> It takes communication and knowledge sharing to the next level, I don't believe no other practices would be as good for these two purposes. | <span style="color:#96160B">'''Member 3:'''</span> It takes communication and knowledge sharing to the next level, I don't believe no other practices would be as good for these two purposes. | ||
<span style="color:#96160B">'''Member 4:'''</span> | <span style="color:#96160B">'''Member 4:'''</span> I believe mob programming has some similar core concerns of approaches such as pair programming. However, the focus on the interaction is the focus on mob programming. | ||
== '''Individual answers of team members: [[GeoXPerience 2016]]''' == | == '''Individual answers of team members: [[GeoXPerience 2016]]''' == | ||
Edição das 15h48min de 18 de dezembro de 2016
Questionnaire about technical knowledge with programming and Mob Programming
Individual answers of team members: Automata.Life 2016
These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:
1. How many years have you programmed? (Educational and professional experience in any language)
Member 1: Programming at 4 years.
Member 2: Around 7 years, with a 1.5 year gap without programming
Member 3: I have 6 years of programming experience.
Member 4: I have been programming for 4 years.
2. How do you evaluate your current level of knowledge in the programming language used currently?
Member 1: In the current project, I know the basics of all languages (Python, javascript, java ...). The language I use most outside of this subject is lua, and I feel extremely comfortable using it (advanced knowledge).
Member 2: Basic to Intermediate.
Member 3: I have intermediate to advanced knowledge about the languages used, but basic to intermediate knowledge of the specific frameworks and tools used in the project.
Member 4: Low Intermediate.
3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?
Member 1: I really liked mob-programming, and it was the first time I heard about it and was the first time that I used this practice.
Member 2: Yes, this was the first time I heard about MOB programming, but I enjoyed using it
Member 3: I love Mob Programming. I had no experience with it before this course.
Member 4: Yes I like Mob Programming, but I did not have any experience in the technique before the course.
4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?
Member 1: I found mob-programming a very rewarding practice, bringing many benefits to our project. I found it agile and with constant feedback on the progress of the project, which is something I felt working with XP practices.
Member 2: The team communication is better with mob and everyone knows about everything in the project so there's no need for stand ups which is nice.
Member 3: Mob Programming helps to create a sense of community, group and even friendship between the members of a programming team. Although I feel XP also has this effect, I believe Mob does more for creating a united group.
Member 4: Since I have had no real experience with other agile methodologies, I do not see myself in a position to compare them. As for the other methodologies more guided by the planning, I can say that Mob Programming made it possible for all the members to have knowledge and understanding of the totality of the project (ideal for the development of small projects), the same can no longer be said of other methods that focus In the proper division of labor among its members. If, on the one hand, the division of labor allows the parallel execution of tasks by accelerating the progress of the project by the number of members, on the other hand, working together allows the overcoming of blockages much more easily and efficiently.
Individual answers of team members: Mezuro
These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:
1. How many years have you programmed? (Educational and professional experience in any language)
Member 1: 30 years.
Member 2: 5 years.
Member 3: 5 years.
Member 4: five years.
2. How do you evaluate your current level of knowledge in the programming language used currently?
Member 1: In the current project, my knowledge is only the basics of Ruby on Rails and Bash. The language I have advanced knowledge is C #. However, we used a lot of Ansible, and I did not know anything about Ansible, but I did learn with the group members who know Ansible, Linux, Fedora and Debian very well.
Member 2: Most of the code was written in Ruby, of which I have a good knowledge, and Bash, of which I have average knowledge.
Member 3: Intermediate.
Member 4: I would say I have a pretty basic knowledge of ruby, not advanced knowledge at all.
3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?
Member 1: I loved using Mob, I learned a lot about Ansible and Linux. Yes I had already used it, but this time I learned more. However, it is natural learn more in the university, with an environment favorable to scientific experimentation in relation to the labor market with its need by result and profit.
Member 2: I enjoyed using Mob, but I had never used it before.
Member 3: I do like it. But I also believe it does not fit everywhere. It does depend on the people and activities involved.
Member 4: I think it is a really interesting method to equilibrate knowledge in the team. However, this was the first time I used mob programming.
4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?
Member 1: Mini retrospectives are better to improve the colaboration than just a retrospective at the end of Sprint.
Member 2: I wouldn’t rate Mob as a better or worse practice, it’s just another tool to approach specific problems during development.
Member 3: It takes communication and knowledge sharing to the next level, I don't believe no other practices would be as good for these two purposes.
Member 4: I believe mob programming has some similar core concerns of approaches such as pair programming. However, the focus on the interaction is the focus on mob programming.
Individual answers of team members: GeoXPerience 2016
These four questions are pertinent to experience in the evaluated technologies and processes in the experiment:
1. How many years have you programmed? (Educational and professional experience in any language)
Member 1: Member 2: Member 3: Member 4:
2. How do you evaluate your current level of knowledge in the programming language used currently?
Member 1: Member 2: Member 3: Member 4:
3. Do you like Mob Programming? You had practical experience with Mob Programming before this course?
Member 1: Member 2: Member 3: Member 4:
4. How would you compare Mob Programming to other practices you have tried or know about such as XP, Scrum, etc?
Member 1: Member 2: Member 3: Member 4:
Questionnaire about your experience with Mob Programming at LAB XP
Teams Answers
These seven questions are pertinent to the setup of the room and also ask for a description of the Mob setting. Please describe the environment where your team practice Mob programming:
1. Do you use a tv or a projector? How many?
Automata.Life 2016: Yes. We use two projectors.
Mezuro: Yes. We used a single large television.
2. Sometimes other computers were used? Could be useful?
Automata.Life 2016: Yes. They were useful for parallel searches.
Mezuro: Yes. Another computer was used when a task with the main computer implied a large idle time.
3. How many people in the work room? Everybody was from you team?
Automata.Life 2016: Around 30 people. Not everyone on our team. We are the only Mob team in the room, with 4 members.
Mezuro: There were around 8 people in the work room, 4 of them belonged to our team.
4. People from other teams asked or helped in something? Noise was a problem?
Automata.Life 2016: We had sporadic interactions with other teams, but nothing regarding technology or problem solution. Two members were heavily annoyed by the noise. Two members were not bothered too much.
Mezuro: Noise was not a problem and people from other teams helped us as they saw problems we ran into while working in the large TV (if we weren’t using that media, it’s likely that they wouldn’t have seen our troubles).
5. How to improve the visualization? Was it adequate to see the code?
Automata.Life 2016: We usually increased the magnification of the text and the brightness of the projectors. Reading the code was adequate, but we would like to be able to dim the room’s lights a little bit more.
Mezuro: The large television helped a lot with the visualization and no obvious improvements were necessary to help with the coding.
6. Did you use a laser pointer or other ways to communicate to the driver?
Automata.Life 2016: We used the laser pointer during some work sessions.
Mezuro: No. We just explained where we the changes were supposed to be made. However we do think that a pointer would be helpful.
7. Could you send photos to us that you and all team member authorizes to publish?
Automata.Life 2016: Alfredo took some pictures during the classes. We authorize the usage of those pictures. Please let us know if more photos are needed.
Mezuro: Yes. The photos will be shared.
8. Were there people missing at the Mob sessions? About work frequency of people, do you think Mob Programming improves engagement or helps in good work environment? Something more about that?
Automata.Life 2016: All members were present at all Mob sessions. We think Mob Programming improves the engagement and work environment. We believe that having all members solving the same problem really helps understanding how to solve it. Even when individual members leave temporarily, the group is able to make progress.
Mezuro: There were sessions without the whole team, as each individual simply had a total number of hours to be fulfilled during the semester. Mob programming is certainly not detrimental to the work environment, but a harmony among coworkers can be achieved through other organizations too. Alternating between pair and mob programming could be a positive practice.
These questions are pertinent to Driver rotation:
1. Do you use a timer or a program? How was it?
Automata.Life 2016: We developed our own timer tool. It received an integer as argument and warned us when time was up. We enjoyed the timer because it helped us organized the rotation. We typically used 15~20 minutes.
Mezuro: Yes. We created a simple script to count down the time of each driver and alert the team when it’s time to swap.
2. Do you use Strong Style driving style? When the driver does not have the ideas and for an idea to go from your head to the computer, it must go through someone else’s hands.
Automata.Life 2016: We were able to use the Strong Style at some points.
Mezuro: Only in the beginning, we soon decided try our own style.
3. If the Strong Style was not used, please describe the experience and compare with other styles that your team used including how it worked.
Automata.Life 2016: N/A
Mezuro: We started trying to evenly divide the driving time among the team, however the disparities in the previous knowledge of the members prevented us from doing Strong Style driving in mind. With that in mind, we decided to let the less experienced members drive more often, which greatly improved the knowledge spread.
4. If your team tried Strong Style, please describe the experience and compare with other styles that your team used or have previous experience with.
Automata.Life 2016: We had difficulty enforcing it all the time. We found it difficult to force the rotation when the current driver had an idea to solve the problem, but we were able to do that sometimes. We had a good experience with Mob Programming, but we believe that its potential could be better developed when most members of a team are familiar with all technologies used in the project.
Mezuro: The team spontaneously tried in the beginning. Then we decided that the driver only drive, so the less experienced members drove more often.
These questions are pertinent to retrospectives and mini-retrospectives:
1. Could you send photos to us that you and all team member authorizes to publish?
Automata.Life 2016: Yes. I will send Alfredo the photos of our retrospective and Kanban boards.
Mezuro: Yes. The photos will be shared.
2. Did the team do daily mini-retrospectives?
Automata.Life 2016: We did not do daily mini-retrospectives, but we did a mid-project retrospective, and a mini-retrospective during a call with Yoder.
Mezuro: We didn’t do daily formal retrospectives as the members talked a lot with each other and we didn’t feel the need to halt our work for that (many of our tasks required a considerable amount of idle time, which gave us plenty of opportunities to retrospect).
3. Did the team do other longer retrospectives (weekly, every other week, monthly, ...)?
Automata.Life 2016: We did one long retrospective before starting Mob Programming.
Mezuro: Yes. The team did larger retrospectives monthly, around the time of each merge request.
4. Did the team change anything after a retrospective (Sprint) or mini-retrospective (Mob Session)? What was changed? Were the changes useful?
Automata.Life 2016: Yes. We decided to start the day with 30 minutes of individual research on an unknown topic or technology relevant to the project. The changes helped us to understand the technologies. These question are pertinent to automation of the job and avoid idle time. The difference between wasting one minute of your time versus wasting one minute of your entire team.
Mezuro: Yes. The retrospectives led to many positive changes, one of which we can highlight is the (already mentioned) reorganization of the drivers and the alterations of the informative workspace to better fit Mob Programming.
These question are pertinent to automation of the job and avoid idle time. The difference between wasting one minute of your time versus wasting one minute of your entire team’s:
1. Did your team automate anything? What? Why? Was it useful?
Automata.Life 2016: Yes. We automated the build, test and deploy processes and the timer. We did it because those tools helped us performing daily tasks.
Mezuro: We tried to reduce wasted time by making use of our text editor’s automated functionalities (Vim). Furthermore, we frequently used shell commands to speed up various processes (especially mass changes).
2. Did members of your team every split off and do some spike solutions to integrate back into the main solution?
Automata.Life 2016: Yes, when we had to learn new technologies and performed separated searches.
Mezuro: No. Mainly because of how troublesome it was to set up a DevOps workspace in different computers.
These questions are pertinent to full involvement all the time can be exhausting:
1. Did the members of your team take breaks together? How were them?
Automata.Life 2016: Team members usually left to and came back from breaks individually, but we had some team breaks.
Mezuro: Due to the abundant idle time, we would frequently stop to chat about subjects outside of the project’s scope. However, we didn’t take formal breaks together.
2. Did your team make sure that every hour there was a 5–10 min break where people weren’t allowed to be behind the screen? What do you think about that?
Automata.Life 2016: We had spontaneous breaks instead of scheduled ones. We liked the freedom of being able to choose breaks individually and knowing that the team continues to make progress even when individuals left for a break.
Mezuro: No. Even during our breaks we were constantly worried about whether our last deploy had succeeded.
This question is about learning as a team:
1. Did your team try learning something? Was it together? Was it at the beginning of the Mob Session? How was the learning experience?
Automata.Life 2016: We did try to learn things together during the project. It was not always at the beginning of the session. Sometimes we were able to learn effectively.
Mezuro: Once during the semester, we focused on a subject (Continuous Integration in GitLab) and studied it as a team at the beginning of a Mob Session. This study had been planned for some time before that session.
This big question is pertinent to Groupthink. Just because we act with kindness, consideration, and respect does not mean that we always agree, nor does it mean we want to always agree.
Do some of the members in your team have strong personalities? What do you do about strong personalities? Did it help or hurt the team? Do you think that the decisions of your team were sometimes tentious or influenced by a strong personality?
Automata.Life 2016: No. N/A. N/A.
Mezuro: Yes. In some way, each member had their own unique personalities: some due to their knowhow and experience regarding the project, some due to their views on the group organization and the evaluation processes. Fortunately, all these conflicts had a positive effect on the team, as many of our decisions (especially when talking about knowledge dissemination and driver setup) were made with each member’s opinions, preferences and needs in mind. For example, we considered organizing small lectures made by the experienced members to the rest of the team.
These questions are pertinent to Collective Intelligence. Every programmer has experienced moments of mental exhaustion where it can take a lot of time to resolve even the most trivial problem. Most programmers (even those that do not practice pair or mob or pair programming) are aware of this and will invite a fellow programmer to take a look at their code in those moments of frustration. In a mob programming session, such moments are practically non-existent.
1. Does your team agree with the above affirmation? Was it unanimous?
Automata.Life 2016: Since our entire team was not familiar with all the technologies that we used in the project those moments of frustration happened, because no one knew what to do. When that happened we switched to individual searches.
Mezuro: No, the team does not agree. Basically, during some devops tasks, there were some days that a project build was failing and no member of the team knew what to try. It was exhaustive to the whole group to approach these situations. However, we do not know if that is simply because of the nature of devops tasks.
2. Did the experience help the overall team grow with collective intelligence? Were there advanced members that felt Mob Programming was holding them back or slowing them down?
Automata.Life 2016: Yes. Sometimes a member of the group was able to come up with a solution that helped the group.
Mezuro: Yes, Mob programming definitely helped on that matter. Since the knowledge was not spread on the beginning of the project, Mob Programming helped equilibrating that. This could be seen on further discussions of the team, which every member started raising questions and opinions about the project.
3. Were there advance members that felt Mob Programming was holding them back or slowing them down?
Automata.Life 2016: No.
Mezuro: About the advanced member, there was no such feeling. Mostly because the tasks the team was performing demanded knowledge that no member in the team already had. Therefore, the contribution of every member on solving issues were gladly welcomed.
These questions are also pertinent to Collective Intelligence. When dealing with more far-reaching issues like design and architectural questions, swarming provokes a creative dialogue and exchange of ideas without falling into a trap of long and heated arguments. After a while, in cases when a significant difference in opinion persists longer than usual, the collective decisions are based on mutual trust.
1. Does the team agree with the above statement? Tell something about that based on your team experience at LAB XP.
Automata.Life 2016: Yes. We usually made decisions based on trust and emerging from a group vote. We discussed opposing ideas but we always reached a consensus.
Mezuro: Yes. We realized that this “united development” allowed each member to better understand the thought process behind the decisions, which, in turn, reduced the amount of unnecessary arguments and conflicts. Most of those conflicts were resolved with a simple nod from each member.
These questions are pertinent to Learning and mentoring. In the knowledge industry, learning and mentoring should be an integral part of everyday work activity. A swarm provides an ideal environment for that, as long it is done in a deliberate manner and at a steady pace. By observing others, team members learn almost immediately how to make better use of tools and perform their day to day work. More importantly, they will soon gain deeper understanding of a problem domain and will improve their problem solving skills as they observe and question others on proposed solutions. 1. Do you agree with the above statement?
Automata.Life 2016: Yes. We use two projectors.
Yes. 2. Please, describe if Mob Programming helps to understanding of the problem domain and improve technical competence based in your team experience at LAB XP.
Automata.Life 2016: Yes. We use two projectors.
Yes. We were able to learn from others’ knowledge and experiences. We grew as a team while we learned new technologies.
These questions are pertinent about if other practices were used or only Mob Programming:
1. Do your team used Mob Programming all the time? Was there activities where your team do not apply Mob Programming? Why?
Automata.Life 2016: Yes. We use two projectors.
We used Mob Programming all the time.
2. What other practices did your team use such as informative workspace of Kanban?
Automata.Life 2016: Yes. We use two projectors.
We used a Kanban and a burndown graph.
3. Please, tell us about your informative workspace and about other practices you used?
Automata.Life 2016: Yes. We use two projectors.
We used a whiteboard where we wrote the Kanban and the burndown. We also used a small whiteboard where we drew concepts and ideas.
4. Did your team stop using Mob Programming or used other practice together with Mob
Programming?
Automata.Life 2016: Yes. We use two projectors.
No.
5. Did your team try to Improve the Mob Programming Session?
Automata.Life 2016: Yes. We use two projectors.
We tried to inserted learning sessions during the Mob Sessions, where each member used a computer to learn or search a topic.
6. Do you think that it is good mob programming all the time?
Automata.Life 2016: Yes. We use two projectors.
We think that when no one on the team knows a technology it is better to individually search and learn.
7. Did members of your team say that they approved and enjoyed the Mob Programming? Was it Unanimous?
Automata.Life 2016: Yes. We use two projectors.
Yes it was unanimous.
8. Do you think that Mob Programming was productive? Why? More productive than other ways you’ve previously used working with groups of people?
Automata.Life 2016: Yes. We use two projectors.
Yes because the team was able to continue working even when some members left for a break. We believe that Mob Programming was useful to spread the knowledge between team members and was more productive because every team member became familiar with the code and the build process.
9. Did your team measurement something? How and what your team measured?
Automata.Life 2016: Yes. We use two projectors.
Yes. We measured the points of each task using a burndown graph.
10. What was your favorite experiences of Mob Programming?
Automata.Life 2016: Yes. We use two projectors.
Sharing knowledge and working with friends.
These questions are pertinent to Continuous Improvement:
1. Was there any change from when you started to do Mob programming?
Automata.Life 2016: Yes. We use two projectors.
Yes. We started to allocate 30 minutes at the beginning of each session to individual searches.
2. How would you improve your environment in the future?
Automata.Life 2016: Yes. We use two projectors.
We would like a more silent room and that each member has access to an individual notebook or computer.
3. Do you have any ideas on improving the Mobbing process or Swarming?
Automata.Life 2016: Yes. We use two projectors.
No.