https://github.com/yegor256/est
Estimates Automated
https://github.com/yegor256/est
estimate programmer risk ruby skills
Last synced: 2 months ago
JSON representation
Estimates Automated
- Host: GitHub
- URL: https://github.com/yegor256/est
- Owner: yegor256
- License: mit
- Created: 2014-12-18T20:50:54.000Z (over 10 years ago)
- Default Branch: master
- Last Pushed: 2025-03-13T23:11:40.000Z (3 months ago)
- Last Synced: 2025-03-22T21:07:06.179Z (3 months ago)
- Topics: estimate, programmer, risk, ruby, skills
- Language: Ruby
- Homepage: https://rubygems.org/gems/est
- Size: 111 KB
- Stars: 13
- Watchers: 7
- Forks: 3
- Open Issues: 8
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
README
[](http://www.zerocracy.com)
[](http://www.rultor.com/p/yegor256/est)
[](https://www.jetbrains.com/ruby/)
[](https://travis-ci.org/yegor256/est)
[](http://badge.fury.io/rb/est)
[](https://gemnasium.com/yegor256/est)
[](https://codeclimate.com/github/yegor256/est)
[](https://coveralls.io/r/yegor256/est)
Install it first:
```bash
$ gem install est
```
Run it locally and read its output:
```bash
$ est --help
```
Every estimate should be in its own file, with `.est` extension (YAML format).
Here is an example of an estimate file `simple.est` for a simple web app:
```yaml
date: 19-12-2017
author: Yegor Bugayenko
method: champions.pert
scope:
1: basic Sinatra scaffolding
2: front-end HAML files
3: SASS stylesheet
4: five model classes + unit/integration tests
5: PostgreSQL migrations
champions:
2:
worst-case: 40
best-case: 10
most-likely: 18
5:
worst-case: 30
best-case: 8
most-likely: 16
```
All estimates found in a directory will be combined and a final
project estimate will be produced:
```bash
$ est --dir=./est
Total: 27
2014-12-19: 27 hours by Yegor Bugayenko
```
## Scope Champions
Scope Champions estimating method was introduced a
patent application [US 12/193,010](https://www.google.com/patents/US20100042968).
This article explains it in more details:
[Revolutionary Method Of Cost Estimating](http://www.technoparkcorp.com/innovations/scope-champions/).
In a nutshell, there are three steps.
First, you break down the entire implementation scope into items, like
it's done above, and list them under `scope`. Pay attention, you should list
only technical code-writing tasks. Testing, requirements analysis, thinking
and talking should not go into this list. Imagive, what would you do
if you would be the only programmer working with the product. Imagine, you
have to create the product from scratch, being the only programmer in house.
It is important to keep all work items on the same level of abstraction. This
means that the complexity of all items should be approximately the same.
Second, select a few items from the list (2-3), which are the most difficult
to implement. They are called "scope champions". List their numbers
under `champions`, as it's done above.
Third, estimate that champions using [three-point estimating method](https://en.wikipedia.org/wiki/Three-point_estimation).
As in the example above, every scope champion should get three numbers.
Worst case is how many hours you would spend on it, if everything would
appear to be very difficult and most probable risks would happen. Best
case is how many hours would this work take if everything would go easy
and without any risks. Most likely is how much would it take, in a normal
situation, according to your estimate.
## Best Practices
**Don't Look Back**. Try not to look into previous estimates
made in the project. It's tempting, but try to control yourself. Create
your own estimate first and then look at others that already exist in
the project.
**Coding Time Only**. Estimate code writing time only. Don't estimate
time you would spend on discussions, thinking, modeling, diagramming,
documenting etc. The estimate should count only the time you, as a single
programmer in the project, would spend on code writing.
**Estimate Regularly**. Re-estimate the entire project from scratch regularly.
In each estimate look at the project as a whole and estimate the entire
scope. Not what's left, but the entire scope, as if you would need to
re-create it all from scretch. Even if the project is close to its end,
don't stop re-estimating it.
**Change Estimators**. Try to ask everybody in the project to estimate it
time to time (programmers only). Changing estimators will help the project
to keep numbers out of bias.
**Count On Your Skills**. Estimate the amount of work you would need to
develop the product, not some abstract programmer. Rely on your personal
skills, speed and expertise.