I saw Vikram‘s talk at Droidcon NYC 2016 talk about app performance, and wanted to make sure I made it to his talk. He talks about overall processes for a successful development team along with tools and tips for shipping apps.
Developers shouldn’t be afraid to dip your toes into “product”.
Contribute to feature definition to make your voice heard as a user and for technical implementation.
Understanding your users – Fantasy Football Example:
You should be aware of who is using your app. You might think everyone using a fantasy football app are very serious users, but we find that 12% randomly pick, and 60% are first year users. Try to find patterns between different types of users of your app. Build personas of your users. Building personas of your users is a way to explain behavior that would be hard to explain otherwise. Give these personas name and put them up on the wall in your office. Know who your users are and design for them.
Personas for fantasy football includes:
- Seasoned pros
- People that are forced to join by their friends
- People that are serious, but learning
- “average” users
Data Driven Decisions via Experiments:
DAUs and Downloads are really “Vanity Metrics”, since they don’t gain a ton of insight. Data driven insights are real; not opinions. Wrong decisions can be validated quickly, so feel empowered to test, measure, and grow. Instead of doing costly user research, you can push something to a small group of users, and gain data there vs. expensive user research.
Each experiment should have:
- A hypothesis
- An owner
- A deadline for the end of the experiment.
- Planned removal of the code from your app. You learned something from it, now “Let it go!!!”
Scrum
Planning is a good investment. You can see how long things will take, determine dependencies, and people can show interest in pieces of the work. Agile is important because it’s not adverse to change like Waterfall is.
Types of stories in Scrum:
- User story
- Engineering story
Scrum story checklist:
- Clear definition
- Acceptance criteria
- Edge cases and error scenarios
- Analytics
- Animations and design
Grooming
- should be (1x/week for 1 hour)
- It helps the team to understand stories -> Determine level of effort for stories (Points)
- Stories should have reasonable detail. Be very critical and make sure the story is well defined.
- Don’t get hung up on one story. If your getting hung up, move on and take that offline so you don’t waste your entire grooming on one thing.
- NEVER write stories during Grooming.
- NEVER point a story that doesn’t have all the details.
If you get roll-over and carry-over after a sprint consistently, you’re doing something wrong and should revisit your processes.
Daily stand-ups should be no greater than 10 minutes and should provide high level updates. Low level updates should be taken “offline”, or “parking lotted”.
At the end of the sprint, you can hold a retrospective and demo completed stories. Please prepare up front for this so we don’t have to wait for you to launch the emulator or recompile your project.
“If you’re are not practicing scrum in sprit, you are better off not doing it.”
Continuous Delivery
- Minimizing the time between “code complete” and “deployable”
- deployable != deploy
- This can only be achieved with continuous integration (CI)
- If you do deploy immediately to your users, you get immediate feedback, but not always the best for your users. Vikram recommend every 2 weeks on average, but depends.
- Have internal alpha and beta programs for internal users to try the app before it goes to production.
Pull Request (PR) Tools
- facebook/mention-bot – Can tag reviewers based on “git blame” history
- SonarCube
- https://codecov.io for Code Coverage
- Danger -> Keep PRs <500 lines, PR message should be >25 chars.
- Emulator in an iframe, running the code in the PR. -> https://appetize.io Removes need to compile and install.
APK storage and deployment:
- Use an artifact repository like Artifactory
- Note: Bitnampi has an AWS image for Artifactory.
Culture
- How you act/think/interact. Keep high standards, because you are what your lowest standard is.
- Ownership is important. Communicate deviations and compromises so it’s not lost. Proactively check app quality issues and triage as soon as you can.
- Set goals, but aim for 70%. If you get 100%, then your goals are not high enough.
Meeting etiquite
- Everyone needs to have value, or they shouldn’t be there
- Reject meetings if they are not needed
- Meeting owner should have adgenda, goals and come out with action items.
- There should be a hard start and end type.
Code is a liability. Once it’s out there, you have to support it. Changing code is expensive. Deleting code is a good thing.
Feature Flags – Client-side feature flags are important, along with remote feature flags. Client-side flags should take priority, but if it’s on, then use the remote flag.