Tickets (Working Item [Small unit of work known as task to be done via a human resource]) flow since planning and writing till starting point

Overview on software manufacturing process:

---

---

Possible states of assigned tickets

---

Ticket template example

---

---

---

MANUFACTURING DEFECTS (MALFUNCTIONING, BUGS, ...) UPON COMPLETION IS 0%, MORE IS AN ILLEGAL ACT AND NOT ALLOWED

---

Must to read: SDLC

A ticket is a synonym to a task (single feature) AKA the smallest workable unit based on the seniority level of the human resource AKA title.

Agile model is adopted.

---

Project is controlled/managed via a Project manager via a science called project management:

Suggested references in project management.

---

A specialized software shall be made of Microsoft technologies to keep the projects history internally when such specialized companies is made for full control purposes after establishing a verified bloody hell 💪 strong paper-document-system 📚 🖊 🗂 first via the science acquired via a LEGAL-university 📚 🎓 🧠 💯 🌍 ✅ which is subject to a governing system not from the AIR 🌈 💩 👽 🤖 👾 👹 🤡 🧙‍♂️ 🧜‍♀️ 🧞‍♂️ 🐷 🦄 🐞 🛸.

---

---

Business Analyst: Starting analysis and doing necessary diagrams (Use case diagram, Data flow diagram, Component diagram, ...), then store the result periodically in a specific Git repository to maintain the project's history for future's live documentation.

|

v

---

Those 2 points occurs in parallel

Then the next state can be started which is:

• start making the wireframes and other related resources via UI/UX Designer, then store the result periodically in a specific Git repository to maintain the project's history for future's live documentation.

• adding System Architecture plan via Java Architect, then store the result periodically in a specific Git repository to maintain the project's history for future's live documentation.

|

v

---

Those 2 points occurs in parallel

Then the next state can be started which is Product's backlog filling via:

The ticket state is OPEN

• Product Owner:
  • Business requirements filling and breaking down to small workable units using finished work from previous state as an attachments in tickets for more details
• Java Architect: Technical type tasks
  • for testing environment skeleton which will be done via the Senior System Admins [Linux Based],
  • CI/CD pipeline if automated deployment is adopted which will be done via the Senior DevOps Engineers [Linux Based],
  • filling the app's skeleton and connecting components which are done via Senior Java Developers [Backend],
  • filling the app's skeleton and connecting the web-frontend-component which are done via Senior JavaScript Developers [Web-Frontend],
  • filling the app's skeleton and connecting the mobile-frontend-component which are done via Senior Java Developers [Mobile-Frontend].

|

v

---

Then the next state can be started which is implementing the tickets from technical type which done previously via the Java Architect.

The ticket state is TO DO upon assigning.

• Implementers:

  • Senior System Admins [Linux Based]
  • If automation model is applied: Senior DevOps Engineers [Linux Based]
  • Senior Java Developers [Backend]
  • Senior JavaScript Developers [Web-Frontend]
  • Senior Java Developers [Mobile-Frontend]

• Happy Scenario:

  • The ticket state is In Progress upon start working on it
  • The ticket state is In Review and assign it to Java Architect for auditing
  • The ticket state is Under Review upon starting the auditing process via the Java Architect
  • The ticket state is Approved upon approval via the Java Architect
  • The ticket state is Done upon completion and marked via the Java Architect

• Negative Scenario:

  • Just use your brain to think about it, you have to move back the state to the implementer and other cases upon need to maintain good project's history for the future's live documentation.

| ^

v |

---

Then the next state can be started which as below:

Java Architect is responsible to assign tickets based on the seniority level

1. adding features in backend-side via the Developers.

• (Junior | Senior) Java Developer [Backend]

The ticket state is TO DO upon assigning.

• Happy Scenario:

  • The ticket state is In Progress upon start working on it
  • The ticket state is In Review and assign it to a Senior Java Developer [Backend] for reviewing
  • The ticket state is Under Review upon starting the reviewing process via a Senior Java Developer [Backend]
  • The ticket state is Approved upon approval via a Senior Java Developer [Backend]
  • The ticket state is Done upon completion and marked via the Java Architect

• Negative Scenario:

  • Just use your brain to think about it, you have to move back the state to the implementer and other cases upon need to maintain good project's history for the future's live documentation.

2. adding features in frontend-side via the Developers.

• (Junior | Senior) Java Developer [Mobile-Frontend]
• (Junior | Senior) JavaScript Developer [Web-Frontend]

Note that frontend-side tickets has dependency over backend-side ones.

The ticket state is TO DO upon assigning.

• Happy Scenario:

  • The ticket state is In Progress upon start working on it
  • The ticket state is In Review and assign it to a Senior (Java | JavaScript) Developer [Web-Frontend | Mobile-Frontend] for reviewing
  • The ticket state is Under Review upon starting the reviewing process via a Senior (Java | JavaScript) Developer [Web-Frontend | Mobile-Frontend]
  • The ticket state is Approved upon approval via a Senior (Java | JavaScript) Developer [Web-Frontend | Mobile-Frontend] according to his/her specialization
  • The ticket state is In Test upon start working on it via the (Junior | Senior) Tester (QA Stuff)
  • The ticket state is Pass upon completion and marked via the (Junior | Senior) Tester (QA Stuff)
  • The ticket state is Done upon completion and marked via the Java Architect

• Negative Scenario:

  • Just use your brain to think about it, you have to move back the state to the implementer and other cases upon need to maintain good project's history for the future's live documentation.

| ^

v |

---

At the end of the sprint, when the Scrum Master (Team Lead) found done tickets, then he/she has to transition it to Completed state.

Development work is stopped during the week of demonstrating periodical finished work to the client.

---

---

Demonstrations:

Ticket state to mark it as Completed at the end of each sprint via the Scrum Master (Team Lead), so the Product Owner can start periodical demos according to the completed tickets effectively. It is considered as an indicator of completion and delivery.

Periodical demos to the client at the end of each sprint via the Product Owner on the testing environment before moving to production upon completion and double checking the full demo on production environment as well with tea ☕ and biscuits 🍪.

---

Legal/Ethical work buffer:

Ticket by ticket to avoid burning out the human resource and be able to verify the quality and correctness at the end and be focused not energy drained.

When the ticket's state is Done, then a human resource can have a new ticket.

---

Attach UI/UX Designer output to the frontend tickets to have usable effective visual on the implemented UI later via frontend channels.

Ticket will be reopened back to Developers based on a certain flow.

Testers (QA Stuff): They test/verify the system under construction from the frontend channels as a final end user using the UI (WEB | MOBILE) due to finished tickets from the developers, also it has a certain flow.

---

---

Mixture of single and parallel processing will be effective and efficient as applied in this agile flow. Just check your human resources before start doing anything to avoid any loss AKA 0% loss which is not allowed by the way.