チームとプログラミングに関するtakatamaのブックマーク (5)

  • エンジニアを疲弊させる、「やりません」「できません」を言わせない開発チームとは - paiza times

    Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』 こんにちは、谷口です。 開発をしていて、「いま当にこの機能が必要か?」「この納期でその機能作るのは無理だろ」などと思った経験はありませんか? 新人の頃は何も考えずに上に言われたものを作っていた、もしくは作ろうとしたけど無理だった案件があったという人も多いでしょう。上の立場の相手に「この機能、当に必要ですか?」なんて、言いたくてもなかなか言えないものです。 しかし、現場の開発者が「これ要らなくない?」「これはできません」と思っているのにそれを口にできないようなチームって、よい開発チームとは言えないのではないでしょうか。 今回は、エンジニアが「やりません」「できません」と言うことについて考えてみました。 ■それ、当にいま必須の機能ですか? ユーザー「あー顧客情報を一覧で見れたら便利なのになー」

    エンジニアを疲弊させる、「やりません」「できません」を言わせない開発チームとは - paiza times
    takatama
    takatama 2016/07/17
    作ったら負け。まぁ、実際に「引き算」で考えるのは物凄く難しいんだけどね
  • 続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~ – とあるコンサルタントのつぶやき

    とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS (Microsoft Consulting Services) の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが;、二回分のエントリを通して読めば、牛尾さんが言いたい

    続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~ – とあるコンサルタントのつぶやき
    takatama
    takatama 2016/06/24
    すごい大作。請負vs内製の議論を、ウォーターフォールvsアジャイルにすり替えないで論が展開されてて同感
  • 朝会で進捗共有はやらない - ゆるふわカウンターアタック

    朝会で進捗共有する。どこの現場も多いと思います。 必要ですかね?? うちのチームでは朝会で進捗共有はやってません。 進捗のステータスはだいたい3つだと思ってます。 「オンスケ」 「早く終わった」 「ちょっと遅れそう」 そもそも3ヶ月くらい先の仕事がある程度チームでスケジューリング出来てる前提ですが 出来てなかったらマネージャがいないかマネージャが無能のどちらかです。 または、明日には明日の風が吹く現場だったらそもそも朝会とかマクロな話してる場合じゃないです。。 「オンスケ」これは明らかにいらないですね。朝会で全員の稼働を使っての共有?。。いらんいらん。だって問題ないんだもん。 「早く終わった」と「遅れてる」という状況は朝会ですべきじゃないです。それじゃ遅い。特に後者は。それがわかった時の新鮮な状態で教えて。なんで朝会待つの?? だいたい「ちょっと遅れそう」はずるずる行くんだし・・。 進捗は

    朝会で進捗共有はやらない - ゆるふわカウンターアタック
    takatama
    takatama 2016/04/21
    朝会で「できるようになったこと」を共有してみたらいい感じだった
  • ドラクエ風スキルマップ - nemorineのブログ

    あるとき突然『チームのキーマンが抜ける』というイベントが発生しました! まあ会社という組織ではよくありますよね(苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ~ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ!! 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に

    ドラクエ風スキルマップ - nemorineのブログ
    takatama
    takatama 2016/02/19
    わいわいできるのがいいなー
  • ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ

    マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた1つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは? 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ

    ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
  • 1