Is there a nice way in TFS to see all the Stories/Tasks I have worked on and what day I committed/closed them out and maybe did associated check-ins for them. I want this because I work on many different client projects and need to track my time in a time sheet and sometimes forget what I did each day if I don't fill my timesheet out daily.
There is no out of box feature for this. A similar feature request on VSTS User Voice can be found here: User Activity Stream.
As an alternative solution, there is an TFS Timetracker extension in VSTS Marketplace which you can try to use. This extension will allow you to record the time you spend on every work item and generate a report.
I believe TFS is unlikely to enable this capability in the nearest future.
You can try out time sheet extensions to TFS.
For example, TX Chrono (https://www.teamexpand.com/product/tfs-timesheet) allows to log hours directly from a Work Item tab in TFS and get a work time day-by-day breakdown over the selected period (So you can make a report where you'll see hours spent on a particular WI, how many hours were spent each day, WI current state, etc.)
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
Say, I use stripe subscriptions for my users with one plan which is $10 per month for 100 API requests and that's the standard price. However, if the user has used 150 API requests, I charge them $3 more on top on $10. For 200 and more requests it's total of $17.
Say, I've subscribed the user on October 9th. On November 9th they will be charged again by Stripe. When should I "freeze" the amount of the APIs the user has used during the month to calculate the overall price and start counting from zero again for the new period of November 9th - December 9th?
As far as I'm concerned, it's either on payment.success or invoice.success event in my stripe web hook controller. However, I think it's not reliable because:
Which one is it exactly - payment.success or invoice.success - the one I need? They occur both, as far as I know sometimes payment.success occurs first, sometimes - invoice.success and it's unknown which one occurs first in each particular case.
Theres's the time period between these 2 events, I don't know how long exactly, probably a few minutes. But during those few minutes the user might consume at least one Invoice
I'm not sure if it's guaranteed that for each user the events payment.success and invoice.success occur only once per month. Do they really? If not it's even less reliable to use them to achieve my goal.
invoice.created event occurs 1 hour before the Invoice is closed.
Um. Why wouldn't it be the moment your user clicked 'BUY'? The fact it took an hour/day for payment to be received isn't relevant is it? Think about iOS apps. I can buy the app right now, but most of the time I don't get an invoice from Apple for several days (even a week sometimes).
I think you're going to be frustrated trying to time it to events from your payment provider. IMHO that should be done within your app.
I'm not sure if its the best idea to create a background job that scans the database all the time for updated product prices, especially when in my application I expect to have 100,000s if not millions of products being observed for lower prices.
I have two models, Product and Price. a Product can have many different Prices. So the way I thought it should be done was:
Subscribe to a Product.
Create background job that scans database every hour for lower prices.
Notify users by email.
I'm not sure about #2 and if that's the best way for it to be done. What would you guys suggest?
If your Rails app is adding new Price objects to the Products in its database, why not have an ActiveRecord callback (after_create in this instance) every time a new Price object is added?
That ActiveRecord callback could start a delayed job to email the user about the new, lower price.
If it were me, I would use database triggers rather than a background job sweeper.
Here's an intro to triggers:
http://www.mysqltutorial.org/mysql-triggers.aspx
I'm looking for guidance on how to architect an elegant solution to what has become a bit of a thorny problem. Although I am using Ruby (and Rails) I think my problem is largely an architectural one, though my choice of language obviously has an impact in terms of suggestions involving libraries, etc., so the language remains relevant.
Anyway, in a nutshell: my application contains objects representing memberships, belonging to people who are members of fitness facilities. Memberships contain a series of recurring payments. Some memberships automatically renew at the end of their term, while others do not.
So for example, you may have a membership that is for an initial period of one year, and then renews month-to-month after that. In the application, creating a membership of this kind causes 12 recurring payments to be created. When the last month expires, so does the membership. A daily cron task is responsible for causing memberships to expire based on completed payments. If the membership is set to automatically renew, the same cron task will renew the membership.
You may also have memberships that have no initial term and simply run month-to-month or week-to-week. These work in a similar manner, minus the initial payment scheduling.
So far so good. What makes things complicated are the additional requirements:
administrators can "freeze" memberships (put them on hold), for specific durations, after which they automatically reactivate (e.g. to represent people who go away on vacation for a set period of time). I can choose to freeze a membership right now and have it reactivate later, or I can choose to schedule a freeze by setting the freeze date at some point in the future, as well as the reactivation date (note: there is always a reactivation date, which makes things a bit easier).
administrators can cancel memberships, either right now, or by setting a cancellation to occur in the future. (Future cancellations are not yet built.)
administrators can refund memberships, which is like a cancellation except any past payments are refunded.
What makes these difficult to deal with is the effect on recurring payments. When you freeze a membership, the recurring payments must "stretch out" around the freeze period, so that the period of time that represents the freeze is not paid for. This is both conceptually and programmatically difficult to handle. Payments, for example, may extend for different periods (i.e. each payment for someone who pays every other week pays for two weeks of a membership), and the date of cancellation may be anywhere within the period the payment covers.
For the freezes, I have taken the approach where the membership object contains some dates, namely "freeze_on" and "thaw_on" to handle the freeze period. However, the client now wants future cancellations as well, and I have noticed some bugs with the freezing functionality, which leads me to believe I need to reconsider my approach.
I am considering changing things so that future events can be scheduled but have no effect on the recurring payments portion of the application. The idea would be to queue up particular events. For example, a freeze in the future would be accomplished by queuing up a freeze event on a particular date, and a thaw event on a subsequent date (these two events would be connected into a single "scheduled freeze" from the user's perspective). A future cancellation would be handled similarly.
This approach has some benefits, for example, if you wanted to cancel a future cancellation (that's the kind of annoying, tricky stuff I'm talking about), you could simply remove the scheduled cancellation from the events queue.
However, I have the nagging feeling that I may simply be jumping from the frying pan into the fire. I'm wondering if anyone could provide me with some guidance on this issue. Are there design patterns or existing architectural principles for this sort of problem that I can examine?
An additional thing to note is that recurring payments for memberships with scheduled terms (i.e. not month-to-month automatically renewing) must exist as database records that can be edited (moved in time, price adjusted), so using temporal expressions (as Martin Fowler suggests) is not appropriate for this problem, so far as I know. I realize that my proposed solution of an events queue would not display to the user the changes that would happen to any existing recurring payments, but I think I can live with that.
not a scanlife bar code, it's a qr code
toronto, give us your creative people
Edit: To respond to the two great suggestions below (the comment boxes don't allow nearly this level of detail):
Kris Robison:
Yes, the freeze period can be an arbitrary length, although in practice I imagine it would be rare for it to be less than two weeks. But any solution should work regardless of the length of the period.
Yes, the renewal date changes - it is pushed forward by the length of the freeze. So if the freeze is two weeks long, it pushes the payment forward by two weeks. To make things especially tricky, in some businesses, the payments can only be withdrawn on specific dates - for example, some clubs only process payments on the 1st and 15th of each month. So when dates are pushed around, for these clubs, they have to "snap" to a particular date.
Can you explain in more detail why these rules affect event queuing but not management of subscription payments?
I'm interested in your amortization table concept. That's basically exactly what I have built already - a year-long membership with monthly payments creates 12, with weekly it created 52 - and each of these have an amount, tax, etc., associated with them, along with a state machine that governs "pending", "paid", "failed", and "refunded" states.
The part I am struggling with is how this table responds to events. Right now, if you set a freeze, it affects the table immediately by changing the dates of the payments. Set a freeze in the middle of the table, and it pushes payments forward. That sounds effective, but it's actually quite complex and hard to manage. How would your amortization table idea improve this situation?
Arsen7:
This sounds like the event queue I proposed originally. It seems obvious to me that you've worked with stuff like this before (I was impressed by your error check on the processing date, this is a great idea and one I intend to implement ASAP) so I'm hoping that you can explain your suggestion in a little more detail.
Specifically, I'm wondering how your concept would deal with the recurring payment situation I've described in my original question, and in the comment that I just left on Kris Robison's answer. If I have set up a schedule of recurring payments for a given purchase, and a freeze event is scheduled for right in the middle of the payments, would the schedule of payments remain unchanged until the date of the freeze became the current date, at which time the freeze would be instituted and the payments would move forward?
This strikes me as perhaps a great way to simplify my application, but I am wondering how users would perceive it. How would I indicate to them that the schedule of payments they were looking at when a freeze has been scheduled is no longer an accurate schedule, but will change once the freeze takes place?
Is it acceptable to apply a scheme used by banking, where you process all account operations once a day?
Every object may have a set of (future) operations, like freeze periods, and every day the object has to make a simple decision, like: "should I expire today or not?"
The good part is, that such daily processing is very simple to program. Also a strange renewal rules (in case you would want them) are simple to design: "is it Friday? is it the last one in this month? If yes, mark me as renewed, add some amount to required payment, or do anything".
That would be very costly (in terms of computing power) to calculate the status dynamically, every time the object is asked. If you store the current "account", you only need more complex calculations when you want to predict future state.
Consider it a pseudo-code:
def process(day)
raise "Already processed or missed a day" unless day == last_processed_day + 1
check_expiration day
check_frozen day
check_anything day
#...
self.last_processed_day = day
self.save!
end
RESPONSE:
Specifically, I'm wondering how your concept would deal with the recurring payment situation I've described in my original question, and in the comment that I just left on Kris Robison's answer. If I have set up a schedule of recurring payments for a given purchase, and a freeze event is scheduled for right in the middle of the payments, would the schedule of payments remain unchanged until the date of the freeze became the current date, at which time the freeze would be instituted and the payments would move forward?
This strikes me as perhaps a great way to simplify my application, but I am wondering how users would perceive it. How would I indicate to them that the schedule of payments they were looking at when a freeze has been scheduled is no longer an accurate schedule, but will change once the freeze takes place?
The "daily processing" scheme helps you with providing quick responses for questions which require complex calculations.
You have three "groups": current state (asked often), history (almost never changing, asked relatively rarely), and future.
Your daily processing procedure is not constrained to only update "current" state. If some event is scheduled for the processed day, the procedure probably needs to add "history" records.
If your users will often ask questions about future (and as you said, they will), the "processing" may also create a kind of cache for these questions. For example: find (calculate) the next payment date, and write it in a helper table (a schedule).
The main thing you need to do is to decide which questions will be asked by users, and whether you are able to calculate the responses on-the-fly or you need to have the answer prepared.
In a bank (it varies, of course) if you ask about your current balance, they may give you the answer which was true at the beginning of the day. "Better" banks will tell you that you had X$ at the morning, but now there are also Y$ waiting for accounting.
So, if you put a freeze record into the event queue, you may call a method, which will update the schedule at once. The same procedure (or a very similar) will or may be called in the daily processing routine.
Couple of questions come to mind:
Can the freeze be for time periods less than a month?
If so, does the renewal date change? Or how does the monthly payment get applied for the partial month?
Those affect how your event queuing system may work, but don't ultimately change the management of subscription payments.
One way to address subscription issues is to create an amortization table of subscription payments. If they are paying monthly for a year, twelve payments are queued up in the table. A weekly customer may have 52 payments in the table for the same year. Each time the renewal date comes up, after checking whether a freeze is in place, apply the next payment.
The amortization table keeps track of which payments have been made. If an account cancels, unpaid rows are refunded. If an account freezes according to your event queue, no payment is applied and the table remains static until the account is thawed.
Reply
It sounds like you have the concept of renewal date built into the amortization table. I use the amortization table more as a queue, and keep just the next renewal date with the subscription.
If the renewal date is inherent with the amortization table, then yes, it would be complicated to make changes as things go along. However, the renewal date should only affect the day on which you check to see if another payment gets applied.
If you are preserving partial payments while a subscription is on hold, and if a hold can be for an unspecified period of time, having the duration value on the amortization table lets you push a partial payment back in the queue in a "credit" state with a duration equal to the remaining time left in the payment. That way when the account is thawed, that partial credit is applied first and you calculate the next renewal date from the remaining duration.
Use some form of ordered list to preserve payment order at this point. It also comes in handy should someone ever want to insert a renewal period's worth of credit for customer service reasons.