Visual Studio Online's source control (along with everything else) is handled through TFS. You are given the choice of using the TFS repository or a Git repository, that is managed by the TFS server. While I prefer Git, I chose the TFS repository since that is what I use at work. Since I use it on a daily basis, I am more comfortable and familiar with it. I want to spend my time learning better ways to code and building a quality product rather than spending time learning the ins and outs of Git via TFS Server.
The Visual Studio IDE has excellent source control support, so I was up and running really quick. I brought my self up to speed with the revised ALM Rangers Guide for branching strategies and got my branching system put together. Initially I'm starting with just a single branch, Main. Once the application gets to a stable point, I'll branch to a Dev branch and continue development there. I'll will ultimately end up with a Development and Release branch isolation strategy. Being a solo developer, I think this works well. It lets me stage chunks of code in Main, that will ultimately end up in Release, while continuing to develop new content in Dev until I am ready to ship Main.
One of the things I'm really anxious to start doing, is automating my builds everytime I check in. Since Visual Studio online only provides you with 60 minutes of build time per month, I will probably only run continuous integration builds when I merge from my Dev branch in to Main and Release. When I am checking in code to Dev, I'm don't really need to have a build generated.
The nice part with this is that I can easily access a build of my application from anywhere. I just need to log in to Visual Studio Online, download the drop and run it. Since I don't like storing my source code on cloud services like OneDrive or Dropbox, this lets me access my source and drops from anywhere.
We use a variation of Agile at my work and I don't have any complaints with how Agile works. I used it somewhat with AllocateThis! when my buddy and I where working on some stuff together and found it helped provide a clear path for development. Typically, I just start writing code, then end up going back and re-writing code so that the new features I want work well with the old code. This time around, I'm going to plan properly.
I have crafted a series of user stories already and have a decent back log that is being built. An initial prototype of the app has already been wrote, so I've already got a decent idea of what is involved with creating a Universal Windows app. I will spend the next week or so finalizing the initial backlog, then start taking my prototype and building an actual product with it.
I'll post updates of my progress (without giving away to much detail!) as I develop the app. I kind of want to document a little bit the entire process, from start to finish, of creating a Universal Windows App Store app. Coming from WPF, it's been a bit of an adjustment. I had thought that they would be relatively the same (which they are); the differences however between the two frameworks are pretty significant and slowed my prototype development down. I imagine as I progress, my overall velocity should increase. At least until I start doing UI animation in Blend!