{"id":34112,"date":"2019-10-31T21:56:27","date_gmt":"2019-10-31T18:56:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:56:27","modified_gmt":"2019-10-31T18:56:27","slug":"kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/kak-my-pytalis-v-komandnuyu-rabotu-i-chto-iz-etogo-vyshlo","title":{"rendered":"How we attempted teamwork and what came of it","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"How
\n<\/p>\n

Let's go in order<\/h3>\n

\nWhat this illustration means a little later, but for now, let me start with the introduction.<\/p>\n

On a cold February day, nothing foreshadowed trouble. A group of innocent students came for their first class in a subject they decided to call 'Methodology of Designing and Developing Information Systems'. It was an ordinary lecture; the teacher talked about agile development methods, such as Scrum, and there seemed to be no cause for concern. And then, towards the end, the teacher announced: <\/p>\n

I want you to experience all the hardships of teamwork; split into groups, come up with a project, appoint a leader, and go through all stages of design together. At the end, I expect a finished product from you and an article on Habr.<\/p><\/blockquote>\n

And this is where our story begins. <\/a><\/noindex> Like billiard balls, we bounced off each other until the energy of the strike dissipated and a group of 7 gathered together. Perhaps that's too many for a school project, but it helped to better distribute roles. Discussions began on project ideas, ranging from 'Let's take an existing project' to 'An emulator for creating cosmic objects'. But eventually, the idea came forth, the title of which you read in the first image. <\/p>\n

Stop Procrastination \u2014 what it is, how it works, and how we developed it and what came of it<\/h2>\n

\nThe story will be told from the perspective of the project leader, who, happily or unfortunately, was appointed as me. So what idea came to our minds? Inspired by the popular alarm clock 'Shake Alarm' from SupperCommon, particularly the feature to completely block the smartphone's operation until the user performs a specific action likely to wake them up, we decided to create a similar application that helps to overcome smartphone addiction, using the same principle as 'Shake Alarm'.<\/p>\n

Operating principle<\/h3>\n

The user sets timers
\n- Time that can be spent on the smartphone
\n- Time without the smartphone (blocking period)
\nAfter the timer expires, an overlay appears on the screen that cannot be dismissed.
\n-To close the overlay, you need to complete a small challenge (enter a password on a scrambled keyboard, solve a math problem, shake the phone for a couple of minutes)
\nAfter unlocking this way, the time you can spend on the smartphone is reduced by half, down to just one minute\n<\/p><\/blockquote>\n

Building a team<\/h3>\n

First, we needed to determine who would be responsible for what and in which language everything would be written. I think this has little to do with project management because when you assemble a team for a real project, you gather exactly those you need right away. In the end, I took on the role of designer as well, selected a team lead who had good experience in application development, assigned three programmers to him, and two more became testers. Of course, the programming language was chosen based on skill levels. Ultimately, it was decided to use Java since all the programmers were familiar with it.<\/p>\n

Setting tasks<\/h3>\n

Following the instructor's recommendation, a task board was created on a free service Trello<\/a><\/noindex>. It was planned to work using the Scrum system, where each stream would represent a completed application.
\nHowever, in reality, this turned into one long and continuous stream, where constant edits, additions, and corrections were made. <\/p>\n

\"How
\n<\/p>\n

Writing specifications<\/h3>\n

Under the influence of Savin\u2019s book \u2018Testing.com\u2019, I had my own vision of how everything should be structured. It all started with writing specifications, as I believe that without a clear description of what we expect, how things should work, nothing will work as intended. Programmers will code based on their understanding, testers will test something different, the manager will expect a third outcome, yet it will end up as a fourth, as always.
\nWriting specifications is not easy; you need to think through all the details and nuances. Of course, nothing worked out right the first time. In the end, the specifications were supplemented and rewritten four times. The last version can be found at the end of the article in the links section. <\/p>\n

Designing<\/h3>\n

Design in a mobile application is the most important aspect. However, not everyone understands this, including many from my team who ardently debated with me that design is unnecessary, that it's the least important part of the application, etc. Don\u2019t be so naive. First of all, a finished design simplifies the work for the programmer; they don\u2019t have to think about what to place where, they just take it and code according to what has been drawn. Along with the specifications, the design almost completely frees the programmer's mind from unnecessary details, allowing them to concentrate on logic. Initially, a prototype (terrible) design was drawn:<\/p>\n

\"How
\n
\nBut then the design was refined and brought to a proper appearance.
\n(Link to all design elements at the end of the article).<\/p>\n

\"How
\n<\/p>\n

Programming<\/h3>\n

Programming is difficult, but doable. I will skip this point since I personally have not been involved. The programmers did a tremendous amount of work without which everything would have been pointless. Of course, we managed to implement some ideas. The program still needs further refinement. There are many bugs and features that need to be addressed. If we had more time, we would have emerged from deep alpha, but for now, you can test the application at the end of the article.<\/p>\n

And about testing<\/h3>\n

What is the most important thing in programming? In my opinion, the main thing is that everything works and looks as needed. However, it doesn\u2019t always turn out that way immediately. For this, testing is required. I suggested a testing model to my testers using test cases. First, test cases are written in full accordance with the specifications, and then testing is conducted based on them. You can see the results below in the links. <\/p>\n

Thank you for reading. I hope you found something useful here, maybe an idea for your startup, or perhaps good advice or tools.<\/p>\n

Links:<\/h3>\n

Latest the specification<\/a><\/noindex>.
\nDesign on Figma<\/a><\/noindex>.
\nTest cases<\/a><\/noindex> and bug reports<\/a><\/noindex>.<\/p>\n

The application itself on HokeyApp<\/a><\/noindex>. \u2014 The application was built under the name HandsOff, don\u2019t even ask why (because Stop Procrastination is too long).<\/p>\n

And finally<\/h3>\n

Do you think all this made sense?<\/p>\n

Only registered users can participate in the survey. Please log in<\/a><\/noindex>, please.<\/p>\n

Is such practice needed in educational institutions, and how useful and applicable is it in real life?<\/h2>\n