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 6 years ago.
Improve this question
Choosing the correct lifecycle and methodology isn't as easy as it was before when there weren't so many methodologies, this days a new one emerges every day.
I've found that most projects require a certain level of evolution and that each project is different from the rest. That way, extreme programming works with for a project for a given company with 15 employees but doesn't quite work with a 100 employee company or doesn't work for a given project type (for example real time application, scientific application, etc).
I'd like to have a list of experiences, mostly stating the project type, the project size (number of people working on it), the project time (real or planned), the project lifecycle and methodology and if the project succeded or failed. Any other data will be appreciated, I think we might find some patterns if there's enough data. Of course, comments are welcomed.
PS: Very large, PT: Very long, LC:
Incremental-CMMI, PR: Success
PS: Very large, PT: Very long, LC:
Waterfall-CMMI, PR: Success
Edit: I'll be constructing a "summary" with the stats of all answers.
My personal experience:
Project size: Very large (150+
persons)
Project time: Very long (+6 years)
Project income (estimated): 40
Million $ (Military is paying)
Project life cycle: Incremental
lyfetime. Main milestones every
year.
Project structure: Traditional at
first (system department,
development department, etc) not so
good. Process based later (the
process establish a flow of work,
requirements, design,
implementation, test, feedback,
metrics): quite good so far.
Project result: success (so far)
Here you go:
Project size: about 1 million lines of code, 30 people
Project time: 9 years
Project life cycle: good old waterfall, due to big customers requirements, but with staggered delivery to the QA team - it is very difficult to be agile when you have customers commitments to large clients
Project structure: we are organized in departments but we use CMMI to keep them in sync - we have stakeholders, work products, deviance procedures, etc.
Project result: we've really improved with the implementation of CMMI and have delivered our last few releases on time every time
-C.
Related
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
here in my company we're using SCRUM with TFS and sprints two weeks long, we have to maintain basically .net applications (web, desktop), android apps, and SAP programs.
So, we can't create a full sprint because there isn't enough work to do, but, at half sprint start to appear more Product Backlogs to take care of and everybody starts to apply pressure so their PBs be finished quickly (Basically emergencies).
We can't wait for the sprint to finish to attend this emergencies so we change priorities on the fly. So basically the sprints mean nothing to our team :/ and all the pretties charts lose meaning.
How we can deal with this, we are not living a project like day by day to have the knowledge of what tasks are going to appear at the next sprint.
Maybe Kanban would be a better approach if you can't commit to a two week timeboxed period but still would like to follow a formal process where "charts" make sense.
http://kanbanblog.com/explained/
You can add as many tasks as needed to capture the work required to complete each item. For example, you have a task in Future Sprint, but you would complete it in Current Sprint, you can move this task to Sprint1:
More information of Sprint Plan, you can check:
https://www.visualstudio.com/en-us/docs/work/scrum/define-sprints
https://www.visualstudio.com/en-us/docs/work/scrum/sprint-planning
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 7 years ago.
Improve this question
Our project has 4 developers, but we have a lot of Rspec tests: they take 30 minutes in one thread.
Comfortable count of threads for one build is 3. Also we follow agile methodology and there are few simultaneous commits at Friday’s afternoon. Waiting in the queue is not what we want. So our team wants to run 2 builds (each in 3 threads) simultaneously: 6 threads as a result. As I understood, at Travis we need to pay at least $250 - it’s not so pleasant.
Also I read about Vexor.io - new CI service with unlimited number of parallel threads. As I understood, with Vexor you need to pay only for minutes of testing. It's an unpopular service, so I'm afraid of using it. Did anybody try Vexor? Which price can we expect?
Or you could advice some other CI with which we could:
Avoid standing in the queue.
Test in 3 (at least) threads.
Don’t pay for this big money.
I used Vexor and it left good impression. Take a closer look at it, because:
Vexor really allows you to run as much threads as you want.
As I remember, it has some free minutes each month, so you can try it for free.
Vexor is compatible with .travis.yml.
We had a similar by size project and price was less than 50$.
Good luck!
I didn't try anything but Travis (if we talk about SaaS). But you can try some self-hosted solution like Jenkins. You can customize it as you want, also you’ll achieve a lower price.
You could also take a look at CircleCI. I've been using it for a while, it's really easy to set up and use, and it is also very flexible in terms of configuration. And their staff is very helpful too, I get answers to all my questions within 12 hours.
Here's the link to their docs section about parallelism.
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 9 years ago.
Improve this question
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.
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 3 years ago.
Improve this question
I've recently been looking at Extreme Programming and wondering if it would be realistic to implement it where I work.
My question is, if you're pitching to a potential new client and you tell them that you're using XP, and you explain what their responsibilities are as the customer, are they likely to be put off selecting your company if they've never worked within an XP environment before?
What are peoples experiences of selling XP to a client given that it seems to me to be a very customer intensive software development methodology? The context here is selling medium to large websites to a a wide variety of clients.
I usually try to explain it to my clients in non-technical terms, and focus on the benefits of my business model. With XP, you'll always have a higher degree of communication with your clients. This is always a plus for them. They like to know what's going on. Focus on that. Also, focus on the idea that they are able to discuss business requirements with you as the process moves along, so they don't get tied down into doing something the way they first envisioned it 6 months ago when they didn't really know what they wanted. This will also allow your contracts to extend their lifetimes when your clients get comfortable working with you and want to continue improving their products.
I'm working on a project that uses XP. The weekly meeting with our customer and the outcome of these meetings was that good, that our customer decided do try to implement an 'agile like' process as well.
Additionally I think that agile is getting more and more common in IT projects and that more customers are satisfied by the outcome of these projects. So I think that in a couple of years it will be harder to sell a non-agige project than an agile one.
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 3 years ago.
Improve this question
In scenaios where an RFP is issued by a customer for a vendor to be selected based on a certain technical and financial criteria, i.e. in a fixed scope / fixed price projects, is there any methodology can be used other than WATERFALL. I.e. Can the Incremental / Iterative approach work?
Why wouldn't you be able to do iterative? You can chunk up work in any size and do design-build-test iterations. I suppose what you're asking is whether or not a lightweight methodology designed to deal with changing or undefined scope is appropriate. I dont' see why FDD is not appropriate, for example, just because you know where you are going. :)
If they want that type of proposal, then they are presumably prepared to pay the price in change orders and large buffers (in time and $$) for unknowns. And you can bid accordingly.
But once the contract is signed, the most productive methodology is what it is. And if you're flushing out the risk factors, delivering early and often, etc. you just have the benefit of writing those change orders sooner.
Agile techniques are designed to contain change, but they work just as well if change is not so great. Most of the benefits still accrue. Just divide the work up into customer stories, the stories across milestones, and start the iteration clocks running. It should work just fine. You'll have to do a little more planning up front, but that doesn't imply waterfall.
Waterfall is when you do all the planning, then all the coding, then all the testing/debugging in that order. Instead you can do just enough planning, then iterate through planning/coding/testing cycles.
I think agile and iterative approach can be used and is important in many levels. The phase of defining business needs is extremely important and should also be iterative. By requesting fixed scope / fixed price contract the customer is giving up the chance to be flexible and killing the spirit of agile. Of course you can and should do some iterations even under fixed scope contract. But the most valuable advantages of iterative approach have been lost with signing the fixed scope.