About me, about school 1C and about the June module of the course "Management of software development"
In June, I taught a course on software development management at the 1C: Programmers Club. For two weeks we discussed with schoolchildren the realities of IT life, and schoolchildren in teams coded projects. In this post, I tell you exactly what we were doing.
My name is Vitaly Pavlenko, I graduated from the MIPT undergraduate degree in Applied Mathematics and Computer Science. Trained year software engineer in the company Intel. For the past four years, I have led a circle on Olympiad programming in the Moscow Gymnasium of 1534, computer science lessons at the Intellectual School, and taught at the Summer Computer School and many other mobile schools. I’m used to telling schoolchildren Dijkstra and Cartesian trees, and in the last year I’m also trying to talk about web frameworks and cryptographic protocols.
This spring, I was called to 1C: Club of Programmers ( http://club.1c.ru ) to give a course entitled “Managing Software Development”. The program of the course seemed to me extremely unusual. Some parts of it were taught to us in high school at the Faculty of FIVT in the courses "Innovative Workshop" and "Project Management." Other parts are general knowledge about the realities of working in software companies.
As I later learned, “1C: Club of Programmers” is a network of hundreds of branches in different regions of Russia, which was created on the basis of centers for teaching adults how to work with 1C products. Schoolchildren in them are taught not 1C: Enterprise, but more interesting things: the basics of Java programming, basic algorithms, elements of system administration. At the same time, the development of a program of courses, manuals for pupils and teaching guides for teachers is conducted centrally in order to standardize teaching in various centers.
')
This year, the school management decided to launch a new course - “Management of software development”, which is intended for graduates of the course “Fundamentals of Java programming”. The guys are already good at programming, including working with window applications and drawing on the form. The main idea of ​​the new course is to talk about what is happening in the IT industry, as well as to give students the opportunity in small teams to code the project during the course.
A textbook describing the topics was written by Nikolai Zavriev (Lyceum of Information Technologies No. 1533, Moscow).
The textbook tells about such things:
- What are the various employees working in IT companies, what they do
- The path of the software product: design, implementation, testing, implementation
- Requirements collection process, terms of reference
- Software development models, waterfall model, iterative development, Agile and Scrum
- User Interface Design
The basis of the flow of time in the School is a module. During the year, the module is 12 lessons of two academic hours on weekends (it turns out the module = academic half-year). This year, 1C: The Club of Programmers held a special two-week June module for Moscow schoolchildren.
On the module in June there were only those who had already gone to the club before. Each student studied in June one of three courses: system administration, Olympiad programming and management. The pilot module of the course “Management of Software Development” was entrusted to me.
The statement of the problem was, as they say, challenging: there is a textbook just written and 14 schoolchildren. It is required to think up how to read this course: how to tell a theory and what practical tasks to give on it. And it was also required that the students in parallel with the development of the theory broke up into teams of 2-4 people, chose the theme of the project, which can be jointly coded in two weeks. The themes for the projects were chosen in such a way that the children could expand the functionality over the next year and present the project in the spring at one of the project competitions.
The module in June was conducted as a typical summer school: before lunch we had two pairs - theory and practice, and after lunch the students had a cultural program, consisting mainly of excursions. School leaders were able to organize a lot of excursions: both to leading IT universities like MIPT, Moscow State University and the Higher School of Economics, as well as to an underground bunker, to the main office of Yandex and to the Baskin Robbins ice cream factory.
At the very end of the school, at the closing, each team presented its project to all students of the school and their parents.
Here is an example of one such statement: http://www.youtube.com/watch?v=VA-30ANDArA
Everything we did during the course can be divided into three parts.
The first is the actual discussion of the theory. Every day we discussed a single topic from the textbook, which took half an hour to an hour.
The second is the practical tasks of the theory, if the theory allows it. For example, after the theory about TZ, each team needed to jointly write a technical task for their project in an hour.
And the third is programming in commands. About two hours a day, the teams programmed at the school itself, many people coded something at home in the evening.
I call the course on development management humanitarian. In contrast to the technical, the content of which consists of strict logical constructions, this course consists of a free description of reality from the point of view of the author. Teaching such a course was a new experience for me.
When you teach algorithms, the situation is this: at the beginning of a class, you are the only one in the audience who knows a detour wide (or almost the only one), and at the end - it seems to many schoolchildren that they also understood something. That is, at the beginning there is a clear difference in knowledge between you and during the lesson a tangible process of their transfer takes place. When teaching a course on the realities in the IT industry, everything is different. I read Habr and work in an IT company. But students also read Habr, and many parents also work in IT companies. Many already know certain aspects and realities, and it is very difficult to say something really new to everyone. However, in teaching such a course, there is also its own ease. On a course on algorithms, a teacher may poorly explain a detour wide, and a student may not understand it. With a course on managing the development of such problems almost did not arise.
Thinking about how to teach a course, I decided that it was important to do two things. First of all, it’s important to anticipate as many sub-topics as possible with questions to the audience: what do you know about it? For example, when discussing the project implementation stage, you should first ask schoolchildren: where should the project code be stored, where is it stored in real practice? Or: what is the correct programming style? Should I stick to it? Why do programmers do this? Pupils know most of what you yourself know about and tell you your vision. And here it is important to do the second thing: to tell something new, something that almost none of the listeners used to know before. For example, after discussing the topic of storing code, tell you about version control systems and their device. Or, after discussing the programming style, give an example of a real rule from the style guides and explain why its non-observance sometimes costs people several hours of happy debugging. It is very good to give examples from your own practice at work or examples from friends' stories.
To give a concrete idea of ​​how the classes were conducted, I will describe how we went through the topic “What, in fact, are we developing?”. It is arranged as follows:
- The stage of collecting requirements: communication with the customer, why is it difficult to find a common language with him?
- Work analyst with the customer: a demonstration of existing solutions, monitoring the lives of future users.
- Brainstorming to determine the requirements. Three stages: we collect a circle of potential users, generate ideas for implementation in the product, analyze and select the most suitable ideas.
- Technical assignment: its content, the problem "you can not describe everything in the TK."
We first discussed the theory. We started with a collective discussion of this situation. A customer comes to you and says: “I want a website for selling smartphones with weekly revenue of 100,000 rubles.” How should start a dialogue with him to gradually understand what we really need to do as a programmer?
After we discussed the theory at the lesson and looked at an example of a real TK for creating a site for a holiday home, I suggested to each team:
- brainstorm to develop the requirements for your project for the implementation of two weeks;
- to make up the results of brainstorming TK.
As a basis, I advised to take the TK, which we analyzed on the theory. After an hour of work, each team presented its TK and we discussed the strengths / weaknesses of the work done.
The technical assignment session was held on the third day of the course, when all the teams already coded the project framework. Of course, it would be more logical to start writing code after developing requirements and design. But with a consistent and logical presentation of the course, the first two classes go to discuss professions in the IT industry and the software life cycle. Along with this, students are already starting to write code: do not wait for them to do the collection of requirements. This is a common problem of such courses: theoretical knowledge comes late.
In one module of the course, we completed half the program. We had three practical tasks: analysis of previous decisions, brainstorming followed by drawing up the TOR and designing the interface. The first two tasks each team performs in relation to their project.
During the analysis of previous decisions, the team searches the Internet for data on projects with functionality and themes similar to their own project, analyzes the strengths and weaknesses of analogues, is determined with a unique feature of their project.
Brainstorming is the task of clearly separating the stage of generating ideas from the stage of analyzing and selecting ideas. During the compilation of the TK, the team tries to describe and formalize in detail each feature that was selected during the brainstorming session.
Before the task of designing interfaces, we discussed some general laws of good design: focusing on the user, repelling the user's task, hiding rarely used functions, grouping objects with a general purpose, giving the user feedback about what is happening in the system. The task itself was as follows: using the interface prototyping service, design and prototype a website for recording a patient to see a doctor. The idea is not original: I borrowed it from the introductory into the Artyom Gorbunov Trainee School. I suggested using gomockingbird.com as a prototyping interface service: it is very simple and allows you to get started in a few seconds. As in the case of the first two tasks, after prototyping each team presented its decision, and we discussed it.
In the first lesson, I introduced many of the projects that can be done during the module. The students broke up into five teams, each team chose a unique theme.
The first team undertook a large project on traffic modeling and control of traffic lights. For the June module, they tried to write a road traffic visualizer with intersections and a road editor.
The second - I decided to write an educational game based on Lightbot.
The third is a plotter of functions along with an expression parsing module.
The fourth is an arcade maze and map editor for it.
Fifth - tried to transfer the game "Sokoban" on the Rubik's Cube. The action takes place on the surface of the cube N * N * N. At each moment, the user can see the entire scan, on one of the faces there is a little man, drawers, walls and target cells are drawn on the surface of the cube. The Rubik's cube can be rotated, because of which the field can change very oddly.
Every day the classes lasted two pairs - from the line to lunch. The end of the first pair and the entire second pair we spent on programming in the classroom. The main principle of programming was iteration: from each team before the start I demanded to report what was done on the project over the previous days and that they were going to code in the next couple of hours. At the end of the second pair, each team showed everyone else how much she managed to realize what was planned for today. Day after day, teams learned to properly evaluate their strength, set more realistic goals, move in smaller steps. "Every two hours, everything should work and something new should be implemented." Personally, it seems to me very important to instill this principle in schoolchildren. At the beginning of the programmer’s life, each of us has a “waterfall development demon” who designs a spaceship in the guise of a harmless toy. This demon must be etched by a process of small iterations from childhood.
During team programming, it feels very good that the forces of the teams are not equal and the forces within the team are also not equal. The team that modeled traffic lights in the early days tried to raise the git repository on its own home server. According to Murphy's law, the team paid for their desire to administer everything on their own: one day, their remote git server lay because of the lights off in the house.
Other teams had no idea about version control systems. I did not try to teach them this: I think that at first it is better to store the code in the cloud file storage and switch to version control systems only when the team gets tired of the hell of conflicting copies of the files. However, many teams were reluctant to work even with cloud storage. For programming in the classroom, we had a local network raised and the teams communicated through shared folders in it.
The team that developed the Lightbot equivalent was three people, and the level of one of them was too high for the rest. This man alone wrote the entire framework of the project on Java in a day. The next day it seemed to him that in Java it would not be very convenient to use drag-n-drop, and he rewrote the entire project in Java script, putting it on GitHab. Working with this team was my complete pedagogical failure: I could not convince the divine programmer to explain to the other two members of the team what Javascript is, what git is and how they can program something themselves. Most of the time, the other two members of the team looked for suitable illustrations and thought through the levels.
I think I managed to figure out how to teach this course. Now we have a manual for students, a training manual for teachers of my authorship, and we are selecting decent teachers in the regions. From October, the course will be taught in many 1C training centers in Russia.
Who am i?
My name is Vitaly Pavlenko, I graduated from the MIPT undergraduate degree in Applied Mathematics and Computer Science. Trained year software engineer in the company Intel. For the past four years, I have led a circle on Olympiad programming in the Moscow Gymnasium of 1534, computer science lessons at the Intellectual School, and taught at the Summer Computer School and many other mobile schools. I’m used to telling schoolchildren Dijkstra and Cartesian trees, and in the last year I’m also trying to talk about web frameworks and cryptographic protocols.
This spring, I was called to 1C: Club of Programmers ( http://club.1c.ru ) to give a course entitled “Managing Software Development”. The program of the course seemed to me extremely unusual. Some parts of it were taught to us in high school at the Faculty of FIVT in the courses "Innovative Workshop" and "Project Management." Other parts are general knowledge about the realities of working in software companies.
What school and what course?
As I later learned, “1C: Club of Programmers” is a network of hundreds of branches in different regions of Russia, which was created on the basis of centers for teaching adults how to work with 1C products. Schoolchildren in them are taught not 1C: Enterprise, but more interesting things: the basics of Java programming, basic algorithms, elements of system administration. At the same time, the development of a program of courses, manuals for pupils and teaching guides for teachers is conducted centrally in order to standardize teaching in various centers.
')
This year, the school management decided to launch a new course - “Management of software development”, which is intended for graduates of the course “Fundamentals of Java programming”. The guys are already good at programming, including working with window applications and drawing on the form. The main idea of ​​the new course is to talk about what is happening in the IT industry, as well as to give students the opportunity in small teams to code the project during the course.
A textbook describing the topics was written by Nikolai Zavriev (Lyceum of Information Technologies No. 1533, Moscow).
The textbook tells about such things:
- What are the various employees working in IT companies, what they do
- The path of the software product: design, implementation, testing, implementation
- Requirements collection process, terms of reference
- Software development models, waterfall model, iterative development, Agile and Scrum
- User Interface Design
What was this June?
The basis of the flow of time in the School is a module. During the year, the module is 12 lessons of two academic hours on weekends (it turns out the module = academic half-year). This year, 1C: The Club of Programmers held a special two-week June module for Moscow schoolchildren.
On the module in June there were only those who had already gone to the club before. Each student studied in June one of three courses: system administration, Olympiad programming and management. The pilot module of the course “Management of Software Development” was entrusted to me.
The statement of the problem was, as they say, challenging: there is a textbook just written and 14 schoolchildren. It is required to think up how to read this course: how to tell a theory and what practical tasks to give on it. And it was also required that the students in parallel with the development of the theory broke up into teams of 2-4 people, chose the theme of the project, which can be jointly coded in two weeks. The themes for the projects were chosen in such a way that the children could expand the functionality over the next year and present the project in the spring at one of the project competitions.
The module in June was conducted as a typical summer school: before lunch we had two pairs - theory and practice, and after lunch the students had a cultural program, consisting mainly of excursions. School leaders were able to organize a lot of excursions: both to leading IT universities like MIPT, Moscow State University and the Higher School of Economics, as well as to an underground bunker, to the main office of Yandex and to the Baskin Robbins ice cream factory.
At the very end of the school, at the closing, each team presented its project to all students of the school and their parents.
Here is an example of one such statement: http://www.youtube.com/watch?v=VA-30ANDArA
About the course itself
How things are arranged
Everything we did during the course can be divided into three parts.
The first is the actual discussion of the theory. Every day we discussed a single topic from the textbook, which took half an hour to an hour.
The second is the practical tasks of the theory, if the theory allows it. For example, after the theory about TZ, each team needed to jointly write a technical task for their project in an hour.
And the third is programming in commands. About two hours a day, the teams programmed at the school itself, many people coded something at home in the evening.
I call the course on development management humanitarian. In contrast to the technical, the content of which consists of strict logical constructions, this course consists of a free description of reality from the point of view of the author. Teaching such a course was a new experience for me.
When you teach algorithms, the situation is this: at the beginning of a class, you are the only one in the audience who knows a detour wide (or almost the only one), and at the end - it seems to many schoolchildren that they also understood something. That is, at the beginning there is a clear difference in knowledge between you and during the lesson a tangible process of their transfer takes place. When teaching a course on the realities in the IT industry, everything is different. I read Habr and work in an IT company. But students also read Habr, and many parents also work in IT companies. Many already know certain aspects and realities, and it is very difficult to say something really new to everyone. However, in teaching such a course, there is also its own ease. On a course on algorithms, a teacher may poorly explain a detour wide, and a student may not understand it. With a course on managing the development of such problems almost did not arise.
Thinking about how to teach a course, I decided that it was important to do two things. First of all, it’s important to anticipate as many sub-topics as possible with questions to the audience: what do you know about it? For example, when discussing the project implementation stage, you should first ask schoolchildren: where should the project code be stored, where is it stored in real practice? Or: what is the correct programming style? Should I stick to it? Why do programmers do this? Pupils know most of what you yourself know about and tell you your vision. And here it is important to do the second thing: to tell something new, something that almost none of the listeners used to know before. For example, after discussing the topic of storing code, tell you about version control systems and their device. Or, after discussing the programming style, give an example of a real rule from the style guides and explain why its non-observance sometimes costs people several hours of happy debugging. It is very good to give examples from your own practice at work or examples from friends' stories.
More specifically about the theory
To give a concrete idea of ​​how the classes were conducted, I will describe how we went through the topic “What, in fact, are we developing?”. It is arranged as follows:
- The stage of collecting requirements: communication with the customer, why is it difficult to find a common language with him?
- Work analyst with the customer: a demonstration of existing solutions, monitoring the lives of future users.
- Brainstorming to determine the requirements. Three stages: we collect a circle of potential users, generate ideas for implementation in the product, analyze and select the most suitable ideas.
- Technical assignment: its content, the problem "you can not describe everything in the TK."
We first discussed the theory. We started with a collective discussion of this situation. A customer comes to you and says: “I want a website for selling smartphones with weekly revenue of 100,000 rubles.” How should start a dialogue with him to gradually understand what we really need to do as a programmer?
After we discussed the theory at the lesson and looked at an example of a real TK for creating a site for a holiday home, I suggested to each team:
- brainstorm to develop the requirements for your project for the implementation of two weeks;
- to make up the results of brainstorming TK.
As a basis, I advised to take the TK, which we analyzed on the theory. After an hour of work, each team presented its TK and we discussed the strengths / weaknesses of the work done.
The technical assignment session was held on the third day of the course, when all the teams already coded the project framework. Of course, it would be more logical to start writing code after developing requirements and design. But with a consistent and logical presentation of the course, the first two classes go to discuss professions in the IT industry and the software life cycle. Along with this, students are already starting to write code: do not wait for them to do the collection of requirements. This is a common problem of such courses: theoretical knowledge comes late.
Practice in theory
In one module of the course, we completed half the program. We had three practical tasks: analysis of previous decisions, brainstorming followed by drawing up the TOR and designing the interface. The first two tasks each team performs in relation to their project.
During the analysis of previous decisions, the team searches the Internet for data on projects with functionality and themes similar to their own project, analyzes the strengths and weaknesses of analogues, is determined with a unique feature of their project.
Brainstorming is the task of clearly separating the stage of generating ideas from the stage of analyzing and selecting ideas. During the compilation of the TK, the team tries to describe and formalize in detail each feature that was selected during the brainstorming session.
Before the task of designing interfaces, we discussed some general laws of good design: focusing on the user, repelling the user's task, hiding rarely used functions, grouping objects with a general purpose, giving the user feedback about what is happening in the system. The task itself was as follows: using the interface prototyping service, design and prototype a website for recording a patient to see a doctor. The idea is not original: I borrowed it from the introductory into the Artyom Gorbunov Trainee School. I suggested using gomockingbird.com as a prototyping interface service: it is very simple and allows you to get started in a few seconds. As in the case of the first two tasks, after prototyping each team presented its decision, and we discussed it.
Projects
In the first lesson, I introduced many of the projects that can be done during the module. The students broke up into five teams, each team chose a unique theme.
The first team undertook a large project on traffic modeling and control of traffic lights. For the June module, they tried to write a road traffic visualizer with intersections and a road editor.
The second - I decided to write an educational game based on Lightbot.
The third is a plotter of functions along with an expression parsing module.
The fourth is an arcade maze and map editor for it.
Fifth - tried to transfer the game "Sokoban" on the Rubik's Cube. The action takes place on the surface of the cube N * N * N. At each moment, the user can see the entire scan, on one of the faces there is a little man, drawers, walls and target cells are drawn on the surface of the cube. The Rubik's cube can be rotated, because of which the field can change very oddly.
Every day the classes lasted two pairs - from the line to lunch. The end of the first pair and the entire second pair we spent on programming in the classroom. The main principle of programming was iteration: from each team before the start I demanded to report what was done on the project over the previous days and that they were going to code in the next couple of hours. At the end of the second pair, each team showed everyone else how much she managed to realize what was planned for today. Day after day, teams learned to properly evaluate their strength, set more realistic goals, move in smaller steps. "Every two hours, everything should work and something new should be implemented." Personally, it seems to me very important to instill this principle in schoolchildren. At the beginning of the programmer’s life, each of us has a “waterfall development demon” who designs a spaceship in the guise of a harmless toy. This demon must be etched by a process of small iterations from childhood.
Imbalance
During team programming, it feels very good that the forces of the teams are not equal and the forces within the team are also not equal. The team that modeled traffic lights in the early days tried to raise the git repository on its own home server. According to Murphy's law, the team paid for their desire to administer everything on their own: one day, their remote git server lay because of the lights off in the house.
Other teams had no idea about version control systems. I did not try to teach them this: I think that at first it is better to store the code in the cloud file storage and switch to version control systems only when the team gets tired of the hell of conflicting copies of the files. However, many teams were reluctant to work even with cloud storage. For programming in the classroom, we had a local network raised and the teams communicated through shared folders in it.
The team that developed the Lightbot equivalent was three people, and the level of one of them was too high for the rest. This man alone wrote the entire framework of the project on Java in a day. The next day it seemed to him that in Java it would not be very convenient to use drag-n-drop, and he rewrote the entire project in Java script, putting it on GitHab. Working with this team was my complete pedagogical failure: I could not convince the divine programmer to explain to the other two members of the team what Javascript is, what git is and how they can program something themselves. Most of the time, the other two members of the team looked for suitable illustrations and thought through the levels.
What's next?
I think I managed to figure out how to teach this course. Now we have a manual for students, a training manual for teachers of my authorship, and we are selecting decent teachers in the regions. From October, the course will be taught in many 1C training centers in Russia.
Source: https://habr.com/ru/post/235521/
All Articles