タグ

Agileに関するjo-taroのブックマーク (10)

  • Jazzに見る開発ツールの要件

    Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.

  • 5分で分かる、「スクラム」の基本まとめ

    5分で分かる、「スクラム」の基まとめ:開発チームを改善するためのスクラムTips(8)(1/2 ページ) 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み(フレームワーク)」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ

    5分で分かる、「スクラム」の基本まとめ
  • スクラム (ソフトウェア開発) - Wikipedia

    複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくア

  • [Think IT] 第4回:アジャイルにおけるドキュメント作成ポイント (1/3)

    【楽々デブドックを書こう!】手法別開発ドキュメントの書き方 第4回:アジャイルにおけるドキュメント作成ポイント 著者:ウルシステムズ 深谷 勇次 公開日:2008/02/28(木) 開発の現場「受託型アジャイルモデル」 最終回の今回はアジャイルモデルにおける開発ドキュメントを作成する上での重要なポイントを解説していきます。アジャイルモデルはソフトウェアの要件を最初にすべて決めるのではなく、開発を進めながら顧客の要望に柔軟に対応していくのが特徴です。そのため、顧客と開発業者が1つのチームとして、同じ場所で作業をすることが推奨されます。仕様決定者が常時プロジェクトに滞在しているため、要件の獲得や仕様の確認作業をスムーズに進めることが可能です。 しかし現実には請負という契約形態に縛られて、事前に要件の大枠を決めなければならなかったり、顧客と開発業者が別の場所で作業せざるを得なかったりするものです

  • アジャイル開発者の習慣―acts_as_agile:第4回 ドキュメントを大切にする|gihyo.jp … 技術評論社

    ソースがドキュメントだ。バグも完全に記述されている。 ――まつもとゆきひろ[1] はじめに 連載ではアジャイル開発を「アジャイルに開発する人たち(アジャイル開発者)が開発するからアジャイル開発」と考え、アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。 これまでの3回を費して紹介した「フィードバックを重視する」「⁠仕組みを育てる」「⁠スケール間に連続性を築く」といった習慣は、チームによるシステム開発の現場でアジャイルにプログラムを書くことを重視したものでした。 しかし、これでは開発対象となるシステムを構成する2つの要素のうち主に1つしか説明していません。2つの要素とは、プログラムとドキュメントです。今回は、これまであまり触れてこなかった、2つの要素のうちの1つであるドキュメントに関する習慣を紹介します。 そのためにまず、アジャイル開発者にとってのドキュメントの位置づけを説明

    アジャイル開発者の習慣―acts_as_agile:第4回 ドキュメントを大切にする|gihyo.jp … 技術評論社
  • アジャイル開発ではドキュメントを書かないって本当?(1/5) - @IT

    連載 開発をもっと楽にするNAgileの基思想 第1回 アジャイル開発ではドキュメントを書かないって当? ――より良いコミュニケーションを実践するコツ―― 福井コンピュータ株式会社 小島 富治雄(Microsoft MVP 2006 - Visual C#) 2006/02/22 はじめに 連載は、人気連載「NAgileで始める実践アジャイル開発」の姉妹版となる別枠の新しい連載である。「NAgileで始める実践アジャイル開発」の連載が基的にプラクティスを実行する方法やツールにフォーカスしているのに対し、連載ではアジャイル開発の基思想を身に付けるためのコツを中心に書いていこうと思う。 どちらの連載もNAgile開発を実践するうえで欠かせない知識となるので、基版「NAgileで始める実践アジャイル開発」と姉妹版「開発をもっと楽にするNAgileの基思想」の両連載(NAgileシ

  • アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか? そのドキュメント

    アジャイル開発におけるドキュメンテーションの実際(1) ―― 当に必要ですか? そのドキュメント 細谷 泰夫 要求仕様書や設計書から取り扱い説明書(マニュアル)まで,システム開発ではさまざまなドキュメント(文書)を作成する必要がある.特に,ウォータ・フォール・プロセスによる開発の場合は,各開発工程においてドキュメントを作成し,それを次工程に引き継ぐことになる.それでは,分析 - 設計 - 実装 - テストを繰り返しながらスパイラルに開発を進めるアジャイル開発の場合は,どのようなドキュメントをどのように作成しているのだろうか? 連載では,アジャイル開発とウォータ・フォール開発の両方を経験している筆者が,アジャイル開発におけるドキュメントの位置づけや作成方法について解説する.(編集部) 「アジャイル開発注1ではドキュメント(文書)は作らない」と思っておられる方も多いのではないでしょうか.「

  • 現場の成功テクニック[イテレーション編、ドキュメント編]

    一見簡単に思えるアジャイル開発は、ウォーターフォール型にない難しさがある。イテレーション、ドキュメント、コミュニケーション、マネジメントへの対策が必要だ。カギは現場のカスタマイズ。四つの失敗パターンに分けて、成功テクニックを探る。 なぜうまくいかないのか──。NECソフトの安藤寿之氏(第二官庁ソリューション事業部 第三システムグループ 主任)は、プロジェクトマネジャー(PM)として初めて参加したアジャイル開発で、その難しさを痛感した。基については情報収集してマスターしたつもりだった。だがイテレーション内に機能が完成しない、メンバーによって作業内容のブレも大きい、タスクをホワイトボードに張り出しても数が多すぎて管理しきれないなど、失敗の連続だった。安藤氏はハプニング続きに「なじみのあるウォーターフォール型に戻すことさえ考えた」。 それでもアジャイルには、刻々と変わる要求に対応できる俊敏さや

    現場の成功テクニック[イテレーション編、ドキュメント編]
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。

  • ObjectClub - アジャイル勘違い集

    やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。 アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。 そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。 さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。 アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、 メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。

  • 1