Windows 8.1 camera feature: Photosynth
Just installed the windows 8.1 preview on my Surface RT … it is a must when you have a RT, really brings some additional value. one of these features is the Photosynth integration.
while it is always a kind of odd and funny when you see people taking pictures with the (low quality) tablets, the Photosynth features makes it really a nice activity.
The Photosynth button.
two view modes … use your finger
and tile mode viewing (move your tablet around)
really nice… and don’t laugh at me when I’m taking standing with my surface above my head.
side tip: you can take screenshots with a RT device by pressing windows key (on the device) and the volume key together.
Small Microsoft Test Manager Exploratory Test Tip for WinRT Apps: Action Log Sliced
A small but useful Microsoft Test Manager feature when executing an exploratory test on WinRT apps: Sliced Action Log.
As an addition to the steps to reproduce, you can look at the sliced action log to investigate the bug.
The extended action log can be found in the links tab of the Bug.
The only property to set is the Diagnostic Adapter ‘Action log’.
Fast and Flexible.
Modern businesses need fast and flexible IT. Fast in the realization of systems to stay ahead of the competition. And flexible in the direction the system implementation goes to easily adopt innovations which can bring business benefit.
A good practice for software development to stay fast and flexible is to take as less as possible dependencies. The well-known SOLID principles are a good example of this low-dependency practice to stay flexible. <<read on at labs.sogeti.com>>
Visuals Studio 2013 feature: Scrollbar Map Mode with Preview
A nice little VS2013 feature which can make your live easier… Scroll Bars map mode with preview.
the C# editor isn’t the only one which has it.
8 / 8.1 Store Apps creation capabilities of Visual Studio 2012 and 2013 Preview
Good to know…
- Visual Studio 2012 on Windows 8 Platform –> 8 Store Apps creation capabilities
- Visual Studio 2012 on Windows 8.1 Platform –> 8 Store Apps creation capabilities
- Visual Studio 2013 Preview on Windows 8 Platform –> No Store Apps creation capabilities
- Visual Studio 2013 Preview on Windows 8.1 Platform –> 8.1 Store Apps creation capabilities *
- Visual Studio 2012 and Visual Studio 2013 Preview side by side on Windows 8.1 Platform –> 8 and 8.1 Store Apps creation capabilities *
* With VS2013 Professional, Premium and Ultimate you can open and edit 8.0 Store Apps on Windows 8.1 Platform and retarget them to 8.1.
If you're opening your solution in Microsoft Visual Studio Express 2013 Preview for Windows, your solution won't load. In the next step, you'll retarget the projects in your solution.
If you're opening your solution in Microsoft Visual Studio Professional 2013 Preview, Microsoft Visual Studio Premium 2013 Preview, or Microsoft Visual Studio Ultimate 2013 Preview, your solution loads but still targets Windows 8.
Retarget your Windows Store app to Windows 8.1 Preview
* Install Visual Studio 2012 Update 3
Although team members work in the same room, still I see many collaboration challenges. Many team members need an extra motivation to start working together.
The Agile coach should explain and stimulate this.
Trust, courage, openes are good drivers to start with.
SkySight - a next generation cloud orchestration service
Capgemini announces SkySight - a next generation cloud orchestration service.
Capgemini, one of the world’s foremost providers of technology, consulting and outsourcing services, together with Sogeti, its local professional services unit, today announced a new cloud orchestration service called SkySight.
Developed with support from Microsoft Corp., SkySight will enable a wide variety of enterprises from multi-nationals to SMEs to integrate, configure, provision and manage cloud-based application workloads using a Capgemini-developed orchestration service.
Capgemini Announces SkySight - a Next Generation Cloud Orchestration Service
A Product Owner read up.
A small reading covering the role of the Product Owner in agile teams.
What does the theory says about the Product Owner’s role?
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product
Backlog management includes:
· Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Ensuring the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
(Scrum guide | http://www.scrum.org/Scrum-Guides)
The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team.
Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away.
A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF).
The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile Delivery (DAD) process framework.
(The Product Owner Role | http://www.agilemodeling.com/essays/productOwner.htm)
The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed.
(Learning Scrum - The Product Owner | http://www.mountaingoatsoftware.com/scrum/product-owner)
How to recognize a good product owner?
Collaborate with the team on an ongoing basis and to guide and direct the team.
Empowered, and present.
(Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner)
Passionately about the customer of the product.
(Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx)
What are the needed capabilities for a Product Owner?
A good product owner is a good negotiator.
(Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx )
Understand the technical decisions
(Transitioning to Scrum: Selecting the Product Owner | http://www.construx.com/Retrospectives/Transitioning_to_Scrum__Selecting_the_Product_Owner )
A thorough understanding of the customer needs
(Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner )
(Skills a good Product Owner should Master | http://blogs.agilefaqs.com/2012/05/26/skills-a-good-product-owner-should-master )
Knows the organization.
(Qualities of a great product owner| http://www.scrum.nl/website/scrumblog.nsf/dx/7-qualities-of-a-great-product-owner )
How to recognize good work from a product owner?
The first artifact of an agile to look at when you want to know how they perform is the Backlog, and investigate if it is nice, clean and mature. If you want to know if the Product Owner is in trouble the backlog is also the place to look. Are there enough backlog items, are they well specified, are there acceptance tests etc …and are there backlog grooming sessions, with the product owner?
The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.
(Writing the Product Backlog Just Enough and Just In Time | http://www.scrumalliance.org/articles/87-writing-the-product-backlog-just-enough-and-just-in-time)
Sometimes called StoryTime sessions, the purpose of these meetings is to make improvements to the Product Backlog.
(How to Hold an Effective Backlog Grooming Session | http://www.scrumalliance.org/articles/339)
Grooming the product backlog should be a collaborative effort that involves the product owner and the development team
(GROOMING THE PRODUCT BACKLOG | http://www.romanpichler.com/blog/product-backlog/grooming-the-product-backlog/)
What are the challenges when mixing roles or transform a role to Product Owner?
It's important to understand that a piece of work can be done better by one whole person than by two half persons. Merging roles can lead us into strange situations. But Scrum guidelines clearly state that there are three roles: product owner, ScrumMaster, and development team. Scrum also demands 100 percent commitment from each of these roles. So if we merge roles, then it's simple: We aren't using Scrum. We should always mix our primary colors at 100 percent, rather than using uneven amounts of a variety of colors, to aim for white. We should not live with gray.
( Why Not Merge Roles in Scrum? | http://scrumalliance.org/articles/524-why-not-merge-roles-in-scrum )
Developer as Product Owner:
Developers like to develop features, technical challenging features. Beside that you see these challenging features bubbling up the backlog also the challenge will be the low level acceptance criteria, just due to the optimistic and code view of the developer.
Trigger: Technical Items on Backlog, Scope Creep.
Testers as Product Owner:
Testers can be good critics of the backlog quality. For example, questions will be asked if the backlog items are good written down and if they have good clear acceptance criteria. Beside the quality view also a good understanding of the product and users will make testers an interesting mix with the Product Owner role. A pitfall can be that too much design up front, will testers want to tackle most of the unknown upfront.
Trigger: big too detailed backlog.
Manager as Product Owner
It should be interesting to have your manager as a Product Owner. But for sure it wouldn’t be a good idea. Probably the knowledge of the product will be low. But more important the manager is your boss and when the boss wants something else you as a team member will probably listen although it is out of the sprint.
Trigger: interference in the sprints
Business Analyst as Product Owner:
You often see that analysts is the Product Owner or that they become the Product Owner due to a missing Product Owner. Although they understand the system / product into detail, this isn’t a good idea. For analysts models / documentation are their primary artifact and often also single point of truth. This often results in the diagrams being the master over the backlog, which results in too many documentation and other challenges.
Old habit: communicating via documentation
(Where Do Product Owners Come From? | http://www.agilemodeling.com/essays/productOwner.htm )
Trigger: diagram first, too much documentation.
End user as Product Owner:
The end user knows what he wants, but this doesn’t make him immediately a good Product Owner. A Product Owner needs to be available for the team all the time and needs to make visionary decisions with technical knowledge, something an end-users can miss during their daily work.
Trigger: missing in action Product Owner, Scope Creep.
Scrum master as Product Owner:
Problems may arise when the PO is being pulled by the customer in one direction that is causing significant strife to the developers (because they need to build some other infrastructure first). The SM job is not to follow the whims of the customer but to protect the developers from their whims. Pulling this off objectively is hard.
(#in comment: In Scrum, why shouldn't the Product Owner and ScrumMaster roles be combined? | http://programmers.stackexchange.com/questions/106966/in-scrum-why-shouldnt-the-product-owner-and-scrummaster-roles-be-combined )
The Product Owner cannot be the Scrum Master. They both have clear interests and habits. Changing their individual habits is hard. Changing them so they can see both points of view is impossible. They first have to learn the new way of doing their job with agility.
(Product Owners not proxies | http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/)
Trigger: sprint interference.
What are the most common problems with Product Owners?
There is a big list of common Product Owner problems, for example when he is not available or that he doesn’t have the power to make decisions, or … see below a list of blog posts which covers them.
AVOIDING COMMON PRODUCT OWNER MISTAKES | http://www.romanpichler.com/blog/roles/avoiding-common-product-owner-mistake/
Product Ownership Antipatterns, or a character description of the PO from Hell | http://agile.dzone.com/articles/product-ownership-practice
Open Space Notes: Building a Better Product Owner | http://www.scrumalliance.org/resources/357
Your Product Owner Is Missing in Action — Now What? | http://www.scrumalliance.org/articles/509-your-product-owner-is-missing-in-action--now-what
Product owner training
Professional Scrum Product Owner Training | http://www.scrum.nl/training/Professional-Scrum-Product-Owner-Training-110224
CSPO: An Introductory Course for Product Owners | http://www.scrumalliance.org/pages/certified_scrum_product_owner
Testing in one week sprints, hierarchy backlog items and test coverage.
One week sprints are great and bring big benefits to you team and product.
The artifacts that are in your system will be; the backlog with nice small backlog. That small that they can be realized in the one week sprint. your sprint will contain a test plan for the sprint, with related product backlog items. Probably there also will be some additional test plans for other concerns/ risks. The regression test plan finally will contain a collection of test cases gathered from the sprint test plans and the additional test plans. And the customer will use a acceptance test plan for there work.
This works great. And, because the PBI’s with their corresponding test cases are that small the team will have the continuous discussion if the needed validation should be implemented with unit test technology/ automated test or, if it would be easier/ faster/ better/ higher ROI to specify and execute the test as a manual test. Work around testing in this way makes it a real team effort which makes it easier to get testing done in the sprint.
How should we test this PBI?
The test cases during a sprint are that small that also the regression set will become a collection of very small validations of the system. After several ‘one week’ sprints the bigger scenario / end to end test cases are missing. A collection of small validations made the team uncomfortable about the quality of the regression and unit test case set.
For example: when making several settings the system behaves in a different way. In our situation is was the backend connection with either SharePoint 2007, 2010, 2013 or O365. Making this setting and saving this setting was one PBI. The different behavior according to this setting where other multiple PBI’s. And the overall collection of settings (all different PBI’s) made the system behaves different. We needed an Activity Diagram to explain its behavior.
The decision to make use of Parent PBI’s is easy made (we called them Features and prefixed them with this name).
Related to these ‘feature’ PBI’s a feature test plan can be created, which will cover the full scenario and all path coverage's. in this way giving the team the comfort that all paths and scenarios are covered.
Finally ending up with a bit more complex organization, but with a better test coverage.
Feature PBI’s broken down in child PBI’s, which are partly implemented in a sprint. A nice additional benefit is that the team focuses on Feature PBI after Feature PBI, implementing them one after another. Activity diagrams support the scenario, and when needed use case or other UML diagrams. The overall scenario (activity diagram) is related to the Feature PBI and the different actions can be related to the child PBI’s. Testers can use their Test Design Techniques when analyzing the UML diagram for test coverage and test cases. And the regression set will be a mix of Sprint Test plan test cases and Feature Test plan test case.
Everything perfect. But the bit more complex organization of the backlog has its challenges. Not all PBI’s relate to a Feature PBI and often a PBI’s influences / relates to multiple Feature PBI’s. The one activity diagram per feature is fake and a theoretically example, the real world is more challenging. See also Martin’s post You can’t stack rank hierarchical work items?.
Although it will give you some extra backlog grooming activities, still Features PBI’s can bring benefit to the system. Don’t try to make it too perfect and definitely have testing knowledge in place for the coverage then it is a good thing to give it a your bigger systems.
6 Testing with Visual Studio 2012 Agile TMap _ The QUALITY A-Z Roadshow
The QUALITY A-Z Roadshow:
A full day overview, with demo’s and real world experiences of all the testing capabilities of Microsoft Visual Studio and needed testing practices.
1: Keynote: The Value of Quality
2: Test Planning
3: Test Specification and Execution
4: Test Controlling and Reporting
5: Test Infrastructure and Virtualization
6: Operations Integration
Feel free to ping me if you want to have these sessions delivered at your company.