Skip to content

Instantly share code, notes, and snippets.

@srph
Last active November 23, 2016 02:34
Show Gist options
  • Select an option

  • Save srph/54997938ba22e5bcf6d16848c820a801 to your computer and use it in GitHub Desktop.

Select an option

Save srph/54997938ba22e5bcf6d16848c820a801 to your computer and use it in GitHub Desktop.
Reasonable, Loose Development Process

Reasonable, Loose Development Process

Note that in this process, we’re not trying to ship half-assed products. This isn’t a 24-hour hackathon. But of course, we’re also trying to ship products as soon as possible while considering everybody’s efficiency and interests and the business's market and users.

We will try to avoid dependency as much as possible.

This doesn’t have to be strictly followed. This only allows the team to have a general guideline in their process so everybody understands what they’re supposed to do, how they’re supposed to do, and for how long. Tweak it to your team's work speed and project's difficulty.

Some products can also be hard. But of course, most products take more time than needed because of the noise; everything that’s not necessarily the main functionality but important: auth, etc.

Why

I noticed a lot of teams put out unrealistic large goals that do not take communication errors and other problems into account. Smaller, reasonable goals allows everybody to ship their product as soon as possible without burn outs, design failures, or smelly code that needs to be rewritten.

Phases

  1. Starting phase. You have nothing yet. Right now, we only have an idea and a project boilerplate. It’s hard to get out of here. We're here, and we're getting our idea out of here.

  2. Maintenance phase. We’re done with the product. Users are probably loving it. We’re making things performant. We’re adding in features. We’re fixing things.

Starting Phase Process

  1. User Story. Make a well-defined user story for our product.

  2. Product Design Stage. Constant iteration between the designer and manager for a few days, maybe 2-4 days. Why? We shouldn’t take too much right now. We’re only working on a wireframe at this point. We need to ship an MVP. We don’t need anything else. This also allows us to understand which elements are important; and which ones aren’t. Also, this is to make sure that the designer and manager can their ideas and solutions in sync. This also allows both to validate feasibility. The developers can get their gears / boilerplates ready for now. It’s also important that both front-end and back-end developer check the design for validation.

  3. Initial development stage. 2-3 days. API and FE guys will initially start working in parallel. API will prepare the documentation while the FE does the static part. This shouldn’t take too long. Also, it's recommended to avoid doing the animations and stateful interfaces (handling empty, error, disabled, etc) here. It still depends: Some UI can eat some time like dropdowns, modals, etc. Designer and manager can now work in parallel until the next stage. No dependencies here.

  4. Actual development stage. This is where the API-FE integration happens. Up to 1 week or a few days more. Why? Remember, we’re trying to ship the “MVP” here. One that’s also working and with proper code — not one that’s just clunky (hacked together). The other stuff like auth, etc. isn’t very hard to do. And usually considered noise because 1. it’s not what you’re trying to accomplish 2. everybody app has it. 3. it’s not very hard to do other, just tedious.

  5. Iteration. After shipping a good MVP, update the design, make things fast, and ship new features. Read the next section.

Iteration Process

This depends on your team's phasing. I recommmend teams to have 2-week sprints (not necessarily scrum) for features and fixes. This doesn't mean that you need to fill your 2 weeks until it's full. Do not try to overwhelm yourself and your team. Make allowances for errors.

You just need to set a target goal: which new features will be added and existing bugs fixed. Personally, I prefer a 1-week sprint because I have less complicated features to ship. Meaning, less time for the implementation and tests. It also lets my team reassemble for priority.

In this stage, you can now start applying major minor details like animations, handling different application state: error, loading, empty, disabled, etc.

Now, go make kickass products, peeps!

Notes

  • We're expecting that everybody's a level on their role here.
  • When shipping an MVP, you don't need more than 4 members. Just get a few members that need to fill up roles you need: Front End Developer, API Developer, Designer, [Manager].
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment