+1 for this answer. Kanban is a great way to generate actually useful metrics for a team, project, or department. You'll be able to calculate things like how long it takes the average ticket to work its way through your processes, where tickets tend to get stuck (cumulative flow diagram), and where the sources of waste are in your processes.
I've led several teams using Kanban as a way to visualize our workflows and measured the cycle times for each work item through our processes. By driving out common causes of variance between work items, its possible to arrive at a consistent cycle time per item. You can then use any process improvement technique you like to show tangible improvements in cycle time.
I'd have to say that there were a few surprises I learned along the way:)
First, expect it to be another full-time job. It takes up as much time as you have, and even more, and forget about having a personal life while you're writing it. The people I know who've done the best job writing a tech book are those who are independent consultants who have non-billable time or employees where their employer supports their writing a book. The extra time each of those kind of people can get to write during working hours is a huge help.
As far as using Word goes, it works well enough for this stuff. Expect to use a separate file for each chapter. I used a subversion repository to check everything into and out of, just to be safe.
Make writing a habit. Set a production schedule and stick to it -- its too easy to take a day off, which then turns into two days, into a week, and then just gets worse and worse. Set out a plan, both long term and short term, track your progress, update the plan as you go, and keep writing.
Finally, using a continuing example throughout the book might be nice for readers, to give them a continuing context, but it greatly increases the risk of a lot of rework on your part if you change your mind about something halfway through writing. You'll have to go back and re-edit everything that depends on the decision you changed. It does make it nice for the reader but much harder for you.
Good luck! Its a great learning experience, whether you finish the book or not.
I've been using tuffmail.com for ages, and it has been great. Not a single problem with an outage I can remember, they are very responsive when I've had a question about setup, great spam filtering, different plans depending on what you want. Highly recommended.
Funny you should ask:) I just removed this very same program from a friend's computer this weekend. I searched all over the web to find out how to remove it. The best answer I got was here.
I loaded Ewido Security Suite, rebooted, and on the way up, it detected and removed all traces of it (as far as I could tell).
Also consider booting into safe mode. In safe mode, Aurora's software isn't loaded, and you can do all sorts of interesting things.
-- bab
Once again, YMMV. Where we live, the customer service at the store near our house is awful. They have one job -- get you to sign up and buy things. Once you've done that, they could not possibly care less about you. OTOH, VerizonWireless customer service has been fantastic every time I have called them. Courteous, fast, concerned, able to fix my problem on the first call. I recommend VZW to everyone I know -- great service, great coverage, and phones that work.
As opposed to a long-term project plan, where the work is laid out in detail for the entire project, SCRUM and XP say that you only plan in detail for your immediate set of work (vast simplification). Then after you finish that work, you replan. Each sprint or iteration is made up of that work that is currently considered the most business-critical functionality. This is very different than traditional project management methods, where the emphasis is on planning the project up front, and controlling change throughout.
When planning like this, you rely on creating small, fully functional releases, verified through automated tests, and delivered to someone often. This generates the nearly immediate feedback needed to reprioritize as business conditions change.
In my experience managing software developers the difficulty is this: after even 10 years writing software, most programmers have no idea how long it will take them to implement a feature specification.
As another poster wrote, this is because they usually aren't asked to estimate their tasks. Lots of times, their managers estimate their tasks for them!
What would happen if we kept the sizes of the things developers had to estimate down to a reasonable size, like a few weeks. Then we asked them to estimate these things fairly often, as new stories are written. Pretty quickly, the developers would build up a history of how their estimates matched reality. They could then start estimating new stories based on relative sizes with things previously done.
Given the rapid buildup of history, and the small sizes of the chunks, the estimates get pretty good pretty fast
At a higher level, most developers don't have any idea how long it will take them to develop the feature spec.
One reason for this is because there is no way to tell when you are done. How do you test a feature spec for completeness? For accuracy? For bugs?
What if we let the customer write down as many features as they wanted, allowed them to add features at any time, and gave them rough estimates on what those features cost? We wouldn't care how long the whole spec took to write, because it would be evolving as the customer's understanding of the system evolved. And as business conditions changed, and the requirements for the system changed, the customer would be free to change their mind, without incurring exorbitant costs. Customers love this!
Go another step and ask them to write a test plan, and you'll discover that most developers don't even know what a test plan is.
If you are talking about end-to-end tests of a feature, then that is the responsibility of the customer, along with QA. As customers decided that certain stories were the highest priority things to work on, they would have to come up with a verifiable set of acceptance tests that would both define the acceptance criteria for that story, and also provide detailed, executable requirements. Programmers could now tell, in a binary manner, if they were finished with a feature or not!
If you are talking about unit tests, the developer simply writes the most appropriate test at the most appropriate time, and you end up with almost 100% code coverage automatically. You'll have to read more about TestFirstDesign to understand more fully what I'm talking about here.
Disclaimer: I am an Xp coach, and I teach teams to do this for a living. It works. It really does:)
Not to sound rebellious against the original poster, but he clearly doesn't understand Xp. His point in [a] is completely true, programmers do love creating the impossible. [b] is true as well. None of this would work without the builtin feedback and communication in Xp.
Customers are allowed to ask for anything they want. Programmers are allowed to force the customer to refine what they are asking for until the story can be estimated and tested. Programmers then assign an estimate to it, somewhere in the range of 1-3 weeks. Customers can then make intelligent choices about the value of a story versus its cost.
As for your second point, how is this customer/programmer relationship different from any other methodology. Someone has to decide what gets worked on. In most methodologies, programmers end up making these decisions, based on what seems cool. In Xp, Business decisions are made by business people. What a novel concept:)
Why would you say that? Keep in mind that the review only mentioned the briefest description of the practices involved with XP. There are a lot more.
For example, maintainability is maintained through several cooperating practices, the first being PairProgramming. Every line of code is written with two sets of eyes looking at it. There are reasons for this that I won't go into here, but you can find out about them at the URL I mention below. Next, there is the rule about OnceAndOnlyOnce. This says that code can only appear in one place in a system. If you have the urge to replicate some portion of the code, then you are obligated to refactor the system to provide for a single place for that code to live. This above all else serves to create an elegantly designed system. This leads to RefactorMercilessly, UnitTestsFirst, and a few other of the XP practices.
In the end, though, XP-produced systems tend to be exactly what the customer wants (PlanningGame), thoroughly debugged (UnitTestsFirst), and easily maintainable (OnceAndOnlyOnce et al.).
Check out the Extreme Programming Roadmap for a thorough discussion of the XP principles, and subscribe to Rational's Object Technology User's Group for a spirited discussion with many of XP's founders.
Slashdot Mirror
+1 for this answer. Kanban is a great way to generate actually useful metrics for a team, project, or department. You'll be able to calculate things like how long it takes the average ticket to work its way through your processes, where tickets tend to get stuck (cumulative flow diagram), and where the sources of waste are in your processes.
In addition to the book mentioned above, I also like this one by David Anderson: http://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_1?s=books&ie=UTF8&qid=1324000945&sr=1-1
I've led several teams using Kanban as a way to visualize our workflows and measured the cycle times for each work item through our processes. By driving out common causes of variance between work items, its possible to arrive at a consistent cycle time per item. You can then use any process improvement technique you like to show tangible improvements in cycle time.
-- bab
I'd have to say that there were a few surprises I learned along the way :)
First, expect it to be another full-time job. It takes up as much time as you have, and even more, and forget about having a personal life while you're writing it. The people I know who've done the best job writing a tech book are those who are independent consultants who have non-billable time or employees where their employer supports their writing a book. The extra time each of those kind of people can get to write during working hours is a huge help.
As far as using Word goes, it works well enough for this stuff. Expect to use a separate file for each chapter. I used a subversion repository to check everything into and out of, just to be safe.
Make writing a habit. Set a production schedule and stick to it -- its too easy to take a day off, which then turns into two days, into a week, and then just gets worse and worse. Set out a plan, both long term and short term, track your progress, update the plan as you go, and keep writing.
Finally, using a continuing example throughout the book might be nice for readers, to give them a continuing context, but it greatly increases the risk of a lot of rework on your part if you change your mind about something halfway through writing. You'll have to go back and re-edit everything that depends on the decision you changed. It does make it nice for the reader but much harder for you.
Good luck! Its a great learning experience, whether you finish the book or not.
-- bab
I've been using tuffmail.com for ages, and it has been great. Not a single problem with an outage I can remember, they are very responsive when I've had a question about setup, great spam filtering, different plans depending on what you want. Highly recommended.
bab
Funny you should ask :) I just removed this very same program from a friend's computer this weekend. I searched all over the web to find out how to remove it. The best answer I got was here.
I loaded Ewido Security Suite, rebooted, and on the way up, it detected and removed all traces of it (as far as I could tell).
Also consider booting into safe mode. In safe mode, Aurora's software isn't loaded, and you can do all sorts of interesting things. -- babOnce again, YMMV. Where we live, the customer service at the store near our house is awful. They have one job -- get you to sign up and buy things. Once you've done that, they could not possibly care less about you. OTOH, VerizonWireless customer service has been fantastic every time I have called them. Courteous, fast, concerned, able to fix my problem on the first call. I recommend VZW to everyone I know -- great service, great coverage, and phones that work.
bab
As opposed to a long-term project plan, where the work is laid out in detail for the entire project, SCRUM and XP say that you only plan in detail for your immediate set of work (vast simplification). Then after you finish that work, you replan. Each sprint or iteration is made up of that work that is currently considered the most business-critical functionality. This is very different than traditional project management methods, where the emphasis is on planning the project up front, and controlling change throughout.
When planning like this, you rely on creating small, fully functional releases, verified through automated tests, and delivered to someone often. This generates the nearly immediate feedback needed to reprioritize as business conditions change.
As another poster wrote, this is because they usually aren't asked to estimate their tasks. Lots of times, their managers estimate their tasks for them!
What would happen if we kept the sizes of the things developers had to estimate down to a reasonable size, like a few weeks. Then we asked them to estimate these things fairly often, as new stories are written. Pretty quickly, the developers would build up a history of how their estimates matched reality. They could then start estimating new stories based on relative sizes with things previously done.
Given the rapid buildup of history, and the small sizes of the chunks, the estimates get pretty good pretty fast
At a higher level, most developers don't have any idea how long it will take them to develop the feature spec.
One reason for this is because there is no way to tell when you are done. How do you test a feature spec for completeness? For accuracy? For bugs?
What if we let the customer write down as many features as they wanted, allowed them to add features at any time, and gave them rough estimates on what those features cost? We wouldn't care how long the whole spec took to write, because it would be evolving as the customer's understanding of the system evolved. And as business conditions changed, and the requirements for the system changed, the customer would be free to change their mind, without incurring exorbitant costs. Customers love this!
Go another step and ask them to write a test plan, and you'll discover that most developers don't even know what a test plan is.If you are talking about end-to-end tests of a feature, then that is the responsibility of the customer, along with QA. As customers decided that certain stories were the highest priority things to work on, they would have to come up with a verifiable set of acceptance tests that would both define the acceptance criteria for that story, and also provide detailed, executable requirements. Programmers could now tell, in a binary manner, if they were finished with a feature or not!
If you are talking about unit tests, the developer simply writes the most appropriate test at the most appropriate time, and you end up with almost 100% code coverage automatically. You'll have to read more about TestFirstDesign to understand more fully what I'm talking about here.
Disclaimer: I am an Xp coach, and I teach teams to do this for a living. It works. It really does :)
Customers are allowed to ask for anything they want. Programmers are allowed to force the customer to refine what they are asking for until the story can be estimated and tested. Programmers then assign an estimate to it, somewhere in the range of 1-3 weeks. Customers can then make intelligent choices about the value of a story versus its cost. As for your second point, how is this customer/programmer relationship different from any other methodology. Someone has to decide what gets worked on. In most methodologies, programmers end up making these decisions, based on what seems cool. In Xp, Business decisions are made by business people. What a novel concept :)
For example, maintainability is maintained through several cooperating practices, the first being PairProgramming. Every line of code is written with two sets of eyes looking at it. There are reasons for this that I won't go into here, but you can find out about them at the URL I mention below. Next, there is the rule about OnceAndOnlyOnce. This says that code can only appear in one place in a system. If you have the urge to replicate some portion of the code, then you are obligated to refactor the system to provide for a single place for that code to live. This above all else serves to create an elegantly designed system. This leads to RefactorMercilessly, UnitTestsFirst, and a few other of the XP practices.
In the end, though, XP-produced systems tend to be exactly what the customer wants (PlanningGame), thoroughly debugged (UnitTestsFirst), and easily maintainable (OnceAndOnlyOnce et al.).
Check out the Extreme Programming Roadmap for a thorough discussion of the XP principles, and subscribe to Rational's Object Technology User's Group for a spirited discussion with many of XP's founders.