Lastly if it isn't too much can you post links to the course website for this,the software communications and software metrics?
In terms of books, I really like "The Architecture of Open Source Applications" (http://aosabook.org/) which is also mentioned in the blog post. For the enterprise world, "Patterns of Enterprise Application Architecture" (http://martinfowler.com/books/eaa.html) is a good choice.
However, before applying any technical software architecture methods, it is really important to understand what your stakeholders actually want/need. Unfortunately most of the time they don't even know it themselves. In my experience most software projects fail, not because of technical reasons but simply because the original problem hasn't been understood. This is where communication is key. I assume the reason why the authors of the blog post encouraged drawing diagrams and looking at different perspectives/views is to facilitate this communication.
I think there is none.
I think every organization is different. The best thing to do is be communicative, responsive and honest. Moving agile means all the above. Rule one is start small and go simple. Just spent three days on making something and I got stuck so I said fuck it, start small. So I need to build this tool that reads the output of another tool. Sadly it comes out in terminal with all kinds of custom format. Instead of parsing the full "terminal output" I receive, I start small by reading and getting whatever I need. Gradually I built up the "reader/parser" I need to from this report I was trying to parse. And I finished what I was hoping to finish.
> Also when you're doing sole projects are there specific procedures you should follow and how do they differ from when you're in a team?
It's very subjective. I think if you are accustom to one way you do it that way more often. But I said in my example, I spent three days trying to go complex. That's the failure of me, but it probably happen to everyone everytime because I (or we) think I was smart so I could solve this complex issue. The only rule I have when I do sole project is to define the scope of my project. I write down whatever I want to implement, what it does. Essentially building up a set of user stories for myself. But that's also true for team project. You just can't be sloppy and acting alone when you do team work... so when you work with others, get the user stories up and running, figure out the style you want to code in... they all matter.
Last thing: it's easy to say, but it is damn hard to do it. Just relax.
This fellow: http://www.jonathanholloway.co.uk/work
Wrote his master's thesis on the very subject http://www.jonathanholloway.co.uk/thesis/abstract.html
[Whole thesis back in /work]