I just replaced Windows Vista Ultimate x64 on my laptop with the 64 bit version of Windows Server 2008. What prompted the change? Well, I was hoping to improve the lackluster performance of Vista. I would happily trade in the consumer goodies in Vista for better productivity. Unfortunately it seems to be an either/or proposition. But the most compelling reason for me was Hyper-V, the new virtual server from Microsoft. I do a lot of work with virtual machines, mostly to run a complete Visual Studio Team System environment in a sandbox for development and training purposes. Although Virtual PC 2007 is a good product, Hyper-V seemed to offer better performance and more flexibility with features like snapshots. Hyper-V also supports 64-bit guest operating systems, while Virtual PC 2007 can only run 32 bit OS’s. After reading this article I was convinced that Windows Server 2008 with Hyper-V was the setup for me. So, I took the plunge. In the next blog post, I’ll go over the process of installing Windows Server 2008 as a workstation OS (also dubbed Windows “Workstation” 2008). By the way, I run a Dell 830 laptop with an Intel Core Duo T7500 mobile CPU and 4GB RAM. If your workstation does not support hardware virtualization, then it won’t run Hyper-V. However, you can enjoy the benefits of Windows “Workstation” 2008 and still run your virts using Virtual PC 2007 SP1. Although Windows Server 2008 is not officially a supported host OS for Virtual PC, it seems to work just fine.
OK, let’s say you’re on a Scrum team that’s planning its next iteration. You pull a story to implement Feature X for the next release of Application Y. You review the specs, maybe have a conversation or two with the product owner to clarify a few details, and discuss implementation details with your team lead. Cool. Now, you design the feature, code it up, build it and tweak it until its working to your satisfaction. Then you check it into the source control system and move on to the next feature. Done, right? Not necessarily so! Sure, you can stand in front of the users at Sprint Review and watch them salivate as you demonstrate Feature X in action. But, can they walk out of the review and begin using it right away? Most likely not. If not, is it really done? “Code complete” is just one milestone on the yellow brick road to Emerald City, where users are happily whistling away while using your excellent Feature X in their Application Y. There is so much more to consider. What about unit testing? Integration testing? Acceptance testing? Documentation? Packaging? Deployment? Getting an application successfully delivered involves much more than working code. Failure to take this into account, and considering “code complete” to mean the same thing as “done”, inevitably causes a development team to fall behind schedule as they scramble to deliver what was already considered done. This is a form of technical debt, a topic I’ll explore in a future post. For more information on the meaning of “done”, check out this excellent podcast on HanselMinutes.com: What is Done? – A Conversation with Scrum Co-Creater Ken Schwaber
Back in the 80s (way back!) Apple got a toe-hold in the PC market in part by engineering a high presence in colleges and high schools. The theory was that if you get a young person started on an Apple computer then they will want to continue using Apple computers into their adult careers, if for no other reason than they already know how to use it. This strategy actually worked reasonably well.
Microsoft has always struggled with their presence in colleges and high schools. These institutions tend to favor the JLAMP stack (Java, Linux, Apache, MySql, PHP) over the Windows platform. What mind-share Microsoft has with students seems to tend toward the "evil empire" variety.
I'm pleased to see that Microsoft has finally made a bold move to improve their visibility in the college community. My son - a college student - pointed it out to me the other day. The program, launched last February, is called DreamSpark:
DreamSpark is simple, it's all about giving students Microsoft professional-level developer and design tools at no charge so you can chase your dreams and create the next big breakthrough in technology - or just get a head start on your career.
Looking at the list of software available for free through this program, it almost makes me want to enroll in a class or two at my local university!
For more information: https://downloads.channel8.msdn.com/
A bug is a bug is a bug, right? Not so! Most development shops treat a bug as a task. That seems reasonable - it's a bit of work that needs to be done. Unfortunately, it's not so easy. If a bug is discovered in a feature that is currently under development, and it will be fixed in the current Sprint (iteration), then the bug can and should be treated as a task. It would be considered a new Sprint Backlog Item that must be closed before the feature can be considered "Done". However, if the bug is not fixed before the feature is considered "Done" (yes this really happens), or the bug is discovered after the feature has be deemed "Done", then the bug becomes a bit of work to be scheduled into a future Sprint. In other words, the bug should be treated as a Product Backlog Item. The rule of thumb is rather easy really. If the bug is going to be fixed in the current iteration, then treat it as a task. If not, then the bug needs to go on the product backlog and be prioritized right along with all the other Product Backlog Items. Of course, this raises the question: What does "Done" mean exactly? Many dev teams grapple with this deceptively simple question. I'll explore this question in a future post.
While at TechEd 2008 earlier this month I attended a presentation by Colin Bird where, among other things, he presented the next generation of the Conchango Scrum For Team System process template. According to Colin, Conchango will continue to offer a free version of their scrum process template. But, they will also be offering for the first time an "enterprise" version that they will sell for a yet-to-be-determined fee. This enterprise version will contain an exciting new feature: and Electronic Scrum Board. This WPF application simulates the cork board and index cards that many scrum teams use to track the progress of their sprint. Each row represents a Product Backlog Item (also called a User Story) that describes a specific feature to be implemented, while each card represents a Sprint Backlog Item that describes a specific task. The columns on the board represent the various states for a Sprint Backlog Item.
 |
I took this shot while sitting next to David Starr in the presentation, who also took a snap with his camera phone.
|
When a card is dropped onto a row the board, it is automatically linked to the corresponding Product Backlog Item, and it's State is also updated automatically. This is sooo much more convenient that the current method of updating work items, and the board methaphor makes it much easier to visualize the overall status of the sprint.
I also happened to be part of the same lunchtime discussion of Electronic Scrum Boards with Jeffrey Palermo that David blogged about. I respect Jeffrey's opinion very much, as well as Dave's reaction to Jeffrey's comments. But my take on the topic is slightly different.
As I recall, Jeffrey was not thrilled about the Electronic Scrum Board because a physical cork board works just fine. The cork board is simple and easy to use. It's highly visible to the scrum team and its stakeholders. Why go to the trouble and expense of implementing an inferior solution?
I get it. But I also beg to differ. First, let's assume that an organization has decided to use Team System work item tracking because it offers rich reporting of current and historical data, as well end-to-end traceability resulting from linking work items to changesets to builds to build verification tests. Now, if a scrum is using both work item tracking as well as a cork board, then the same information if being maintained redundantly. This being the case, it's almost certain that the work items will be out of sync with the cork board some if not all of the time. With two conflicting views of project status, which one is authoritative? Which one do you believe?
Also, the cork board works great if the scrum team is co-located in one open space. Having all team members together in one location is ideal, but the reality is that a growing number of teams are geographically dispersed - sometimes in different parts of the world. For these teams, the cork board offers a poor solution.
Similarly, project stakeholders are often not in the same physical location as the cork board, making it difficult if not impossible for them to benefit from the information the cork board contains.
For these reasons, I believe that the Electronic Scrum board offers a superior solution. It not only shows current status, it also automatically maintains work item history. Analysis of this historical data can calibrate future estimates, enabling better sprint planning. Also, an Electronic Scrum Board offers a far more practical solution for teams that are not co-located.
Finally, I find it curious that scrum teams are in the business of creating automated solutions for others, but some of these same teams are loathe to give up their cork boards for an electronic version. Doesn't that seem just a bit ironic?
I recently ran into a problem with our new Windows SharePoint Services (WSS) 3.0 instance running on Windows Server 2008. I'm running Windows Vista x64 on my laptop, which has been working very well. But, when I tried to download a file from this new SharePoint site, the download started OK but then stopped almost immediately, as if the connection was lost. I did some searching around the web and came across this post. As it turns out Windows Vista can negotiate the TCP packet size with Windows Server 2008 to optimize download speed. Apparently my router (A NetGear FVS318) is throwing a wrench in the works by blocking the SYN packets used to negotiate packet size. Result: no download! Fortunately the fix is very easy once the problem has been identified. Just run a Command Prompt as Administrator, and paste this onto the command line: netsh interface tcp set global autotuning=disabled That did the trick for me! However, you may want to re-enable auto-tuning when connected to a router that handles SYN packets properly. To re-enable TCP auto-tuning, use this command: netsh interface tcp set global autotuning=normal To see the current TCP settings on your Windows Vista client, use this command: netsh interface tcp show global
Now that Team Foundation Server 2008 is out, the Visual Studio Team System product team is totally focused on the next version, known as Rosario. If the current release rhythm continues, Rosario is likely to be released in 2010 (Visual Studio 2005 was released in November 2005, and Visual Studio 2008 was released in November 2007). The latest version of Rosario is now available for public download on the Microsoft download site. This version is called the April Community Technology Preview (CTP). It's called a CTP because the product is still under development. The CTP gives the development community an opportunity to see what's been produced so far and provide feedback. It's not called a Beta because the bits have not been as thoroughly tested. For this reason, Microsoft recommends that this CTP release not be used for any sort of production development. The product team has made impressive progress so far. Rich Hundhausen and I got a sneak preview of this CTP a few weeks ago, and what I saw blew my socks off! Whereas the new features in Team Foundation Server 2008 focused mainly on improvements to build and version control, the main areas of focus for Rosario are project management, design and test (Although I'm interested in all things Team System, I'm somewhat partial to project management). This April CTP is the third CTP release for Rosario. To see the features included in each release, as well as a slick way to download the beast, check out these posts from Jeff Beehler:
Mike Azocar, a fellow Team System MVP, reports: We released LWS version 2.1 today. This version includes a new process guidance and SharePoint template as well as many work item enhancements. You can download it at
www.codeplex.com/vstsscrum Mike also indicates that they will soon release a version that will work with the Project Server connector.
Martin Woodward has done his magic again! For those of you who don't know Martin, he is the primary developer of Teamprise, a fantastic suite of client applications that gives Java developers cross-platform access to Team Foundation Server from the command line, a stand-alone GUI or an Eclipse plug-in. In his blog, Martin announced the release of Teamprise 3.0, updated to take advantage of the new features in Team Foundation Server 2008. This release contains some many impressive new features including check-in policy support, recursive folder compare, single sign on support on windows clients, and gui support for version control undelete and destroy commands. Perhaps the most impressive new feature is the full Team Build integration and the brand new Teamprise Extensions for Team Foundation Build, which allows developers to use Ant scripts with Team Build - amazing! Even better, Teamprise Extensions for Team Foundation Build, including source code, is available free of charge to everyone. For more information, see Martin's announcement.
Have you ever had a production application in the data center act up, and you spend countless hours hunting down the source of the problem? If so, then then you might be interested in a new project on CodePlex called Design for Operations (DFO). For years now engineers have been designing physical products with ease of manufacturing in mind. Called Design for Manufacturability (DFM), this technique takes fabrication and assembly into consideration early in the design process. DFM has a significant impact by improving the cost and quality of a product. Well, a variant of the technique has finally found its way to the world of software. Called Design for Operations, this technique allows software architects and developers to design their applications with built-in, real-time health monitoring, giving the operations staff much better operational information and improving the quality of service. According to William Loeffler, a Microsoft program manager: It’s a recent effort from patterns & practices to provide tooling for architects and developers with a means to model their application in terms meaningful to operations. Once modeled the tool can be used to create a Health Model for the application and once the Health Model has been completed at the architect and development roles the tool can be used to generate platform instrumentation as defined in the model. All that’s necessary for the developer is to call the generated API within their solution for each instance of instrumentation. The tool will also generate a Management Pack for System Center OpsMgr 2008 from the model that matches the generated instrumentation. For more information see: http://www.codeplex.com/dfo Hopefully DFO will become mainstream in the software development discipline, in the same way that unit testing has become popular.
|