-3

Im starting a project with some college friends and we want to make a team of audio engineers and software developers. We have experience in apps development, filters implementation and audio streaming (wireless and usb) but now we want to develop apps for real time audio streaming and audio processing in smartphones using usb accessories and wireless accessories. We have to do a lot of research, testing and development for this apps and features.

For example we want to develop a feature for noise cancelation when some one is working in the office. Considering that we have a headphone with microphones. The audio is capture by the microphones and is streamed to the smartphone, in the smartphone the audio is processed (in this case the noise is cancelled) and then is sent it back to the headphones.

What methodologies do you recommend me to manage the development of features of this nature?

closed as primarily opinion-based by Venture2099, Mark C. Wallace, Todd A. Jacobs, Aziz Shaikh, Mark Phillips May 22 '16 at 12:05

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Project methodologies are not usually selected based on the features you are developing, but on the nature and flow of the work, the expertise with various methodologies within an organisation, the appetite of the personnel, including management, for supporting various methods and a host of other soft factors. Project management is "just" the practise of facilitating the delivery process in ways that are meaningful to the organisation- What do you want your delivery methodology to give to you and the organisation? – Marv Mills May 4 '16 at 14:16
1

You should take a look at Kanban. It's remarkably simple.

You would have a 'backlog' of work, written up as simple reminders to do something (we call that a story), which as a group you prioritise, adding new stories to the backlog whenever you want. You can then track the progress by moving the items across a three column table -- ready to be done, in progress, and complete. You'd move items from the backlog to the first column when you all agree that work should be done, you move it to the next column when someone is working on it, and the final column when the work is complete. Try to limit the work in progress to two items per person, then play with that number as you progress and get comfortable with the process.

I find this fits very well with a creative, entrepreneurial product development process.

  • Generally, it's recommended that you limit WIP to one item per dev until you have enough data/experience to change it. Helps keep people focused on getting their current piece of work done. – RubberDuck May 9 '16 at 22:25
  • Generally you start with people taking work whenever they've got downtime from their current task. Given that some time on each story is often spent blocked a typical developer will often have 3 or 4 stories in progress simultaneously. That is, generally, there is no WIP limit at first. WIP limits are usually only imposed after a team has started feeling the negative impact of not having them, which is usually somewhere in the 3-6 month period. The minimum I've seen teams use is 2 stories in progress -- 1 would cause unproductive downtime unless you have another way to handle blockages. – Engineer Dollery May 10 '16 at 21:01
  • I'll be honest. That sounds awful. I simply can't imagine having more than 1 story in "Active" at once. Far too much context switching. I think maybe you thought I meant 1 total WIP? I meant 1 per column on the board. (Which is obviously far too high long term, but a nice place to start.) – RubberDuck May 10 '16 at 21:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.