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
It says:"Attractive pricing: the most favorable of 5% or 1.9% + 30c (USD) per transaction is automatically applied."
Is the pricing attractive for me or for Google?
So for $1 how much will I get and how much google?
Will I get it on 5% schema(Me=95cents, Google=5cents ) or 1.9%+30c (Me=68cents, Google=32)?
It's attractive to you. Developers complained to Google that 5% charge for microtransactions (small transaction) was attractive (i.e. beneficial) to them (the developers), but that as amount increase, they don't want to pay 5% which is a lot.
So they changed their pricing to benefit you, the developers and call it "Attractive Pricing". With this new pricing, you could be charged as low as 1.9% (and not the blanket 5%) for larger amount transactions. Here's more details on this.
Via: Updates to Google Wallet for digital goods including attractive pricing and subscriptions support.
First, we’ve heard feedback from developers that 5% transaction fees
are great for microtransactions but not as attractive for larger
transactions with higher order value. To improve your experience
*selling higher priced items*, we’re introducing 1.9% + $0.30 (or local
equivalent) pricing in addition to the current 5%. Google will apply
the option that charges you the lower of the two possible transaction
*fees for that order*. Learn more and see examples of when each pricing
option will apply in the Help Center.
Related
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 5 years ago.
Improve this question
Can someone explain how I can configure Azure cosmosDB to not be so expensive? 30€ for 3 days??
It's a small test environment with very few users.
In the backend, I only see that it will cost some cents ...
Here is my Cost overview:
I have around 18 collections but all are only kbits big.
It the backend database for the js cms : http://keystonejs.com/
Example scaling for one collection in azure:
The problem is that you are billed by collection. So even if you use only a little storage space and you make only a couple of requests, you have to pay the minimum RU per document collection.
You created 18 collections, meaning you have 18 billable database constructs. And with the lowest-cost collection starting at roughly 20 Euro per month (about 5 Euro per 100 RU per month, minimum 400 RU), the math works out: You basically created an environment with 400*18=7200 RU. Perhaps just use fewer collections to reduce your cost footprint (note: collections have no rules around documents being homogeneous). You could use a single collection, since you have such a low amount of data.
EDIT FEB 2018 - note: with database-level RUs (a feature added a few months after the OPs question was posted), the cost model would be very different. 18 collections would be able to share an 1800RU database-level allocation (the minimum is 400RU, up to 4 collections, then 100RU per additional collection). With database-level RU, the cost of an 18-collection configuration would start at 25% of the original cost, based on 400RU per collection.
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 6 years ago.
Improve this question
Recently, Azure DocumentDB came out of preview and is available in General.
I wanted to know how the pricing is set if I have a DB with Two separate collections in it? Currently, the Pricing Calculator doesn't show Document DB in it.
Say S1 pricing is $25/month and I have one database with two collections on S1.
So will I be charged:
a) $25, since I have one database
b) $50, since I have two collections
I had a hard time getting information on how the DocumentDB pricing works. After lots of emails and support requests, I found that the pricing is based on per collection basis.
So, if I have a DB with say two collections in it and each with a performance tier of S1 i.e., $25/month.
Then, I will be charged
$25 x 2 = $50
In case, you go higher on the performance, say one of the collection was set for S2 and one remained in S1 then the pricing will go as
$50 + $25 = $75
Also, note that you will be billed the flat rate for each hour the unit exists, regardless of usage or if the unit is active for less than an hour.
For example, if you create a unit and delete it 5 minutes later, your bill will reflect a charge for 1 unit hour.
For more FAQ on DocumentDB, you can check the FAQ section in this link.
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 5 years ago.
Improve this question
My team have recently gone to sprints and we are going through breaking down our user stories into tasks. What is the best practice in breaking down the user stories?
Should each task include developing, design, testing, and so forth? Or can the tasks be individually broken out? If so, should the tasks that aren't testing related just go straight to done and skip "Verify" or "To Test" column in the workflow?
From what I've read online it seems there is no 'set' way and people do it differently. I'm curious if people have had problems with their way of doing it.
Any help would be useful!
What is the best practice in breaking down the user stories?
Splitting user stories: the hamburger method
Elephant carpaccio
Should each task include developing, design, testing, and so forth?
As you wish. Maybe, you can test feature, not a task. But testing of small peaces (task) is easier, than whole feature (if it possible). BUT sprint product should be tested as well.
+1 for the Elephant Carpaccio :-)
The goal is to understand the power of thin and vertical incremental developments :
Thin : the smallest code is written, the less code have to be changed for future stories
Vertical : each story should change any part of the n-tier
architecture
code (presentation, logic, data), so that each story delivers
immediate business value
I facilitated it and met his creator (Alistair Cockburn). This game/exercise is really interesting for teams facing customers with frequent change needs and small cash funds.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
It seems that both these terms get thrown around a lot. Both, I think, describe the same idea. Which was established first?
Also, it seems like some people describe it as a good thing to have a low x factor, while others describe it as a good thing to have a high x factor. Which is it?
You want a high truck/bus factor:
Truck Factor (definition): "The number
of people on your team who have to be
hit with a truck before the project is
in serious trouble"
(From: http://www.agileadvice.com/archives/2005/05/truck_factor.html)
i.e. you don't want parts of the code that only one person knows how it works or only one person can extend/maintain. Knowledge should be spread amongst the whole team via things like wiki info and pair-programming.
Wikipedia says bus number is "more commonly known as truck number" But in the US, "hit by a bus" is practically an idiom, while "hit by a truck" is not (although either phrase is easily understood.) Regarding high/low being good, the wikipedia article says:
"High bus numbers are good (with the
best case being equal to the number of
developers on a project). This means
all developers understand the codebase
more or less equally. A low bus number
(especially, one) represents a high
risk."
I'd add to what #cartoonfox said: Promiscuous pair progamming is a good way to distribute critical knowledge around a team so that the truck number is as high as possible. If you don't swap pairs often and with many different team members, knowledge isn't distributed very quickly.
The Truck Number (or Truck Factor) is the number of people with key knowledge that you cannot replace i.e. if that number of people went simultaneously under a truck you wouldn't be able to carry on developing.
I believe that certain chemical companies forbid key members of staff from travelling together for this very reason...
Discussion here: http://c2.com/cgi/wiki?TruckNumber
Here's a story about Bill Atkinson being the one key person in the Mac's truck factor - one of the key people that worked on QuickDraw during the early days of the Mac. Had a car accident apparently and people were concerned that he wouldn't be able to finish his work on the Mac's graphics software:
http://folklore.org/StoryView.py?project=Macintosh&story=I_Still_Remember_Regions.txt
A high truck number is better - i.e. it's harder to wipe out that many critical people at once...
A low truck number is worse - i.e. there is a greater risk that a few critical people could be ill, or leave or die, leaving the project in a state of unrecoverable collapse.
Pair progamming is a good way to distribute critical knowledge around a team so that the truck number is as high as possible.
The principal is the same, whether you call it:
bus number
truck number
bus factor
truck factor
et al
Also, the principal is the same whether or not you describe it using a higher number as being better, or a lower number being better:
A high bus number is good if you are describing the number of project members who could be hit by a bus and have the project survive;
A low bus number is good if you are describing the number of project members who survive a bus crash and have the project survive.
I did look into it once upon a time, but I don't recall which came first (see #Paolo's answer). Regardless of which came first, I have experienced enough confusion about it that I make sure all parties are using the same version of the number, high or low. ;)
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 8 years ago.
Improve this question
How do you charge your customer in a project using agile methodology?
Per hour? Then a great deal of trust has to been established before the project.
Per iteration? There's gonna be a lot of budget decisions, which can take time.
Per project? How can you do that when you don't know the scope? The very essence of agile is to not write a big upfront design/specification.
You charge your customer on the base of the terms defined by your contract that will be slightly different from a traditional fixed bid contract. Let's call that an Agile contract.
Some options are discussed by Alistair Cockburn in Agile contracts.
Another great resource is 10 Contracts for your next Agile Software Project by Peter Stevens.
Mary Poppendieck also has great material on this topic. See agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. More here.
Short answer is, you won't. There are a few services companies that are making headway doing it, but it is a difficult path. Your ability to sell the methodology and convince the customer you can deliver will be high.
Customers don't want to risk paying for a solution that will never be delivered.
Typical approaches to this problem are to put "will not exceed" cost. However, if you can't control scope, you are the one taking all of the risk.
In short, you are looking for customers that would have signed up for T&M (time and materials) contracts before Agile became the latest fad (I'm part of that fad, but it is just one in a long line of development processes. Aspects of it will continue to grow and some permutation of it will have a different name in a few years).
If your customer has already bought into the use of an agile methodology, then you have a reasonable framework for negotiating price per iteration. For example, you know:
How long the iteration will be.
How many people will be committed to work on the iteration (and their rates).
An approximate scope of work.
A process for delivery and acceptance.
That's a lot more evidence on which to base pricing decisions than is available for most fixed price contracts.
If the agile methodology is purely an internal development process that doesn't involve the customer, then it's unlikely to have much effect on the pricing negotiation between the supplier and the customer. There is an argument that says that a process that doesn't involve the customer in setting scope and expectations at least once per iteration isn't agile at all.
Regarding Mark's comment, there is a very common pricing model based around fixed price contracts with loosely defined scope and optimistic schedules. A common outcome is that both supplier and customer find that their initial optimism was misplaced. Both end up negotiating from weak positions over the things that really matter to them, and both end up unhappy.
Some of the techniques that work well in managing this type of contract are very similar to those used in managing agile contracts (frequent delivery, horse-trading on scope, priorities & price, frank communication, ...) the main difference is that these aren't built into the original agreement, and the contract may not be flexible enough to accommodate all of them.
My 2c as a non-agile practitioner...in a quest to know more...
If you are doing a specific project for a customer, you will need to know the scope of the project to provide a cost and a timescale. The cost of producing this scope of work is more often than not part of the discovery of the project, you either take a hit on this to get the work or charge for this (explicitly or implicitly) In this case, a project cost can be worked out and agreed. Im this case the project is usually broken up into various stages.
Although agile may be iterative and not require a full specification; a goal, at least is certainly required. There must be some form of basic specification/requirement. It may be that you need to break the project up into smaller goals and apply costs accordingly.
The iterations I suspect are more to do with the development methodoology, ie to achieve the goals?
If there is not enough specification to produce a definitively accurate cost, I would say that a "estimate" should be given but work should be charged at an hourly rate as I would assume that there would be greater changes in the decisions made on the project over each iteration.
I've seen it work well when approached in 2 phases:
Phase 1) Inception (timeboxed)
A timeboxed inception period with the client to scope the project. (A one month intense inception for a project estimated to last a year is about right.)
Outputs to this phase are a full backlog of sized user stories, an estimation of flow rate per dev pair, and parameters to estimate project costs based on the number of developers and overheads of having larger teams.
The inception provides a useful budget estimation that can be tracked throughout phase 2, a clear shared vision for both client and supplier, plus the option for either side to walk away. This isn't upfront design, the stories have just enough detail for a lead dev / tester to assign relative sizes.
Phase 2) Delivery (time and materials)
A delivery contract based on time and materials, with budget estimates based on the outputs from the inception phase. The trust built up in phase 1 is vital to making this work. Because phase 1 delivered relative sizing of the entire backlog, by regularly measuring actual flow it is possible to easily and frequently report projected flow rate for the rest of the backlog with increasingly accurate estimates of budget and delivery date. The supplier should be contracted to report these stats at least every 2 weeks, with the option for the client to walk away at any point.
By paying for time and materials, the client is free to change the scope and proirity of the backlog, and is therefore in control of the budget. They are encoraged to prioritise their highest priority / highest risk stories first, and by allowing them to walk away whenever they like they should experience a positive return on investment at all times.