Software Requirements Specification (SRS) Creation:

As the project manager, I develop a comprehensive project specification (Spec) outlining all project details using Redmine Wiki. This includes incorporating graphical attachments when necessary.

 

Work Breakdown Structure (WBS) Development:

Subsequently, I work on the Work Breakdown Structure (WBS), breaking down tasks module-wise and estimating the time required to complete milestones. Typically, milestone spans are week-based (5 working days). All modules are organized under each feature, and each feature is linked to the Redmine Wiki Spec through a spec ID. Please refer to the attached screenshot for a better understanding of the WBS.

 

Story Creation and Task Management:

I create related stories on Redmine based on the WBS. Each story includes tasks that are either created by me or developers after discussions. I then assign tasks to developers, monitor task progress, gather updates in meetings, and address challenges or dependencies as needed. We conduct two Daily Scrum Meetings (DSM) each day – one in the morning before work starts and another at the end of the day.

 

Github Code Management:

Code management on Github is also part of my responsibilities. I create the Main, Release, and Development branches. Developers create Prototype branches from the Development branch to work on specific features. After each commit and push to these branches, they assign me as a reviewer, along with other developers if there are dependencies. Following reviews and tests, I create pull requests and merge the Prototype branches with the Development branch, then assign them back to developers. Developers update the status of task tickets on Redmine, and upon completion, assign them to me. At this stage, developers test the Development branch to ensure all features are functioning smoothly.

 

Specification and Task List Updates:

I handle updates and modifications to specifications, WBS, and task lists when new features or modifications arise.

 

Milestone Overview Meeting:

Upon reaching a milestone, we organize a meeting with our section head to provide an overview of project progress and receive feedback.

 

Release Candidate (RC) Submission:

Upon completion of all milestones, we release the Release Candidate (RC) and hand over the project to the Software Quality Assurance (SQA) team. They conduct feature-wise testing and provide feedback. Since we implemented Unit Testing to this module, we didn't have to give any release to SQA.

 

SQA Feedback Analysis and Task Assignment:

I analyze SQA feedback, prioritize and address issues, and create new tasks accordingly. Tasks are then assigned back to the relevant developers, but for this module, we don't have to do this because of Unit Testing implementation.

 

Final Release and Deployment:

Following the resolution of feedback, we submit the release to SQA again. In this stage, every developer has to write a BAT (Basic Acceptance Test) file after implementing SQA feedback. Once they confirm it is bug-free or ready for release, we publish the release on Github and CocoaPod. Again, since we implemented Unit Testing to this module, we didn't have to give any release to SQA.

 

Cross-Functional Collaboration:

Since this was a Swift Package manager and CocoaPods, which is exclusively for iOS, I didn't have to do any work on this.

​

Documentation:

Maintain comprehensive project documentation mostly on Redmine and Google, including technical specifications, user manuals, and change logs.

 

App Store Submission:

Since it's an open-source project for iOS developers, we didn't have any App store submission. Personally, I publish the module on CocoaPods when the first release was done.

 

Continuous Improvement:

Identify areas for process improvement, implement best practices, and stay updated on the latest trends and technologies in iOS app development.