UNDERSTANDING OUR METHODOLOGY AND PROCESS
THE PROUDCLOUD WAY
RATES AND TIME FRAMES
We don't do fixed bid projects. We bill our clients on a monthly Time & Materials basis. Our clients understand that agile projects are very dynamic and constantly changing. It is with this understanding that, as the project features, workload, priorities, and business rules change over time, so do the team delivery estimates and work load.
The typical project team is composed of:
It would be ideal that a single point of contact is assigned to work with the Proudcloud team for sprint planning, story (feature) prioritization, story testing, and story acceptance.
LEAD PROJECT MANAGER
He/she will be the Project Manager and SCRUM Master on the Proudcloud side. He/she will help conduct traffic, keep the communication lines open, make sure the project is kept on track, help in avoiding scope creep, and try to ensure that resources are best managed for the timely and successful deployment of the project. He/she is also relied on to rationalize each sprint scope, in consultation with the Product Owner and the engineers.
SR. ARCHITECT AND DEVOPS ENGINEER
The lead and senior developer on this project. He/she is an expert in advanced Ruby on Rails and Developer Ops, particularly Amazon Web Services. His/her role is high level supervision and guidance of the rest of the engineering team.
They will systematically, through SCRUM/XP, complete and deliver the user stories in Pivotal Tracker.
Builds the initial wireframes, conceptualizes the UI/UX flow, and style/design elements required by the project.
The Quality Assurance engineer systematically goes through the staging site to ferret out any bugs and usability issues during the development sprints.
We require assigning a development pair to each project as part of our desire to provide good quality code, less technical debt, and accelerate development cycles. To learn more about the practice of Pair Programming and its benefits, you can visit https://leanpub.com/level_up/read
We employ Agile methods (A hybrid of SCRUM and XP) for all our development projects where;
All feature stories and chores start out in the ICEBOX. The team, including the Product Owner, populates this icebox with user stories (features), chores, and bugs at the start, and during the course of the project.
At the start of a sprint, the team decides which stories will be worked on for the duration of the sprint. This is based on the mutual assessment of the team on the complexity and difficulty of the tasks, as well as the prioritization of feature stories.
These stories are then dragged to the BACKLOG for completion and delivery.
Many nice-to-have, but low-value-delivery stories will live in the Icebox until the value to the customer or Product Owner can be reasonably established in the future.
SCRUM uses a points system to establish the initial estimation of user stories. At Proudcloud, we have adopted 1 point, 3 points, and 5 points to assign the difficulty level to, and correspondingly the time it will take to finish the user story.
By experience., we have established a rule-of-thumb that equates each point to one (1) man hour of work.
Also, the collective points of the feature stories in the backlog establish the working Project Velocity. Over time and after one sprint has been completed, the actual project velocity is computed and calculated by Pivotal Tracker.
Likewise, the current Project Velocity will affect the delivery timetable of the user stories, and is visible to the entire team, including the Product Owner.
As user stories are completed (delivered) in the BACKLOG, it is now available for the Product Owner to review, test, and accept. It is important for the Product Owner to complete this in a timely manner to keep the velocity calculation as accurate as possible.
This completion, delivery, review, and acceptance of stories continues through out the project. Pivotal Tracker is effective in tracking, taking control of, and reporting the progress of work throughout time.
Any stories that do not fall within the expected action can be rejected, with proper reason indicated in the rejection. The developer team can then revisit the story, make the necessary fixes, and re-deliver it for another round of review and acceptance.
Meet the Crew
+1 415 5470338
© 2023 All rights reserved PROUDCLOUD PTE LTD