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 2 years ago.
Improve this question
I am learning User Experience. They says Information Architecture is much important to UX. I am studying about IA in online But I wonder how can I practise it? Please Help.
Thanks.
I'm an IA.
Information Architecture is a discipline that can be considered part of the "User Experience" domain. For a good look at this, view "Elements of User Experience" (pdf) by Jesse James Garrett to see where it fits.
Suggested starting point on Information Architecture: read the 'Polar Bear Book': "Information Architecture for the Web and Beyond, 4th ed", Rosenfeld, Morville and Arango. This is the classic text on the field. Its definition of what IAs do: Connect Users with Content through Context is an old one, but the simplest explanation. (f.e., today I've been working on a site section which changes in response to how far down a timeline a user is - it's using the timeline context to get the user the right content).
Boxes and Arrows is a site that has focused a lot on the IA discipline, though it's changed a bit in recent years (as has the IA landscape). It's worth your time to take a look.
The Information Architecture Summit (in Lyons, France for 2018, in the US, most likely, in 2019) is a great place to meet information architects, understand the community, get some starting points. The people who defined the domain are often there, and easy to talk to.
One way to think about what an IA does for a page/site/app/etc. is that the IA designs the information hierarchy so the user can find the important things, so that all things are as findable as they can be, and so the user understands where she is and what she can do at all times in a site.
An Interaction Designer designs user flow through a series of interactions (not necessarily pages)
A UX Designer manages the overall experience of the site, designs it to be coherent and satisfying, while hitting business goals
A Visual designer adds visual flair, while serving the usability, coherence, brand and overall experience of the site.
Information Design is a completely different discipline from Information architecture.
A couple of well-known Information Design leaders are Edward Tufte and Stephen Few. They are concerned with users' ability to understand your presented dataset.
They do this with good design heuristics ("maximize the data/ink ratio") and critique ("don't use chartjunk"), as well as great basic advice ("if you don't have a story to tell, you don't have anything to present". "Steal with abandon. There's no reason to re-solve a problem that has been solved for 100 years").
They also appear on Jesse James Garrett's chart on the Elements of UX.
Hope this gives you some useful tips for where to begin.
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
Agile development is a very useful methodology. Is it realistic to apply this to a lone developer who codes as a hobby (I also code for a living in a team where I have learnt agile from)? Things like stories, scheduled retrospectives, etc, can be useful (Even if I am asking myself things)?
Thanks
Yes, Agile is a lot about Getting Things Done (the real meaning, not the book, see below). It's about getting trough procrastination too. I've found that Agile methodologies tend to solve mostly psychological problems. In fact, most problems we encounter in software development are not technical, but psychological.
I have many projects where I'm the only one involved, and yet I've my own backlog, sprint backlog, my own information radiator, I apply the same "done" definition rules, reviews, retrospectives, ...
But no, I'm not doing standups meeting alone or with my cat :)
I've read many books about productivity improvements before I discovered agile methodologies. And what I've observed is that agile is very similar to them.
For exemple, Scrum is a lot about Getting Things Done, and others well known books on the subject.
That book certainly saved my life at a certain point. So get it and read it. It will helps you "get it", I mean, understanding what Agile means. Trying to do Agile not understanding it will leads you to failure.
Certainly, though some of the practices may not apply or may feel a bit silly.
Breaking your work into stories and timeboxing your development can definitely help even if your all alone.
Test-Driven-Development is really an individual process anyway, and certainly is useful as a solo developer.
Pair-programming would require schizophrenia however. Daily standup meetings would probably go much more quickly...
There was some talk of this on Ward's Wiki years ago, which might be worth a look.
Is it realistic to apply this to a lone developer who codes as a hobby (I also code for a living in a team where I have learnt agile from)? Things like stories, scheduled retrospectives, etc, can be useful (Even if I am asking myself things)?
Definitely yes and it worked for me. I have tried doing it myself and it definitely makes me more productive. A good way to try it without the need of buying a whole lot of office supplies is using ScrumWorks (google danube) which is freeware for the basic version. You can add products, releases, user stories. tasks, and see burn down charts etc.
Doing a retrospective by yourself would be a little weird and it may make people in your house think you are losing your marbles while you talk to yourself out loud but that is just my opinion. What I do is I write down the Retrospective notes on a soft document and attach it to the Sprint or a Backlog in ScrumWorks.
Hoping this will help you.
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
What, in your opinion (although I would highly appreciate articles / books on related issues), should be the the level of the programmers knowledge of the domain?
(This related question didn't quite answer my question / had a reference to something I can use)
If programmers were domain experts, they would not be programmers. :-)
For example, I do a lot of software development for archaeologists. If I knew as much about archaeology as the users I work for, I would be digging and surveying in the field rather than programming. Which makes no sense.
Having said this, I think that programmers need to be knowledgeable about the domain, and as much as possible, but without losing track of priorities.
If you need domain expertise, bring a domain expert into the team.
Yes and no.
As Kyle pointed out, programmers are often changing domains on every project and this pretty much precludes you becoming an "expert" in any given domain. On the other hand, you need to understand the problem well enough to a) craft a solution, and b) test that it actually solves the problem at hand.
One reason for not claiming domain knowledge is so that your customers are forced to take ownership of this part of the project. The best way I have fouond of forcing them is to require a clear overall description of the project (no more than a couple pages long) plus a ton of User Stories ... written by the users. You can lead them through the process of how to write US's, but they will not truly own the end solution unless they were intimately involved in creating it.
Having US's and using them both for design and testing puts project ownership where it ultimately belongs -- in the hands of the users of the system.
As a consultant I am constantly (every 6 to 12 months) changing domains. Though I can never proclaim to be a true expert by the time I finish a project, the more domain knowledge I acquire, the more value I can add the project.
If you don't understand the problem domain, you shouldn't be coding a solution.
You don't have to be an expert, but you cannot be ignorant of the key ideas.
As a FORTRAN expert, you won't make any progress coding an FFT unless you have
some background in signal processing, and understand why an FFT is necessary,
and know a variety of implementations.
That depends on how related to the domain the specific job they're doing is. In team context, I can imagine that the lead programmer and some others benefit from a bit of domain knowledge while others in the team don't need it.
Banking/financial applications
Networking/wireless/telecom
Mobile Applications
Web/storage/enterprise/Numerous others..
If by "domain" you mean your area of work, yes you should strive to understand everything related to your area of work. How far into other areas that extends is another question.
programmer is like people who can interface "other people" with computer by creating software, and better understanding of the domain where you're working for would help the communication between the problem and the "other people" thus would make you a better programmer.
but the problem domain is often very wide and deep, you can expect everyone to be expert at programming and expert at another field, for example you can expect great scientist or physicians to be expert at programming to solve his problem when creating space-ship because programming is not his main concern, so with programmer, but programmer or scientist who can talk to each other is the best fit
Even if you change projects and with them domains frequently, domain specific know how and experience in one sector (or branch of trade) will be always a plus.
I look at this as "WHAT" versus "WHY". As in What is the business requirement versus Why is the requirement such as it is. A junior programmer only needs to understand the WHATs of a project. An analyst needs to understand both. In my opinion and my professional status, to stop being a developer and to become a software engineer, you need to add analyst to your skill set.
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
When you have sprint task in Scrum, where do you put how you want to program something? For example, say I am making a tetris game and I want to build the part of the game that tracks the current score and a high score table. I have my feature, my user story and my task, but now I want to talk about how to design it.
Is that design something that is recorded on the sprint somewhere as to how to do that or is that just somethign the programmer figures out. Do you put do task x use database such and such, create these columns, etc.? If not, do you record that at all? Is that what trac is for? I don't mean too high level design.
I touched on it here: Where in the scrum process is programming architecture discussed?
but my current question is later in the project after the infrastructure. I'm speaking more about the middle now. The actual typing in the code. Some said they decide along the way, some team-leads. Is this is even documented anywhere except in the code itself with docs and comments?
edit: does your boss just say, okay, you do this part, I don't care how?
Thank you.
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).
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
The Mythical Man-Month is now classic, but the "Surgical Team" methodology is still interesting. What methodology most closely resembles it or has the same essence?
To summarize the Surgical Team analogy:
A surgeon understands the problem/business domain and is the expert. They are the authority when there are questions or conflict with in the team. The surgeons work between themselves when there are issues, say with design, functioning as a smaller tight team of experts. So in essence they have the knowledge of the domain, are entrusted to do they think is right, and do the actual coding? The rest of the team focuses on support, testing, documentation, and project plans are delegated tasks. Consequently the surgeon is also the most skilled/trained resource.
The answer could be project, programming, design methodologies as it seems to have implications across main methodology domains. Agile, MDA, Extreme, in sourcing development?
This question also make more sense for software that is large in a complex business domain, think air traffic control, not a COTS developer to or common utility.
One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.
Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.
In the case of a surgeon, the key actor is both the domain expert and the implementor.
I.e., he's both the software program manager (architect) and the developer.
This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.
For general development, however, there are a few issues with such "hero" methodologies:
Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.
Scalability is limited by the number of "surgeons" you have available.
There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.
I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.
If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.
I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.
From the text I see the following:
Agile Like:
Small teams focused on solving specific problems
Collaboration among the surgeions
Non Agile Like:
Surgeons are the authority, driving the plan, determining the design, allocating support tasks (viewng them as subservent to coding) and doing the coding. All of those are very command and control in approach and contrary to self directing teams (vs a directed team)
There appears to be no collaboration with the business partner (let alone frequent collaboration with the busines partner)
There appears to be no prioritized product backlog, thus the surgeon picks what is important not the business partner
There appears to be no incrmental delivery (tight feedback loop)
For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.
One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.
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 11 years ago.
Improve this question
I read a lot of books about what practices work well or not in software development.
And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.
Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.
ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.
That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.
Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).
In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.
The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.