Agreement within the team
Hi, we have a fairly large flow of mixed projects. At some point, we had the bright idea to create an internal charter for project management, with which every team member agrees. It is hoped that this will reduce costs, increase quality and reduce confusion, make it easier to introduce new “players” and generally Redmine was chosen as a project management system, and I must say even in the default installation, this thing correctly solves many questions for you: the division into Bug \ Improvement, Git integration, action log, subprojects, convenient Wiki, etc.
Each application is one Redmine project.
For example, the mobile application "To search for fresh bread." Most likely the application will have three sides: web, android & iOs, then the project structure looks like this:
Tasks within the project
Standard process of task statuses (M. - manager, P. - programmer): M.Sozdana → P.In work → P.Reshena → M.Zakryta. ( M., if necessary, change to K - client )
Specifying the parameters of the problem: M. Created → P. Feedback → M. Feedback → P. In work.
Type of tasks: Error - bugfix, Support - scheduled work, Improvement - works not included in the original plan.
Little, but capacious in the Wiki.
For example: FTP access, contacts of team members, etc. In other words, information is administrative in nature. Redmine - the desire to build a single information space in which every member of the team has access to all the necessary information.
')
Git
Binding of a bunch of commit commit tasks. If possible, follow the rule one completed task is an attached commit. And vice versa, a task is attached to each commit. When describing a commit (commit -m), specify the task id - “refs #Issue ID”.
DB Migrations
The programmer creates in the root project a file migration.sql which contains instructions for creating the database.
File storage
Files - file storage within the project directory. PSD and PDF in the appropriate folders inside the primary project (design and ui). Thus, the history of drawing is preserved, it is not a pity to put a place on hdd).
Description test cases.
As the project progresses, the manager, together with the programmer, describes the application testing scenarios. At the end of each micro correlation, at the end of the sprint, regressive testing of the project is carried out. Based on the completed tasks in the release, the document is supplemented.
The milestone
We support the ideology of continuous integration; when starting a project, the project manager assesses the key stages in project development. And marks them on the operational plan. For example, "Registration of users is possible" on May 15th. Thus, it is possible to roughly estimate the length of the project, the cost and the workload of specialists.
Not tested in practice Sprint
The duration of the sprint for each project varies from 3 to 5 working days, and for each team is set individually. At the beginning of the sprint, the team jointly selects the tasks for the next iteration (the priority and personal interest in the task are taken into account). At the end of the sprint, the team meets on a “retrospective”, discussing the course of the previous sprint, as a rule, it does not take more than 20 minutes. So, at the entrance there are tasks, in the process of sprint they are solved, as a result we get working interfaces. If the problem is not solved during the sprint, the programmer in the comments describes the reason. At the end of each sprint, the team conducts regression testing.
Algorithm for project implementation
PS So,% username%, I appeal to you. All items are tested in practice and written inblood . But if you share a bit of wisdom, I will be very grateful. He is particularly interested in how you use Redmine, do you have standards for writing code on your team?
Each application is one Redmine project.
For example, the mobile application "To search for fresh bread." Most likely the application will have three sides: web, android & iOs, then the project structure looks like this:
- Primary - web (ibid all organizational issues)
- Subproject 1 - iOs
- Subproject 2 - Android
Tasks within the project
Standard process of task statuses (M. - manager, P. - programmer): M.Sozdana → P.In work → P.Reshena → M.Zakryta. ( M., if necessary, change to K - client )
Specifying the parameters of the problem: M. Created → P. Feedback → M. Feedback → P. In work.
Type of tasks: Error - bugfix, Support - scheduled work, Improvement - works not included in the original plan.
Little, but capacious in the Wiki.
For example: FTP access, contacts of team members, etc. In other words, information is administrative in nature. Redmine - the desire to build a single information space in which every member of the team has access to all the necessary information.
')
Git
Binding of a bunch of commit commit tasks. If possible, follow the rule one completed task is an attached commit. And vice versa, a task is attached to each commit. When describing a commit (commit -m), specify the task id - “refs #Issue ID”.
DB Migrations
The programmer creates in the root project a file migration.sql which contains instructions for creating the database.
File storage
Files - file storage within the project directory. PSD and PDF in the appropriate folders inside the primary project (design and ui). Thus, the history of drawing is preserved, it is not a pity to put a place on hdd).
Description test cases.
As the project progresses, the manager, together with the programmer, describes the application testing scenarios. At the end of each micro correlation, at the end of the sprint, regressive testing of the project is carried out. Based on the completed tasks in the release, the document is supplemented.
The milestone
We support the ideology of continuous integration; when starting a project, the project manager assesses the key stages in project development. And marks them on the operational plan. For example, "Registration of users is possible" on May 15th. Thus, it is possible to roughly estimate the length of the project, the cost and the workload of specialists.
Not tested in practice Sprint
The duration of the sprint for each project varies from 3 to 5 working days, and for each team is set individually. At the beginning of the sprint, the team jointly selects the tasks for the next iteration (the priority and personal interest in the task are taken into account). At the end of the sprint, the team meets on a “retrospective”, discussing the course of the previous sprint, as a rule, it does not take more than 20 minutes. So, at the entrance there are tasks, in the process of sprint they are solved, as a result we get working interfaces. If the problem is not solved during the sprint, the programmer in the comments describes the reason. At the end of each sprint, the team conducts regression testing.
Algorithm for project implementation
- Initialization of the project in Redmine.
- UI study. At the "Project Forum" opens UI branch. The PDF file is attached directly to the message in the forum, I note that discussing the UI on the forum does not cancel the office meetings. Once the UI is complete and agreed, the “Final UI.pdf” file appears in the Files section.
- The project manager starts the first sprint, design and programming on parallel processes. Contributes to the operational plan: the date of completion of the sprint, version 0.1. To discuss the design, a branch is formed on the forum, and the manager, designer, and ui specialist participate in the discussion. As in the case of the UI, the forum does not cancel live meetings. The result is agreed, and in the "Files" section appears the file "Final DESIGN"
- Stage layout and programming deserves a separate article.
PS So,% username%, I appeal to you. All items are tested in practice and written in
Source: https://habr.com/ru/post/146231/
All Articles