自分の失敗を完璧にフォローされて涙が出るレベルな件｜NZ MoyaSystem
いま勤めている会社ではアジャイル開発を取り入れており、2週間を1スプリントとして管理しています。 各スプリントの終わりにはチーム内での実績報告とレビューを行います。今日はそのレビューでの話。 超絶無能だった自分 そのスプリントでの自分のパフォーマンスは最悪でした。 とある一見単純なバグ修正を、鼻歌交じりで「ふふ〜ん」とコミットしたら、 「残念！ こっちの機能が壊れてます。やり直し :)」 とリーダーからあっさりコードレビューで却下される始末。コードレビュー前に当然走らせておくべきユニットテストの結果確認を怠っていたので何も言い訳できませんごめんなさい……。 で、またコーディングのやり直しとなるわけですが、やればやるほどユニットテストが壊れていくんですよ……。 あちらを立てればこちらが立たず地獄。もともと様々な条件にうまーく対応するように書かれているデリケートな処理なので、ヘタにいじれない部
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
それ、開発しないほうがいいですよ | rake enjoy
うちの会社が開発会社なのと会社名からちょいちょいサービス立ち上げの相談を受けます。そこでどういったサービスを立ち上げるのかなど色々お伺いしていくんですが、結構な確率でお断りすることが多いんですね。その際に 「それ、開発しないほうがいいですよ」 と伝えさせてもらってます。うちは開発会社なので、仕事として請けたほうがメリットも大きいんですが、多分結果誰も幸せにならないだろうなーと思って止めさせてもらってます。 割と同じような話を何回もさせてもらっているので、今回は改めてまとめてみたいと思います。 開発はお金がかかる まず、ここの認識を持ってもらいたいのですが、開発をはじめてしまうと非常にコストがかかるんです。今時はサービスを立ち上げる場合、ローンチして終わりではなく、継続して改善し続けないと成長しないどころか立ち上がってもきません。ですのでリーンスタートアップにも書かれているように小さく立ち上
チケット管理のアンチパターンとベストプラクティス
主語がでかいタイトルですが、自分なりに考えようという目的です。 自分の思考の整理。 何か意見があればガンガンコメントなりツイートなりして欲しい。 前提として、 チケット管理システムは２つぐらいしか使ったことがないので、そちらに偏ってしまうかも。 ちなみにRedmineとBacklog。 （今がRedmineだから多分それに偏る気が） アンチパターン アンチパターンというのかは分からないけど 今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。 ・運用フローが複雑 フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。 抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。 誰もフローに乗ってくれない状態になる。 ・使われていない項目がある なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。 誰かが埋めてくれるだろう、他の人
もうExcel管理は嫌だ！小さなチームを軽量OSSで回そう（DevHub+TaskQuest） - Qiita
これは、小さなチーム管理のためにいろいろ採用したり内製したりした経験のログです。 モチベーション 下記の２つのファイルがあるつらみは計り知れません。 ガントチャート.xls 課題管理表.xls もっと軽量に、楽しく、リアルタイムに、Windows非依存でやりたい。 やりたかったこと 数名レベルの小規模チーム向けに、下記システムを構築したい。 ※ただし、外部にデータがおけないので、オンプレミスで。 情報共有 チャット ちょっとした確認を非同期で行えるようにしたい。 簡易なタスク管理 メンバーのタスクが終わって手が空いたことを知りたい 導入したもの１：DevHub（チャット・通知・情報共有） プログラマの為の開発支援コミュニケーションツール。作業中メモをリアルタイム共有する。 特徴 チャット メモ共有 簡易ブログ機能 チャット＋メモ画面 ブログ機能 ある程度メモに内容がまとまってきたら、 パー
Code Quality Tool & Secure Analysis with SonarQube
In your IDEFree IDE extension that provides on-the-fly analysis and coding guidance Self-managedSelf-managed static analysis tool for continuous codebase inspection
Redmine まだ使ってるの？ Trello 試してみるといいよ。【動画付き】 - Kawaz広報ブログ
こんにちは、ぎぎねっとさんとTetuさんと共に『コミュアゲ』というゲームを作っておりますハワイ長万部です。 さてさて、チーム開発と言えばオンラインレポジトリやタスク管理、円滑なコミュニケーションのとれるチャットツールが不可欠ですね。 『コミュアゲ』ではそれぞれ、GitHubと時々Dropbox（非エンジニア向け）、Trelloと時々GitHub Issue、Slackを活用しています。 さて、その中で今回取り上げるのは Trello 。( https://trello.com/ ) 『コミュアゲ』は自分にとって久々のゲーム開発ということもあって、 「 Slack の使い勝手を試してみたい」 「タスク管理ツールの Trello ってやつを試してみたい」という希望がありました。 Slack は順番前後して、結局 Kawaz全体での Hipchat からの移行が先になりましたが、 Trelloに
2,000人のタスクを一元管理する「JIRA」の使い方！全員の業務負担の可視化に成功 | SELECK
今回のソリューション：【JIRA/ジラ】 今、誰がどんなタスクをどのくらい抱えていて、それぞれの進捗はどのようになっているのか。プロジェクトの管理者やチームマネジメントを行う人であれば、その状況は常に把握しておきたい。 そこで力を発揮するプロジェクト管理ツールのひとつが、「JIRA（ジラ）」だ。開発からビジネスサイドまで、あらゆるタスクを「チケット」として整理し、パワフルなレポート機能によってプロジェクト進捗や各メンバーのタスクの消化率などを可視化する。 「HOT PEPPER」「じゃらん」「ケイコとマナブ」等のサービスを開発・運営する株式会社リクルートライフスタイル。同社でもJIRAを導入し、メールによるタスク管理から脱却したことで、業務フローの整理とコミュニケーションコストの削減に成功したという。 100→2,000と、社内のユーザライセンス数が急拡大したという同社でのJIRAの活用法
開発スピードをあげるには - パルカワ2
「開発スピードをあげろ！」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず！」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
日経電子版 開発内製化の取り組み / nikkei web development 2015
BPStudy#96 でお話した内容です。
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
社名変更のお知らせ
Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
“エンジニア35才定年説に挑戦する” 開発チームのマネジメント
大規模システムの保守における技術的負債とチームのモラル
ユーザのために技術をどう活かすか
Composer
今どきのやり方でWebサービスを作ろう
