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
I have more of a "what-would-you-do" question than an actual coding question.
It relates to a project I am currently working on. In this project,
we are tasked with combining several marketplace APIs into one interface. Each
API has its own unique way of categorizing products. The top-level
parent categories for all the APIs we are looking at are more-or-less
the same with some variations. But, the subcategories are wildly
different.
For example, one API requires long bread-crumb trails
to select a category, such as: Sports > Ball Sports > New England >
Football > Active Teams > Patriots > Memorabilia. While another API has two-level
categorization: Sports > Patriots Memorabilia. In many cases, there are sub-categories
that don't relate whatsoever to the subcategories of other APIs.
So, the question is - what is the best approach to take when designing
the interface? We are currently wrestling between two possibilities:
1) Design a custom category UI on the client and then build logic into
the server that is able to sort through the needs of the various APIs
based on user-selected choices.
2) Create the UI in such a way that the user has to walk through the
necessary steps for each individual API. Depending on user settings, this means that
he may need to fill out API - specific information 5,6,10, or more
times.
While I am told that option number one is a real programming nightmare (the
example I am given is changing API data fields) I feel strongly that option number two will piss off customers.
Any ideas out there??
This a very hard problem. If you search for "ontology product classification" you'll find many research papers and discussions on the topic. If one was simply a more detailed version of the other it would be quite feasible, but your description implies that isn't the case, and thus you'll need to construct your own classification scheme and map the others onto it.
Do you have a common key (UPC code? or other) that will allow you to verify your mapping between the different product categories? If so, you might be able to construct your own categorization scheme and then map the others onto it with some degree of success.
Clearly the first option is the best for the consumer but it could be very hard and very time consuming to construct such a mapping and it will need constant updates.
One approach would be to construct a simpler hierarchy than any of the ones provided. A simpler hierarchy will make the [mostly manual] effort of mapping categories into your hierarchy much easier as most will simply be inclusions. This might make the user experience worse but if you add great search capabilities and great "related products" / "people who bought this also bought this" tools around the product browsing experience you can probably make up for the lack of hierarchy.
Number One isn't that bad of a nightmare. Your users' experience is the number one priority; never forget that. If the user has an easier time navigating a shorter route, then give them that opportunity. Also, I would wrap the API with some abstraction so my code doesn't know about the API at all and only knows about the abstraction layer. This way I can change APIs and leave most of my code alone, only changing the abstraction layer.
Use a session to pass data from page to page and a factory to create the page's state on entry based on the session data; this will strengthen the context between page, state, and user data.
Keep first level objects (the ones the page directly talks to) in context to the page; this will help when diagnosing problems.
Most importantly, create a series of tests for your abstraction layer that test every object, function, and input output pair to make sure your application is rock solid.
You have to provide to your clients a consistent not changing interface.
I would like to see an example of the two different approaches you have in mind.
API.find( PRODUCT, CATEGORIES_LIST )
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
I've just finished two days of agile/scrum coaching at work which was great. I'm a a novice to professional programming so I needed it. However, I'm struggling very much with the notion of vertical slicing. In particular I cannot see how a database schema can emerge from several developers working separately across all development tiers (front middle and back)? Designing the database schema all in one go is called horizontal slicing and it's considered a no-no. I'm familiar with object relational mapping - slightly - from having worked with frameworks like Grails. But again, I still designed the schema first and worked from there.
To be clear, I am not arguing against the case for agile/scrum/vertical slicing, rather I am asking how it is possible? - in particular when it comes the mapping of objects the the database schema, how can this be done by several developers in tandem and not from the beginning?
This article which i really like seems to - if i've read it correctly - suggest that the database schema should be designed in the spring planning stage before any user stories are implemented.http://www.vertabelo.com/blog/notes-from-the-lab/data-modeling-in-agile-development-one-data-modelers-experience
The idea of a vertical slice is that you do the minimum amount needed to deliver some functionality.
Now it could be that the minimum amount of database design you need to do for the first story is the complete schema. But I think that is unlikely.
For example, to get the first bit of functionality working, do you need the tables related to authentication? What about the tables that do auditing? Maybe some parts of the schema are not related to certain functionality. Say you have a shopping basket application and one aspect of the schema relates to customer's saving their favourite look-and-feel. Could that part of the schema be left until the corresponding story is started?
If you have several developers following this approach then it is going to require a lot of conversation and coordination. Continuous integration of the database schema can really help. So as a developer makes changes to the schema regression tests are run to ensure it hasn't interfered with the other developers work.
This post explains it pretty well: http://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/
You do not necessarily have to have different people working on each piece of the vertical slice. It is more about breaking each part into smaller pieces to achieve incremental results.
From the above article:
Each slice is comprised of any work needed to be done in an architectural layer as well as any testing and integration that may need to be done to make it ready to release.
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 6 years ago.
Improve this question
I have been doing a coding in for last 7 months. Most part of it has been the updations to the very poorly coded software in asp. Now I am going to redevelop entire software in asp.net. I want it to be very efficient. I need some tips and guidance about how to plan project and design a good database. Thanks in advance for help.
As far as planning for the project is concerned you first need to create your application's pages on paper. Write all your ideas on the paper.
Draw each and every page on paper and complete it with your new ideas.
Then taking every page's feature into consideration draw the database tables. This is a very careful phase. So include every aspect of your application's functionality.
For designing the database follow these steps :
List all entities
Find Relationships [E-R matrix]
Draw Cardinality
Define Primary keys
Draw ERD
Eliminate many-to-many relationships
Identify attributes [attribute entity matrix]
Map attributes - only 1:1 with each entity
Draw final ERD
More help here
Structured process you must know to develop a web application
Here's my super-quick spiel about database design.
A database is two things. It is a 'logical engine', and it is a 'physical engine'. It is a logical engine in that it allows you to create meaningful models of entities. It is a physical engine in that it processes bits of data to update or return results.
I suggest paying about equal attention to each of these aspects when designing a new system. To adress the first, work out the relational model and normalize as far as possible. To address the second, think about where you might want to denormalize for speed, what indexes you'll need to speed the processing, etc.
It's good that you ask, this is one of the most anti intuitive things in software development. My approach would be: pick one feature, implement it in ASP.NET, and convince your users to move over. You'll be surprised how many things you missed, or how actual performance compares to developer testing.
The quicker you iterate, the better your replacement project will be, and the less time you spend on things that don't really matter. There's a excellent blog post at Coding Horror about this; it's called Boyd's Law of Iteration.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So if a user story is a something nebulous like:
As a sales rep, I would like to capture the contact information so that I can follow up later on.
I'm not even sure if that's a valid user story but I'm sure it's close enough.
Then there are details/tasks for implementing that user story.
And I'm sure "The sales rep should be able to tab from one textbox to another." is one of the requirements. How do we capture/track this? Is this part of the user story or is it something that's to be considered separately?
A user story captures the essence of a feature, not the details, a story is a support for the discussion.
So, to answer your question, details are transmitted orally during a discussion, because face to face discussion is the most effective communication media. If you feel the need, details can be captured as notes on the back of the card (if you are using cards) or... in a "notes" field if you are using an electronic tool. Actually, I usually use a "how to demo" field too to capture a high-level description of how this story will be demonstrated at the sprint demo and use very brief "notes" for any other info, clarifications, references to other sources of info, etc (credits to Henrik Kniberg's famous Index card generator). If find this very handy, especially when using executable specifications.
PS: your story is perfectly valid and its a good practice to include the benefits in your template ("As a role, I want action so that benefits").
User stories should be short statements in 1 to 3 sentences.
http://en.wikipedia.org/wiki/User_story
I want to be able to tab from one textbox to another is another user story.
You can track these things in a tool like www.rallydev.com, or just any type of task tracking tool (SharePoint, Excel even ... etc.).
Next thing you do is prioritize.
Just taking a rough stab...
As a sales rep,
I want all data entry and navigation to be accomplished using the keyboard
so that I don't have to take my hands off the keyboard
(and so that we comply with accessibility guidelines).
Or
As a business,
We want all our products to be fully usable using only keyboard input
So that we can sell to customers who require accessible software.
The first part belongs to a "business requirements" document (usually written by a business analyst). The first generations of this document are quite high level, but the final versions (several iterations later) are pretty detailed.
http://www.tdan.com/view-articles/6089
The second part (about tabbing) is part of another document - "UX spec" (shows all screens and describes user interaction). This one is usually written by a different person/team (Product or UX team).
http://uxdesign.com/ux-defined-2
http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php
Yes, that is problem we also have a lot. On the one hand, user stories need to be conscise, on the other hand all the nitty gritty details must be put somewhere.
We use XPlanner, and we solve this by putting the short description into the text body of the user story. Then we use XPlanners "notes" feature (arbitrary text or files that can be attached to a user story) for the details.
That way we can add as much information as necessary to a user story, without cluttering up the user story text itself. You can also refer to external documentation, if you don't want to have everything in XPlanner.
This approach works quite well for us.
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have several problems planning an iteration for a single week. We use XP and TDD in Pairs and it is hard to decide who is pairing with whom. Is there any tool support for planning an iteration that also supports planning of pairs?
In XP you don't plan who pairs with who and when. Team members just pick a task to work on at the start of the day, in the daily stand-up meeting. If someone else also wants to work on the task, they'll volunteer to pair on it. Team members who do not pick a task first will pair with someone who did. Sometimes the person who picked a task will want to use the expertise of another team-member and so will ask them to pair with them. But that person may have something more critical to work on and decide not to. Pairs often switch while a task is in progress, especially if it takes more than a day to complete.
So, pairing up on tasks is fluid and informal.
The one thing to keep an eye on is that everyone on the team pairs regularly with everyone else. If that is not happening, it can indicate a deeper problem in the team -- someone not pulling their weight or people who do not get on, for example. If left to fester this can lead to siloed knowledge and key-man dependencies that increase project risk.
In those situations, some teams like to use "pair stairs" to keep track of pairing and highlight problems.
However, that is just addressing the symptoms (uneven pairing) not the underlying problem. It's better to address the problem head-on in a safe environment (e.g. run a retrospective) and work out how to solve it.
I suggest using a product such as VersionOne.com. With this product you can either load up your projects (resources, etc.) into their online version or you can grab a copy of their product and install it to your local servers. This is not a free product but for the non-enterprise version you do have the first year to try it for free! It is similar to crack...give the first taste cheap to get you hooked. Great product though. I have yet to meet an agile team that didn't enjoy working in this environment.
If this is not your cup of tea though there is a product out from the folks at ThoughtWorks.com called Mingle which I have been eye-balling for a while now. This looks to be a wonderful product as well. I have not yet used it though...but have spent a fair amount of time researching it and chatting with others about it. Very slick product!
There are quite a few products available for agile/scrum teams... have a look at http://userstories.com/products for a decent list.
We use versionOne where I work, and it does some things quite well, and other things... not so much.
You'll need to use a product for a little while, at a low level and a high level to make sure it fits your needs.
As part of a scrum team, I deal most with planning and writing sprints/stories, and tracking progress of my work. Thus for me, those are the two most important pieces to get right.
That said, I don't know if this is addressing the "planning in pairs" question -- what exactly are you trying to achieve? Is there a reason you are trying to avoid your devs make that decision? Are you trying to rotate teams all the time? Does everyone always want to pair with one person? You could always just pair up people based on who wants to work a particular story...
Without a better understanding of you constraints, I wouldn't know how to answer that part of the question. I also doubt that how to pair up is something you should be using a tool for.
Make pairs based upon working style, or people who work well together and can communicate easily with each other, or have different strengths.
Avoid vastly different experience levels, since that doesn't always encourage discussions, and is more apprpriate for mentoring than pairing.
Glad to see you are pairing and using TDD. WIth pairing, rotating pairs is important. However, for any story card, it is important that a developer stay with the card from start to finish. That person is the primary half of the pair.
So you have two issues. How should you handle rotating pairs, and how to you track the burn down in XPlanner or some other iteration tracking tool.
Regarding the burndown, the primary developer can be assigned to the card and responsible for updating the burndown daily. For pairing, you should have a big visible chart (BVC) showing the pairing schedule. This will ensure that all developers pair with each of the team members and help ensure that the code is shared across the team.
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 am from an XP background. I know the process very well and have solid working experience with it. I have found it to be the best way to develop software.
I find myself in the position of a process doctor of sorts and this creates much self examination and revaluation of my own understandings.
A very common thing I hear is that some work can’t be made into stories. I personally don’t believe this. The excuses include
Its too big (The developer will have nothing to show until the end of 5 weeks).
it’s a complicated algorithm or abstract concept (will take 5 weeks to write and nothing to show).
This question is to get hints, tips or suggestions.
I am looking for hints, tips, and suggestions as to how to address these and similar perceived problems (and more if you can think of them).
I will mark the answer that has the most information on how to get around users/developers who wont write stories and address their many excuses as to why not (I have only listed a few and there are many more).
Here are a few resources that I've collected over time and that might help:
Patterns for Splitting User Stories
Story Weight Reduction Toolkit
Twenty Ways to Split Stories
Ways to split user stories
Too big or too complicated, there is always a way to put a story on diet (maybe you won't obtain the final result in one iteration but this doesn't mean you can't and, well, there will be more than one iteration).
So basically, your question is "What can I do if people claim a task is too big for a user story, and can't be split up.
In my experience, almost any problem can be split up. Ask them if they can implement a simplified version, leave out advanced features, maybe even use default values in some places; basically anything to produce something that gives meaningful (i.e. testable) results within one iteration.
Remember: The point of an iteration is not to deliver complete functionality, but just useful and testable functionality.
This splitting can be difficult, but it forces you to consider what you really need first, which is very valuable. The developers may bitch about it (I often do myself :-)), but it's really necessary. Breaking down big tasks into manageable user stories is at the very heart of all agile methods.
That said, if the task really, really, really cannot be broken down (think complex mathematical algorithm in a research setting, that takes weeks to even understand the basics of), then your iteration is too short. The iteration needs to be long enough to produce meaningful results. And if most of your problems are so hard that they take 2-3 months to get anything done, then that's your iteration length. But I've never seen a project where that was really the case...
Usually when you get "it's too big", what they are really saying is "I only have a vague idea how this should work". You need to work with them to better define it until it becomes possible to split it into logical parts that can be more easily managed.
users/developers who wont write stories
Users aren't supposed to write user stories. They aren't supposed to tell you user stories. You can expect them to talk about how they work, the problems that bother them and what they would like to have to facilitate their everyday work.
You, in your turn, is supposed to listen to them and take notes. If they allow, use a tape recorder or a camera. Then you bring the collected information back when you replay it and identify what you call user stories. You discuss them with the team and when you have agreement you have use cases to target in your development.
What role developers play, is up to you. If they just coders, they don't take part in the process.
If they in part act as consultants, then they help define user stories.
The "algorithmic specification" problem is common.
Many people prefer to write code and don't really care who the user is or what they do.
I try to get them to focus by asking these questions.
What action can the person take? What could they possibly do with the information? If they have some responsibility, they can take action to deny, approve, hold, reject, reprocess, stop, start, something. If the user can't take any action, you need to ask if they're really stake-holders.
What decision do they have to make? How do the decide which action (if any) to take? We can't automate that decision -- that's why people are in the loop.
What information does this person need to make the decision to take action.
Information-Decision-Action.
We only write software to prepare information for people to make decisions so they can take action.
If that's not the focus, then the stories get out of control.
Its basically the duty and responsibility of the product owner. And there can be any requirements/task that cannot be split into User Stories. I found many such discussions on SCrum Master Forums
If development team claims that the story is too big and can not fit within the sprint.. take their feedback and try to split the story with must have and nice to have tasks and try to split it based on that.
check this flowchart.. can be a help: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf