XpVelocity extreme programming · project planning · estimation tags: Velocity is a notion from ExtremeProgramming that helps calibrate a plan, tying broad statements of effort into elapsed time. Velocity is a statement of how much stuff a team (or a person if it's personal velocity) gets done in a time period. You should usually determine velocity by measuring how much got done in past periods, following the principle of YesterdaysWeather. A typical approach is to average the velocity the past three time periods to determine velocity for future time periods. For example, a team is working in two week iterations and estimates effort for stories using StoryPoints. Velocity is a tool for calibrating estimations for YesterdaysWeather, it is not a measure of productivity. Velocity is commonly used with fixed iterations, but you can use the same idea with Kanban based planning.
The Roots of User-Centered Design — Beyond Wireframing: The Real-Life UX Design Process UX and Agile: Tying the knot "Something old, something new, something borrowed, something blue, and a silver thruppence in her shoe."—classic wedding tradition In the modern software development environment, UX and agile practitioners are becoming part of a growing culture defining the way online products and services are being delivered. The modern UX team is much more multi-disciplinary and organic than ever before, and it's no surprise that hybrid processes and methodologies are being employed to ensure better management of personnel and project deliverables. Although UX and agile both address key pitfalls that exist in traditional software development to deliver a better solution for the end-user, sometimes UX and agile approaches seem to work against each other when people focus too much on the processes and procedures. Here are some factors and advice for a happy marriage between the two. Something Old: The project management triangle Something New: The project management triangle redefined Will it Last?
Client-Centered Services By Tal Bloom Published: April 22, 2013 “Just as we ask our clients to focus on users when making design decisions for their Web site, shouldn’t we similarly focus on our clients when making service decisions for a project?” As UX professionals, we practice user-centered design—which means we stay focused on users and their needs when designing a Web site, product, or service for a client. To actually put this into practice, though, we need to convince our clients to follow our UX approach. Well, just as we ask our clients to focus on users when making design decisions for their Web site, shouldn’t we similarly focus on our clients when making service decisions for a project? Figure 1—Consider your client’s goals and user needs to create a usable design and useful content View the full-size image In this article, I’ll flesh out these ideas, but first, let’s take a look at a case study. Case Study: Cultural Roadblocks So, how did this realization affect my approach? Turn Up Your Warmth
Agile Product Design, holistic product design and agile software development The Four Waves of User-Centered Design In the fall of 1988, a small group of professionals from the technology industry gathered at Bentley College (now University) in Waltham, Mass., to discuss the topic of user advocacy and assistance. These gatherings were informal, simply a group of professionals with a shared passion for improving the quality of technology for the user. Eventually, at the urging of participants, these meetings were formalized into a seminar series and, not long after that, an Information Design Certificate program. Though the term user experience did not yet exist, it was clear to the program designers (myself included) that there was a need for this type of formal instruction given that few, if any, formal programs existed in the U.S. at the time. We quickly adopted a holistic view of the domain including the study of human behavior, design, research methods, management, and testing. While much has changed over the years, the core guiding principles of the program have remained constant: Conclusion
So Agile Together: How designers and programmers can join forces to create great experiences Earlier this year, I attended a UX meetup that featured a panel discussing whether or not integrating UX designers into the agile software practice works. I noticed during the discussion that the panelists made strong distinctions between "developers" and UX designers. While this is commonplace, it stood out to me because I’m primarily working on the development side as a programmer, but I have an interest and background in user experience. I realize the need in larger organizations to hire for specific positions, but I think that as long as we maintain these distinctions, UX designers will not be able to effectively work within the agile software process. I also think the skill sets and aptitude for programmers and UX designers have significant overlap. Common Ground One of the principles listed on agilemanifesto.org is that, “Continuous attention to technical excellence and good design enhances agility.” People work much better together when they can find common ground. Creative Techies
7 Agile Best Practices that You Don’t Need to Follow There are many good ideas and practices in Agile development, ideas and practices that definitely work: breaking projects into Small Releases to manage risk and accelerate feedback; time-boxing to limit WIP and keep everyone focused; relying only on working software as the measure of progress; simple estimating and using velocity to forecast team performance; working closely and constantly with the customer; and Continuous Integration – and Continuous Delivery – to ensure that code is always working and stable. But there are other commonly accepted ideas and best practices that aren’t important: if you don’t follow them, nothing bad will happen to you and your project will still succeed. And there are a couple that you are better off not following at all. Test-Driven Development Teams that need to move quickly need to depend on a fast, efficient testing safety net. TDD is not only a way of ensuring that developers test their code. Pair Programming In Pair Programming Considered Harmful?
Given-When-Then Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using SpecificationByExample. It's an approach developed by Dan North and Chris Matts as part of Behavior-Driven Development (BDD). [1] It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-Phase Test pattern. The essential idea is to break down writing a scenario (or test) into three sections: The given part describes the state of the world before you begin the behavior you're specifying in this scenario. Since we're talking about using examples as specifications, it makes sense to show this with an example [2] The above example uses Cucumber [3], which a popular way of writing BusinessFacingTests but you can use the Given-When-Then style with any kind of tests. It's usual with this approach to see "ands" used to combine multiple expressions within each clause. 2: from Pete Hodgson
Pair Programming Interviews September 11, 2013 About Me My name is Parth Upadhyay and I'm a rising senior at the University of Texas at Austin, majoring in Computer Science. This summer, I interned at Square on the Register team. Interviewing At Square When I first started exploring internship opportunities at Square, I didn’t know a lot about the engineering culture at Square—that is until I came in for pair programming interviews. Square's interview, however, was really different. I was confused. Sensing my confusion towards this foreign interview style, he explained that he wanted me to be comfortable coding on the machine so we could actually focus on the problem we would solve, and not have to worry about the cruft surrounding it. After setting up the environment, I did 3 pairing interviews with 3 different Square engineers. These interviews stood out because I was coding just as I would in the real world.
Why Usability Testing Matters: A Newbie's Perspective As a designer, I’m a perfectionist. I enjoy solving problems, analyzing human intuition, and testing all the available research tools to turn ideas into something viable and realistically executable. This heuristic, analytical approach to design was what shifted me from advertising into software in the first place. I enjoyed leading creative teams, driving process innovation, managing campaigns, and sharing with and learning from other designers. But ultimately, I didn’t find designing for advertising rewarding. Working in software, I can test my ideas and get honest feedback — on the spot. User Testing as Validation – The Best Way to Build Confidence Designers are validation junkies. When the client asks you, “How do you know it will work?” We encourage clients to participate in these sessions, to see first-hand the value in how this new product idea addresses their needs. It’s all about the ride, not the destination. I see the software interface as a means to an end.
Beware of Capybara Interacting with Hidden DOM Elements Due to a project’s integration tests spuriously reporting failures with capybara-webkit on our CI servers, we switched to the capybara-selenium driver. In the process of switching, we discovered that a number of tests needed to be tweaked or partially rewritten. Why? It turned out that capybara-webkit was allowing us to interact with invisible or hidden DOM elements, but capybara-selenium prohibited this. Some of the issues stemmed from naughtiness on our part. For other tests, we discovered there were timing issues related to animations. Regardless, it was an eye-opening experience to realize that our tests were not running at all like we expected.
Your Tests Are Your Conscience Have you ever inherited a project without any tests? Trying to get a foothold in the code can feel daunting, let alone feeling confident about making changes. I recently took over a project that lacked any tests, and as I began to explore the code, I came to a realization. Despite the fact that the app had known issues and a general air of “bugginess,” the code wasn’t terrible. You can understand your language inside and out. Writing tests exposes the “pain points” in code. Here are just a few “paraphrases” of code problems I saw in the project I inherited, problems I attribute to the lack of tests. Repetition This particular block of code (plus or minus a few key/value pairs) occurs as the last statement in three or four action methods on a controller. This code has a different — but closely related — issue. Overloaded Responsibility In this app, the create function on the main controller is almost 200 lines long. Spaghetti Code As for me and my projects, I’ll be writing tests.