이 책을 빠르게 읽어 보았다. 비폭력 대화로 가장 유명한 책은 좀더 전에 읽었더랬다. 이 책을 통해서 다시금 비폭력 대화에 대해 생각해 볼 수 있는 시간이 있어 감사하다.

Joseph Campbell의 말이 언급된다. 놀이가 아닌 일은 살면서 하지 마라. 여기서 놀이는 내가 삶을 통해 자라는데 기여하는 어떤 것이라고 정의하고 있다.

비폭력 대화는 관찰, 느낌, 욕구, 부탁의 구조를 가지고 있다. 여기서 핵심은 욕구라고 할 수 있다. 욕구를 Needs라고 표현하니, 즉 필요라고 이해하니 좀 더 도움이 되었다.

내 삶의 욕구를 채워가는 일이 뭘까? 놀이 아닐까?

그렇다면, 비폭력 대화를 통해 나의 욕구에 천착하는 훈련이 많이 된다면 삶이 풍성해진다는 논리가 생기는 거 같습니다. 그렇다면 NVC는 참 알아둘만한 가치가 있어 보인다.

이제 "기린과 자칼이 함께 춤출 때"라는 제목의 책 한 권 더 읽으면서 기초 내용에 대한 훈련에 집중해볼 요량이다.

참 분노의 놀라운 목적 관련한 내용도 참 좋았다. 배고픔을 통해 우리가 먹을 것을 찾듯이 분노를 통해 우리가 확인해야 할 욕구를 찾을 수 있다는 것이다. 분노라는 감정을 선하게 활용하자.

[24.02.01]

ISP, 즉 정보화에 대한 전략을 수립하는 것에 대해 정리해 본다.

ISP가 생겨 난 배경이 뭘까? 정보화 전에는 무엇이었는지를 살펴보는게 순서일듯 하다. 전산화였다. 전산화는 기술 영역의 이야기다. 그럼 정보화는? 경영 영역이 이야기다. 기술에서 경영으로 시선이 이동했다는 이야기다.

ISP가 뭐다라는 얘기는 제일 첫 문장에서 언급했지만 다시금 리마인드를 해보자. 최적의 정보화를 추진해 나가기 위한 중장기 전략을 계획하는 것, 즉 중장기 IT 마스터 플랜을 수립하는 것이라고 통상 정의한다.

왜 필요한가? 배경에서 언급했듯이 기술에서 경영으로 세상 사람들의 시선과 관심이 이동해서 필요하다고 설명할 수 있다. 추가적으로 전사 구성원의 정보화에 대한 이해 및 마인드 향상을 위해서 필요하다고도 설명할 수 있다.

ISP를 하고 나서 기대가 되는 점은 전산 팀장으로서의 지위, 즉 경영을 지원하는 지위의 낮음에서 CIO, 정보기획, 정보전략이라는 타이틀로 경영에 연계된 정보를 제공하는 지위로의 상승을 가져올 있다.

이제 ISP를 어떻게 진행하는지에 대해 살펴볼 차례이다. 분석이 필요하다. 내가 가야할 방향을 수립하기 위해서는 외부환경, 내부환경, 그리고 개선하고자 하는 실제 영역의 수준을 점검할 필요가 있다. 이것이 환경 분석이라고 하면 업무 분석도 필요하다. 업무 체계, 업무 양식, 사용 정보 등이 필요하고 정보시스템 현황 분석이 필요하다. 그리고 하드웨어, 소프트웨어, 네트워크 등 IT 인프라에 대한 현황 분석이 필요하겠다.

이렇게 분석한 다음에는 개선 모형 설계를 위해 구조적인 접근이 필요하다. 업무 관점의 정보 구조, 시스템 관리 관점의 정보 관리 구조, IT 인프라 관점의 정보 기반 구조, 이렇게 세 가지 영역의 정보 측면의 구조에서 조망하며 개선 과제를 도출하자. 이런 다음 세부 사항을 개념 모델에 포함시키면서 하위 설계를 진행하며 실행계획을 도출하자.

[24.01.17]

의도적 수련 관련된 글, 전문가 만들기라는 글을 봤고, 중요하게 생각되는 부분을 발췌하였다.

전문가는 결국 태어나는 것이 아니라 오랜 기간의 의도적 수련으로 만들어지는 것이다. 끈기와 담력이 그래서 필요하다.

The journey to elite performance is not for the impatient or the faint of heart. It takes at least a decade and requires the guidance of an expert teacher to provide tough, often painful feedback. It also demands would-be experts to develop their “inner coach” and eventually drive their own progress.

It will take you at least a decade to achieve expertise, and you will need to invest that time wisely, by engaging in “deliberate” practice—practice that focuses on tasks beyond your current level of competence and comfort. You will need a well-informed coach not only to guide you through deliberate practice but also to help you learn how to coach yourself. 

How, then, can you tell when you’re dealing with a genuine expert? Real expertise must pass three tests. First, it must lead to performance that is consistently superior to that of the expert’s peers. Second, real expertise produces concrete results. Brain surgeons, for example, not only must be skillful with their scalpels but also must have successful outcomes with their patients. A chess player must be able to win matches in tournaments. Finally, true expertise can be replicated and measured in the lab. As the British scientist Lord Kelvin stated, “If you can not measure it, you can not improve it.”

Things to Look Out for When Judging Expertise: Individual accounts of expertise are often unreliable. Anecdotes, selective recall, and one-off events all can present ...

They continually work to eliminate their weaknesses.

Deliberate practice involves two kinds of learning: improving the skills you already have and extending the reach and range of your skills.

Moving outside your traditional comfort zone of achievement requires substantial motivation and sacrifice, but it’s a necessary discipline. As the golf champion Sam Snead once put it, “It is only human nature to want to practice what you can already do well, since it’s a hell of a lot less work and a hell of a lot more fun.” Only when you can see that deliberate practice is the most effective means to the desired end—becoming the best in your field—will you commit to excellence. Snead, who died in 2002, held the record for winning the most PGA Tour events and was famous for having one of the most beautiful swings in the sport. Deliberate practice was a key to his success. “Practice puts brains in your muscles,” he said.

Before practice, opportunity, and luck can combine to create expertise, the would-be expert needs to demythologize the achievement of top-level performance, because the notion that genius is born, not made, is deeply ingrained. It’s perhaps most perfectly exemplified in the person of Wolfgang Amadeus Mozart, who is typically presented as a child prodigy with exceptional innate musical genius. Nobody questions that Mozart’s achievements were extraordinary compared with those of his contemporaries. What’s often forgotten, however, is that his development was equally exceptional for his time. His musical tutelage started before he was four years old, and his father, also a skilled composer, was a famous music teacher and had written one of the first books on violin instruction. Like other world-class performers, Mozart was not born an expert—he became one.

출처: https://hbr.org/2007/07/the-making-of-an-expert

참고: 레오폴트 모차르트, 아들에게 올인 한 아버지의 명암, https://www.joongang.co.kr/article/25149895

[23.12.07]

크리스토퍼 알렉산더의 책에 관심이 간다. 그의 인생과 책을 접해보고 싶고 일단 the nature of order 4권을 읽어 보는게 내 버킷 리스트에 들어왔다.

일단 이 영상부터 보고 있다. 아쉽게도 그는 작년에 사망했다

https://www.youtube.com/watch?v=xmlo0Lva5AU

[23-10-23]

애자일 원칙의 첫번째는 소프트웨어의 조기 및 지속적인 제공을 통한 고객 만족이다. 

두번째는 고객 만족이 구체적으로 어떤건지를 설명하고 있다. 요구사항이 변경되더라도 환영하고 활용하여 고객의 경쟁력을 제고하는 것이라고 말한다. 

이제는 소프트웨어를 어떻게 제공하는 것이 좋은지에 대한 추가적인 설명을 세번째 원칙에서 언급하고 있다. 즉 자주 제공하고 가능한 짧은 주기로 제공하여 보다 빠른 피드백을 통해 고객에 제공되는 가치를 극대화할 수 있도록 하라 말한다. 

이제는 이렇게 가치 있는 소프트웨어를 빠르게 자주 제공하고 요구사항 변경을 수용하여 고객 만족을 극대화하기 위해 사람들은 무엇을 해야 하는지 네번째 원칙에서 설명하고 있다. 우선 비즈니스 요구사항을 알고 있는 현업과 그 요구사항을 받아 소프트웨어를 만들어야 하는 개발자 간에 매일 같이 협업을 해야 한다고 말한다. 

그럼 어떻게? 다섯번째로 모든 사람이 목적 의식을 통해 동기를 탑재하고 보다 일을 잘 할 수 있도록 필요한 환경 및 지원을 제공하고 신뢰 가운데 목적하는 일을 해낼 수 있도록 하라 말한다. 

다시 어떻게? 소통을 통해, 즉 여섯번째로 얼굴을 보고 하는 대화를 통해 의사소통의 질을 최대한 높이라 말한다.

여기까지로 애자일 12원칙의 반환점을 돌았다.

일곱번째,, 7월달^^.. 그렇다면 애자일에서 일의 진척은 무엇으로 측정하는 가에 대해 언급한다. 즉 일의 진척은 가치의 누적을 얘기할테고 결국 일의 진척은 가치가 담기는 것을 살펴봐야 하는데 그 가치가 담겨야 할 대상이 작동하는 소프트웨어이다. 즉 가장 중요하게 가치있게 여겨야 하는 것은 다름 아닌 소프트웨어이다.

그렇다면 가장 바람직한 진척의 모습은 어떤가? 계속 속도가 빨라지는 건가? 그렇게 되면 좋겠으나 현실적으로 그렇게 될 수 없다. 그래서 우리가 구해야 하는 것을 여덟번째 언급하고 있다. 일정한 속도다. 이것이 곧 부지런함이다. 부지런함의 반대가 경솔함, 서두름인 경우도 있다. 무리하게 속도를 높이지 않는다. 그것이 지혜로운 프로세스다.

왜 속도가 계속 올라갈 수 없는가? 왜 최선이 일정한 속도인가? 아홉번째에서 알려 주고 있다. 할 일이 있기 때문이다. 품질을 보살펴야 하는 것이 그것이다. 품질을 보살핀다는 것의 구체적인 양상은 기술적 탁월성과 좋은 설계에 관심을 갖는 것이다. 

이제 열번째다. 자릿수가 바뀌었으니 다시금 우리가 집중하는 것이 무엇인지 환기할 필요성이 있다. 바로 우리가 비용을 들여 달성하고자 하는 원하는 것인 가치이다. 가치를 높이는 일이다. 가치를 높이려면 어떻게 해야 하는가? 취사선택을 해야 한다. 이때 사용하는 본질적인 도구가 단순성의 원칙이다. 복잡한 것은 별로 가치를 가지고 있지 않은 것이 섞여 있을 때 만들어진다. 다시금 가치를 기준으로 솎아 내면 단순해진다. 그러니 단순함을 달성하는 일이 쉽지 않다. 가장 어렵다.

결국 높은 가치를 달성해야 하는 걸로 우리가 해야 할 일이 귀결된다. 그럼 어떻게? 열한번째에서 그 비결을 알려주고 있다. 사람들로 하여금 자율적으로 조직할 수 있도록 해줘야 한다. 그것만이 가장 효과적으로 주어진 요구사항을 충족하는 최선의 아키텍처와 설계를 찾아낼 수 있는 방법이기 때문이다.

이제 다 된건가? 고객의 가치, 비즈니스 가치가 중요하고, 그 가치를 높이기 위해 관계된 사람들이 책임과 권한을 바르게 행사하는 팀다운 팀으로 구성되었다. 끝? 아직 끝나지 않았다. 열두번째 지혜의 말이 제시된다. 반복이다. 그간의 프로세스를 되짚어 보고 세밀하게(tune) 혹은 다소 큰 틀에서(adjust) 개선 포인트를 발견하고 적용하는 숙달의 과정이다. 유능으로 가는 길은 오직 반복뿐이다.

[23.10.04]

첫번째 애자일의 원칙은,

1. Early and continuous delivery of valuable software
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

어디에 방점이 찍히는가? 핵심 키워드를 뭐로 고를 것인가?
고객 만족? 가치있는 소프트웨어의 이르고 지속적인 제공?
둘다 무게감이 있어 쉽지는 않은 선택이나 원인이 되는 소프트웨어의 이르고 지속적인 제공을 나라면 고르겠다.
요즘과 같이 비즈니스 가속화가 중요해지는 시점에 이 애자일의 원칙은 곱씹을 충분한 내용이라 할 수 있다.
이 원칙에서 떠오르는 단어가 있다면 피드백이다.
고객과 개발자 간에 소통을 무엇으로 하는가? 가치있는 소프트웨어로 한다. 가치있는 소프트웨어를 같이 보면서 소통, 즉 피드백을 한다. 그렇기 때문에 MVP와 같이 기능을 하는 소프트웨어를 빠르게 제공하여 비즈니스를 아는 사용자의 피드백을 받을 때 똘똘한 기능을 탑재한 목적에 맞는 소프트웨어의 탄생을 기대할 수 있게 된다.
애자일 선언에는 원칙 말고 가치도 있다.
개인, 상호작용, 작동하는 소프트웨어, 고객과의 협업, 변화에 대응이 말하고 있는 가치인데,, 첫번째 원칙은 이 가치를 전반적으로 다 터치하고 있다.

2. Embrace change
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

두번째 애자일 원칙은 요구사항을 변경하는 것을 받아들여라이다. 개발 프로젝트 후반부라 할지라도.. 애자일 프로세스는 고객의 경쟁력을 위해 변경을 이용한다. 끌어 안을 뿐 아니라 장려한다. 사람도 바뀌고, 시간도 바뀌고, 시장도 바뀐다. 이런 상황에서 변경을 해결해야 할, 피해야 할 문제로 바라보는 것은 맞지 않다.  문제가 아닌 기회로 인식하여 이용하고 활용하라는 소리다.
harness라는 단어를 유심히 보자. 말이나 개에 채워 주는 장비.. 말의 경우는 마구라고 한다. 통제하거나 이용하기 위한 장비이다.
물론 모든 변경을 환영하라는 이야기는 아니다.

애자일의 3, 4, 5, 6번째... 네가지 원칙을 한꺼번에 살펴본다.
잦은 딜리버리, 협력, 자율과 동기, 보다 나은 의사소통의 원칙들.. 암기하자. 가슴에 새기자.

3. Frequent delivery
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

세번째는 딜리버리를 자주 하라는 것이다. 첫번째에 이른 딜러버리를 얘기하고 있고 이 원칙이 겹치는 부분이 있어 보이긴 하지만 이 원칙을 한번 더 별도로 언급하는 이유는 그 의미를 다시 떠올려야 하기 때문이다. 짧은 주기로 딜리버리를 하게 되면 무엇이 좋은가? 에러가 날 확률이 낮아진다. 그리고 고객의 피드백을 받을 기회가 많아져 프로젝트가 탈선할 가능성을 원천봉쇄한다. 애자일의 원칙 중 핵심이라 해도 무방한 것 중 하나가 이것으로 생각되지 않는가.

4. Cooperation
Business people and developers must work together daily throughout the project.

네번째는 협력의 원칙이다. 전에는 분석가가 있어 비즈니스 요구를 해석해서 개발 계획을 수립했고, 프로젝트 관리자가 고객과 개발팀 간 중재를 하는 방식이었다면 이제는 현업과 개발자가 프로젝트 내내 매일 같이 일하는 환경이 중요하다. 왜냐하면 이로 인해 의사소통과 협력이 자연스럽게 되고 서로의 상황을 보다 더 이해할 수 있다. 

5. Autonomy and motivation
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

다섯번째는 자치와 동기에 대한 원칙이다. 마이크로 관리는 지양해야 한다. 개발자는 자기 일에 자부심이 강하다. 지나친 관여는 무익하다. 성공에 대한 동기부여가 되어 있지 않다면 당연히 실패로 가게 되지 않겠는가. 관리자는 개발자와 건강한 관계를 유지하고 개발자가 일과 삶의 균형을 가질수 있도록 신경 써야 한다. 개발자에게 성공을 향한 동기를 유발하라, 그러면 보다 자연스러운 프로젝트 개발 공정이 펼쳐질 것이다. 

6. Better communication
The most efficient and effective method of information to and within a development is face-to-face conversation.

여섯번째는 보다 나은 의사소통에 대한 원칙이다. 팀즈 등 소통의 도구가 있으나 대면 미팅의 효과를 초월할 수는 없다. 해석 과정에서 정보를 잃게 되고, 이메일은 수신함에 묻혀 잘 전달되지 못한다.

애자일의 12개 원칙에 대해 마무리를 해 볼까 한다.

7. Working software
Working software is the primary measure of progress.

일곱번째 원칙은 작동하는 소프트웨어에 관한 것이다. 작동하는 소프트웨어로 진척의 정도를 가늠하라는 것이다. 여기서 소프트웨어를 제품으로 치환하면 좀 더 명확하게 그 의미를 알 수 있다. 그렇다면 어떤 잘못을 저지르지 말라는 것인가? 요구사항 분석 문서, 모델, 목업(mock-ups)은 쓸모는 있을 수 있으나 그 정보가 작동하는 제품으로 전환되지 못하면 대단히 유용하다고 볼 수 없다는 의미이다. 문서 작업에 집중하기보다 제품을 만들어내는 것을 극대화해야 한다. 완성되지 못한 제품은 재고일 뿐이다. 재고는 가치를 제공하지 못하는 비용일 뿐이다.

8. Stable work environments
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

여덟번째는 안정적인 작업 환경에 대한 것이다. 애자일 방법을 정확히 구현하였다면 납기를 맞추기 위해 야근을 밥먹듯 할 필요가 없다. 이해관계자와 고객과 개발자가 긴밀한 한팀으로 행동하는 것을 요구하기 때문이다. 한 팀의 구성원들이 정보를 공유하게 되면 정확한 예측, 예산, 타임라인을 만들어내기가 무척 쉬워진다. 고객은 개발자에게 무엇이 필요한지 얘기할 수 있고, 이해관계자는 변경이 개발에 어떤 영향을 주는지 이해하게 되며 팀은 어떻게 진척이 되는지에 관하여 정보가 제공된 상태에서 결정이 가능해진다. 누구도 개발 과정에 대해 모르지 않으며 예상치 못한 개발로 인해 놀라게 되는 상황도 없다. 이로 인해 스트레스가 줄어들고 번 아웃되는 일이 없게 된다.

9. Quality assurance
Continuous attention to technical excellence and good design enhances agility.

아홉번째 원칙은 품질 보증에 관한 것이다. 품질보다는 속도와 양에 우선순위를 두는 경우가 있는데, 이렇듯 품질에 오랫동안 관심을 갖지 않게 되면 제품을 고객의 요구에 민첩하게 대응하도록 할 수 없게 된다.

10. Simplicity
Simplicity—the art of maximizing the amount of work not done—is essential.

열번째 원칙인 단순성은 일곱번째 작동하는 소프트웨어와 비슷한 구석이 있다. 다만 작동하는 소프트웨어는 불필요한 문서 작업을 경계하는 것이라면 이 원칙은 프로세스에 관한 부분이다. 불필요하게 복잡하거나 도움이 안 되는 프로세스는 필요없다. 그리고 자동화 할 것이 있다면 그렇게 해서 단순성을 제고해야 하고 과거 프로젝트의 기존 자산이 있다면 적극 활용해야 한다. 개선의 여지는 항상 있고 그걸 찾으려고 해야 한다. 이 원칙은 계속되는 노력을 기울여야 달성할 수 있다.

11. Self-organizing teams
The best architectures, requirements, and designs emerge from self-organizing teams.

이 열한번째 스스로 조직하는 팀 원칙은 다섯번째인 자율성과 동기와 비슷해 보인다. 과거의 개발팀은 기능별로 구획화 되었다면 애자일에서 얘기하는 개발팀은 여러 개인이 하나의 유닛을 구성해서 자율적으로 품질 보증을 해 나가면서 개발한다. 이로써 상위의 관리자가 세부 관리를 할 필요가 없게 된다.

12. Reflection and adjustment
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

마지막 열 두번째 원칙은 애자일 방법론이 비즈니스 전략과 잘 어우러지는지에 대한 PoC 개념의 원칙이다. 회고와 조정이 되려면 의사소통, 피드백, 애자일 방법에 대한 이해, 실수로부터 혁신과 배움을 도출하려는 공감대가 필요하다. 팀이 완벽할 수는 없다. 다만 개발을 개선하기 위해 사전적 혹은 사후적 측정을 통해 성숙하고 정보에 근거하며 책임감 있는 팀이 되어야 한다.

이제 애자일의 원칙을 전반적으로 들여다 보았으니 암송하고 각각을 묵상해 나아가라.
차미리사 여사가 말씀하신 것처럼 자기것으로 체화하려면 끊임없는 묵상만이 유일한 길이다.
("살되, 네 생명을 살아라. 생각하되, 네 생각으로 하여라. 알되, 네가 깨달아 알아라.")
장담컨데, 이 열 두가지 원칙을 제대로 알고 적용할 수 있다면,
그로 인해 애자일이 지향하는 가치가 무엇인지 깨달을 수 있다면,
그 사람은 애자일 전문가이고, 뭘 해도 잘 할 수 있다고 믿는다.
알지 않은가.
해 아래 새것은 없다. 몰라서 못 하는게 아니다. 제대로 알려고 하지 않고 성숙의 길에는 그만큼의 댓가가 필요한데 그걸 지불할 생각이 없는 것이다.

1. 가치 있는 소프트웨어를 이르고 지속적으로 배달 하라
2. 변경을 끌어 안아라
3. 자주 배달 하라
4. 협력하라
5. 자율과 동기
6. 보다 나은 의사소통
7. 작동하는 소프트웨어
8. 안정적인 근무 환경
9. 품질 보증
10. 단순성
11. 스스로 조직하는 팀
12. 회고와 조정

이게 다다.

출처: https://www.knowledgetrain.co.uk/.../agi.../agile-principles

[2023.08.11, 올해 초반에 해서 페북에 올렸던 것을 오늘 정리해서 옮겨 놓음]

애자일의 가치는 네가지인데.. 두 그룹의 사람과 두 그룹의 사람 사이에 위치한 소프트웨어,, 그리고 이 사람들과 소프트웨어를 둘러싼 변화관리에 대해 얘기를 하고 있다.

두 그룹의 사람들 중 먼저 개발자 관련한 가치..

소프트웨어 개발의 업은 그 복잡도가 높다. 그래서 일의 프로세싱이 개발자의 머리에서 대부분 일어난다. 따라서 소프트웨어 개발의 성패 혹은 품질에 대한 담보는 동기가 부여된 능력 있고 협업 및 책임감 높은 개개인의 역량이 중요하고 그들 간의 상호작용이 중요하다는 소리다. 물론 프로세스 측면과 도구 측면도 중요하지만 말이다. 이게 애자일 가치의 첫번째 덕목이다.

두번째는 업의 중심에 있는 소프트웨어에 대한 얘기다. 네가지 가치 중 가장 중요하다 할 수 있다. 소프트웨어 개발 일에서 가장 중요한 가치가 담기는 것은 뭘까? 문서일까? 소프트웨어 자치일까? 이것에 대한 주장이다. 소프트웨어 개발에 있어 가장 중요한 산출물이 소프트웨어이기 때문에 일의 진척에 대한 판단을 소프트웨어로 해야 하고 일의 모든 중심은 작동하는 소프트웨어 관점에서 판단되고 얘기되어야 한다는 소리다.

세번째는 소프트웨어 담길 피처, 기능의 발원지라 할 수 있는 고객 혹은 사용자에 대한 내용이다. 두 종류의 사람 그룹을 가치에서 언급하고 있다 했는데 개발자 그룹에 이은 두번째 종류의 그룹이 업무 진영의 사람, 즉 소프트웨어를 사용하는 사용자 그룹이다.

이들과는 계약도 하지만 계약이 중요한 것이 아니라 계약 성사 후 소프트웨어를 만들어 나감에 있어서 지속적인 협업이 중요하다는 소리다. 단순한 일이 아니기 때문에 개발하는 주체인 개발자도 중요하지만 개발자가 해야 할 일을 정해 주는 사용자의 지속적인 관심과 참여도 중요하다는 것이고, 이 가치를 상실하면 소프트웨어 개발 프로젝트는 실패한다는 소리다.

마지막 네번째 가치는 이 사람들과 소프트웨어 사이에서 일어나는 일이 모든 일이 마찬가지이겠지만 변화에 대한 관점이 중요하다는 소리이다. 변화를 인정하느냐, 난 모르겠고 처음에 결정된 계획을 사수해야 하느냐의 문제다. 소프트웨어 개발에 담길 피처, 기능에 대한 식별 작업의 난해함 때문이겠는데 소프트웨어 개발에 있어 처음부터 완벽한 계획이 나올 수 없다는 진실을 깨달아야 한다. 따라서 지속적인 계획의 수정 및 조정이 필요하다는 소리다.

이렇게 가치에 대한 나의 생각을 "소리다" 네번으로 정리해 보았다.

[2023.08.09]

Agi #3

애자일 선언과 원칙에 대해 두루 두루 보고 있는 중이다. 원칙은 선언을 뒷받침하고 있다.

선언은 네가지이다. 개인 및 상호작용, 동작하는 소프트웨어, 고객과의 협업, 변화에 대응.. 이렇게다.

원칙은 열 두가지이다. 각각 선언과 매칭을 시키려 하였으나 그런 맥락은 아니라 본다. 원칙이 선언 여러개에 걸쳐 의미를 가질 수 있다.

열 두가지 원칙은 12개의 이모티콘과 키워드로 정리를 하고 있는데도 있으나 원칙 전체의 의미를 같이 보는게 좋다고 본다. 키워드로 정리하면서 훼손되는 의미가 있어 보이기 때문이다.

그래서 스마트폰에 선언과 원칙을 옮겨 놓고 계속적으로 상기해 볼 요량이다. 왜냐하면 이게 소프트웨어 개발의 핵심이고 정수이기 때문이다.

일단 12개의 원칙을 떠올려 본다. 음~~

첫번째 원칙이라 그런지 고객 만족이라는 원칙이 기억난다. 소프트웨어 개발의 가장 중요한 우선순위가 고객 만족이라는 것이다. 고객 만족을 하는데 도구가 되는 것은 무엇일까에 대한 언급도 있다. 문서 산출물이나 납기가 이루어지는 시점이 아니다. 가치있는 소프트웨어이다. 고객이 원하는 기능이 탑재된 소프트웨어이다.

다음은 일곱번째 원칙으로 넘어간다. 소프트웨어 개발은 진척관리도 중요한 포인트인데 뭐로 진척 관리를 하면 되는가에 대한 물음에 답이 될 수 있는 원칙이다. 소프트웨어 개발의 진정한 진척의 척도는 동작하는 소프트웨어를 봐야 한다. WBS의 태스크로 두리뭉실 퍼센트 화 해서 숫자를 인위적으로 만들어 80% 진척.. 이렇게 하면 안 된다. 그냥 이제껏 만든 소프트웨어를 데모하고 그거 보면 자연스레 어느 정도 진척이 되었는지 아는 것이다.

일정한 속도를 내야 한다는 원칙도 있다. 일정한 속도는 여러가지로 유용하리라.. 뭐겠는가? 일정한 속도를 내게 되면 이러 이러한 기능을 이 팀이 얼마동안의 일정으로 개발 가능한지가 나오기 때문이다. 납기 준수에 대한 자신감을 확보할 수 있다는 점이다.

그리고 자치적인 팀을 만들라는 원칙도 있다. 뭐가 비즈니스에서 생존하기 위한 원칙인가? 돈 많이 주는게 동기 부여의 답이 아니다. 특히 지식 노동의 영역에서는 더더욱 그렇다. 목표, 자치, 전문성 이것이 경쟁력의 삼요소이다. 피플웨어에서 강조하듯이 소프트웨어 개발의 핵심 자원은 사람이다. 그런 사람들로 팀을 만들어야 하는데 그 때 자율성을 갖는 self organizing 요소의 확보가 중요하다는 원칙이다.

짧은 주기로 빈번한 배포를 해야 한다는 원칙도 있다. 가시성 확보와 맥이 닿아 있다.

의사소통 관련한 원칙도 중요하다. 문서, 이메일, 전화, 대면 미팅 등에 대한 혜안을 갖게 해주는 통찰이다.

회고에 대한 원칙도 있다. 효과적인 방법을 곰곰히 생각하고 그것을 팀내 프로세스로 도입하라는 원칙이다.

개인의 기술 역량과 좋은 설계가 일정한 속도를 담보하며 결국은 민첩성을 달성하게 한다는 원칙도 있다.

단순성이 중요하다는 원칙도 있는데, 이는 불필요한 낭비 요소가 있는지 확인하고 그러한 일들을 제거하는 노력이라는 측면으로 설명하고 있다. 하지 않아도 되는 일을 하지 않을 때 소프트웨어 개발 현장이 단순하고 깔끔해진다.

요구사항 변경에 대한 태도도 언급한다. 프로젝트 막판에 요구사항 변경을 수용할지 말아야 할지에 대한 기준이다. 애자일은 프로젝트 막판에도 요구사항 변경을 환영해야 한다고 말한다. 그런데 거의 대부분의 프로젝트에서 어떠한가? 영향도 운운하며 요구사항 변경을 하면 안된다고 피 터지게 싸우지 않는가? 물론 이렇게 여유롭고 호기롭게 요구사항 변경을 수용하려면 좋은 설계라는 탄탄한 기반이 뒷받침되어야 한다.

애자일 선언과 원칙을 넘나 들며 올바른 소프트웨어 개발에 대한 관점을 견지해 나가다보면 좋은 날이 오리라~

Agi#1

Agur를 닮기로 한 크리스천이라는 정체성 말고 직업적인 정체성으로 생각한 것은 Agile Coach 이다. 줄여서 Agi... Agu와 Ag를 맞추기 위함이고 구별하기 위함이고..

소프트웨어 개발이란 영역은 쉬운 영역은 아니다. 그만큼 여러 주장들이 난무하고 실패할 확률도 많은 업이다.

지금 수행하고 있는 프로젝트도 지연이 될려고 하니 말이다.

그런데, 30여개의 프로젝트를 하면서 생각이 머무는 것은 Agile이라는 프레임워크가 유념하고 기억하면 참 좋은 사상이라는 점이다. 지식이 난무하고 범람하는 가운데 중심을 잡아주기에 충분한 생각들이다. 그래서 잘 살펴 보고 내 것으로 만들어 놓으면 피가 되고 살이 된다.

그리고 또 한가지는.. 생각하라는 것이다.

우리나라 사람들 똑똑하다. 하지만 아직 소프트웨어 개발의 국내 현실을 보면 아쉬운 부분이 너무 많다.

이는 생각을 깊이 하지 않고 좋은 머리라는 자만으로 너무 피상적인 접근을 하고 있어서가 그 이유이지 싶다.

그래서 지금 독서 토론회를 1회 마쳤고, 2회를 시작하려고 하는 "The Nature of Software Development"는 참 고마운 책이다. 책의 모토가 "생각하라"이기 때문이다.

이 책에서 던지는 화두들을 웹사이트에도 차곡 차곡 모아 나갈 생각이다. 암튼 장독대에 간장, 된장 담그듯이 충분히 생각하는 여유를 가져 보자.

참.. Agi는 매주 월수금에 할 저널링이다.

Agi#2

이번주도 직업 현장을 마무리하는 시점이 왔다. 즐거운 금요일이고 크리스마스 이브이다. 오늘은 건강 검진을 받고 오후는 한가하게 보내고 있어 감사하다.

크리스마스가 한해의 마지막에 있어 좋다. 한해를 정리하고 한해를 계획하는 일은 참으로 중요한데 예수님의 탄생도 생각할 수 있기 때문이다. 예수님의 탄생은 삶의 마지막에 대한 묵상거리를 주기에 충분하지 않은가.

암튼..

나의 인생책인 소프트웨어 개발의 본질(nature)를 1월 초가 되면 두번째 온라인 독서 토론회를 하게 된다. 이 책은 애자일 선언을 한 사람 중 한 사람인 론 제프리스의 책이다. 이 책을 통해 애자일을 깊이 있게 이해할 수 있다. 그리고 더불어 애자일 선언과 원칙이 있는 사이트를 방문하게 만들었다.

애자일 선언은 다 알지만, 아니 모를 수도 있다. 피상적인 세상을 살고 있지 않은가. 본질에 입각한 통찰은 깊은 사색의 강을 넘은 사람만의 전유물이지 않는가.

애자일 선언은 소프트웨어 개발의 가치에 대한 선언이다. 소프트웨어 개발에 있어 무엇이 가치가 있느냐에 대한 발견의 공유다.

비교법을 사용하여 가치에 방점을 찍은 것들을 강조하고 있다. 오늘은 네 개의 방점 중 첫번째 것을 다루어 본다.

개인에 대한 것과 상호작용에 대한 것이다.

개인이 중요하고 여러 개인 간의 상호작용이 중요하다는 것이다. 비교법이라고 했으니 뭐보다?

프로세스와 도구이다. 프로세스와 도구도 일을 진행하는데 있어 사용이 되고 그 안에 개인 및 상호작용도 발견할 수 있다. 액티비티 담당자인 역할자로 개인이 등장한다. 워크플로우(일이 마쳐지면 다음 일로 던져 주는 도구)가 되었든 위키, 게시판이 되었든 도구도 소프트웨어 개발 현장에서 발견되고 어떤 때는 도구가 중요하다고 도구 도입에 집중하는 경우도 있다.

이런거다. 개인, 상호작용, 프로세스, 도구..

다 중요해 보인다. 뭐가 더 중요한지 잘 모르겠다. 하지만 고수들은 경험이든 학습이든 자기만의 철학이 있고 믿음이 있는 것이다.

소프트웨어 개발은 햄버거를 찍어내는 단순 생산이 아니다. 지식 노동이다. 그럼 그에 걸맞는 옷이 있어야 한다. 그런 옷에 개인, 상호작용이 더 잘 어울린다는 것이다. 명품 옷이라는 것이다.

프로세스와 도구를 어설프게 적용하면 소프트웨어 개발의 본질인 개인, 상호작용이 훼손될 수 있다는 것이다. 그래서 개인의 역량, 개인의 태도, 개인 간의 cross functional한 상호작용에 가치를 두고 잊지 않아야 한다고 강조하는 것이다.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools