Sorry for the delay... I was sick with a broken dev machine, and without our source tree for reference, my knowledge on the subject is, well, not quite there...
Oxygen was setup for continuous integration before I started, so I know the "how" it works, but not the "why."
Before I started, I never had continuous integration setup (wow, I didn't know what I was missing!), so I don't know if my previous organizing methods would have worked so well... (even if I did really like them)
On to the point...
We use subversion for source control and have a build server running CruiseControl. We try to keep the build machine clean, so we're confident we have the project dependencies under control. The build machine does not even have Visual Studio installed -- just the .NET SDK so our projects can be built on the command line.
As for the development tree, its pretty simple:
1. Project Root
a. lib (Oxygen libraries)
b. tools (3rd party libraries) -- references like mbunit or rhinomocks and tools needed to build (like nant, msbuild...)
c. src (project source code)
There are some other folders in the root, but they are specific to the project, like documents or media... All references are to assemblies in lib or tools, never the GAC, this minimizes dependencies that need to be installed on the build server.
The only other file of note in the project root is our build file, which is a NAnt script. This script has several targets, like compile, unit-test, setup-dev-environment, install, cruiseconrol, etc (such a pain to write, but well worth the effort!) The cruisecontrol target, compiles, runs tests, builds installers, deploys installers, runs metrics, sends us result emails and has our bunny tell us updates.
So, "D", I hope this satisfies your curiosity about our development tree! If you have more specific questions, please let me know :)
Monday, March 12, 2007
Wednesday, March 7, 2007
Sprint Planning
At the end of every sprint review, we have our sprint planning meeting... This is our most painful meeting. We've done a lot to mitigate the suffering and the pain has lessened in return. However, our process, like any, is not without flaws and some planning sessions just plain suck.
During sprint planning we review the user stories in our backlog. For our enterprise projects, Salim, our SCRUM master, keeps track of the stories and priorities and the rest of the developers usually know whats going on too. For the new product development our client proxy, Ilio, manages the backlog, which is always well thought out and organized.
Before the review, the developer's knowledge of the stories is anywhere from nothing to very familiar. The more unfamiliar we are with the stories, the more painful our meeting.
Makes sense, because unfamiliarity and uncertainty go very well together, and uncertainty, while unavoidable, makes for long conversations and design talk. Too many unknowns during one sprint review makes us desperate to end the meeting.
The meeting is suppose to go like this:
1. Salim reads a story card
2. On the count of 3 we hold up an estimation card (very easy, easy, medium, hard, very hard and unknown)
3. Salim writes down the estimation
4. repeat
This process repeats until we've estimated more than an iteration of work.
Seems pretty simple, right?
Except, it only happens that smoothly when:
1. The story and solutions are well known
2. Everyone is focused
Sometimes the process is more like this:
1. Salim reads the story card
2. Ilio is asked to explain what it means
3. Ilio explains the story
4. Someone disagrees with Ilio about some behavior on the card
5. Ilio explains the logic again (he's so calm its amazing) and if necessary goes to Bob, our user interaction guru
6. Salim asks if people are ready to estimate
7. Someone answers, "what story are we doing?"
8. The card is re-read
9. On the count of 3 we hold up an estimation card
10. There are only 2 estimations that match, the others range from easy to question
11. The highest estimation explains their reasoning
12. The lowest estimation explains theirs (unless they changed their minds)
13. Salim asks if we want to re-estimate
14. On the count of 3 we hold up an estimation card
15. Kris or Luke make a final decision if we don't agree
16. Salim writes down the estimation
17. repeat
That took a lot longer to read, no? Believe me it makes the meeting take a lot longer too!
Does this make you think we're disfunctional? I think we'd be disfuctional if it always went perfectly... That may sound odd, but its conversations like these that bring interesting design discussions, find issues we missed, discuss user interactions we don't like, etc. These are important conversations to have.
When planning gets filled with unknown stories, we'll have 15 minute meetings each day to discuss stories for the next sprint. This helps, but is difficult too, because its another meeting to fit in during non-war room hours and there is very little time as it is...
I think we all decided that we'd rather have one long day of meetings (which we're having anyway) and a slightly more painful sprint planning than think about sprint planning every day of the week.
At the end of it all, we just want to code :)
During sprint planning we review the user stories in our backlog. For our enterprise projects, Salim, our SCRUM master, keeps track of the stories and priorities and the rest of the developers usually know whats going on too. For the new product development our client proxy, Ilio, manages the backlog, which is always well thought out and organized.
Before the review, the developer's knowledge of the stories is anywhere from nothing to very familiar. The more unfamiliar we are with the stories, the more painful our meeting.
Makes sense, because unfamiliarity and uncertainty go very well together, and uncertainty, while unavoidable, makes for long conversations and design talk. Too many unknowns during one sprint review makes us desperate to end the meeting.
The meeting is suppose to go like this:
1. Salim reads a story card
2. On the count of 3 we hold up an estimation card (very easy, easy, medium, hard, very hard and unknown)
3. Salim writes down the estimation
4. repeat
This process repeats until we've estimated more than an iteration of work.
Seems pretty simple, right?
Except, it only happens that smoothly when:
1. The story and solutions are well known
2. Everyone is focused
Sometimes the process is more like this:
1. Salim reads the story card
2. Ilio is asked to explain what it means
3. Ilio explains the story
4. Someone disagrees with Ilio about some behavior on the card
5. Ilio explains the logic again (he's so calm its amazing) and if necessary goes to Bob, our user interaction guru
6. Salim asks if people are ready to estimate
7. Someone answers, "what story are we doing?"
8. The card is re-read
9. On the count of 3 we hold up an estimation card
10. There are only 2 estimations that match, the others range from easy to question
11. The highest estimation explains their reasoning
12. The lowest estimation explains theirs (unless they changed their minds)
13. Salim asks if we want to re-estimate
14. On the count of 3 we hold up an estimation card
15. Kris or Luke make a final decision if we don't agree
16. Salim writes down the estimation
17. repeat
That took a lot longer to read, no? Believe me it makes the meeting take a lot longer too!
Does this make you think we're disfunctional? I think we'd be disfuctional if it always went perfectly... That may sound odd, but its conversations like these that bring interesting design discussions, find issues we missed, discuss user interactions we don't like, etc. These are important conversations to have.
When planning gets filled with unknown stories, we'll have 15 minute meetings each day to discuss stories for the next sprint. This helps, but is difficult too, because its another meeting to fit in during non-war room hours and there is very little time as it is...
I think we all decided that we'd rather have one long day of meetings (which we're having anyway) and a slightly more painful sprint planning than think about sprint planning every day of the week.
At the end of it all, we just want to code :)
Tuesday, March 6, 2007
Development tress and continuous integration...
Oksana, who doesn't have a blog to answer this on her own, is very disappointed I have not responded to the comment asking how we setup our development tree for continuous integration...
Well, its war room hours and I haven't had a chance to respond, so this post serves as a reminder, that yes Oksana, I will respond... back to coding :)
Well, its war room hours and I haven't had a chance to respond, so this post serves as a reminder, that yes Oksana, I will respond... back to coding :)
InternalsVisibleTo
At the chat on mocks, I mentioned you can test "internal" methods in your test fixture even if it isn't in the same assembly as the class under test (CUT). I used the wrong terminology (of course) and called it making the assembly friends, so if you spent the last few days googling that, my appologies :P
Testing internal methods comes in handy quite a bit:
1. Testing things that you don't want other assemblies accessing
2. Testing state machines or some other context of a class that you wouldn't otherwise expose
3. Using partial mocks
So, how do you let your test assembly access you internal methods?
Its quite easy, first you'll need your test assembly to have a strong name. Once thats done, you need to add one line to your CUT's AssemblyInfo.cs file.
[assembly: InternalsVisibleTo("TestAssembly, PublicKey=yourpublickey")]
For those of you used to 2003, you give your assemblies key files in the properties of the project and not in the assembly info :)
Testing internal methods comes in handy quite a bit:
1. Testing things that you don't want other assemblies accessing
2. Testing state machines or some other context of a class that you wouldn't otherwise expose
3. Using partial mocks
So, how do you let your test assembly access you internal methods?
Its quite easy, first you'll need your test assembly to have a strong name. Once thats done, you need to add one line to your CUT's AssemblyInfo.cs file.
[assembly: InternalsVisibleTo("TestAssembly, PublicKey=yourpublickey")]
For those of you used to 2003, you give your assemblies key files in the properties of the project and not in the assembly info :)
Saturday, March 3, 2007
Failing at TDD
Someone asked for more clarification about how I failed at TDD... I gave reasons why I failed, but no measurement of success. In the class, I had said that I failed until I finally changed my way of thinking and actually got what test driving is all about...
But I was thinking about this statement on the way home and this isn't true. Even after I understood how to test, my classes under test would outgrow their test fixtures because I wasn't in the habit of writing tests first or the tests were too rigid to change or I just wanted to get something to work really quick without having to write a test... a little extra code here and there eventually leads to a lot of failing tests, ignored tests, ignored assemblies and then total failure...
A few years ago I was lucky enough to have lunch with Bob Martin and we had a long talk about discipline. I would argue that this is the most important attribute for test development (he really knew what he was talking about, how little I knew then).
I finally considered myself successful in TDD when I had several projects that were test driven, and continued to evolve test driven as well... i.e. I was finally successful when my tests were refactored with the rest of my code, my tests continued to drive change and it wasn't painful.
But I was thinking about this statement on the way home and this isn't true. Even after I understood how to test, my classes under test would outgrow their test fixtures because I wasn't in the habit of writing tests first or the tests were too rigid to change or I just wanted to get something to work really quick without having to write a test... a little extra code here and there eventually leads to a lot of failing tests, ignored tests, ignored assemblies and then total failure...
A few years ago I was lucky enough to have lunch with Bob Martin and we had a long talk about discipline. I would argue that this is the most important attribute for test development (he really knew what he was talking about, how little I knew then).
I finally considered myself successful in TDD when I had several projects that were test driven, and continued to evolve test driven as well... i.e. I was finally successful when my tests were refactored with the rest of my code, my tests continued to drive change and it wasn't painful.
Hope you had fun at code camp
For everyone who sat in on our talks at code camp, thanks for being a great audience. I'll post some notes, answers to questions and code samples in the near future.
We hope you had fun and maybe learned a thing or two :)
Thursday, March 1, 2007
Killswitch Engaged tonight!
I've been looking forward to this for the past two months! I haven't been excited for a concert in a while, so its nice to have the teenage excitement of seeing one of your favorite bands :)
The show comes during a tough week because I'm still adjusting to my training schedule for team in training and Oksana and I have been working late for our Code Camp presentations. I'm still looking forward to it though!
The show comes during a tough week because I'm still adjusting to my training schedule for team in training and Oksana and I have been working late for our Code Camp presentations. I'm still looking forward to it though!
Subscribe to:
Posts (Atom)
