Follow Us on Twitter
by Sandy Gupta on October 27, 2009 08:00pm
It is great to see the work that started last year with the Eclipse Foundation at EclipseCon 2008 in Santa Clara, California continues its exciting journey.
Today at the Eclipse Summit in Germany, the Interoperability team at Microsoft announced a number of updates with our partners Tasktop and Soyatec. Microsoft is providing funding to these projects and architectural guidance.
Here are the goodies:
Windows Azure SDK for Java developers to facilitate the use of Windows Azure component by Java developers
You can get more details in the blog from Vijay Rajagopalan in Microsoft Interoperability team, who is leading this effort.
Ian Skerrett's blog also mentions a recent survey targeted at Eclipse users, which shows that more than 64% of respondents used Windows Server or Client as their development platform for Eclipse. These users are a mix of Java, PHP, Ruby and C/C++ developers.
This is good data to show why we care to make Windows the platform for choice for these Eclipse users. These are our customers.
Microsoft already participates in projects under both the Eclipse Foundation and Apache Foundation. A couple of weeks back I blogged about our participation and code contribution to the Apache Qpid project. We will continue to serve our developer customers in the open source world.
by Peter Galli on October 26, 2009 06:20pm
Great news on the data portability front: today, Microsoft announced that it will be releasing documentation for the .pst file format - the format in which data is stored in Microsoft Outlook Personal Folders.
Even better is the fact that the documentation will be released under Microsoft's Open Specification Promise when complete. This lets anyone implement the .pst file format on any platform and in any tool, without concerns about patents, and without the need to contact Microsoft in any way.
But it is important for me to point out that this documentation is still in its early stages and the work is ongoing. However, Microsoft is also engaging directly with industry experts and interested customers to gather feedback on the quality of the .pst technical documentation to ensure that it is clear and useful.
As an increasing amount of information is stored and shared in digital formats, it is vital for people to be able to reuse their data across various applications and platforms. Giving access to the documentation will facilitate interoperability and let customers and vendors to access their data in .pst files across a variety of platforms.
This is also just another example of how Microsoft is listening to its customers and responding to their requests for greater interoperability, in this case around data portability.
Also, enabling customers and vendors to access the data in .pst files on a variety of platforms allows developers to read, create, and interoperate with the data in .pst files in server and client scenarios using the programming language and platform of their choice.
"We're excited about the possibilities created for our customers and partners by this kind of effort, and we look forward to continued collaboration with the industry in our pursuit of improved interoperability with Microsoft Office," said Paul Lorimer, the Group Manager for Office Interoperability at Microsoft, in a blog post.
by saraford on October 20, 2009 04:11pm
In my first post for this series, I stated that "Agile is the single greatest things a team could do to significantly improve the user experience and quality of their website" and "not designing the full 100% is a true blessing in disguise." By putting these two concepts together, you can fully embrace the power that is Agile: Course Correction.
Making Design Changes in Waterfall
In the traditional waterfall, a Program Manager writes a specification, in which all members of the team and the associated business owners review and approve. Then, the development cycle begins to code to the specification word for word. Once code complete, the test team takes over reviewing the code to ensure it matches the specification.
But, what if half way through, someone on the team realizes the specification is wrong? Or more practically, what if the requirements change sometime during development? In my Microsoft experiences, this is called a Design Change Request (or a DCR), and it is extremely costly. New designs need to be made and reincorporated with the rest of the specification. Dev needs to re-code the feature. And the test team has to restart any prior testing, especially for regressions. In other words, DCRs are not good things.
Making Design Changes in Agile
One of the light bulb moments for me on CodePlex.com was accepting the fact that Agile is really just a series of mini waterfalls. Instead of designing a waterfall release cycle that will span the course of several years, you're only designing for a waterfall process of a few weeks. There's a Planning Phase, a Development Phase (which encapsulates the Test Phase, but is beyond the scope of this blog post), and the Deployment Phase. It's waterfall, but waterfall moving at an incredibly fast pace.
Now let's reconsider those Design Change Requests, but on an Agile team. The work is very, very scoped, which implies less ambiguity. (Yes, you could have a perfect specification that isn't ambiguous at all, but if that spec is 60 pages, the risk of human error is higher. Trust me, I've seen this, where I was the human in error.) And, recall that you're only doing 80% of the work. The cost of the design change is already accounted for in the remaining 20% of the development cycle. In other words, it's in the spirit of Agile that you're going to make changes along the way to better the product, or "course correct," as it was initially described to me. In agile, DCRs are good things.
Regardless whether you discover that you need to make a course correction during the Development Phase or the Deployment Phase, it's okay because Agile by its very nature can adapt and respond to these changes quickly.
An Example of Course Correction
Below is a screenshot from the original ratings and reviews designs. Notice how I circled the downloads count.
During implementation, a developer realized that the download count could be confusing. Did it mean total downloads for the entire project, total downloads for the release, or just recent (past 7 days) downloads for the release? We realized that given these designs we couldn't really convey the information we felt necessary to provide the right user experience to our visitors. So, we went back to the design and made a few tweaks. Again, we weren't trying to completely redesign the project directory. Even if we wanted to, there was no time to do anything radical. At the time the developer noticed this issue, we were going to finalize the build for deployment in a little over a week.
What we did instead was "course corrected" by making slight changes to the project metadata on the left-hand side to finish the current feature (or user story, if you're more aware of that terminology). Circled below is the metadata we added. We also added the * next to the number of page views and downloads, where we state at the bottom of the page "in the past 7 days."
Aside: CodePlex shows past 7 days data as a way of reinforcing release early, release often, which we continue today in the project directory. The screenshot below was taken at the time of this writing.
Conclusion of Part 2: Course Correction
This concludes my second post on Program Managing an Agile team.
If you like what you see, let me know! And if you don't like what you see, please don't hesitate to let me know. Seriously, I love discussing my Love / Hate Relationship with Agile development, as depicted on my personal blog.
Up Next: Putting it All Together - How the CodePlex team Builds Software
by saraford on October 19, 2009 02:16pm
Before I became the Program Manager for CodePlex.com, Microsoft's open source project hosting site, I worked on the Visual Studio team on four different product cycles. Since Visual Studio uses traditional Microsoft product lifecycle releases, I had to learn about Agile development alongside learning about open source development when I joined the CodePlex.com team. Making the switch from releasing every three years to every three weeks didn't happen overnight!
One of the things I discovered is that Agile is used a lot in open source communities. In fact, many of the people who I've worked with personally on learning Agile have strong roots in OSS. Also, the fact that Microsoft is starting to adopt Agile philosophies shows how the company is changing, becoming more transparent, finding more ways to connect with the community, and embracing other schools of thought. And this is why I am here, to be on the inside to push for these cultural changes within Microsoft.
Although Agile is the single greatest thing a team could do to significantly improve the user experience and quality of their website, I believe it can be quite challenging for anyone not in a developer role to get accustomed to. I hope that by sharing my experiences, I can help others in non-developer disciplines on an Agile team.
In this series of blog posts, you'll discover how I learned to program manage an Agile team after six years of waterfall (the traditional method of software development).
Three Major Takeaways
If I could go back in time, here are the three things I would tell myself about Agile.
1. Design and plan for the very next step.
It's not about reaching the moon, but getting out of your front door. Sure, you can design the perfect feature, but if it is going to take you six months to get there, it is useless to an Agile team. It's about designing the journey towards the perfect feature that matters.
2. Break down work into the smallest possible functional sets.
Adding work is fun and rewarding, but removing incomplete work due to a lack of development time is painful and risky. But, you can't deploy a half-written feature either. First, break down the work into the smallest pieces. Then, put together the smallest functional sets that have to be deployed together for the feature to make sense. Your development team will tell you how many sets they can do per release.
3. Design and plan only 80% of the way.
Not designing the full 100% is a true blessing in disguise. Since you have another release right around the corner, you have the time to collect user feedback and incorporate it into the next design. Not only does this solve the remaining 20% (getting you closer to the perfect design with less cost), but also allows your customers to be virtual members of your team.
The Program Manager Release Cycle
To begin, here's an Agile release cycle from the point of view of the Program Manager. For simplicity, this illustration only depicts a single release cycle, without any overlap of previous or future cycles.
Ratings and Reviews: An Example
To further illustrate, consider the ratings and reviews feature on CodePlex.com as an example. Users can rate a release and write a review for projects on CodePlex.
One quick aside about ratings and reviews: CodePlex users rate an individual release instead the entire project. For example, consider Stephen King as an author. What does it mean for me to rate Stephen King 4 out of 5 stars? I find some of his books to be awful, like the Tommyknockers. I want those 7 hours of my life back. 1 out of 5 stars. Yet, for me, some of his other books are incredible, like The Dark Tower. 5 out of 5 stars. Hence, we allow users to rate an individual release to provide more relevant information to potential downloaders of the project.
Let's explore the ratings and reviews feature step-by-step in the Program Manager shoes.
1. Design Phase Part 1: Limit the scope to designing the minimum to make the feature useful and meaningful. For ratings and reviews, the feature must have the following:
a. User can rate a release. User can view the rating.
b. User can write a review. User can read the review.
c. User can sort by highest rated releases in project directory.
2. Design Phase Part 2: Bucket into smallest deployable functional sets. For me, personally, I use sticky notes to illustrate the "must have" pieces for each set.
a. Sticky Note #1: Rate releases / View rating
b. Sticky Note #2: Write a review / read review
c. Sticky Note #2: Sort by highest rated releases
3. Iteration Planning Meeting: To start the development cycle, meet with the development team to discuss costing.
a. In the case of ratings and reviews, my devs said they could do Sticky Notes #1 and #2, but the project directory sorting feature would have to wait for the next release.
4. Dev Cycle: Because the designs are closer to 1-page specifications rather than fully-documented implementations, questions will come up from the dev team. This is where you, the Program Manager, will:
a. Answer any questions about the missing 20% of the specifications / wireframes
b. "Course correct" (more on that later)
c. Add more feature work if time allows
5. Deployment: The release goes live. Now you can collect user feedback and incorporate it into the next development cycle.
a. The very first tweet I saw regarding the ratings and reviews feature was "Sara, is there a way to sort by highest rated?" Here, I was able to ask the user questions about how this feature should work to confirm our designs. Most of the time we don't inform users what's coming up next (we like surprises.) But in this case, it was pretty obvious.
Here's the visual representation of the ratings and reviews feature in the Program Management agile release cycle:
Conclusion of Part 1: The Agile Program Management Cycle
This concludes my first post on Program Managing an Agile team. Since I could go on endlessly writing about topics I'm passionate about (and those who know me will confirm this is not an exaggeration), I'm going to pause here to conclude this initial train of thought.
Up next: The concept of Course Correction.
by hjanssen on October 07, 2009 12:06pm
Hello again! It has been a pretty busy couple of months for us, and I wanted to give you an update on what we've been doing.
We just completed the first step in another major milestone for Hyper-V. As you can read from Mike Neil's Blog, Microsoft and Red Hat just completed certification in each other's virtualization program.
This means that customers now can deploy Microsoft Windows Server and Red Hat Enterprise Linux and a range of select applications, virtualized on Red Hat and Microsoft hypervisor virtualization software, knowing that the solutions will be supported by both companies.
This again demonstrates Microsoft's commitment to its virtualization platform, and the Hyper-V team's continuous investment in interoperability and heterogeneity through the datacenter.
And I am very proud that my team has been working very hard on getting the Red Hat certification completed.
But, for my group, this is just the first step: we worked on and got certified for Hyper-V running Red Hat in emulated mode and, now, the next step for us is to get certification for enlightened mode, the mode where the guest OS is Hyper-V aware,and can thus access Hyper-V functionality directly.
So, what is needed for enlightened mode? Well, to get that step, we needed to get the Linux Integration Drivers submitted to the Linux kernel, and then we needed those drivers officially accepted in a mainline kernel.
This has now happened as well, as we have been accepted into the mainline kernel. We are in Linux Kernel release 2.6.32, and that release is currently going through development and testing. Once that one is final and officially released, we can take the next step, which is to get those official Linux Integration Component drivers certified with Red Hat.
The timeline for that is not completely set in stone right now, and I do not know if there is an official expected release date for 2.6.32 as yet. But we should be able to move forward with the enlightened mode certification soon after the 2.6.32 final release.
And we are, of course, continuing to work on the Linux Integration components, adding new features and all that good stuff. But I will write more about those items in the near future.