'애자일 개발'에 해당되는 글 2건

  1. 2009/06/02 Application Lifecycle Management
  2. 2008/07/11 마인드맵 정리 - 애자일 개발 방법을 적용한다는 것은 어떻게 하면 되는 것인가?
2009/06/02 08:13

Application Lifecycle Management


 

ALM (Appplication Lifecycle Management)


이미지 출처: http://www.camwood.com/images/services/management.jpg

What is Application Lifecycle Management?

  • It's common to equate ALM with the software development lifecycle (SDLC)
  • application's lifecycle includes the entire time during which an organization is spending money on this asset, from the initial idea to the end of the application's life.

ALM Benefits

  • Agility
    • Through the collaboration and application of "just enough" processes
  • Predictability
    • Through better estimation, better communication and more repeatable processes
  • Auditability
    • Traceability of work back to a business need, accountability for each change or decision made and the ability to separate concerns
  • Quality
    • Through more-effective management of requirements, design and quality processes
  • Productivity
    • Through the continuous improvement of processes and practices, and more effective utilization of resources
  • Low Cost of Failure
    • Minimizing the error costs with goal-orientated diagnostics

Application lifecycles are characterized by specific demands in phases

ALM SCOPE

  • Business /IT Governance View
    • Governance
    • Standards Compliance
    • Long Term Program Management
  • Development View
    • Project Management
      • Project Management
      • Project resources can be managed with this tool (Time/Budget/Scope).
    • Requirement Management
      • project and product requirement specification (SRS) is documented
    • Modeling
      • Project or product is defined and modeled in software design specification (SDS)
    • Documentation
      • Shipped applications should be documented with tools.
    • Development
      • Editing/Debugging/Profiling/Testing environment for software development
      • This is commonly an IDE
    • Testing
      • Some tools for quality team.
      • Not only unit test but also integration and stress tests must be included
    • Release Management
      • Package and Deployment tools are needed for version and change management.
    • Bug Management
      • As the system goes alive, users find many bugs.
  • IT Operation View
    • Data Management
      • Application data requires maintenance
    • Performance Management
      • Performance is one of the biggest problems of enterprise applications
    • Runtime Management
      • Applications run-time should be easily managed.
    • Deployment (Configuration Management)
      • Application should be easily deployed to the target system without pain.
      • Upgrade or new system installation should be done to the running system with acceptable or zero down-time with automated tools.

ALM market

  • Tools that are focused on enabling agile (in particular, scrum)
  • ools that are building from strength in an ALM submarket (such as software change and configuration management [SCCM])
  • Tools that take a complete suite view
  • Tools that are positioned as an integration hub

크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Trackback 0 Comment 0

Trackback : http://blog.mandki.com/trackback/144 관련글 쓰기

2008/07/11 08:30

마인드맵 정리 - 애자일 개발 방법을 적용한다는 것은 어떻게 하면 되는 것인가?



애자일 프랙티스

1.애자일 시작하기

  • ?
    • 어떻게 애자일을 시작할 수 있을까?
  • !
    • 결과를 위해 일하라
      • 비난은 버그를 수정하지 못한다.
      • 가능한 해결책을 제시하라.
      • 중요한 것은 긍적인 결과다.
    • 땜질식 수정에 빠지지 말자
      • 몇 줄만 고쳐봐... 동작하쟎아
      • 근본적인 문제를 해결해야 한다.
    • 사람이 아니라 아이디어를 비평하라
      • 누구의 아이디어가 더 나은지를 입증하는 것이 아니라
      • 해결책에 도달하는데 자부심을 가져라
    • 문제가 있다면 사실을 얘기해라
      • 고양이 목에 방울달기
        • 누구든 방울을 달아야 한다.
      • 진실을 얘기할 수 있는 용기를 가져라

2.애자일 기르기

  • ?
    • 애자일의 구체적인 실천방법은?
  • !
    • 기술의 변화에 따라가야 한다.
      • 변화에 뒤쳐지면 안된다.
      • 변화에 대한 자극을 지속적으로 받아야 한다.
    • 팀에 투자하라
      • 팀이 흥미를 보이는 기술이나 프로젝트를 이롭게 할 기술을 도입하자
    • 버려야 할때가 언제인지 알자
      • 새로운 기술을 배우고 예전 기술은 버려라.
      • 결국 구형차보다는 새차가 휄씬 낫다.
    • 이해할 때까지 질문하라
      • 계속 왜 냐고 물어봐라.
      • 쟁점이 되는 내용의 핵심을 이해할 때까지 계속 질문하라.
    • 리듬을 느껴라
      • 일이 쌓이기 전에 부딪쳐라.
      • 일상들을 규칙적으로 유지해서 반복적으로 작업할 수 있도록 하라.

3.사용자들이 원하는데로 만들기

  • ?
    • 진짜 사용자 요구사항에 맞추어 개발하려면?
  • !
    • 고객이 결정하도록 하라.
      • 개발자/관리자/비즈니스 분석가가 비즈니스에 대한 결정을 내려서는 안된다.
      • 사업주가 직접 결정하도록 하라.
    • 설계가 강요하는 대신 안내하도록 하라.
      • 좋은 설계는 지도다. 스스로 진화하게 하자.
      • 설계(혹은 설계자)에게 인질로 잡혀서는 안된다.
    • 필요에 따라 기술을 선택하라.
      • 먼저 무엇이 필요한지 정하라.
      • 어떤 기술의 사용에 결정적인 질문을 하고 진실하게 답해보라.
    • 항상 릴리즈 가능하게 하라.
      • 항상 컴파일할 수 있고, 실행할 수 있으며, 테스트하고 배포할 수 있도록 하라.
    • 규칙적으로 계속 통합하라.
      • 코드 통합은 주요 위험 요인이다.
    • 항상 어플리케이션을 자동 배포할 수 있도록 하라.
      • 배포테스트도 함께 해야 한다.
    • 데모를 자주하여 피드백을 받아라
      • 개발 과정의 결과물을 항상 고객이 볼수 있게 해라
      • 고객과 매주 또는 2주에 한번씩 데모를 해라
    • 반복 개발을 짧게 하고 점진적으로 배포하라.
      • 초소의 유용한 기능 단위로 묶어서 제품을 릴리스 하라.
    • 실제 일을 기초로 해서 예산을 작성하라.
      • 고객이 기능과 예산을 직접 조정할 수 있도록 한다.
      • 고정된 예산이란 있을 수 없다.

4.애자일 피드백

  • ?
    • 요구사항의 변경을 코드에 반영하는 방법은 무엇일까?
  • !
    • 자동화된 테스트 도구를 사용하라
    • 테스트 주도 개발 방법으로 만들기 전에 테스트하라.
      • Test Driven Development
    • 통합 빌드 도구를 사용하여 빌드를 자동하라
      • CruiseControl
    • 핵심 비즈니스 로직은 별도로 개발하고 테스트 하라.
    • 모든 사용자 불평은 진실을 담고 있다.
      • 진실을 찾아 진짜 문제를 해결하라.
    • 실질적인 진척 상황을 측정하라.
      • 현실성 없는 측정기준으로 자신이나 팀을 기만하지 말자

5.애자일 코딩

  • ?
    • 코드를 유연하고 수정가능할 수 있게 유지하는 방법은?
  • !
    • 독창적이지 않고, 명확하게 코드를 작성하라
      • 읽기 쉽지 않은 코드는 독창적이지 않다.
    • 코드를 주석화하라
      • 좋은 코드를 대신하려고 주석을 사용하지 말자.
      • 잘 고르고 의미 있는 이름을 사용해서 코드를 문서화 하라
    • 합리적으로 릴리즈를 계획하라
      • 하찮거나 미비한 성능이나 우아함을 위해서 디자인을 복잡하게 하지 말라.
      • 성능, 편이성, 생산성, 비용, 기간에 맞추어 릴리즈 계획을 세워라
    • 코딩 범위를 짧게 유지하라.
      • 짧은 수정/빌드/테스트 주기 안에서 코드를 작성하라
    • 코드를 단순하게 만들어라
      • 패턴/원칙/기술을 사용해야 하는 부득이한 사정이 있을 때만 적용하자.
      • 단순한게 최고다
    • 클래스에 집중하고 컴포넌트는 작게 유지해라
      • 커다란 클래스나 컴포넌트 혹은 잡다한 클래스를 작성하려는 유혹을 피해라.
    • 묻지 말고 말해라
      • 다른 객체나 컴포넌트의 일을 떠맡지 마라
    • 위임은 언제나 상속보다 바람직하다

6.애자일 디버깅

  • ?
    • 디버깅을 효율적으로 수행하는 방법은?
  • !
    • 문제와 해결책을 로그로 남겨라
      • 문제를 해결하는 일의 일부는 나중에 해결책을 찾고 적용할 수 있도록 하라
    • 경고를 에러처럼 다루자
      • 경고가 있는 코드는 에러나 테스트에 실패한 코드를 체크인 한 만큼 나쁘다
    • 문제를 나누어서 해결하자
    • 모든 예외를 처리하거나 전달하라
      • 예를 덮어 두지 말자.
      • 코드가 실패할 수 있다록 생각하며 작성하라
    • 유용한 에러메세지를 제공하라.

7.애자일 협력

  • ?
    • 애자일 팀이 되기 위한 방법들은?
  • !
    • 스탠드업 미팅을하자
      • 회의를 짤고 집중적으로 하자
    • 좋은 디자인은 좋은 프로그래머에서 진화한다.
      • 진짜 통찰력은 적극적인 코딩 작업에서 나온다.
      • 코드를 작성하지 않는 아키텍트를 기용하지 말자.
    • 코드를 공동 소유하라
      • 다른 모듈이나 태스트를 교차해서 개발하라
    • 멘토가 되자
      • 아는 것을 공유하는데 즐거움이 있다.
    • 서로에게 답을 주기 보다는 해결 방법을 알려줘라
      • 스스로 해결하면서 배울수 있게 하라.
    • 준비되었을 때만 코드를 공유하라
      • 다른 사람이 쓸 수 있도록 준비되지 않은 코드는 절대 체크인 하자 마라.
    • 모든 코드를 리뷰하라.
      • 코드 리뷰는 코드 품질을 개선하고 에러를 낮추는데 매우 가치 있는 것이다.
    • 다른 사람에게 계속 알려라
      • 조사한 자료나 아이디어등을 다른사람들과 함께 나눠라

참고자료

  • 애자일 프랙티스 - 알라딘
    • 애자일 프랙티스 - 10점
      벤컷 수브라마니암 & 앤디 헌트 지음, 신승환.정태중 옮김/인사이트

크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
Trackback 0 Comment 0

Trackback : http://blog.mandki.com/trackback/57 관련글 쓰기