Need for speed?

Need for speed?

https://richrtesting.com/2018/12/11/need-for-speed/?fbclid=IwAR2jRWcngvGNCdedGAP8700yiuMkZwVlbgz-ePxZCrCapYO5uKvwT-IDHFc

Need for speed?

속도에 필요한 것?

Posted on December 11, 2018 by richrtesting                

This article was written for, and originally published by TechBeacon as ‘How to deliver speed without losing your customers’. You can find that original article here.

---

The complex relationship between velocity and quality

속도와 품질 간의 복잡한 관계

There is a widespread narrative that in software development and deployment, faster is better.

소프트웨어 개발과 배포에서 빠른 것이 좋은 것이라는 광범위한 이야기가 있다.

The inexorable move among teams and organisations towards methods associated with Agile principles has been followed by the rise of DevOps practices. For businesses, a desire to make changes to software more quickly, and to get these changes to customers at shorter intervals, has been one of the primary motivators in adopting these method and practices.

애자일 원리와 관계 있는 방법론을 향한 팀과 조직 사이의 멈출 수 없는 이동은 데브옵스 (DevOps) 관행이 부상한 뒤로 이어져왔다. 사업적으로 소프트웨어를 더 빠르게 변경하고 이러한 변경을 고객에게 더 짧은 간격으로 전달하려는 열망은 이러한 방법과 관례를 적용하는데 있어 주요한 동기 중 하나가 되고 있다.

Organisations that have succeeded in implementing mechanisms which allow them to deploy code changes frequently and rapidly are held up as examples of how things could (and perhaps should) be done. The likes of Facebook, Netflix and Amazon are able to deploy code changes multiple times each day, and other organisations aspire to the kind of models that allow these companies to do so.

코드 변경 사항을 빈번하고 빠르게 배포할 수 있는 메커니즘을 구현하는데 성공한 조직은 어떻게 그것을 할 수 있었는지에 (그리고 아마 해야만 했는지) 대한 예시를 보여준다. 페이스북, 넷플릭스와 아마존 같은 업체는 매일 여러 번 코드 변경을 배포할 수 있으며 다른 조직들은 이러한 회사들이 그것을 할 수 있었던 여러 가지 모델을 열망한다.

Whilst there is far more to DevOps culture and practices than rapid, frequent deployment, some of the most eye catching claims and statistics that have emerged about these organisations’ software practices over recent years relate to speed and frequency, notably Amazon’s famous 2011 revelation that they could deploy to Production every 11.6 seconds. Yet, leading proponents of DevOps have also emphasised the importance of quality, and with good reason as there are undoubtedly challenges associated with making change at pace.

데브옵스의 문화와 관행에는 빠르고 빈번한 배포보다 더 많은 것이 있긴 하지만 최근 몇 년간 이러한 조직의 소프트웨어 관행에 관해 제기된 눈에 띄는 주장과 통계 중 일부는 속도, 빈도와 관련이 있다. 특히 매 11.6초마다 사용자 환경에 배포 가능하다는 2011년에 나온 아마존의 유명한 폭로가 그렇다. 하지만 데브옵스의 선도적인 지지자들은 품질의 중요성을 강조하고 있으며 본인의 속도로 변화를 만들어 내는 것과 관련해 명백한 도전과제가 존재한다는 훌륭한 이유도 제기한다.

Whether you believe these quality challenges are given appropriate attention probably depends a great deal on what you understand quality to mean.

당신이 이러한 품질 도전과제에 합당한 관심을 두고 있는지는 아마 당신이 품질을 어떻게 이해하는지에 크게 좌우될 것이다.

If you believe that it is the development and distribution mechanisms – the processes, methods and tools involved in creating, deploying, and maintaining software – that really matter; that if we optimise these, then we will naturally deliver on quality, then you may well be convinced that many of the challenges have indeed been addressed. After all, much discussion and debate has contributed to the refinement of practices, and there are undoubtedly some clever and reliable tools which allow some of the tasks involved to be automated and the systems themselves to be monitored.

만일 당신이 이것을 개발과 배포 메커니즘이 (소프트웨어를 만들고 배포하고 유지보수하는데 포함되는 프로세스와 방법론 그리고 도구) 진정으로 중요하다고 믿고 이것을 최적화한다면 우리는 자연스럽게 품질을 유지한 채로 배포하여 많은 도전과제들이 실제로 처리되었다고 확신할지도 모른다. 결국 많은 토론과 논쟁이 그것의 정제된 실천에 기여했으며 확실히 자동화와 시스템 그 자체의 모니터링을 가능케하는 영리하고 신뢰성 있는 도구가 존재한다.

If however, you believe that quality can only be truly assessed through the perception of the human beings that the software is intended to serve, that the relationship between person and product is what really matters, then there are some factors in this relationship which might be worthy of greater consideration.

하지만 당신이 품질은 소프트웨어가 서비스를 제공해야 하는 인간의 지각을 통해서만 진정으로 처리될 수 있고 사람과 제품 사이의 관계가 진정으로 중요한 것이라고 믿는다면 이러한 관계에 몇 가지 요소가 존재한다는 걸 논의하는 것이 가치 있을 것이다.

Business need and the benefits of speed

비즈니스의 요구와 속도의 이익

Firstly, lets look at some of the reasons why, for some businesses, speed of delivery can itself be considered an important factor in quality. There can be compelling business reasons for adopting mechanisms that facilitate rapid deployment, and they can bring great benefits to customers too:

먼저 비즈니스 관점에서 왜 배포 속도 그 자체를 품질에서 중요한 요소로 고려해야 하는지에 대한 이유를 살펴보자. 빠른 배포를 가속화하는 메커니즘을 적용해 고객에게 큰 이익을 가져다 주어야 하는지에 대한 중요한 비즈니스상의 이유가 있다.

• Changes allow companies to demonstrate a willingness to listen and rapidly respond to customer feedback which can be elicited through direct contact with customers (e.g. from surveys and product reviews), or through means which are less apparent (e.g. telemetry). If direct and indirect feedback from customers is properly analysed and considered, and if objective decisions are made about which changes which will provide a better experience, then there are clear benefits for both businesses and the people they intend to serve.

• 변화는 회사가 경청할 준비가 되어 있음을 나타내며 고객의 직접적인 요청 (예를 들면 서베이나 제품 리뷰) 또는 덜 명확한 방법을 통해 (예를 들면 원격 측정) 촉발될 수 있는 고객이 주는 피드백에 대한 빠른 응답을 나타낸다. 만일 고객으로부터 오는 직접적이고 간접적인 피드백이 올바르게 분석되고 고려되어 어떤 변화가 더 나은 경험을 제공할지에 관한 객관적인 결정이 내려지면 비즈니스와 그것의 서비스를 받는 사람 양쪽 모두에게 명백한 이익이 된다.

• In dynamic markets, being the ‘first mover’ – the first company to get to market with a product or feature – can provide a competitive advantage, and for software applications a quick and reliable deployment mechanism facilitates this. Such mechanisms can also enable ‘fast followers’ – those companies who move quickly into the market with a similar product or feature – to respond if a competitor gets there first.

• 동적인 시장에서 ‘퍼스트 무버’가 되는 것은 (제품이나 기능을 가지고 시장에 처음 등장한 회사) 경쟁력을 제공한다. 그리고 소프트웨어 어플리케이션에 있어 빠르고 믿을 수 있는 배포 메커니즘은 이것을 가속화한다. 또한 그러한 메커니즘은 경쟁자가 그곳에 처음으로 도달했을 때 반응하는 ‘패스트 팔로워’를 가능하게 한다 (유사 제품이나 기능을 가지고 시장에 빠르게 뛰어드는 회사).

• For the customers who use products, mechanisms for rapid and frequent change mean that problems can potentially be resolved quickly. The mechanisms also offer opportunities to be the first to try new features or own new products. Novelty can be a quality aspect for some. Why do people line up outside Apple stores for hours (or even days) in order to be the first to use a new iPhone model? Because they want to be the first to experience the new features provided, and probably want to be able to tell their friends about it. To them, novelty matters.

• 제품을 사용하는 고객에게 있어 빠르고 빈번한 변화를 위한 메커니즘이 그 문제가 잠재적으로 빠르게 해결될 수 있다는 걸 의미한다. 또한 이 메커니즘은 새로운 기능 또는 자신의 신규 제품을 처음으로 시험해 보는 기회를 제공한다. 참신함은 어떤 면에서는 품질의 요소가 될 수 있다. 왜 사람들이 새로운 아이폰 모델을 최초로 사용해 보기 위해 애플 스토어 바깥에서 몇 시간 동안 (또는 며칠 동안) 줄을 설까? 왜냐하면 그들은 새로운 기능을 최초로 경험해 보기 원하며 아마 그것에 대해 친구에게 이야기할 수 있게 되기를 원하기 때문일 것이다. 그들에게 있어 참신함은 중요하다.

The potential benefits of rapid, frequent change to businesses and their customers seem clear, but there are other considerations which are less commonly discussed but which should not be ignored.

비즈니스와 고객에게 빠르고 빈번한 변화가 주는 잠재적인 이익은 명확해 보인다. 하지만 덜 논의되었고 무시해서는 안 되는 다른 고려사항이 존재한다.

When is a product not a product?

언제 제품이 제품이 아닌 것이 되는가?

Fundamentally, frequent change dramatically alters the notion of a ‘product’. In many instances, the software we purchase is not the same product that we use after a week, a month or a year. Whilst many of the code changes made to software may be hidden from the person using the product (perhaps to improve performance, stability or security), over time there are likely to be some visible changes too; features may be added, altered or removed, and methods of operation, the look and ‘feel’ might also alter.

기본적으로 빈번한 변경은 ‘제품’의 개념을 극적으로 바꾼다. 많은 경우 우리가 구매한 소프트웨어는 한 주, 한 달 또는 일 년 이후 사용하는 제품과 동일한 제품이 아니다. 소프트웨어에 만들어진 많은 코드 변화가 제품 사용자에게 숨겨지지만 (아마 성능, 안정성 또는 보안성 개선) 시간이 지나며 몇 가지 가시적인 변화가 존재할 가능성이 크다. 즉 기능이 추가되고 변경되거나 삭제되어 운영 방법이나 룩앤필 같은 것 또한 변경될 것이다.

Video games are a good example of this changing landscape. A decade or more ago, a gamer may have visited a store, decided which game to purchase, and returned home with a disc to use with a games console. The game itself might offer different modes of play and configuration options, but these would be limited to whatever was contained on the disc. The product, no matter how complex or rich in features it might be, did not change.

비디오 게임은 이런 변화하는 풍경의 좋은 예이다. 십여 년 전에 게이머는 가게를 방문해서 어떤 게임을 구매할 것인지 정해 게임 콘솔에 사용할 디스크를 가지고 집으로 돌아왔다. 그 게임 자체는 서로 다른 게임 모드와 설정 옵션을 제공하지만 이것들은 디스크 안에 담긴 것의 제약을 받았을 것이다. 그 제품이 얼마나 복잡하든지 또는 기능이 풍부하든지 이 사실은 변하지 않는다.

Digital distribution has fundamentally altered the relationship. A gamer might now download an initial version of a game but this core game is likely to be altered through updates over time. New game modes might be added, additional characters made available, menu structures changed and so on. Patches and upgrades are required. The product changes. It could be argued that it has now taken on the characteristics of a service.

디지털 배포는 그 관계를 근본적으로 바꾸었다. 게이머는 이제 게임의 초기 버전을 다운로드 받지만 이 코어 게임은 시간이 지나며 업데이트를 통해 변경될 가능성이 높다. 새로운 게임 모드가 추가되고 추가적인 캐릭터가 가용해지며 메뉴 구조가 바뀌는 식이다. 패치와 업그레이드가 요구된다. 제품은 변한다. 이제 이것이 서비스의 특성을 갖췄다고 주장할 수도 있다.

So what does all of this mean for quality?

그럼 이 모든 것이 품질에 있어 의미하는 바는 무엇인가?

Despite the benefits, there are effects associated with frequent change which might not be desirable to some of the people who use software products. Here are some examples:

그런 장점에도 불구하고 소프트웨어 제품을 쓰는 사람 중 일부가 바라지 않는 빈번한 변화와 관련된 효과가 존재한다. 다음은 그러한 예이다.

Familiarity

친숙성

Some people may simply prefer that products retain the characteristics and features which existed when they made the decision to purchase them, or when they first used them. This might not be a concern to people (including those of us who work in software development) who are comfortable with technology, but what about people who perhaps take time to familiarise themselves with the appearance and operation of software? If they use the software in question to carry out important tasks – for example using a banking app to pay rent, or an energy company website to pay a bill which allows them to keep their home warm – readjusting to changes might be confusing or worrying.

어떤 사람들은 제품을 처음 쓰거나 구매 결정을 내릴 때 기존의 특성과 기능을 유지하는 제품을 그냥 선호하기도 한다. 이것은 기술을 편안하게 느끼는 사람과 관련된 것은 아니다 (소프트웨어 개발에서 일하는 사람도 포함해서). 그러면 소프트웨어의 외관과 동작에 그들 자신이 친숙해질 시간이 필요한 사람들은 어떨까? 만일 그들이 중요한 작업을 수행하는데 불안한 소프트웨어를 쓴다면 (예를 들어 월세를 내는데 은행 앱을 쓰거나 집을 따뜻하게 데우려고 고지서를 납부하는 에너지 회사의 웹사이트의 경우) 변화에 다시 적응하는 것은 혼란스럽거나 걱정거리일 수도 있다.

How might changes which visually alter a screen, and are straightforward for fully sighted people to adapt to, affect somebody who is visually impaired? Small changes could confuse but significant changes here could be bewildering.

It is not the case that everybody values change and novelty. For some, familiarity might be crucial to their perception of quality.

어떻게 하면 시각적으로 한 화면을 바꾸는 변화가 시각적으로 정상인 사람들이 적응하기에 직관적이며 시각적으로 불완전한 사람에게 영향을 줄 수 있을까? 여기서 작은 변화는 혼란을 줄 수 있지만 큰 변화는 당혹스럽게 될 수도 있다. 이 경우는 모든 사람들이 변화와 참신성에 가치를 두는 상황이 아니다. 일부는 친숙성이 자신이 인식하는 품질에 중요할 수도 있다.

Availability

가용성

Means of downloading and installing patches or upgrades can also affect perception of a product. Delays, preventing us from using software until a new version of a product is installed, or a device is restarted, can be great sources of irritation, particularly when there is an urgent need to use software. The person running late for an important video call for example, will not welcome a lengthy upgrade to the software.

다운로딩과 패치 설치 또는 업그레이드하는 방법은 제품에 대한 인식에 영향을 줄 수 있다. 새 버전의 제품을 설치할 때까지 소프트웨어 사용이 금지될 때 지연은 짜증을 유발하는 큰 원천이 될 수 있고 소프트웨어를 급하게 사용해야 하는 경우 특히 더 그렇다. 예를 들어 중요한 비디오 전화를 늦게 실행하는 사람은 그 소프트웨어의 긴 업그레이드를 환영하지 않을 것이다.

Meanwhile, downloading large update files can be problematic for those with limited mobile data allowances, or limited bandwidth available on a home network. Such updates can take time, limit access to network features and cause frustration for others too. Preventing family members from streaming their favourite show in the evening is not likely to generate goodwill.

Frequently updating your product counts for little if people are frequently prevented from using it.

거대한 업데이트 파일을 다운로딩하고 있는 중인 상황은 모바일 데이터가 제한적인 사람이나 집안 네트워크 대역폭이 제한적인 사람에게 문제가 될 수 있다. 그러한 업데이트는 시간이 걸리고 네트워크 기능 접근에 제한을 만들어 다른 사람들에게 좌절감을 준다. 저녁에 가족들이 좋아하는 쇼를 스트리밍으로 보지 못하게 막는 것은 좋은 감정을 주지 못할 것이다.

Assistance

지원

A person’s experience with a product can depend on far more than the code which drives its operation. Support and communication can be crucial elements, particularly when introducing something new or changing the way something works after a long period of consistent behaviour. The help offered within a product may require adjustment, staff may need to be trained, and communications to customers about changes may also be required. If changes or new features are not matched with accurate and reliable support mechanisms, confusion and frustration is likely to result.

제품을 통한 누군가의 경험은 그것을 동작시키는 코드 그 이상의 것에 의존적이다. 지원과 의사소통은 중요한 요소이며 특히 무언가 새로운 것을 도입하거나 장기간 일관된 행동을 보인 이후 작업 방식을 바꾸는 경우 더욱 그렇다. 제품에서 제공하는 도움말도 조정이 필요하며 지원 인력의 훈련도 필요하다. 또한 변화에 대해 고객과 의사소통하는 것도 필요할 수 있다. 만일 변화와 새 기능이 정확하고 믿음직한 지원 메커니즘과 일치하지 않는다면 혼란과 좌절은 필연이 될 수 있다.

Meanwhile, there are important accessibility considerations associated with changes, for example screen reader compatibility, alternative text and accessible form controls which could make those changes, and perhaps critical features, unusable for people who rely on your product.

예를 들면 화면 리더 호환성의 경우 변화와 관련한 중요한 접근성 고려사항이 존재하는 반면에 대안 텍스트와 접근성 폼 컨트롤은 그러한 변화를 일으킬 수 있으며 아마도 당신의 제품에 의지하는 사람에게 부적절하거나 중요한 기능이 될 수도 있다.

The balancing act

균형을 잡는 활동

Some basic principles can help balance the pace of delivery with these risks to quality:

몇 가지 기본적인 원리가 품질에 대해 이러한 리스크를 가진 채로 제품을 출시하는 페이스에 균형을 맞추는데 도움을 준다.

Size over speed

속도 대비 크기

A focus on incremental change (rather than rapid change) with smaller, more targeted adjustments typically carries less risk. Specifically:

작지만 증감적인 변화에 초점을 맞추고 (급격한 변화 대신에) 목표가 명확한 조정은 대체로 적은 리스크를 동반한다. 구체적으로는

• changes in operation, look and feel are likely to be less noticeable and therefore can be more easily accommodated by people who value familiarity
• upgrade file sizes will be reduced, installation times shorter and therefore the process less disruptive
• simple instructions can be used to communicate the nature of the change in a consumable and learnable way.

• 운영과 룩앤필에서의 변화는 덜 주목 받을 가능성이 있다. 따라서 친숙성에 가치를 두는 사람이 쉽게 적응할 수 있다.
• 업그레이드 파일 크기가 감소되면 설치시간이 짧아지고 따라서 그 프로세스가 덜 방해하게 될 것이다.
• 간단한 명령은 소비성이며 학습 가능한 방식으로 변화의 성격을 전달하는데 쓰일 수 있다.

A byproduct of this may be that changes can be made more rapidly and more frequently, but the emphasis on size rather than speed is a healthy one for quality overall.

이것의 부산물은 변화를 더 빠르고 더 빈번하게 만들 수도 있다. 하지만 전체적인 품질에 관해 속도보다는 크기에 대해 강조하는 것이 더 건설적이다.

Speed is nothing without control

속도는 제어가 없으면 아무것도 아니다

in this case, the control that matters is the control that the people who use an application have over the changes that are made, and when they are made. A feeling of control can result from:

이 경우 중요한 통제는 어플리케이션을 사용하는 사람들이 변경의 내용과 변경 시기에 대해 가지는 통제이다. 통제감은 다음의 경우 발생할 수 있다.

• providing opportunities for people to react to features and other changes they like or don’t like
• simple configuration options to toggle changes on and off where possible, or in some cases retaining existing behaviour or appearance with an option to switch changes on (rather than the other way round)
• choice over when to install an upgrade, and clear information on the implications (e.g. the file size, likely duration of an installation, need for restarts)

• 그들이 좋아하든 좋아하지 않든간에 기능과 다른 변화에 사람들이 대응할 선택권을 제공한다.
• 가능하다면 변화를 켜고 끌 수 있는 간단한 설정 옵션 또는 어떤 경우 변화를 전환하는 옵션을 통해 기존 동작이나 외관을 유지한다 (다른 우회 방법을 제공하기 보다는).
• 업그레이드를 설치할 때 선택권을 주고 그것이 의미하는 바에 대한 명확한 정보를 준다 (예를 들면 파일 크기, 대략적인 설치 시간, 재시작 필요 여부).

Focus on the human factor

인간적인 요소에 집중

Think about the people using your product, then really think about the people using your product and their needs. Empathy for your customers, colleagues or anyone else using your product can go a long way in providing them with a rewarding experience. For example:

당신의 제품을 사용하는 사람에 대해 생각한다. 이후 당신의 제품을 사용하는 사람과 그들의 요구에 대해 진정으로 생각한다. 당신의 고객, 동료 또는 제품을 쓰는 그 밖의 누군가에 대한 공감은 그들에게 보람있는 경험을 제공하는 긴 여정이다. 예를 들면

• consider Accessibility for every change you make and factor in regular checks for potential Accessibility problems
• offer simple and understandable opportunities to learn about changes and how to enable or disable them
• keep all support channels – e.g. documentation, support staff, forums and communities – well informed about what has changed but also why it has changed
• if you are not able to offer choice or control (e.g. an urgent security patch is required), communicate why this is the case

• 당신이 만드는 모든 변화의 접근성을 고려한다. 또한 잠재적인 접근성 문제를 주기적으로 점검할 것을 고려한다.
• 변화에 대해 배우는 간단하고 이해 가능한 기회와 그것을 활성화 또는 비활성화할 수 있는 기회를 제공한다.
• 예를 들면 문서화, 지원 인력, 포럼 그리고 커뮤니티 같은 모든 지원 채널을 유지한다. 무엇이 바뀌었는지 뿐만 아니라 왜 바꿨는지에 대해 잘 알린다.
• 만일 당신이 선택이나 통제를 제공할 수 없다면 (예를 들어 시급한 보안 패치가 필요한 경우) 왜 이런 경우인지 의사소통한다.

Recognising the great advantages that speed of delivery can bring does not mean that there isn’t time for considering some of the risks to quality that may come with the territory, and it certainly doesn’t mean losing sight of the people software is intended to help. As we adjust our products, taking time to think about the different needs and desires that those people might have can help remind us that it is their product too. After all, what is the advantage in delivering at speed if we don’t meet people’s needs?

배포의 속도가 가져올 거대한 장점을 고려하는 것이 품질 리스크를 고려할 시간 부족을 의미하는건 아니다. 또한 그것이 확실히 소프트웨어가 도움을 줘야 할 사람들의 시야를 잃게 만드는 것도 아니다. 우리가 우리의 제품을 조정할 때 그것이 그들의 제품인 것을 우리에게 일깨워 주는 사람들의 서로 다른 요구와 열망에 대해 생각할 시간을 가진다. 결국 우리가 사람들의 필요를 충족시키지 않는다면 속도감있게 배포하는 것의 이익이 무엇인가?

• 끝