FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
OGIS Scalable Agile Method の真髄（後編） | オブジェクトの広場
既存の見積もり方法を用いた場合の見積もり精度 一括（請負）契約が可能か 開発依頼者の関与がどれくらい必要か 以降、推敲フェーズ終了時点での要求の不確定性の大きさで場合分けして議論します。 まず、不確定性が小さくなる場合（大→小、中→小）では、不確定性が小さくなる作成フェーズ以降は従来の見積もり方法で費用を見積もり、開発スコープと費用を定めた一括（請負）契約が可能になり、開発依頼者の負荷も減ります。 不確定性が中ぐらいの場合（大→中、中→中）では、不確定性が中ぐらいで残るため従来の見積もり方法で精度よく費用を見積もることが困難であり、契約上の選択肢は準委任契約になります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。 不確定性が大きいままの場合（大→大）については、開発スコープが定まらないために、開発スコープと費用を定めた一括（請負）契約を結べないことになります。そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
