We're starting a new development project using on-premise TFS 2018, git and Visual Studio. In the past we've followed the Agile model of creating epics and user stories and putting the requirements/ui mockups and other details directly in the user stories.
After living through that approach, we don't want go back down that road for the following reasons:
1) Once that feature is shipped, it becomes extremely difficult to locate the info. Who remembers what feature was done in what user story?
2) No centralized place to store feature documentation. Of course, we all don't want take the waterfall approach of spending 2 years writing feature requirements, but there is something to be said of having a centralized place organized by feature area that contains the relevant documentation.
3) Have you ever tried to read an extensive user story with requirements acceptance testing through either the web interface or through Visual Studio? It gets old pretty fast having to read through a 8 line window.
What we would like to do is do a hybrid of documentation and reference a link to the doc in the user story. The user story exists for sprint tracking, but the details are stored in the document. After the feature/user story has shipped, we can refer to the doc.
Therefore the question becomes how to store this type of info in TFS and link to it so it can open with a link in the user story. We know we can do this with SharePoint, but is it possible to do in on-premise TFS?
Currently, this is not directly possible in TFS with outgoing with some 3rd party vendors like Modernrequirements which will be paid services.
You could always use the CMMI template which is used for creating and managing requirement Workitems, but not for storing a huge set of requirements as you typically stored in requirement documents.
As you mentioned there are other ways like Storing the documents in
SharePoint, one drive etc., and link to the user stories
Creating a
markdown
in the user stories itself.
Check-in those documents in the version control(Git,TFVS)
Refer to this similar SO in order to understand it better.
Related
I am using TFS 2012/VS 2012.
I have five work items available to me: Bug, PBI, Task, Test Case and Impediment. I cannot figure out how to access user stories, and none of the information put out by Microsoft is very helpful.
I suspect the template that was used to create my project did not include them, but I am not sure. Is this true?
Can I alter my existing project to add user stories or requirements?
When creating a new project, which templates will automatically contain user stories or requirements?
Looks like you used the Scrum Template to create your Team Project. Only the Agile Template includes User Stories by default.
You can use the witadmin.exe tool to add additional Work Item Types to an existing project.
In Scrum PBI is the equivalent of a User Story (and in CMMI the Requirement is the equivalent of a User Story).
I am looking for a product that can solve a problem for me, and I hope you can help me with this ASAP.
I have a client which needs software modules to be integrated together, the following are the modules with what I think is the software that fulfills its goals next to it:
Document Management System (DMS): Sharepoint Portal.
Company Organization Structure (needed for workflows and used in DMS also): Probably custom development integrated with Active Directory and sharepoint portal.
Workflow Managment System (or BPM): Nintex Workflow.
The questions are:
Are the points above logical, or is there something missing.
Will it take too much time for development to integrate the Company organization structure with the workflow management and sharepoint, or is there a simpler solution, such as a built in Organization Structure in sharepoint or in Nintex Workflow?
I am still reviewing software solutions, I am not familiar with sharepoint, a combination of software solutions which lead to this product/solution I can use as a product later on for future clients is what I am looking for also.
For example, let's say we have a Leave request workflow process, the process is as follows:
Start -> Fill Leave Form -> Approve Form by CURRENT active manager -> save leave form data by HR team (on file or on separate HRMS) -> Close process
The organization structure is defined, and then the "CURRENT active manager" is defined for a group of people, the process will be built by a "workflow management system"/BPM software, the "Leave Form" can be a webform, or a template stored on a document management system.
I'm not familiar with Nintex Workflow however if your active directory information is up to date, in terms of the organisation structure and user details & groups, the organisation structure is probably supported out of the box by SharePoint.
Thus all that might remain is the workflow component which again could probably be created using standard SharePoint functionality, with minor customization with SharePoint Designer.
Having said that, configuring and installing SharePoint is not simple, and needs some thought.
From my experience with Nintex Workflows, it integrates really well into SharePoint and would work in a hierarchical company organization structure. If Active Directory is correctly set to indicate "bosses", "subordinates", etc, this information can be used within the workflow. For instance, "Send this workflow to my boss", followed by "send it to his boss", would be simple to program, since that information would be available from Active Directory.
Depending on what is needed, standard OOB SharePoint and Nintex can be used together to produce amazing workflows. One of the major advantages of using Nintex Workflows is that it can be used without programming. However, if programmers are available, additional logic can be added to augment a workflow (such as event-level programming).
We are researching the various options that exist in our environment to create an Employee Directory. We have a SharePoint portal, AD and recently moved from Lotus Notes to Exchange. Our current employee search is a custom Notes DB that has since been retired.
Since moving to SharePoint an year ago, we've used a custom list using SharePoint Profiles that are updated from AD. But the simple list interface isn't very user friendly and is very slow. Sone of the requirements include type-ahead, pictures, and details of skills/certifications and other demographic information etc. We are considering building an ASP.NET or SilverLight application that can consume the information in the SharePoint list. With the introduction of Outlook and the Global Address List, we are now wondering if it might be easier to build something within Outlook.
Has anybody traveled a similar path and what would you advice us to do?
Microsoft has a huge set of offerings for Collaboration and Social Computing in Sharepoint.
See this document, pages 8 and 9 for information about features related to an employee directory, including details of skills/certifications and other demographic information.
A la carte availability of individual features (such as People Profiles and People Search) and pricing may be an issue, but you may want to look into buying something rather than building it (if you can get the pieces you want for a price you can afford).
Sharepoint can connect with Outlook to keep the lists synchronized if you want to use outlook. And there are definitely a lot of different ways to change the way the lists are presented in the Sharepoint portal to make them more user-friendly. Having those details on the portal will certainly be a boon when combined with the powerful search and indexing features in SharePoint so you can identify employees based on their profile details easily.
We use the people search for this pretty effectively. We populate data in AD, then connect profile properties to AD attributes. That's only if you have MOSS, though. If you're working with WSS, you'll have to build something more custom.
One gotcha, though, is that the People Search out of the box doesn't easily do partial searches (i.e. searching for "john" doesn't match "johnson"). That's a big downer in my mind. You can use Ramon Scott's approach of a Content Editor Webpart with a form and some Javascript to work around it, and you can also get there via the advanced search box (albeit indirectly), but it sure would be nice if it were easy to make the default search box do partial name searches.
I recently just discoverd a somewhat easy visual basic script that draws information from the active directory where you can specify which OU to draw from where it displays all user information in a simple .HTM page. it includes a search bar, recognizes patterns (address) (company telephone number) etc... If you would like i can post it for you. you only need to fill in a few sections (display name for directory, OU, OU display, and tags) and you can always change the way things look too.
This should be taken care of by using the My Site feature that's available within SharePoint. You will then be able to search SharePoint users by skills, certifications, projects, and educational qualification.
Please refer to the SharePoint Planning and Deployment material on TechNet for more info.
SH.
This question already has answers here:
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki [closed]
(11 answers)
Closed 7 years ago.
Duplicate
Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki
I have been tasked with picking a wiki tool for a development organization, comprised of several different development teams. Sharepoint is installed and upper management would prefer this to be used, but in the past it has only used when PMs are forced to use it. None of the developers will update it with content that needs to be shared. I developed in Sharepoint and I liked it, so I have nothing against it. But for this to work I need something I can get everyone using, so Sharepoint will not work.
Step one is to convince management why Sharepoint will not work. We need the typical wiki features:
WYSIWYG, Clean interface, Easy to use, Attach Files to pages, Support for groups of users, Open source, Hosted Locally. (Maybe others I am not considering now?)
Can anyone provide a list of objective reasons why Sharepoint is not the solution we can use to take our first step?
There are many such products out there so step 2 should be easier.
SharePoint is the exact opposite of a wiki: A wiki is lightweight, easy to use, obvious, quick, doesn't get in the way.
To elaborate: A wiki allows your to jot down an idea quickly and moving details to the next page. In SP, people start to create processes, editing rights, workflows.
Wikis are designed to not get in the way. SP is designed to prevent you from doing "something bad"; whatever that might be. Wikis are driven by the idea that brainstorming works in open space while SP is driven by FUD: Who can see this information? Can it be used against me? How can I prevent someone to see/edit something?
Note: This is not a critique of SP per se; it's just how it used in most organizations. If you look at the security settings and edit rights, you sometimes feel like the workers of the company must all have been inmates in some high-profile prison (or should be).
I have absolutely no sharepoint-foo at all, but the sharepoint setup by IT at my employer has a wiki that we can use for documentation. Wouldn't that be good enough? Works ok-ish in firefox on mac, so I'm a happy camper.
SharePoint is best when using many of it's features (eg DM, WCM, workflow, collaberation etc) - you get a lot of it's benefits from the synergy of using all these things together with a common interface.
In any one area though, it's far from the 'best of breed' application - so, if you want a product for a specific job (eg a wiki), SharePoint isn't the most fully-featured/easy-to-use/delete-as-applicable product to be using - there will be products that do that (single) job far better.
You could also try looking at this question to see others experiences with SharePoint wiki's
I have used MediaWiki, Instiki and Sharepoint. Sharepoint does not work correctly with firefox on purpose. Its wiki functionality is an after thought. All kinds of additional features nobody use. But it does appeal to managers.
Instiki can be up and running in less than a minute and MediaWiki has everything you could need. Sharepoint annoyed most people on our team so nobody wanted to use it which meant a lot of knowledge was lost.
Which version of SharePoint are you using WSS 3.0/MOSS 2007 includes both wiki and blog functionality.
Although the SharePoint wiki isn't as feature-rich as most, the fact is that if your developers would not update a SharePoint wiki, chances are that they would not update any other kind, either.
I recommend creating a SharePoint wiki, and then actually reading the starting page, where it gives the definition of wikiwiki. I recommend only using a wiki (of any kind) for documents that can be written quickly, so that developers can get back to developing as soon as possible. Let the structure and accuracy grow over time. Just get the facts into the wiki quickly.
Wikis offer workflows, Document management and more too. I would disagree with those who say you can't do this in a wiki. Check out Confluence by Atlassian
We have had SharePoint where I work for a little while now, but we've not done a lot with it. We have an intranet with hundreds of ASP/ASP.Net applications and I'm wondering what kind of things can be done to integrate with SharePoint to make a more seamless environment? We put documentation and production move requests and so on in SharePoint now, but it pretty much feels like it's own separate system rather than an integrated tool on our intranet.
I've searched around to see what other people are doing with SharePoint but I've been finding a lot of useless information.
A great idea for you would be move your most used asp.net apps to run within the SharePoint site. Each app can be added either as a control directly on a pagelayout or integrated into a webpart (use the webpart to load child controls).
This would allow you to use the flexible moss interface to move the asp.net app into a unified information architecture so people can find the app easily.
SharePoint is really easy to roll out something that works, but creating a seamless intranet does require a bit of thinking outside of SharePoint itself (i.e. what should go where, which users need to see what, navigation structure...)
That is really a lot of work and requires lots of input from people outside the IT area.
A typical intranet portal segments functionality by department. Each department will probably have some custom web-based apps that you might have historically implemented in ASP.Net, and linked to from the intranet portal. With sharepoint you can start bringing the useful bits of those custom web-apps in as modular parts, so that the business owner of the portal can have more control as to how information is structured and displayed to his/her users.
Think dashboards, populated with custom metrics that only make sense to individual departments. That's one of the most obvious places to start. HR, accounting, IT, they all have metrics they want to track and display. They all have legacy systems that they might want to correlate information from. All this can be done in reusable web-parts. Since Sharepoint gives the end-user the control over layout, display, audience control, etc, you don't end up reinventing wheels all day.
SharePoint was designed to be a collaboration portal and document repository. If you have other business processes wrapped up in other internal web sites, you may not get much benefit from converting these sites into SharePoint sub-sites.
However, if there is signifcant overlap in your applications (contact lists, inventory, specs, etc.) you may want to make the investment to combine.
If you have InfoPath, you can create online forms. You can share your docs and edit them online. You can start an approvement workflow on these docs. You can create polls. You can create work groups.
Basically SharePoint is a giant and robust document store, but you can do anything what you can do in any ASP.NET web application. You can create e.g. custom workflows to automate business processes. We've worked for several customers to create corporate intranets and sometimes internet sites, so it really works. :)
But sometimes it's very hard to implement the requested features (a lot of workarounds).
Really its an intranet in a box. We pretty much run all of our day to day development tasks off of it. We keep documentation, track defects, manage people's time off etc. You can migrate your asp.net and asp applications to run under the sharepoint site. In the adminstration section you can set up web applications to run under the same site, but outside of sharepoint's control. That would probably help with the "feel" of it being completely seperate.
Sharepoint is really a shift in the way people have to think about web development and that's the key. You're no longer developing a standalone application, you're adding on to an existing framework. I would put it akin to having "silos of data" vs. a centralized database system which houses all the company's data. Once people realize that everything is connected, it will feel more like a seemless integration. My advice is to actively try and create applications in sharepoint and think about how to migrate existing apps on to it.
How about BI and reporting from an ERP?
When we know IE is uncapable to handle a page with 10000 table rows (without pagination)
Many don't realize but the success of a reporting tool depends on the performance of the grid object used - Excel and the SpreadSheet obj from the defunct Office Web Components are still the #1 in user's (accountants, managers, ceo) choice.
I think it depends on your environment. In our environment, we setup each department with their own pages and we use it for basic information, surveys, and the employee's homepage. We've built Google/Live Search and Weather.com widgets and roll RSS feeds using Tim Huer's RSS control.
One thing you can do is to create web parts to provide access to data from existing applications. Initially they could simply be read-only views, but depending on your experience they could be fleshed out to allow writes.
Another idea is to add links between SharePoint and your applications (assuming they're web based); that will at least allow a flow between them.
I haven't done it, but you could also theoretically skin SharePoint to look like the rest of your intranet.
Create libraries
Form libraries, documents libraries, slide libraries
Create standard or custom lists
Standard lists - announcements, tasks, contacts
Custom lists - suppliers, contractors, inventories, orders
Setup secure team discussion areas
Build shared team calendars
Create simple workflow processes on documents and lists