This article is the first day article of Advent Calendar of Valtech Co., Ltd..
I am a 4th year engineer and use Java for business.
The reason why I chose "I want to do team development remotely" as the theme is as follows. ・ I want to create a team outside of work ・ I want to find friends who are interested in team development
The following is a summary this time. ・ [Team development image and deliverables in the process](#Team development image and deliverables in the process) ・ [Tools to assist team development](#Tools to assist team development) ・ [Tool to accelerate team development](#Tool to accelerate team development)
・ Internet environment ・ PC (SmartPhone, Tablet not available)
"Situations like this are assumed" "There is such a tool" "I am excellent" If you have any questions, please follow or comment! This article will be maintained after the Advent calendar.
First, let's list the benefits of team development starting at home.
| Benefits | Remarks |
|---|---|
| Ideas of 10 people and 10 colors | New ideas |
| Conducting mutual reviews | Reviewer experience |
| Sharing know-how | Absorption of knowledge other than the person |
| Restrictions | Remarks |
|---|---|
| Differences in machine specifications | Tools may or may not be supported due to differences in OS |
| Time Securing Issues | There is no guarantee that everyone will have time on weekdays |
| Handling of paid tools | Most of the free tools can be replaced |
The developed product is assumed to have the following configuration. I wish I could rent a rental server and release some kind of web application.
| Application Server |
|---|
| Java9 |
| Linux |
| RDB(MySql 8.0) |
If you have a strict server-side and client-side separation of your web application It seems that it is a recent fashion to exchange information from the client to the server via json.
Actually, there was a time when two people were developing in Baltec after the fixed time. There is a history of failure due to restrictions such as inconvenience to each other and the inability to take out materials within the company. .. .. Based on the above experience, this is my best practice for the schedule process.
Assumption: Waterfall until initial release, then agile
Waterfall: Even if there is an omission in the design document of the previous process, do not overwrite the file anyway. Create a diff, write it there, merge it at the end and give one minor version. Agile: We will revise the design document from time to time and give one minor version after release.
Deliverable: Requirement definition
We will roughly discuss what you want to make within the team and the technology you want to implement. As a means of discussion, you can meet face-to-face at a cafe or have a web conference, If there is no output part, it will be extremely difficult to unify the overall consciousness. Example: Whiteboard in a conference room, drawing in Excel
Deliverables: Requirement definition document, man-hour table for outline design
We will investigate and summarize the technical specifications for operating what you want to make.
At the time of initial release, only the minimum configuration will be used, and rich functions will be compatible with the next release. (Because it is difficult to maintain motivation if you do not make a horn and move it)
Clarify in which process common processes and agreements (covenants) will be discussed if they are on the agenda.
Deliverables: screen definition document, interface definition document, database definition document, detailed design man-hour table
I have field experience with RESTFul API and Client <-> I have experience with Swagger (described later) as an interface definition document between servers. Swagger is recommended as the RESTFul API documentation.
On the client side, I think it is necessary to leave the html-based mock as a deliverable. (Since Spring Boot creates screens based on html) In addition, it is necessary to cover the screen transition diagram and the screen pattern at the time of normal / abnormal occurrence.
Deliverables: Program design document, test design document, message definition document, development man-hour table
Create a program design document and a test design document as a set. When implementing a test design, be sure to identify patterns that can be implemented in common. The format of the detailed design document in Japan seems to be Excel. However, Excel is charged, so I would like to use a different format. I have no experience with it, but I want to use Sphinx (described later).
Identify error messages and various messages, and manage them so that there are no duplicate contents.
Deliverables: Product code, test code, test man-hour table
Rabbits must commit and push the deliverables of the day
Coding standards that can be shared, static analysis rules, etc. should be stored in shared storage.
Link and set version control & build tools, and perform [Continuous integration](https://ja.wikipedia.org/wiki/Continuous integration) behind the scenes.
In this process, the production of the program and the production of the test source (unit test) are completed.
Deliverables: test specifications, test code, bug tracking table
Tests that cannot be performed in the development process are performed in this process. Manual tests from a browser, inter-functional integration tests, etc. ..
Be sure to add "Tags" to the source before and after the start of the test. In addition, create a bug management table to accumulate knowledge of recognition discrepancies during team development and get a feel for it.
Release the source to the production server and tap various functions lightly from the screen. (You may automate the operation check items that must be performed at each release and check them later.)
Shift to agile, repeat testing from requirement definition, and repeat development for a short period of time.
| Necessary items |
|---|
| 1: Can speak with N |
| A log of remarks remains, you can search the log |
| The flow to speak is not a detour |
| It doesn't take much time to increase the number of staff |
| Not heavy |
-> Slack
reference -What is business chat "Slack"? Explain the features and how to get started in Japanese!
| Necessary items |
|---|
| 1: Can be executed with N |
| Can make both voice calls and send messages |
| Screen sharing is possible |
-> Skype, Google Hangouts
reference -Zero travel time! Start your meeting now with Skype screen sharing!
| Necessary items |
|---|
| Not eavesdropped by a third party |
| It doesn't take much time to increase the number of staff |
-> Online storage (Google Drive)
| Necessary items |
|---|
| It is clear who drafted |
| 5W1H is expressed by default on the format |
| Can generate Gantt chart |
-> Ticket management (Redmine)
reference -Redmine operation rules that should be decided
| Necessary items |
|---|
| Free to use |
| Easy difference comparison |
-> Sphinx
reference -I want everyone to use Sphinx conveniently
| Necessary items |
|---|
| Free to use |
| Major |
-> Swagger
reference -Easy management of RESTful API with Swagger
| Necessary items |
|---|
| Construction is not a hassle |
| Major |
-> GitHub
reference -Introduction to GitHub
| Necessary items |
|---|
| The operation is not heavy |
| Syntax highlighting works |
| Can be translated into Japanese |
reference -Impression and setting memo of switching from Atom to Visual Studio Code
| Necessary items |
|---|
| Can work with version control |
| Self-solving |
| Can be translated into Japanese |
-> Leave it to yourself
By the time this article was published, we couldn't include any visible issues in team development. Example) When developing remotely, you cannot grasp all the progress of your teammates. I would like to add it at the right time, or try risk analysis when the team is established.
SpecialThanx Prior to publishing the article, I asked my seniors, juniors, and wife to check the text. I would like to take this moment to say thank you.
Also, I'm looking for a remote team developer. Words include "Spring Boot", "Java 9", and so on.
Recommended Posts