いまの案件の詳細設計書は、ダメだ。必要な情報は書かれてないのに、不要な情報ばかり書いてるから、性能改善を行うために何の処理なのか理解しようと思ったら、プログラムを読んだ方が早いということを、声を大にして叫んでいたら、先輩より「みんなそれでも頑張って書いているから、そこらへんにしてあげて」と言われてしまった。人としては反省。 まず先に書いておくと、私は詳細設計(=内部設計)は必要だと考えている。もし詳細設計書を省略しても成立する案件があるとしたら、それは、外部設計だけでことが済んでしまい詳細設計書が不要なほど小粒の案件か、それ以外のドキュメントで詳細設計で行うべき検討が行われてしまっているかのどちらかだ。前者はともかくとして、後者は、詳細設計工程で検討した内容のまとめとしての詳細設計書はないけど、詳細設計での検討は行っているという意味で、詳細設計書相当はある形になる。 ただ、詳細設計工程で何
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな?誰だっけ、それ言ったの?オレじゃねーよ。お前だよ。おめーの
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
統計の食わず嫌いを直そう(その11)、5分で残存バグ数を予測する方法:山浦恒央の“くみこみ”な話(83)(1/4 ページ) 「回帰分析」は統計分析の有力な手法であり、Excelさえあれば5分で統計的に根拠のある数字を出せます。今回はExcelのツールを使って簡単に残存バグ数を予測する方法を解説します。 1.はじめに 前回は「ワインを飲まずに、ワインの品質を予測する方法」と題して、ざっくりと相関分析の話をしました(統計の食わず嫌いを直そう(その10)、ワインを飲まずに品質を予測する方法)。 「統計の食わず嫌いを直そう」の最終回となる今回は、「統計分析の双璧」のもう一方である回帰分析を用い、Excelの統計ツールで簡単に残存バグ数を予測する方法を解説します。この方法を使えば、5分程度で統計的に根拠のある数字を出せます。 ソフトウェア開発のテストでは、いろいろな終了条件があります。その1つが「予
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!本当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
ビジネスシーンで使えるメッセージングサービスSyncをローンチしました。 その開発の舞台裏をiOSを中心に紹介します。開発のスケジュール、リソース、アプリの規模や進め方など参考になれば幸いです。 サービスについて Syncは社内・社外を問わずプロジェクトやビジネスコミュニケーションがより良い体験なることをゴールに開発しました。以下のURLよりご利用頂けます。 Web版 , Desktop版(OnlyOSX) , iPhone , Andorid アーキテクチャ サーバ 既存のWantedlyサーバに並列して、Syncのサービスをマイクロサービスアーキテクチャ風に構築しています。要素技術や構成はサービスの初期フェイズにおけるスピディーな開発とスモールな運用に適しているものを選定しています。 AccountServerが認証やユーザ情報管理を、APIServerが主要なデータのやり取りをRES
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く