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
We have two distinct agile teams, each working on separate, but related, applications.
Each team has, until now, been able to work in an independent fashion (distinct code bases, persistence stores, sprints, backlogs etc). Recently, product management decided that these applications will become even more closely integrated. On a side note, the size of each team (comprised of QAs, Devs, BAs) will be increasing over the next 6-12 months.
Management has decided to keep the agile process largely intact, since it has worked well (two teams working independently as much as possible) but have floated the idea of a contract-based service layer as means of integrating the applications.
In each sprint, any story that requires integration with the other application will be identified. At that point, an additional "integration" story will be added to the other teams backlog. That team will then be tasked with fulfilling the contract. In the meantime, the other team can continue their original story work, substituting a mock/fake service until the other team produces a working service.
Since Agile preaches a KISS philosphy, several people on the teams have taken issue with the "complexity" of this approach. They are advocating continued used of stored procedure sharing as a leaner/simpler integration methodology that "has worked well in the past".
I prefer contract based programming for all sorts of reasons, but the main reason is it's ability to provide compile time visibility into the behavior your application is expected to provide. You also get clear boundaries around who owns what code, and whose code you are likely to break if you break your contract. Stored procedures do none of that.
Since we have already reaped many benefits from agile, I'd like to think that there is already an "agile-friendly" way to deal with this kind of app integration/synchronization. Does creating a contract based SOA layer meet the agile smell test? Is there a third option I haven't considered?
I don't think that keeping current process intact is good idea. Cooperation and communication between teams has to increase otherwise it will have negative impact on both teams. You should follow similar practice to Scrum of Scrum.
Edit
Scrum of Scrum: I don't have experience with project handled by more than one scrum team but because of very good experience with Daily Scrum a believe that Scurm of Scrum works and increase productivity in all teams.
Great question. Walking the design tightrope is always a tricky one. I think keeping the applications as loosely coupled as possible is definitely the way to go.
The simplest thing that could possible work is a great approach, but following this to a dogmatic end without regard for the SOLID principles and general good design is going to give you two applications that are tightly coupled and probably full of technical debt that will bring the team grinding to a halt at some point in the future.
Decoupling and adding the abstraction in now seems like the most sensible thing to do, as long as you aren't adding lots of additional "framework" that isn't yet needed. The trick is to ensure you have a good enough design that would allow that framework to grow if needed, without building out a lot of unnecessary stuff at this point - you need to do just enough to decouple the applications.
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
I have read much information about agile and waterfall and I just cannot think of any reason why someone today should do the waterfall. I am concerned especially about testing process.
Do I miss something, is there some clear advantage that I have overlooked?
There are still cases where waterfall is appropriate. Canonical examples include military, space, medical and safety-critical systems such as flight control software where you absolutely need to determine the spec first in exact detail, develop it, then thoroughly test the complete product.
Agile works for most business and product software (i.e. the majority of software built) because it allows users to start with a rough idea and refine it as they go along. If their website or internal line-of-business application isn't quite right (or has bugs) for a few iterations then it is generally outweighted by the business value that's delivered quickly from the bits that do work. You wouldn't want to start with a rough idea for a nuclear power plant controller system and refine it as you go along.
The trade-off of using pure waterfall is that it is orders of magnitude more expensive to develop software in these scenarios. However, the cost-benefit is still favourable since you cannot afford for (say) your spacecraft to hit a null pointer exception halfway into orbit.
There are of course shades of grey in between. It is possible to use Agile techniques within a waterfall framework (see RUP) and the balance can be scaled up and down between pure waterfall and pure agile.
One of the main pros of the waterfall model of development is that it has been used for years and years to develop. It works. Even though there is a large shift and focus on agile, waterfall is a very clear process with start points and end points for each section of the development.
With the introduction of agile programming it is easy to see the falls of waterfall and how it is not as adaptable to the demands of programming these days.
As long as you are careful and plan ahead and test sufficiently I would say testing in agile can be as effective or even more effective than waterfall - it is certainly easier to work with agile when testing throws a few bugs that can cause design changes your way.
Another thing to consider is developing using, test driven development. http://en.wikipedia.org/wiki/Test-driven_development
Outsourcing
I have seen many companies stick with waterfall for outsourced projects. Most vendors will be very specific when it comes to pricing quotes. Waterfall suits this model quite well - you hand off what you want, they produce it. I'm not a fan of this, but I can understand the reasoning for executing this way. I think most outsourcing companies will eventually find a way to become more agile as it becomes more of the industry standard.
The answer to the question depends on what kind of development methodology you are using for your project. Is it agile/Is it waterfall/etc etc. Over the past three to four years I have been part of projects that involved only Agile or only Waterfall, so will be using them as my reference point.
If the requirements of the project keeps on changing we should never go for a waterfall design , since waterfall methodology assumes that designing/analysis/etc has been finalized while if we go for agile it is based on an incremental approach where we divide our project into incremental stories and building/testing as we go along, so if the requirements change it does not involve to much of re-work from developers as well as the testers.
For example say we have to create four new web pages as part of our project, then waterfall assumes that their design etc has been finalized and that testing will start once all the four pages have been developed while incase of agile what happens is we first develop one page and hand it over to the QA for testing [manual/automation], and so on. Thus we can see that agile adds value to our project by not making it susceptible to requirement changes in addition to finding the functionality flaws/bugs at the time of development.
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 has grown fairly quickly from 1 to 5 over the last year or so and are very interested in changing our development style from Waterfall to a more iterative approach like Scrum. We work for a University and specialize in CRUD web apps for internal customers who are always changing requirements along the way.
So, my question is...How do we best implement Scrum techniques?
Supplemental concerns: Is it recommended to quit Waterfall "cold turkey" in order to facilitate the transition or do you feel a progressive approach is more effective? In other words, pick and choose some scrum techniques to implement now and add others further down the road?
Make sure your dev practices can support agile. You should have automated tests, daily integration builds, one-change-one check-in, customer accessible test environment, etc.
Get your customer on board. Scrum is a business-centric PM framework. It is in their interest to use agile techniques because it gets them the greatest value for their money. But they have to want it.
Get your team, PO, and management professional training in Scrum.
Make sure you, your team, and customers share the agile values (Agile Manifesto style). You would be amazed how many people value documentation over working software.
If you have 1-5, then go cold turkey. Scrum is a simple framework.
IMHO a step by step approach is wiser. You should first start doing retrospectives at the end of each iteration / sprint (if you use iterations - if not, that should be step 0 :-)
On the retrospective, you look through what is going well, not so well, and what can / should be improved. Then pick the most pressing issue and think about how it can be improved - primarily using Scrum, but you may have a look at other (agile or not) solutions too if you feel the need to. The aim is to work out your own process, which may be strict Scrum, or a hybrid - whatever works best for you, in your specific situation.
Personally, I would go a bit more Jeet Kun Do when it comes to project management strategies. With my team, I've created a piece of software where they answer the scrum questions (with some personal sauce), so instead of 15 minutes of debating, everybody knows what to do. And it beats having someone taking notes.
Even though SCRUM/Agile project management is populair, the waterfall approach has it benefits too. I would give a try-out first and keep the goodies and get rid of the baddies.
Make sure your team is truly cross-functional. Get all team members be commited 100% to the project on hand.
Note - succes of scrum teams often depends on strong scrum master - hence try to get a experienced scrum master or a coach to help your team during the transition period.
Try not to mix waterfall and agile - suggest go cold turkey to scrum.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
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
What do you do when you join a team that says they use Scrum, but only use it as a time-management tool and not the whole process?
How can I reinstate back testing and documentation?
I was thinking to start off with adding user stories specifically for testing and documenting.
Perhaps someone else has more experience with this then I do about this as I am sure its not that uncommon.
The key to scrum is that a task be identifiable as "done" before it can be classed as done. How does you company assess whether something is done without reviewing documentation and tests?
Perhaps they have an unusual, but valid, way of doing it. Or perhaps they have missed the point of "done tasks". I'd suggest you start by asking them how they measure down and whether it could be improved. Then suggest documentation and testing as the way of improving the process.
Note that neither testing nor documentation are in fact part of Scrum. Scrum is a pure project management approach - the required engineering practices, like the ones you mention, are supposed to "emerge" during the project. And most specifically, they are supposed to be identified during the heartbeat retrospectives that you do at the end of every sprint. Are you doing those? Can you bring up your concerns there - and are they actually the biggest concerns the team has?
Is the issue that they don't have any documentation and tests, or that they aren't implementing the entire Scrum methodology? Those are 2 very different problems in my mind.
I would much prefer an organization that has taken the time and effort to find and fit a development process that matches their development style as opposed to mandating down from on high the one true process. So I would not be concerned at all if they were using a process that they called Scrum but that didn't meet all the "official" guidelines. Try to determine why the process is the way it is. Chances are that if they have taken the time to tailor it, the team will be receptive to your ideas, especially if you have taken the time to determine why things are the way they are. If you simply approach it as "this isn't Scrum and so isn't right", you will probably not make much headway, but by being pragmatic about the benefits you can likely make some substantial improvements.
Alternatively, if they aren't doing testing and don't have any documentation I would consider that a fairly bad sign. And by documentation I am taking the minimalist view here - a list of features, bug tracking, etc. - I would be very concerned by the absence of these items, less concerned by the absence of items higher up the abstraction list. In the absence of support from management, I would suggest you lead by example. Take it on yourself to setup a simple bug tracking system (there are several - in a pinch, simple text lists in a central location work as well). Don't declare your features complete until someone else has tested it. This can be as simple as walking over to another developer and asking them to try it in front of you. If someone claims a feature is complete, take a few minutes to familiarize yourself with it. If you find a bug, politely mention it to the responsible developer. Slowly build an environment where the team can see the benefits of running tests and tracking features and bugs.
Most teams operate in this manner simply because of a mistaken belief that they don't have time to "do it right", or that they will get to it later. Often this will occur when a simple proof-of-concept done by a developer or two as a side-project turns into a full-on development effort. By showing that it can actually save time and effort, and reducing the initial costs to the rest of the team, you will often find that it becomes ingrained as part of the process without ever actually being officially endorsed or accepted.
If you have management support it will make it much easier, but always be careful to make sure that the team is receptive to the changes. This may mean it takes longer than you want, but so be it, without the team's support any mandated process will fail at the first sign of pressure, which is when you need the process the most.
*Disclaimer - On my last project I spearheaded the movement to tailor the SCRUM process to fit our environment. The "official" process was simply untenable for our client, but it was still an invaluable guide in tailoring our process.
"adding user stories specifically for testing and documenting"
While meta-user stories might make sense in some circles, it rarely works out well. Software folks rarely cope well with meta-user stories, they either don't get the idea that they can change their own processes by writing a story, or -- more typically -- they engineer the meta-user story to death.
When you're interviewing users, it feels like they're making the user story up. Certainly, you're making it up as you listen to them and try to capture it.
When an IT organization tries to make up its own user stories about how IT should work, the process falls apart. Until the organization has done the thing (testing, for example) a bunch of times manually, they're not really qualified to write user stories. Then, after they've done it, they don't need software development processes, they'll just automate the important bits a little at a time.
I think change has to come from a less formal direction. Actually balking at calling something "done" that hasn't been tested is a good starting point.
IT doesn't do things unless forced. So, meet the users and find out why they're not requiring testing. Coach them to require testing. Tell them the consequences and the words to use.
A lot can go wrong in an organization to lead to poor processes. It's important to know what's wrong, and create a demand for change. The best possible thing is to have your boss complaining that you're not fixing it, rather than you suggesting that perhaps it would be good to fix it.
[It doesn't feel right when your boss demands you fix the process, but it's about the only way change will happen.]
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 4 years ago.
Improve this question
What would you suggest for the following scenario:
A dozen of developers need to build and design a complex system. This design needs to be documented for future developers and the design decisions must be noted. These reports need to be made about every two months. My question is how this project should be documented.
I see two possibilities. Each developer writes about the things they helped design and integrate and then one person combines each of these documents together. The final document will probably be incoherent or redundant at times since the person tasked of assembling everything won't have much time to adjust every part.
Assume that the documentation parts from each developer arrive just a few days before deadline. A collaborative system (i.e. wiki) wouldn’t work properly since there wouldn’t be anything to read until a few days before deadline.
Or should a few people (2-3) be tasked with writing the documentation while the rest of the team works on actually developing the system? The developers would need a way to transfer their design choices and conclusions to the technical writers. How could this be done efficiently?
We approach this from 2 sides, using a RUP style approach. In the first case, you'll have a domain expert who is responsible for roughing out the design of what you're going to deliver - with developers chipping in as necessary. In the second case, we use a technical author - they document the application, so they should have a good idea of how it hangs together, and you involve them right through the design and development process. In this case, they can help to polish the design, and to make sure that it matches what they thought was being developed.
We use confluence (atlassian's wiki-like-thing) and document all kinds of different "things". The developers do it continiously, and we push each other for docs - we let peer pressure decide what is necessary. Whenever someone new comes along he/she is tasked with reading through everything and to find out what still is correct. The incorrect stuff is either deleted or updated as a consequence of this. We're happy when we can delete stuff ;)
The nice thing about this process is that the relevant stuff stays and the irrelevant stuff is deleted. We always "got away" from the more formalized demands by claiming that we could always construct the word documents they wanted if "they" needed them. "They" never needed them.
I think alternative 2 is the less agile, because it means a new stage to the project (although it may be in parallel with tests).
If you are in an agile model, then just add documentation (following a guideline) as a story.
If you are in a staged approach, then I would nevertheless ask developers to work on documentation, following some guidelines, and review that documentation along the design and the code. Eventually, you may have a technical writer reviewing everything for proper English, but that would be a kind of "release" activity.
I think you can use Sand Castle to document your project.
Check it out
Sand Castle from Microsoft
It's not a complete documentation, but making sure that interfaces etc. are commented using Doxygen-style comments means writing code and documenting it are closer together.
That way, developers should document what they do. I still think a review by the architect(s) is needed to ensure consistent quality, but ensuring people document what they do is the best way to ensure they follow the architecture.