On visual studio online there is an option to configure work areas. I created a project and it uses the "Microsoft Visual Studio Scrum 2013.4" process template.
I started entering work items into the project and found an option to configure work areas, I'm not sure how to use work areas in this context.
What is the purpose of a work area in the context of the scrum methodology?
Area's are a way to organize a backlog when you have multiple teams (teams then have their own area), multiple physical things that make up your product (web site, fat client, some kind of integration library).
Or, a very common usage, feature area's of your product (e.g. shopping cart, search, check-out, payment, user management). You can probably derive some of this from the PBI title or you're using tags for this. This leads to stories that include the work on all layers, which ensures that each story in itself provides value.
There is nothing in Scrum that directly relates to this, though many larger scrum projects use feature teams and try to break up the product in multiple of these area's to prevent teams from tripping over each other in the same piece of code. It provides the teams with clear focus and helps them in the refinement (because they don't need to know all the ins and outs of the whole product all the time).
In the past many teams used the area to denote technical area's of the product (front-end, business layer, database layer, database schema, webservices etc), which is considered not the best way to break up a backlog, as it often leads to component or layer stories that in themselves do not provide any value.
The official documentation can be found here. I think these Q's at the bottom of the page will help you as well:
* Q: What kind and how many area nodes should a team define?
You don’t have to add any area nodes. However, areas are useful to filter work item queries and reports based on features. Consider these guidelines when adding area nodes:
Define areas that support your traceability and security requirements.
Avoid creating an area structure that is too complex. You can create areas to partition permissions on work items, but complex trees require significant overhead for permission management. You might find that it is too much work to duplicate the structure and permissions in other team projects.
Each team can create a hierarchy of areas under which the team can organize their backlog items, user stories, requirements, tasks, and bugs.
Use areas to represent logical or physical components, and then create child areas to represent specific features. Your team can use this structure to keep work items organized and improve traceability by component or feature. (Remark: Be careful with this is it also reflects your team
structure. It may lead to delayed value.)
Create areas that you want to restrict access to.
* Q: How do I structure teams, areas, and iterations to support hierarchical teams or scale agility within an enterprise?
A: Although there is no concept of sub-teams, you can create teams whose area paths are under another team, which effectively creates a hierarchy of teams. To learn more, see Add another team.
Also, these two white papers can walk you through the steps for configuring teams, area paths, and iterations to support portfolio management or enterprise organizations:
Agile Portfolio Management: Using TFS to support backlogs across multiple teams and
Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs.
* Q: Is there a way to decouple teams from the team area path?
A: Yes. If your organization has several teams that work from a common backlog and across many product areas, you might want to change how teams are configured. By adding a custom field to represent teams in your organization, you can reconfigure the agile planning tools and pages to support your teams and decouple assignment to teams and area paths.
(Remark: this is currently not possible on visual-studio-online)
Related
I'd love to be able to create an interactive something like the picture below to include in an app - rows represent partners that we'd work with, and columns represent how many widgets they are assigned to build per month (those numbers come from the partner based on their resources, availability, etc.) The goal is to track how many of the expected widgets were created, how many were started and cancelled, etc. according to how mnay "slots" were allocated. Clicking on a "box" would cycle through the colors to indicate the status of that widget. All data would be stored in the underlying CDS entities.
This UI is familiar to my team, which is currently based in Excel, but want to transfer into a custom widget I can surface in our Model-driven App in CDS.
Any suggestions on a web UI framework/approach/etc. to help me get started? I don't want to recreate something that already exists somewhere, or start building from scratch something that there is a cool (yet unknown to me) UI framework that would make this easier than starting from complete scratch.
PowerApps component framework is the way to go. Typescript is the language to be developed on and Dynamics context awareness is main plus for this PCF control.
As far as I know, there is no control available for this. Check here
PCF builder is a good place to start the development.
I have requirement of preparing an in-house Project Management and accounting app using Microsoft Dynamics. My requirements are similar to what explained in the below page:
http://community.dynamics.com/product/crm/f/117/p/54453/98182.aspx
Can someone suggest that should we use ERP or CRM? And which one to use i.e. SL, GP, NAV, AX? And why?
CRM is probably the first choice to eliminate. Project management is usually an internally facing application, while CRM is by definition, externally facing. Secondly, if you need to maintain budgets, Dynamics CRM doesn't have anything built in for this (a general ledger for example).
As for the others, each will have its own costs and the extent of support you can get for any of them will vary depending on where your business is located. In some areas you may be able to get good SL support but no NAV or AX for example.
As for one you may not have considered, have you considered Project Server / SharePoint? If you need really heavy weight PM capability, Project may be your best bet. SharePoint can do some PM stuff. There's at least one book around by Dux Raymond Sy, published by O'Reilly. He's also done at least one webcast. Both are based on SharePoint 2007.
HTH
Of the Dynamics ERP products, SL is the one most focused on the project management (i.e. Project Accounting) space. CRM doesn't have a lot of project management capabilities built in, but is probably the most customisable and extendable of the dynamics range.
If you're after something that needs to cover the financial aspect of PM (e.g. billing, tracking costs etc) then you should look at the ERP options. If you're not worried about the financial side, then building a custom solution within CRM might be an option.
Came across this thread in a search I was doing. Hope Sukhminder Singh is still listening...
Sounds like you shouldn't abandon Dynamics CRM, a tool which your organization has tried and tested for nurturing customer satisfaction and turning it into ongoing revenue. On the other hand, you need to maintain a smooth accounting and billing relationship with the same customers - and for that, you'll need an ERP solution. As ccellar suggested NAV can do that, or even SharePoint, as suggested by Mike. I'll hazard a guess your organization already has SharePoint, too.
Now, what about the integration? You know, devising an effective, scalable, and future-proof way for getting MS folk to "talk" is quite a challenge! Also, you need a solution that places stress on human, as well as system workflows. The human factor can be decisive in time-critical projects.
Sukhminder, are you going to be coding solutions on either end? That's one way to go, though often, that option comes with high overheads: dragged-out coding projects, functionality that can be difficult to maintain, and even harder to modify, and serious concerns when one of the systems is upgraded or replaced.
From another angle--are you considering BPM? I'd urge you to.
BPM (Business Process Management) software suites are becoming an increasingly practical and mainstream option as an organization's central integration hub. BPM lets you rapidly map out and control mission critical processes involving multiple systems (as in your scenario). BPM lets you visualize the players, processes and apps over time, and when it comes to adjusting, remapping, and remodeling your workflows, you may have to do some coding, but a large part of the work can be done by experienced, non-programmer BPM users.
There are a bunch of vendors out there, each with its own pros and cons. For the job of connecting MS CRM and MS ERP/Sharepoint, here are 3 candidates I have come across.
Kofax's TotalAgility BMP integrates between Dynamics CRM and SharePoint, by leveraging SharePoint capabilities. The solution obviates elaborate coding by supporting workflows, rules, and user screens. It "orchestrates" processes between itself and other MS and products, most notably SharePoint, CRM, Lync, Visio, Outlook. They enable "in-flight" process change and dynamic BPM, so that down-time on your production is minimal. See the data sheet.
Sequence Business Process Management from PNMsoft. Provides integration with systems from many vendors. The forte is on human-centric processes, with a strong bent for Microsoft products. Sequence lets you integrate with existing systems using wizard-based connectors. When your organization changes, Sequence lets you "hot-swap" your business processes fast, without down time in your production.
MuleSoft's CRM-ERP integration. Their strong point is application integration, for connecting (legacy) systems from a range of vendors, including SAP, Oracle, Salesforce.com, and MS. The Mule ESB is a lightweight integration platform. It comes with a library of connectors to quickly create connectivity with all systems and services, whether on-premise or in the cloud. When adding or modifying an endpoint, you can easily update your integrations to reflect the change.
HTH some....
I'd start off at the Microsoft Dynamics site and explore what each product has on offer. They even have an ERP selector tool for you to try out with just a few questions. Why not contact Microsoft yourself and they could provide a list of potential partners that work in your area - it will be an important decision and they would better guide you through the selection process.
After a few projects which also had an accounting part, I would not recommend to use Dynamics CRM (at least for the accounting part). That's not what it's meant for and you have to spend much effort to get to a level of Dynamics NAV for example.
On the other side: why not combine both systems and use their strenghts.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
What is the difference between a Program Manager and Product Manager? Is there actually a difference in the roles/responsibilities or our the terms mostly used interchangeably.
The difference is usually that the program manager handles the whole series of related products, their schedules, budgets, etc, and the product manager handles just the internals of a particular product such as scheduling of individual components and dividing team tasks, as well as leading the particular product team.
Usually, product managers report to the program manager, and the program manager has the final say on budgeting for each product team and the scheduling. The product manager then takes the resources he or she has and divides them amongst the team, coordinating the team's efforts.
Depends entirely on the company. Microsoft, for instance, has its own rather unusual definitions:
Program Manager = one of the members of the core technical staff (alongside developers and testers). Typically responsible for designing & specifying features, planning release cycles, triaging bugs, presenting at technical conferences, managing compliance with technical regulations (internal & governmental), connecting with online communities, and more.
Product Manager = basically a synonym for "marketing suit." They design the product's ad campaigns, sales website, and related swag. More generally, they define the "message" that they hope people (mainstream media, word-of-mouth, and everything in between) will associate with each release.
Both positions gather a lot of data about where the market is heading -- Program Managers from their relationship with the technical community, Product Managers from their industry & media contacts -- but the ultimate decisions about what to build are made by someone higher in the chain. (not the nitty gritty, of course; Program Managers & UX designers are the experts at specifying the details. thinking more of "vision" / "value props" that individual product subunits then go "align" themselves toward)
AIPMM and PMI, two professional organizations in these fields, have both defined unique knowledge areas (KA) associated with their professions that can answer this question. Both product and program managers must master their unique KAs and manage the activities and deliverables associated with them in order to successfully complete their products or programs.
PMI has defined 9 unique project management KAs required to manage projects and programs. They are: Integration, Scope, Time, Cost, Quality, Resources, Communication, Risk and Procurement. Programs are collections of related projects but still require mastery of the 9 unique project management KAs.
AIPMM has defined 6 unique product management KAs as part of a universal, cross-industry Product Management Framework (PMF) required to manage products. They are: Customer, Strategy, Product, Market, Business, and Program. The Program KA involves the management those cross-functional projects required to bring products to market. (and very often the Program Manager is a member of the cross functional product management core team).
Hopefully this explanation has introduced some clarity and consistency into the discussion. For more information on the AIPMM unique KAs and the PMF, go to the www.AIPMM.com web site and download the APMF whitepaper.
[1] http://en.wikipedia.org/wiki/Association_of_International_Product_Marketing_%26_Management
My trick is to change "manager" to expert and see how the titles work. So a product manager becomes a product expert; a project manager is a project expert. See "managers as experts" at http://www.pragmaticmarketing.com/publications/topics/06/0603sj
A product manager ensure product profitability by finding and quantifying market problems. He or she defines the business, technical, and marketing artifacts to move an idea to the market and to profitably revenue.
They're different. But definitions will vary between companies.
Generally a product manager has ownership for a specific product. He or she is responsible for working with the customers, sales people, engineers and sr management to figure out what is the best product to be created, determining the time schedule, features, etc.
The program manager is often more of a support person, keeping all the wheels turning, especially working with specialized groups such as manufacturing.
In other firms, the program manager is senior to the product managers, with responsibility across a series of products.
At a former employee of mine that did both defense contracting and product development, program managers and product managers had a peer relationship on the organizational chart and were both subclasses of "project manager".
Program managers were project managers that managed the projects associated with on-going government programs with which we either had direct contracts or were working as subcontractors under another organization. A large enough program could have multiple project managers working under the direction of a program manager.
Product managers were project managers that managed work associated with product development -- this included the "product owner" role associated with Scrum.
Product managers are the voice of the customer and are accountable to two things: profit & loss of a product or product line and positioning. Product managers are a horizontal role and work as mini-CEO for their product.
Since a product is "what people think you sell," product managers generally have influence over anything that impacts that idea from customer experience to technical definition.
Program managers are project managers that are responsible for several projects related to a specific initiative.
Microsoft Team System appears to be a great platform for process-oriented systems implementation, however if you strip out access for the BAs, PM and Business Users and just purely use it within a Dev team does it have any more value than just using Visual Studio Professional, SourceSafe, a Defect Tracking Tool and a continuous integration server like CruiseControl or TeamCity?
Yes. Every replacement technology you've mentioned is something that is supported by the Team System package (either in this release or the next). All of these components are designed to integrate and work with each other in TFS. This is a high priority of the TFS team for all components. The result is a set of features which in most cases seamlessly integrate with each other.
I'm not familiar with several of the other projects you mentioned but it's unlikely that they integrate as well with each other as the corresponding TFS components. This is not to say they have no integration or perform poorly as products. Just that they are not designed ground up to work with each other. Hence the interaction will not be as crisp as the TFS components.
Is this valuable enough to continue using TFS? Don't know because it would be highly dependent on how much you value this integration.
One of the big selling points for TFS for my team is the coherency it provides to our overall product life cycle. We do allow BAs, PMs and Business Users to have certain levels of access to TFS, but even if we did not, the product would still be of great value to use. The ability to manage our workflows within TFS and enforce consistency across the development team is great.
Some of the features that TFS provides that we use: security, reporting, work flow management, integrated builds, email alerts, branching / merging.
Could you pull it off with a hodge-podge of other tools? Probably, but it wouldn't be as easy to manage and maintain and you probably wouldn't be able to pull out the kind of data necessary for reporting and tracking the way you can with TFS.
On a sidenote, if your counting on Visual SourceSafe as your repository I would highly suggest looking elsewhere. From personal and business experience, I can attest that it cannot be counted on as a stable/robust repository.
My thoughts.
Sure it has value. There are a ton of client features only in the Team SKUs (don't let the name fool you -- they are primarily just the new "super premium" kitchen-sink versions, that also have the nice bonus of including a server CAL for TFS.) Exact specs available here: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx
Looking specifically at the collaboration features, again there's clear value in a system whose components were design to "just work" with each other. The setup is streamlined (though it has a ways to go); the UIs are consistent and accessible from each other; the backend feeds a unified reporting/analysis service. If you have a large team, the overall perf/scalability also far exceeds what the typical OSS suite is capable of at the moment.
The question is whether it's worth the $$ to you. Why use Visual Studio Professional instead of SharpDevelop? Why SourceSafe instead of Git? Why not Notepad and specially labeled folders?
All of the commercial products are commercial for a reason (ok, maybe not SourceSafe!). If you want something with a broad feature set, tight integration, well-defined support & testing lifecycle, good fit & finish, etc then it's usually worthwhile to spend the $$ and let your development staff get on with their work. If you don't mind doing setup & troubleshooting yourself, switching between several applications as part of the development workflow, losing the ability to query & report on team statistics as a whole, etc then by all means go open source -- many OSS dev tools are very solid nowadays.
So I just started an internship with this nonprofit company and it's pretty cool. My first assignment was to find a type of program that would work well for the company and its users. I and some team members just finished summarizing down what I think is a good list for the needed functionality. Before I started working, I've never even heard of content/document/knowledge/project management systems. So I've done a bit of research on many other programs and I've narrowed it down to Joomla, activeCollab, Basecamp, sharepoint and a few more. Which program out there would fit my needs the best? It doesn't have to be from the list I just wrote, those are just the programs that popped up first when I started searching.
MUST-HAVE CAPABILITIES
Searchable
Keyword search
Advanced search: Ability to tag & search documents by different categories, for example, type of file (e.g. PDF, Word, etc.), service line (e.g., fundraising, strategy, etc.), type of document (e.g., deliverable, data set, etc.)
In-document search
Categorization
Simple navigation to browse all content
Simple to set up and modify the tree/hierarchy used to browse content
Workrooms
Provide each team a separate workroom to post their own documents
Easy to navigate from team workrooms to the Toolkits (best if team workrooms reside in the same system the toolkits reside)
Version Control
Ability to see which is the most recent file
Security
Password protected
Tiered security, i.e. certain permissions for certain users (to create workrooms, change navigation tree, change toolkits, view/post team files, etc.)
Multi-year support
Easy to “archive” old workrooms or files so the navigation doesn’t become cluttered over time
Share across workgroups
Ability for power users to access multiple team workrooms
Ability to send docs from one group to another—or to the toolkits (by simple tagging or simple “submit” feature)
Uploading
Ability to upload files to workrooms
Ability to submit a new file for consideration for a toolkit (not a file currently in any workroom)
OPTIONAL CAPABILITIES
Messaging
Opt-in notification of uploaded files or changes to existing files
Version Control
Ability to see who has the file checked out
External Access
Client access to certain documents
Within our website
Users gain access from our website
It looks like it resides on our website
Collaboration Tools
Team Calendar
Blog / Forum
Instant Chat
WebEx/Remote Presentation (for virtual team meeting)
Ratings
1-5 Star document rating (by user community)
Searching & Sorting documents by rating (best documents display first in search results)
Simultaneous Edit
Multiple people can edit the same document at same time
Workflow
Ability to tag a file to be reviewed by another user (ability to “escalate” a file for review by someone else)
Messaging alerts when a file has been flagged for a user
Most of the features that you mentioned above are available for free using Plone, which is an application that runs on top of Zope. I actually built and deployed an instance of Plone for a non-prof that had a lot of the features that mentioned above. They features might not have had the same names, but you get a lot of the same functionality.
Here's what my users really liked about Plone:
The ability to index the content of MS Office documents, so that people could search for documents based on content in addition to property and tags/keywords.
Usability. The default theme for Plone isn't the flashiest thing that you will ever see, but it's usability is excellent.
How easy it was the change the system and add new sites or functionality.
Here's what I liked about Plone:
Zero licensing costs. I was able to implement features that usually only come in very expensive systems for free. And I'm aware of these types of costs, because I administer FileNet systems for a living
It was very easy to install, upgrade, and administer. Please take that "pro" with a grain of salt if you're not a professional systems administrator :)
Overall, it was just very easy to work with.
And here are my cons:
If you need the web site to be accessible on the public internet, then your hosting costs may be higher-than-expected. It's definitely cheaper to set up a vanilla Joomla site than it is to set up a vanilla Plone site. Please note that you sound like you need a lot more than a vanilla content management system, so their may be no difference in hosting costs.
Plone is built on Zope, and Zope is an application server. It's easy to set up and use, but it works a little differently than a lot of other web and application servers. If you're used to administering a LAMP stack, then this will be different (but not necessarily bad).
One final con is true with all modern content management systems: don't give your users enough rope to hang themselves. When it take 2 minutes to a wiki and a blog to a web site, then users expect you to add new sites all of the time. Every new site adds a lot of administrative work to your plate, so try and get as much functionality as you can from each site that you add.
Hope that helps!
Tom Purl
Basecamp. Even if it doesn't have all the features you think you need, it does what it is supposed to (37Signals loves to rant about too many features, you aren't gonna need it (YAGNI), etc.)
Joomla is a pain. Activecollab is a poor clone of basecamp (unless it has changed drastically in the year or so that its been since I tried to use it to get out of paying for basecamp).