Planification for new project
Draft Disclaimer: Please note that this article is currently in draft form and may undergo revisions before final publication. The content, including information, opinions, and recommendations, is subject to change and may not represent the final version. We appreciate your understanding and patience as we work to refine and improve the quality of this article. Your feedback is valuable in shaping the final release.
Planification for new project
There are couple of steps and actions that I take whenever I am building a new project. I am sharing with you my game plan.
-
Determine project goal
-
Determine target audience
-
Find core app feature
-
Choose technology
-
Design the UI/UX
-
Build core app feature
-
Test with audience
-
Iterate!
-
How do u test it and for which purpose ? I start a new project to solve a problem for an audience. The project is therefore a solution I want to put in front of that set of persons. Main reason because we developer are biased. We tend to build features that we want not necessarily what users want.
Second reason it to test your solution once you have something to start with.
- Adjust with feedbacks received for the next iteration
- make the target audience participated. They will feel more concerned and willing to give you their money since the solution is tailored to them
- Find core app feature core app feature:
- your app = f(problem, audience)
- core features are the ones solving your target audience problems
for a streaming platform it would be the video player and the file manager
-
Design the UI/UX UI is just about how you feel. Since creativity is involve there is no predefined rules just some good practices. Here on this thread it was about making some wireframes then build up from that
-
When Think many people would love to hear your thoughts on testing. When to test what; sketches, wireframes, prototypes, hallway testing, moderated/unmoderated, etc... when to test ? as soon as possible. You need to put your product in front of people with early access to get their first feedback for the next iteration. Doing so they will feel like they participated to the final product then you can reward them with discounts.
Summary
- Description and estimate
- Issue/ticket as work item
- Benefit of scoping tickets
- Backlog as group of tickets
- CI / CD pipeline
Project onboarding
- What is the target audience ?
- this will determine who to serve and where
- sometimes usage of the application can dictate where it should be serve (ie e-wallet likely better as an app)
- ask client for opinion. When none provided, give educated advices
Description and estimate
- Make a rough project description and estimate
- client describe project
- client give budget
- We roughly estimate the project (budget, execution delay)
- If that is matching client expectations then we elaborate to deliver a better estimate and schedule This allows me to quickly weight the client as this will prevent both of us from losing time.
Example: Watson wants a million dollar project but only has $100k
Issue/ticket as work item
You can see an issue as a result. The goal is have daily incremental progress. For that we keep issue scoped and small enough to be completed the same day. We create the issue with three sections:
- Scope
- Acceptance criteria
- Technical directions
Backlog as group of work item
We define the backlog as collection of tickets (work items). We include everything we think that can/should be done. Backlog should also contain budget, execution delay. These are estimates so not actual due dates.
We will do anything possible to deliver earlier but more importantly delivery quality. For that I use github
- setup an org (:insert link) if not exists
- create repo(s)
- create project (like trello)
- create backlog as set of issues sorted this way:
- backlog
- validated
- ready
- in progress
- in review (if you are a team)
- done (means it is )
Benefit of scoping tickets
What's good about this is that you are communicating the desired end result as opposed to communicating the steps. We find this to be more effective to share goal/result. Everybody coming late can understand what we are trying to achieve. As opposed to,
- create this file
- add this line
- create this function Doing something without having an overview of the end goal, the whole picture.
Communicate changes via changelog. What's the best place to communicate change than changelog ?
CI / CD pipeline
One of the reasons I use github is that I like their new changes since acquired by Microsoft like github actions Create linting and test workflow (action). Our pipeline may differ from yours so I'll leave this part empty but hit me up if you are interested in seeing ours.
Feature/bug fix flow
- create issue on github that describe the feature or the bug we want to fix.
- create local branch to start coding
branch=master|main|develop depending on your case
issue=123
git checkout $branch
# Try to be up to date before creating a new branch
git pull
git checkout -b issue/$issue
That's it! Now deliver!
Wrap up
Some principles of mine
- deliver quality and on time
- bug free (or at least very little)
- Catch any new bug with new issue on github
- TDD to develop and refactor in serenity
I do not pretend to have the truth. These are my thoughts and standards we apply everyday with the team of developers I am leading. Hopefully it will help. What would change if it was up to you ?
Tweet: https://twitter.com/babacarcissedia/status/1359839653935935491?s=20
Product specs
Summary
- User story
- Work item
- Backlog
- Contributing
User story
are just simple sentence describing what you want ie
as a user, I can login to my account as a user, I can pay my order online
- Can be used by the different team on an organization. Managing team, marketing team as well as developers
- Can be used to speech the project. User stories are usually a good way to list out all the features. I usually decide on what to work on depending on the priority.
Work item
user story can be small in term of efforts ie
as an admin, I can see the delete/edit button
sometimes you can have other that require more efforts
as a user, I can pay my order online
- setup payment processing (stripe, paypal, OrangeMoney, FreeMoney)
- design checkout flow UI (shopping cart, product listing, checkout form)
Work item should be small. Ideally work item is something that can start and finish the same day. What we don't want to have an issue that is too big to be reviewed. With size comes complexity, breaking changes, and so on
Backlog
User story list constitute your backlog. You should then order your backlog by priority. Often it is driven by the value of the user story addition to the current product.
if changing app logo is bringing more value than having checkout form working then it should be app logo change first
Project manager or developers can order the user stories but does not dictate his will over the client wants.
We developers have that bad habits of putting our wants first before the clients ones.
Contributing
- put together standards which can include linting so that the code base can be uniform.
- testing (unit, feature, integration, smoke) so that you can rely a bit more on your software. This is also allow incremental changes without breaking the previous features
Contributing - Github
The rule of thumb is one issue, one branch, one PR
- The issue is the user story in general
- The branch is your little word where you are building the user story
- The PR is the request to have your implementation of the user story in the current product. You just need to mention
closes #issue-number
ie closes #110 Github will automatically close the issue when the PR is merged. Closing an issue is like marking it as done.