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.

1. Determine project goal

2. Determine target audience

3. Find core app feature

4. Choose technology

5. Design the UI/UX

6. Build core app feature

7. Test with audience

8. Iterate!

9. 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

3. 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

5. 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

6. 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.