My team is using TFS2017 and we have some 100+ past iterations (sprints) in our backlog/board. (I'm talking about Past, Current & Future iterations). We're only interested in 5-6 most recent Past iterations and scrolling to the end of the list is generally annoying.
Is there any way to change the sort order of the past iterations to descending?
If this isn't possible, is it possible to create a new group/item/list/whatever besides Past, Current and Future, called Old iterations (or something like that)?
Thanx in advance.
To reduce the number of iterations on the "Past" section you can configure in the team settings to see only the iterations of the current year.
Press on the Gear icon when you on your team page --> Work --> Press on "Change" near the "Backlog iteration".
After that, you will see only the iteration from the current year and the scrolling not will be so annoying...
I have been using TFS to track my backlog items and I am now trying to write a query to see how long I took on particular tasks in the last 7 days. So Far I have this query:
Work Item Type = Task
AND State = Done
AND Closed Date = #Today - 7
AND Area Path = #Project
AND Assigned To = #Me
and have added the column "Closed Date" which shows the time work stopped on this item. But I cannot get any information as to when work started on the Task
Feels like the data should be there as on particular tasks it has the following kind of information:
Is this possible? I don't mind extracting the data to Excel to analyse.
The reason I ask is because I would then like to go on to compare the amount of hours assigned to a particular task and compare it to amount of hours actually taken to help my predictions of time taken in future.
It's a pretty simple query actually.
Here's what I'm using.
(Work Item Type = User Story
OR Work Item Type = Bug
)
AND State <> New
AND State <> Removed
Simply include the Activated Date, the Resolved Date, and the Closed Date in the displayed columns. The time between Activated and Closed is your total cycle time.
My team uses Resolved as a "pending deployment" status, so comparing Resolved to Closed allows us to determine how long it takes to get an item from "done" to "in prod".
TFS is not intended to be a time tracking tool. You could query the work item history with the TFS API and check the timestamps on when the state transitions occurred if you really wanted to.
Agile projects don't focus on how long individual tasks take -- they focus on how much value the development team is providing over the course of a set period of time. One thing might be estimated low, one task might be estimated high, but it ultimately doesn't matter as long as the team delivers what they committed to deliver.
It's a good practice to track Cycle Time for a team to discover areas for improvements (for User Story level, yes)
It's not good that user must go Excel to calculate Cycle Time. I can't use diagram Azure Devops tools with this calculations and its not automated.
Cycle Time widget don't shows results for several teams and it's not flexible tool, so it's not enough
I'm working on an iOS app for having a list of top 10 of everything.
So the problem I'm facing is how do I update the list every week ?
I thought of linking it to external links but then I was unable to format the webpage according to the interface of my app.
Lastly I want the app not only to display the top 10 list but also to be able to interact. For example if the user enters into top 10 songs then he should be able to play the tracks as well ! So for this I guess I'll be needing a database which I could update weekly. I don't know how to go about this. Please help !
You need a remote server, running with an application that handles the list generation/updates, and you will probably need also to manage a remote database, if you expect that the number of item will be reasonably large.
Your ios application will have to interact with your remote server using an API that you will have to define as well.
I'm sorry to be that generic, but the hard truth is that there is no quick or easy way to do it: you will need to learn and possibly develop every part of your system and then integrate them.
You have nearly an infinite number of options in terms of platforms/languages/databases to choose from, for the backend part.
Over the last few years, there have been services that should make handling the remote backend easier (Stackmob, cloudbase...) but it really depends on much control you want to have on the "lists" you want to manage.
I am trying to retrieve a list of opened work items for a given project programmatically. In searching through the web, the only way that I can see to do this is to use the WorkItemStore API and execute a query.
The major issue that I am having is that retrieving the workitemstore takes almost 2 minutes. I subsequently caches it, but the first hit is unacceptable. Beyond that, my application needs to refresh it every x number of minutes in case new work items are added.
Is there any way to get a list of opened work items associated with a project without using the WorkItemStore. I only need the work item number and optionally the title. I don't need any other information.
If not, is there something that I am doing wrong or something wrong with the TFS server (index missing perhaps) that makes the performance so slow. I have tried different ways of getting it by the way. They are all extremely slow.
WorkItemStore store = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
or
workItemStore = new WorkItemStore(tfsTeamProjectCollection);
or
workItemStore = new WorkItemStore(tfsServerName);
Any help in this matter would be greatly appreciated.
Even with an incredibly large DB you shouldn't experience two minutes delays.
I would load up SQL Profiler and take a look at the query generated to get work items. From there, you can probably identify what part of the query is causing the delay.
You can also consider running the query on the same box that the TFS DBs are on and see if that is the issue. As the comment above points out, remote connections can certainly cause delays.
If none of this resolves the issue then hopefully you can provide some more information like size of the project (shouldn't matter), TFS installation configuration (where are your servers and how are they setup) and what hardware it is on.
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
There are several tricks you can use, but none of them 100% fail save.
You can use some kind of licensing mechanism.
You can store the setup time somewhere hidden in the registry.
You can store the setup time in a file (possibly an executable file or dll).
You can store the IP address in a central database and check each time if the 14 days are passed (you need a internet connection for that).
You can create a file (for example a dll) dynamically on your server and have the installer retreive that file. (Be sure to log the IP so a second attempt will not be possible).
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).