status-im
/
samyoul-notes
mirror of https://github.com/status-im/samyoul-notes.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
samyoul-notes/attachments/2024-10/Feature Lifecycle - Team Re...

5.5 KiB
Raw Permalink Blame History

♻ Status Feature Flow Exploratory Calls

🎨 Design Team

  • Multiple platform directions are not helpful
  • Features across platforms should be considered and worked on as close to simultaneously as possible
  • Reduces efficiency of work to drop and re-pick up context with months apart
  • Having multiple CCs involved from an early stage has positive impact for marketing so that comms can be clearer
  • 3 Amigos may need to be flexible on the "3" part

📄 Docs Team

  • Concern about starting with a feature with a figma file
    • It is uncertain what is implemented and what is not
  • Developers write on github, doc team have to hunt down the epics or issues
    • Also it is uncertain what will be included in what release
  • Is there shared workspace for all of the activity that the CCs work on
    • Consider Crews workspace template
  • Formalise the process of share a screenshot of the feature in the documentation, and release articles
  • Changes to features need to be documented somewhere
    • Record somehow that a change decision was made.
    • Explore automation process to highlight when feature changes are made
  • When writing an article about a new feature identify who the developers are
  • Automate alerting teams when certain stages of a feature lifecycle have been met.
    • Possibly link into label inclusion for same with QA

🖥️🔍 Desktop QA

  • The development process doesn't include user stories during a particular point
  • Issues lack an entry point in the development lifecycle
  • We should have some kind of business ownership of building processes
  • Revenue needs to have specific goals from a particular role
  • We should have processes that allow us to compete with small startup team in the web3 space.
  • Sometimes a user story may be too formal and scary to interact with. It is too much / overkill
  • Ideation output needs to be easy to access for anyone, less formal than user stories
  • Experts should give input at the appropriate place.
    • Different stages don't require everyone's input, but they should have visibility
  • Who should be responsible for quality?
  • Potential to move the QA bottleneck from the PR stage to the Acceptance Requirements stage.
  • Requests for PR review on demand seriously damages the ability to plan work
    • No visibility of what is up coming from the development team
  • Currently QA time is not considered as part of the timeline.
    • QA work is assumed to be doable within a day's work.
  • Testing needs to be integrated into the whole workflow including in time estimations.
  • We need to remedy the friction between using Github vs Notion for integrating user stories into the development process
  • Reconciling the different styles of development between all teams.
  • We need to decide and account for divergence in feature parity across platforms
    • Some platforms are unsuitable for certain features
    • But that decision needs to be made and recorded.
  • We should have a pool of feature ideas that can be fed from multiple sources, but it is prioritised and organised.
    • Inputs from:
      • user feedback
      • CC ideas
      • Business considerations
  • B2B relationships are a fertile ground for discovering feature improvements

🖥️👛 Desktop Wallet

  • We need context on the document
  • Do we need every stage of a process some things need to be flexibility.
  • Flows need to be simple
  • Feedback stages need to have an output that feeds into ideation (or roadmap), to ensure a proper cycle
  • Iterative development needs to be considered
  • Input from other teams such as legal to give
  • At each stage the 3 Amigos should decide what should the next step should be and contain
    • cycling back may be an option

🖥️🤘 Desktop Core

  • At least integration tests should be included in feature
  • Functional tests should be required
  • Having tests in mind allow you to have good code.
  • Technical specs are needed.
  • Feedback loops should be required throughout the stages
  • Technical specs are hard to produce in a single step
    • But the specs shouldn't be done all at the end of the process
    • Specs should exist at the beginning but not in there entirity
  • Technical specs could be living documents that update as the implementation progresses.
  • Flexibility is very important
    • Declare that the proce
  • spikes should be considered
  • Document decisions
  • https://www.industrialempathy.com/posts/design-docs-at-google/
  • Features should be welcomed by everybody
  • Possibly retrospective specifications based on the code, to build

Volo

  • Nominate a point of contact that drives the feature.
  • Team lead should always know what is happening within a group.

📱👛 Mobile Wallet

  • flexibility on flows should be considered
  • some features do not require specific documents, flexibility is necessary
  • Notion vs Github consideration
    • Move to github
    • we can have the ability to close issues of milestone / epic / user story types, which is not inherent in Notion.
  • https://www.notion.so/Activity-Mobile-63d352b527844a48a296470340f5e445 A good feature to experiment with a new approach

📱🤘 Mobile Core

  • Requirements are a gradually developing process
  • Need the ability to loop back in the process when discovering
  • Epics may like require multiple 3 amigos
  • How do you measure success? Compare against OKRs.
  • Assess success criteria measured against the OKRs.
  • Develop a process of gathering feature ideas from:
    • CCs
    • Users
    • Business
    • Leads
  • Voting system on a Notion page
    • Anonymous
    • Start simple.
  • What stage does research occur
  • We need to implement an exit phase for features that should be ended - Parvesh
    • We need record rationale / decision making process